Does this project spark your interest?

Become a member to follow this project and don't miss any updates


level: A New Kind of Radio Module

An agile radio designed for low power and narrow bandwidths over a wide frequency range.

Similar projects worth following
A cheap, flexible, and agile radio module designed for low power, low bandwidth applications. Towards that, it has a frequency range of 30 MHz to 4.4 GHz and 812 kHz of bandwidth, perfect for long range wireless sensors. It runs at 3.3V and only draws 63 mA at its maximum output of 16 dBm. The shape may look familiar, but this board is actually NOT an Arduino shield. Instead, it's designed to accept Arduino shields. For example, plugging it into a Bluetooth shield will let you build a wireless bridge between whatever frequency you're using on the Level and any Bluetooth compatible device. The Level was originally designed for experimenting in TV Whitespace, which is awesome because it's free, unlicensed, prime spectrum that cell phone companies normally pay billions for. And of course, it's 100% open source.

In addition to the wireless module, I started working on infrastructure to support a network of devices. I'm using a USRP to coordinate a group of these things and respond in real time to changes in the spectral environment. This is really important in TV Whitespace, because wireless microphones are also in that band and need to be avoided when sensed. Cognitive radio in general is a neat and highly active research topic, so it's good for other applications too. 

Here's the schematic, which could be considered a system design document, but a higher level look at things can be seen in this paper I wrote.

Level is distributed under the MIT license. This means that you can share and adapt the work, but you must attribute the work to the original author.

To save time, I've also been using SimpliciTI as a mesh networking stack. It's open source, but not as free-as-in-speech as I'd like, so I plan on moving away from it. Until then, all SimpliciTI code is distributed under TI's license agreement, which can be found in the github repo which is linked over to the left.

There is also some experimental code for talking with SimpliciTI and doing other whitespace things with a USRP in gnuradio. That's in the Cognitive Basestation repo linked to the left. 

  • 1 × CC430F5137 Application Specific ICs / Telecom ICs
  • 1 × ADF4351 Wideband frequency synthesizer
  • 1 × ADEX-10L Passive mixer
  • 2 × PSA4-5043+ LNA
  • 12 × 10 pF capacitor
  • 14 × 0.1 uF capacitor
  • 2 × 27 pF capacitor
  • 1 × 0.0022 uF capacitor
  • 17 × 100 nF capacitor
  • 4 × 2 pF capacitor

View all 55 components

  • Demo, schematic port, and HAL

    Hunter Scott09/29/2014 at 02:50 0 comments

    I finished the 5 minute video required for the contest semifinals. It goes over some of the recent progress I've made and shows a quick demo.

    Like I said in the video, the schematic port from Altuim to KiCAD is done. I've also got most of the Hardware Abstraction Layer (HAL) done as defined the a previous project log. I've been using a USRP to see what's going on in the frequency domain since I don't have two of these boards assembled yet, and because I don't have a spectrum analyzer. As usual, all the latest changes are up on Github.

  • Making level easy to use

    Hunter Scott09/21/2014 at 04:17 0 comments

    Usability is a big part of engineering design. I want new users to be able to start playing with level as quickly as possible. The first way I'm accomplishing that is by enabling the use of Arduino shield libraries with level. As you know, level is not an Arduino shield, but it accepts shields in order to create bridges between whatever wireless experiments you're doing with level and a common standard like Bluetooth or WiFi or whatever other kind of interface you want. The libraries for these shields already exist, so this is a great way to leverage other work and not have to reinvent the wheel. I'm still developing this feature, but the end result will hopefully make it much easier for people to create new thing with level.

    The second way I'm making things easier is by implementing an API/HAL for high level functionality. This way, you won't have to worry about setting a bunch of registers and bitmasks. Here's the functionality I have sketched out so far:

    set_datarate(float) - Sets the datarate of the CC430. Returns 1 if the datarate is outside of what the CC430 can provide. 

    set_frequency(float) - Sets the transmit and receive frequency. Returns 1 if the frequency is out of bounds. Functionally, this programs the VCO. It may be possible to have separate transmit and receive frequencies, but I'm not sure how long the PLLs take to settle, so for now the HAL will only support a single transmit and receive frequency.

    set_power(int) - Sets the transmit power. Returns 1 if out of bounds.

    set_mode(string) - Takes in either "tx" or "rx" and puts the device into either transmit or receive mode. Returns 1 if not "tx" or "rx". Functionally, this controls the RF switches.

    get_status(void) - Returns a struct of various status information. 

    get_device_id(void) - Returns device ID. Useful for simple testing.

    set_message(char *buf, int length) - Takes in a pointer to a byte array and a length. The buffer is loaded into a FIFO for transmitting. If the buffer is larger than the FIFO, the FIFO is filled and transmitting automatically starts. This process repeats until the FIFO is loaded with the last chunk of data.

    transmit_now(void) - This should always be called immediately after set_message(). This will force the transmit FIFO to empty by transmitting, which will send any fractional buffers still in the FIFO that did not fill it completely. 

    get_message() - Returns a pointer to a byte array that is the size of the receive FIFO. This array contains demodulated data from the CC430. It's up to the user to loop on this function until the end of message identifier is hit.

    set_modulation(string) - Takes in "FSK", "GFSK", "MSK", "OOK", or "ASK". Sets the modulation used by the CC430.

    This is all subject to change of course, but it's what I'm working on implementing now. This will first be implemented in C for use in programming the CC430 itself. I'd also like to implement a version of this for use over the SPI bus, so level can be commanded from another device.

  • Enclosure/Productized Design

    Hunter Scott09/19/2014 at 05:42 0 comments

    I threw together some quick drawings of what the final product may look like. This is my "artists representation". I tried to make design choices that made sense and that kept the design manufacturable. So here's what I came up with:

    A couple things to note: not all the parts in these drawings are exactly to scale yet, and the exact dimensions will change based on the layout in the next iteration. The basic design is two parts that fit over the PCB, held together by 4 screws. There are several purposes this enclosure serves:

    1) Protection against the elements and ESD damage from casual handling of the board.

    2) Thermal relief for the circuit, since the entire enclosure is manufactured from aluminum and acts like a heat sink. This design should be able to be die cast, which will make it more manufacturable. Ideally this would be 7000 Aluminum, but I'm not sure if that's capable of being die cast.

    3) Shielding for spurious radiation and interference from outside

    4) Shielding for spurious radiation and interference from inside (caused by the circuit itself). Both 3) and 4) are very important in passing FCC emissions testing, so I'm hoping this (along with certain layout techniques) will keep this design FCC Part 15 compliant.

    5) Shielding for self-interference. The raised channels on the inside of the first drawing will make direct contact with trace fences on the PCB. This effectively creates a tiny shield around each section of the circuit. This is important because this design uses heterodyning to generate frequencies, so there will be multiple copies of signals at different bands and amplitudes, plus harmonics, all very close to each other. Fencing in the CC430, ADF4351, mixer, and front end will prevent crosstalk and reduce noise and harmonics on adjacent traces.

    I didn't want to design an enclosure that kept the user out though, so all you have to do is remove 4 screws and you can probe or modify the PCB however you want. I didn't include it in the rendering, but to help make this design more understandable, there will be silkscreened labels on the top of the enclosure beside the pins to identify each pin number and function.

    Once I get the next revision done, I'll get a prototype of this 3D printed in at least plastic, maybe metal. I may also play with the aesthetics a little and try to use depth more. I don't want to design anything that can't be achieved with die casting, but I think there are still some things I can get away with. 

    While I'm on the subject of productization, one of the often overlooked problems with getting an electronic product to market is FCC certification. Part 15 says that a device can't cause interference and must accept any interference it encounters. There are lots of good design practices used to help meet this certification. For example, having lots of easy paths to ground prevents stray inductance from occurring. That's why there are so many vias on the board:

    I don't know if this will pass EMC testing, but I'm keeping it in mind and I'm hoping the combination of good layout techniques and the enclosure will make passing it easier.

  • Towards a more open level

    Hunter Scott09/14/2014 at 23:55 0 comments

    Today I made a few changes that make level more open than before. First, I added support to building with msp430-gcc in addition to Code Composer Studio. That means that a lot of the supporting libraries and code that was under TI's license is now under the BSD and GPLv2 licenses. 

    The other thing I did was change the license of my code from Creative Commons to the MIT license. The MIT license is simpler and less restrictive. There's also good news for SimpliciTI: I found a guy who ported it to GNU C. That may be an avenue towards a more open MAC without writing one myself.

    The last thing that I'm doing (currently in progress) is drawing the next hardware revision in KiCAD instead of Altium. Altium is closed source and costs money, so doubly bad. KiCAD is maturing pretty quickly now that CERN is developing it and this will be my first major design using KiCAD. The HackRF One by Michael Ossmann is another example of an RF board that was designed and layed out in KiCAD, so that improves my confidence in the ability of KiCAD to work well enough.

  • Overview and other things

    Hunter Scott08/17/2014 at 21:16 0 comments

    Here's my overview video:

    I only had 2 minutes, so it skips a lot of details. Here's a schematic walkthrough that goes into a little more detail:

    I also wanted to address one other thing that no one has brought up yet, but I imagine may cause some confusion. I've said that this board can do 30 MHz to 4.4 GHz, but it's also narrowband. What I mean by that is the frequency synthesizer, CC430, and mixer can achieve that range (using the new mixer), but the instantaneous bandwidth is only 812 kHz. The current design has filtering for UHF. So to change the frequency to a different band (like S band), different filter values need to be used. In a real software defined radio, this would be done digitally in an FPGA. I want to change the filtering in the next version, but I haven't decided how to do it yet. Maybe an Igloo Nano or a small discrete filter bank or something. I don't want to just replicate a HackRF or Myriad RF or BladeRF or USRP, I want to make a lower performance, lower cost, and lower power radio module. 

  • Previous versions

    Hunter Scott07/26/2014 at 02:56 0 comments

    This board wasn't created in a vacuum, and it wasn't created all at once. This is the 4th spin of the board, actually, and most of the previous versions used entirely different architectures and parts. Here's the first version:

    It's old! It also didn't work at all.

    Version 2: 

    This one was better, but it had seperate TX and RX paths, so needed 2 antennas.

    Version 3:

    Getting closer. A bunch more changes, and this is basically the current version, minus a few tweaks and fixes. 

    This is/was the first RF board I've ever done, so I'm learning as I go!

  • Protocol stack for mesh network

    Hunter Scott07/20/2014 at 19:21 0 comments

    I forgot to mention this before, but I've been experimenting with TI's SimpliciTi mesh networking protocol for talking between devices. I like it because it's open source and designed for applications like Level. Another protocol I was looking at was BATMAN (Better Approach To Mobiel Ad-hoc Networking), which is a robust, fast protocol for P2P networks. I have an implementation for a network simulator I got from the researchers who published the paper on it, but I haven't implemented it on a real device yet. There's another implementation here (along with some other mesh networking protocols) that may be good to play with. 

    I also have some code written in GNU Radio for the USRP that can communicate with stock CCxx devices using the basic packet structure of SimpliciTi. It's still a little buggy, but I've gotten it to work. You can find it here:

    I don't have access to a signal or spectrum analyzer anymore, so it's difficult for me to debug some stuff. I want to pick up a Tek 492 with options 1, 2, and 3, so if you've got one you want to sell for cheap, let me know!

  • Antennas

    Hunter Scott06/25/2014 at 01:40 0 comments

    Experimented with some antennas.

    These were designed in HFSS and are targeted for the UHF band. Here are some simulations for the spiral antenna:

View all 8 project logs

  • 1

    It is possible to hand assemble Level. I know this because I did it twice. It just takes a lot of time and a hot air iron. The discretes are 0402, so a microscope is nice too. The easier way is to reflow it, which I prefer. 

    Building the software requires TI's Code Composer. It can also be built with GCC if you prefer a more open alternative.

View all instructions

Enjoy this project?



bruno.carvalho1505 wrote 10/19/2015 at 16:40 point

can i use this radiofrequency module on a raspberry pi?

  Are you sure? yes | no

kryptyk wrote 08/29/2014 at 21:34 point
btw, have you looked at HSMM for mesh networking? it's quickly becoming the de facto backbone of the 'ham radio internet'.

  Are you sure? yes | no

kryptyk wrote 08/29/2014 at 21:01 point
nice! i've been looking for a broadband UHF device for ham radio data applications. thanks dude! nice work!

  Are you sure? yes | no

Jasmine Brackett wrote 08/15/2014 at 23:44 point
Hello Hunter Scott, please review your project documentation to ensure it has everything we require for it to be considered for the next round of The Hackaday Prize.

By August 20th you must have the following info on your project page:
- A video. It should be less than 2 minutes long describing your project. Put it on YouTube (or Youku), and add a link to it on your project page. This is done by editing your project (edit link is at the top of your project page) and adding it as an "External Link"
- At least 4 Project Logs
- A system design document. Please highlight it in the project details so we can find it easily.
- Links to code repositories, and remember to mention any licenses or permissions needed for your project. For example, if you are using software libraries you need to document that information in the details.

You should also try to highlight how your project is 'Connected' and 'Open' in the details and video.

There are a couple of tutorial video's with more info here:

Good luck!

  Are you sure? yes | no

Hunter Scott wrote 08/17/2014 at 22:23 point
Thanks, everything should be ready to go now!

  Are you sure? yes | no

Daniil wrote 07/26/2014 at 07:09 point
Heterodyning generates 2 frequencies, one at the sum of the frequecnies and one at the difference. Are you doing any filtering at all to make sure the frequency you're not using doesn't end up in someone's paid part of the spectrum?

  Are you sure? yes | no

Hunter Scott wrote 07/26/2014 at 14:04 point
Yes, there is filtering. Right now, it's a bandpass for mid-UHF. There's an ISM band at 433 MHz, and TV Whitespace is right above that. It's the responsibility of the user to make sure they're not transmitting on top of someone else, just like it is when you use an SDR like a USRP or HackRF. You can use the FCC provided spectrum database to make sure you aren't interfering with anyone:

In the future, I'd like to add a filter bank or something, since right now once you get up higher frequencies, you need to change some discretes.

  Are you sure? yes | no

DainBramage wrote 10/31/2014 at 15:09 point
Careful here. According to the FCC, the TV broadcast band begins at 512 MHz, which is a lot more than right above 433 MHz. There is a TV allocation from 470 to 512 MHz, but it isn't whitespace as it is shared spectrum. Below that you will find a number of different allocations including land-mobile, amateur, and meteorological satellite.

  Are you sure? yes | no

Charlie Fullerton wrote 07/16/2014 at 12:17 point
How do you control the Freqs so you can stay legal for the privileges you have?

  Are you sure? yes | no

Hunter Scott wrote 07/16/2014 at 13:53 point
This thing is heterodyning, so the CC430 puts out about 900 MHz which is mixed with whatever is coming out of the frequency synthesizer to produce the transmit frequency. So you write to the frequency synthesizer (the ADF4351) over SPI from the CC430 to tune to the frequency that, when mixed with 900 MHz, gives you the transmit frequency you want. It's up to the person writing the firmware to make sure they stay within the band their allotted. In the case of Whitespace, this module gets commanded to certain frequencies by the base station. The base station knows which frequencies to use by checking the FCC database and scanning potential bands for incumbents. I'm not done implementing the whole Whitespace infrastructure, but that's where it's going.

  Are you sure? yes | no

Tiago wrote 07/06/2014 at 16:08 point
This is pretty amazing, I might build something based on this project sometime in the future, with a bit less arduino.

Thanks a lot for sharing :)

  Are you sure? yes | no

Adam Fabio wrote 06/25/2014 at 05:54 point
This is awesome on so many levels Hunter! Thanks for entering The Hackaday Prize! I love that Level can be used to bridge RF sensed by the CC430 to bluetooth, wifi, or anything one can find on an arduino shield. Keep the updates rolling in, and good luck on your way to Space!

  Are you sure? yes | no

Similar Projects