Hunter Scott •
09/29/2014 at 02:50 •
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.
Hunter Scott •
09/21/2014 at 04:17 •
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.
Hunter Scott •
09/19/2014 at 05:42 •
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.