SDR MK1.5 'Andrus'

The following material is licensed under Creative Commons Attribution-NonCommercial-ShareAlike (CC BY-NC-SA 3.0) license. Basically, you are free to remix, tweak, and build upon my work non-commercially, as long as you credit the original work properly and license your new creations under the identical terms. You have, to, however, ask my permission if you are planning to use the material or inherited works commercially.

November 15, 2011

After being in making for almost half a year, it is my pleasure to publish the SDR MK1.5 'Andrus' Software Defined Radio plans and schematic.

It takes a while to get the units on sale at eBay as I do have a backlog already for some of the prototype run, but they will appear in matter of weeks.

My desktop has been looking like a pictures below for a last several months. This is something what can perhaps be called a "functional prototype" for MK1.5 and has been a test platform for a new radio.

The board on a left is of course the SDR MK1 unit, what serves as a radio part of the fixture, still driven by its own 8-bit Atmega CPU (AT90USB1287). The large board in the middle is a 32-bit Atmel  AVR32 evaluation kit, EVK1101, what is accommodating a AT32UC3B0256 processor what is the brains on the MK1.5 board. The two are connected with a serial bus.

Connected to the EVK1101 evaluation board through the SPI interface is the 10Base Ethernet module by the Ekitszone on the far right, borrowed from one of the Arduino setups I have. It is there only to test the software, as it has the Microchip 10Base Ethernet chip ENC28J10 on-board. While the MK1.5 has also footprint to mount this board, it is too slow to be a useful interface for a radio (both, the SPI speed and Ethernet speed wise), but works as a proof-of-concept here. The much more suitable chip, KSZ8851SNL from Micrel, is used for the final design, providing 100Mbps network speed and sufficiently fast SPI connectivity of 40MHz clock rate.

The little plastic bag with coaxial cable is the CDCE913 clock synthesizer prototype. The coaxial cable from bag is going to a frequency counter on the table (HP5385A) and the synthesizer is operated through TWI (I2C, basically) interface. This is a new addition to the SDR radio now and allows the more precise sync between digital downconverters and output sample rate. (More of it below).

So - without further delays, here be schematic:

Black and white version can be found here

The schematic looks pretty much borrowed from the MK1 design, what it is to a large extent. However, the good and evil both live in details, so here is the comprehensive list of changes what have been made to the design! I have still tried to fit it on one page, as I like the opportunity to work with a single sheet myself whenever possible. If you print it on A4 (or Letter) format, the texts are still visible, but A3 format would suit much better.

One thing I have to apologize for is the annotation (the numbers "R12", "C34" etc.) of the schematic. I probably should have re-annotate it but didnt, so the annotation numbers are now pretty random when components were added and removed from schematic. (Not re-annotating actually saved a lot of work migrating the BOM (bill of material) from MK1 to MK1.5).

The following walk-through will hopefully help to understand the design concept behind the SDR and give some insights if you are hardcore DIY'er and want to build additional hardware what connects to SDR MK1.5 'Andrus'.

Starting from the RF section, the design is pretty straightforward from the National Semiconductor (NSC)  LM97593 datasheet. However, as there is still no reference design available for LM97593 and existing guidelines are suggesting a now-obsolete CLC5526 chip as its DVGA (Digital Variable Gain Amplifier it is) counterpart, I had to select more up to date chip LMH6514 which is not 100% the same but close enough to serve as a direct replacement (the only major difference being the gain, what is slightly higher for the LMH6514).

Addition to the design is the PIN diode limiter placed in the RF input section (check the excellent document on PIN diode limiters on Avago website for a reference), what is supposed to protect the radio from excessive voltage spikes of static. It is not saving from the direct hit of lightning-bolt of course, but deals with static residual discharges. The neon surge arresters are also still there and these will keep the worst happening to your computer and other rig (well, at least keep the arcing spreading around the board) should the lightning hit too close to antenna.

The low-pass filter section is standard Chebyshev lowpass filter and is exactly the same what has been used for MK1, so I will not repeat the in-depth details here. The headers JP6 and JP9 are new and not found on MK1 design. These are used for allowing the extension boards with filters, downconverters and whatever else to be added without the need for soldering on SDR board. Just remove the jumpers and plug in the board instead. The headers are with a standard 2.54mm pitch, so no hassle there (Yes, it will likely generate slight impedance weirdness on the signal path to the ADC converter having a jumper or connector on a way, but on a very subtle level, considering that the RF signal traces are only couple of cm-s long which is not even a small fraction to the maximum wavelength of the signals passing.).

On the RF section general, there is no much tricks on a schematic, but someone with a sick sense of humor at the NSC chip designing department has decided to put all the RF connections on a same side of the LM97593 DRC chip, so the routing of the board to comply with RF design paradigm is really challenging. I would like to see at some point how they did it on their reference design, but as there is none so far, I kept the same layout I used for MK1 and did not touch it.

(Disclaimer: If anyone designing anything commercially based on LM97593 and wants to copy the RF section layout of the chip from the MK1 or MK1.5, you are free to do so!)

One important differnce in RF section from MK1 design is power circuitry. DVGA chips are now powered directly from 5V bus and have additional ferrite beads close to chip to eliminate even the slightest noise entering through the power connections.

As you see, the DRC chip clock is not taken directly from the 64MHz generator any more, but is now provided by CDCE913 clock synthesizer. The reason for that takes a little explanation: 

If we select the output sample frequency of the audio part of the SDR radio, take, 192kHz, we shall ask the digital downconverter to provide that sample rate for us from the DRC chip as well. However, as the DRC chip does not have any PLL internally for its clock generation (well, at least not a programmable one), we end up with the sample rate which is divided from the DRC input clock directly. Closest we can get this way is 192.192Hz (divider 333). This effectively means, that we have to skip 192 samples every second to be in sync with our audio buffer, which will generate some serious signal artifacts.

Much better way around is to program the input clock for the DRC to be 63.936MHz, what divides nicely with 333 and does not generate any headache on the RF downconverter side either (well, the theoretical max frequency dropped from 32MHz to 31.968MHz, but it is still higher than the 31MHz we claim on SDR MK1.5 specs). (And as a side-note - in some reason the crystal and a DCS chip cost about the same as 64MHz 20ppm generator .. go figure.)

The two spare clock outputs Y2 and Y3 from the DCS chip are routed to the extension connector. They are not as useful as one may think on a first glance, since their output can only be the same or an even division from the main clock signal Y1 going to the DCS chip. But who knows, may be they will come handy for something some day.

The DRC chip is connected to a CPU using the serial bus. The parallel interface on MK1, wasting 18 CPU I/O pins, is now abandoned with the added value of getting the 24-bit bus instead of former 16-bit. This is where the SSC (Synchronous Serial Controller) inside AT32UC3B chip becomes really handy. With little tweaking, of the registers on both sides, that serial output of the DRC chip was possible to make compatible with SSC input of the CPU! This is a big thing, as therefore we shall not deal with individual bits, but get the data passed to us in words already. The main mode is to have both channels clocked out from AOUT pin on DRC (SSC interface does not allow multiple inputs to be used simultaneously, unfortunately (there is only one RX register set ...). The BOUT signal is, however, routed to the secondary SSC input pin (shared with LED) through optional 0-ohm resistor (not mounted by default). This creates a possibility to clock in the channel B signal at full speed of 820kHz if needed, but only if the AT32UC3B0512 CPU is used and indicator LED on board is rendered obsolete. In default, both channels are clocked out from AOUT pin, thus the maximum bandwidth will be about 400kHz if both, channels A and B are used simultaneously, and 820kHz if only channel A is in use (the bitrate of the SSC interface for AT32UC3B is not allowing to clock out both channels on 820kHz rate from the same pin).

Moving forward to CPU, then you see the already-mentioned 32-bit AT32UC3B chip doing all the bitwork. The design is initially using the AT32UC3B0256 chip, but it seems that the compatible AT32UC3B0512 is possible to get for the same price, so I think this is what we are going to use at the end of the day. There are some features what I have prepared for 0512 chip what were originally considered an extra options, like BOUT serial data mentioned earlier and audio out (0512 chip has internal audio codec!), so if there is no cost issue, they are nice to include from the beginning.

USB and power part for CPU are pretty much copied from EVK1101 reference design, but common mode chokes were added to the USB power and data signals. Once again, this is done to have a greater noise immunity and to prevent high frequency harmonics spreading around the board.

The signals connecting to CPU seem to be very random and messy at first glance (why the hell are data and address bus signals split into multiple groups, may one ask). Well, they are not! In fact, connecting the signals in this particular way has taken almost a week to lay out. Not saying its a perfect solution, but this was the best I could come up with. 

The rationale behind this is not as fuzzy as it seems. First, you have the already pre-determined signals for external interfaces. these are SPI (for ethernet), TWI (for extension board and DSS chip) and SSC (for DRC chip). Then you have signals, what you do not want to connect anything else permanently, as they are important to get the CPU operational (JTAG, HWBE  signal). And third, you have the pins what can be used for I/O, but would serve nicely for extension connector if you are not permanently using them for something else (Audio, UART). Then you have Ethernet interrupt, and apparently the only pin left now is the PA05, what is still free and can handle the interrupt. And then, after all this, you can fit the address and data lines to pins still left. Good that they both ended up even in two groups, rather than three or four! :)

There are some signals multiplexed with the address bus even now, like PWRDET and BTN1. This is OK, as address bus is used for outputting only, is low-speed and therefore connecting high-impedance sources there does not hinder the address bus ability to perform.

The extension connector is pretty straightforward and contains also the UART signals what I salvaged from the address and data buses :) This is a standard 3.3V level UART, so you will need a level converted to be able to connect to something requiring RS232 levels. Currently the UART and GPIO signals are not used by software, so you have to write your own software pieces to make them useful. I will probably write an API functions for firmware at some point, so one would be able to drive the signals from host software as well, if desired. 

Ah, and the UART signals layout match the FTDI TTL-232R-3V3 USB to 3.3V serial adapter cable pinout, whatever its good for.

The power section f the board is pretty self-explanatory. As we do not need anything above 3.3V for digital buses any more (old Atmega CPU did), we have it pretty straightforward. Just place inductors everywhere you can imagine, to get the crosstalk on digital and analog domain at minimum. 

This works in three ways: First, the noise can not enter back to the power source, if same source is shared between the analog and digital domain. Second, the power supply noise is not able to pass to the power bus and enter to the chip. And last but not least, as the power is passed through inductor, the noise generated by the actual consumption by the chip is not able to modulate the ground plane, but the fast power spikes needed by chip are taken from the small low ESR capacitors close to chip, therefore effectively limiting the noise spreading around the board (chip cant draw the fast spikes from the power source, as inductor acts as a filter on high frequencies, so the capacitor close to chip is the only way to get the fast spikes of power it needs).

And finally, the network!

As you see, there are two Ethernet chips present on schematic. The Microchip ENC28J10 is the one I have done all software development so far, and this is put on only for verification purposes, should there be any problems with the network. The production version is supposed to be only on the Micrel KSZ8851SNL which is a 100Mbit Ethernet chip with 40MHz SPI interface, so this will satisfy our speed considerations to be able to provide 820kHz bandwidth. 

The TE 6-6605851-1 RJ45 connector with  built-in magnetics is chosen to be PoE (Power over Ethernet) compatible. Therefore, if one wants to place the radio far away where the antenna is an have only single piece of shielded CAT5e cable going there, one can!

However, as you see, there is no PoE power supply on board. This is for a reason, that commercial PoE solutions are very expensive and consume lot of real-estate on board, not to mention that there are not that many SOHO routers at peoples homes what support commercial PoE. Also, most, if not all, device-side PoE modules are switching DC/DC converters, what will likely create loads of RF noise. 

On the other hand, there is no unified standard for "hobby PoE" besides that the power is given through RJ45 connector pins 4-5 and 7-8. Therefore, there is a PoE header on board and .. huh .. a prototyping area next to it. If one is brave enough to feed the electricity directly to its network cables, one must also exhibit skills to solder a 6volt linear regulator on board!

The power input is pretty seriously protected by forward diode, 6V clamping diode and self-recovering polymer fuse, so the SDR is not likely to suffer if you do anything awkward. (Not sure about other devices on your network tho ..) The regulator has to be 6volts and I would choose something with at least 1.5 amp range, as the radio can consume up to 650mA. Please use only linear regulators, as any switching circuitry will likely emit lots of RF noise. Also, be sure to use common-mode chokes on the power coming out of your regulator, as the SDR external power input does not have any (for the only reason that I had to delete it from schematic, since it did not fit anywhere on board!)

Guess, thats all for now! :)