Sunday, 6 April 2014

Arduino and the Si570

I've been wanting to experiment with replacing my little AD9850 DDS modules with the Si570 device. Not out of any sense of dissatisfaction with the former - more out of a spirit of adventure and in preparation for future experiments with extended bandwidth. The big problem with the Si570 - apart from cost - is the package.

I decided to solve the problem by mounting the awkward package on one of my little plug in modules, which start with a small printed circuit board...

Here are a few of the "carrier" PCBs, knocked up yesterday in my "back yard fab", along with an Si570



I got out my little USB microscope and did the best I could with my soldering iron, failing eyesight and shaking hands- here's a close-up shot from the microscope part-way through assembly...


Once the chip was on the carrier, I added some header pins to serve as "legs" for the module, which acts as an 8 pin DIL "wide" (i.e. 0.6 inch) package, which is infinitely easier for me to handle (and, indeed, see) than the original bare device...


Now - I just need to program the thing.

I have driven an Si570 before from a PIC (in my original multi-mode beacon) - that was a pretty brute-force piece of coding. This time I wanted something a little more elegant, so I looked around on the 'net.

The first fruit of that search was the ArduinoSi570 Library , by Gabriel Fournier.

I downloaded that library, but could not get it to compile, either with the provided example sketch or with my own simplified examples. Gabriel quickly and graciously answered an email asking for help - but his suggestion was that I should find another library! So I searched some more...

Fortunately, that search soon reminded me of Farhan's new Minima transceiver, and I found the "Radiono" code for it, which includes library resources for controlling the Si570. I downloaded that library and soon had modified the code (which is intended for the ATmega328P) to run on an Arduino MEGA, which allowed me to confirm that my new Si570 module was working correctly...


My real interest was in getting the new Si570 module running under the control of the Arduino DUE and - I'm ashamed to say - I still haven't succeeded in that goal.

My modified program now compiles and I can see the I2C activity between the DUE and the Si570, but they are not yet successfully communicating.

You can see how much I'm struggling by the presence of an empty coffee cup in the frame below - things are obviously bad...


I guess it won't be long before we have Si570-derived RF for the Arduino SDR - but not today!

...-.- de m0xpd

Sunday, 30 March 2014

SDR Front End

Work on developing the Arduino SDR continues with the rationalization of the front end into a plug-in module...


This little unit combines the quadrature clock generator section of my DDS shield, as implemented on a brace of 7474's and the switching Tayloe mixer, built around the 74CBT3253. These surface mount goodies, which add up to the same kind of front end seen on "Softrock"-type SDR systems, are mounted on a little PCB about 3 * 5 cm...


The new board makes it easy to build up the front end of a software defined radio using "building bricks" plugged into a solderless breadboard, as in the case below, which includes one of my standard plug-in 40m bandpass filters, a DDS module for clock generation and the new board...


I'm taking this path away from the DDS Shield used previously, in preparation for some experiments with the Si570 - which will be required to get the x4 clock rates required to achieve coverage of higher HF bands.

Here's the entire Arduino SDR receiver with the new front-end module...


Cleaning up the layout (with the new module) seems to have brought about an attendant clean up of the noise performance of the receiver - but that's just a subjective impression and may be no more than wishful thinking!

...-.- de m0xpd 

Sunday, 23 March 2014

PSK31 on the BITx

Changes being (reputedly) as good as rests, I decided to try working some PSK31 on my multi-band BITx...

I have just acquired an iPad Mini (with which I am delighted) and I stumbled across the PSKer app on the iTunes App Store...


I am not famous for buying things - but I decided that £1.99 was a fair price to pay, so I went ahead and installed it on my new iPad.



There are a few descriptions on the 'net concerning methods to make direct electrical connections to the iPad to use with PSKer - but I decided to use an "acoustic" interface for this first test, so I positioned the rig's speakers near the iPad and confirmed I could decode the signal detected by the internal microphone...


Transmitting was slightly more tricky - I needed to hold my little h/b "fist" mic near the iPad's speakers and press the PTT button, then press the correct little soft button on the iPad's touch screen...


Tricky or not - IT WORKS! I was soon able to work PSK31 on 40m...

I had my first QSO with Pavel, ok1aw, who sent an email in confirmation...


Then I was pleased to work Paul, gw0tau, in Swansea.

This was such fun that I might just make up a set of interface cables to work some more PSK31 on the BITx - but perhaps I'll opt for the comfort and convenience of DigPan on the desktop PC next time.

For now, I'm going to work a few more stations from the iPad.

...-.- de m0xpd

Wednesday, 12 March 2014

Flying a Kite for TX Factor

I was listening to Roger, g4roj(/p), working SSB on 40m on Saturday from a full-wave vertical kite antenna above a field somewhere in the midlands on my Arduino Due Software Defined Radio.

Roger's signals were so strong that I had to put an attenuator in front of the system on his overs to avoid overwhelming my analog-to-digital converters! The attenuator could be switched out for 95% of the stations Roger was chatting to - showing just how strong his signals were.

On Sunday, I had a quick blast on my BITX rig, working some CW and then some SSB. I heard Roger again, so had a quick QSO with him. I described how I'd heard him telling other contacts throughout the weekend that he was preparing for a meeting with the guys from TX Factor - the new UK internet TV show about amateur radio. g4roj and his famous (and - evidently - effective) kites are going to be filmed for a forthcoming episode.

With this sense of  "personal connection" arising from my QSO with g4roj, I took a look at TX Factor Episode 1 today...


I am impressed - production is at a very high, professional standard. The presenters do a great job of putting across the content in a way which is interesting, informative and - in the best sense - entertaining.

I have enjoyed other Amateur Radio "TV" shows - especially AmateurLogic TV. It is great to see something of similar, very high standard emerging from the UK scene.

Apparently, episode 2 includes a visit to dear old BP - and I look forward to seeing Roger's kites in some future episode.

Congratulations and Best Wishes to all at TX Factor,


...-.- de m0xpd

Sunday, 9 March 2014

DDS and DueDDS Libraries

Here are a pair of libraries to ease the interface of an AD9850 Direct Digital Synthesis Module to an Arduino.


The first library, DDS, uses soft SPI to allow any Arduino to control a DDS Module. It is suitable for use with the Kanga / m0xpd DDS Shield.

The second library, DueDDS, uses the enhanced features of Arduino DUE and hardware SPI to achieve a faster interface to a DDS Module. I've been using the DueDDS library in my experiments with Software Defined Radio on the DUE.

To use any library, you need to have a description of the resources that library offers - this description is called the Application Programming Interface - or API...

API 

The two DDS libraries share very similar APIs, differing only in how the resulting DDS classes are instantiated...

DDS is instantiated by...


where the arguments identify four Arduino pins which connect to the Module.

DueDDS is instantiated by...


where the first two arguments identify two Arduino DUE pins which connect to the Module and the third nominates an (unused) "Slave Select" output from the Arduino DUE.

In both cases above (and in the following examples), the resulting instance is called "dds" - but you can call it anything you like. After instantiation, the APIs are identical...

The DDS Module is initialised by the line:


and the frequency of the oscillator is set by this command:


That's all you need to use the Module - three lines - instantiate, initialise and set. Of course, you can change the oscillator frequency by calling setFrequency() as many times as you like!

I've been completely satisfied by the accuracy of the DDS Modules straight "out of the box" for my simple Ham Radio applications. Perhaps I'm easily pleased! But some people like to have oscillators set to the last part-per-million of precision. Others may have DDS Modules with a non-standard clock (the default is 125MHz).

For these demanding applications, the libraries offer one more command, which allows you to "set the clock" of the DDS:


So - if you find that your Module's clock actually runs at 125000017 Hz and you care about it, you would enter '< name>.trim(125000017);', where < name> is the name of your instance of the DDS or DueDDS class.

After the .trim() command, all responses to subsequent setFrequency() commands will reflect the trimming. The trim value is held in volatile memory, so the trim command needs to be applied every time the module is powered up.

Now you've seen how the software works - how do you connect the module to your Arduino?

Connecting the Module 

The AD9850 DDS Module can run with any Arduino under the DDS library. The required connections are shown here:


You must nominate four IO pins as shown above (these are used as the arguments when you create the instance using  DDS < name>(pin1, pin2,...) ). Make sure that your list of arguments is in the correct order!

The AD9850 DDS Module can be controlled more quickly with an Arduino DUE under the DueDDS library. The required connections are shown here:


Two of the Module's pins are connected to pins on the SPI header of the DUE (which is in the same position as the ICSP header on other Arduinos). The other two lines from the DDS Module are connected to two Arduino IO pins, which you must nominate during instantiation. You must also choose one of the hardware "Slave Select" pins (one of 4, 10, or 52). This pin won't be used in our interface - but it can't be used for anything else!

The important pins on the DUE are shown below...

Note that, whilst there is a useful ground connection on the SPI header, the "Vcc" pin is at 5 Volts. Remember we must power the DDS module by 3.3 Volts in this application!

Download and Use of the Libraries

To download the library, visit the GitHub repository and press the "Download ZIP" button on the right of the screen...


Once you've downloaded the ZIP archive, you must de-compress it amd the change the name of the resulting folder to either DDS or DueDDS, depending upon which library you've downloaded.

Then you must put this folder in your Arduino/libraries folder.

Before you can use the library for the first time you must close and re-start the Arduino IDE.

You will be able to confirm that the library is correctly installed, as it will be in the list which appears in the Arduino IDE if you click on 'Sketch' and hover over 'Import Library...'



Examples Using the Libraries

Within each library, you'll find an examples folder. In this folder is a really simple application, "oneMHz", which sets up the DDS Module to produce a 1MHz output. These examples exercise all the functions available in the libraries - so they'll teach you all you need to know!

This is the first time I've written an Arduino library - so I'd love to hear about anybody's experiences with these resources - good or bad.

Enjoy!

...-.- de m0xpd

Saturday, 8 March 2014

Arduino Due and the DDS

The SDR receiver is now running completely on the Arduino DUE...


Previously, I had only the DSP functions on the Due, whilst the VFO and user interface were managed on an Arduino Mega. Now, all these support functions have migrated to the Due.

When I say "migrated", I did have to give them a push - and the most interesting part of that push was the work required to move the DDS. So this post describes controlling an AD9850 DDS module from the Due.

The first point of resistance to be overcome in moving the DDS to its new Due host concerns the operating voltage. Most Arduinos run with 5V supply and logic - but the Due operates at 3.3 Volts. Fortunately, this isn't as hard to deal with as it sounds.

The DDS module will run on 3V3 - indeed it may prefer to run at 3V3 - indeed some samples of the module may ONLY safely run at 3V3 (because of the oscillator module). So switching to 3V3 operation is a blessing rather than a curse.

The next issue is the clock divider chain, required to derive the quadrature VFO square wave signals for the Tayloe mixer from the original clock (at four times the frequency of the VFO). Again, this turns out to be a walk in the park, as the 74AC74 flip flops I used run happily on 3V3.

With all the physical issues like voltage out of the way, the next thing to do was to look at the code. Here again, things turned out to be easy - in fact an opportunity presented itself which works out very much to our advantage...

Let's remind ourselves of the interface between the DDS module and its controller...


The DDS module has four control lines. Of these, two form a conventional serial interface (with a clock and data line). Their functionality can be replaced by the set of 8 parallel data lines - but we're not using these. The other two of the four lines mentioned are what we might call "chip control" lines; a reset and a latching input. Notice here that there is no overall "Chip select" line.

My original experiments with the DDS module were conducted last year in the context of Raspberry Pi. I copied Ron, nr8o's original code...


Ron achieves the required pulse on the FQ_UD line using his function 'pulseHigh()' and manages the serial data exchange by "bit-banging" in C in his 'tfr-byte()' function...


When I came to use the DDS module in my Arduino projects, I replaced the 'tfr_byte()' function with the Arduino equivalent...


There was nothing clever about this (in fact, I'm confident it will be slower than Ron's approach). However, I wanted to keep the code as simple and readable and Arduino as possible to ensure widest access for all including, dear reader, you!

The Arduino reference describes the shiftOut() function as "soft SPI". SPI is an abbreviation of Serial Peripheral Interface, a loosely-defined standard for interconnections between digital devices. In addition to the soft implementation, Arduino also supports hardware SPI which, in the case of the Due, offers some enhanced functionality. It also has the attraction of speed.

Remember that in the present application, the Arduino Due is working its socks off to sustain the DSP task central to software defined radio. I can't afford to have the processor spend time on mundane tasks like controlling the DDS - so I decided to investigate the benefits of interface to the DDS module using hardware SPI.

Here's how my sendFrequency() function looks with the SPI interface...


Not significantly different from before; the shiftOut() function is now replaced by the SPI.transfer() call. Notice that I still manage the FQ_UD line using the same techniques as before - this is not a part of the SPI protocol, as neither is the RESET line.

To set up for the hard SPI interface in software requires only a little work ...


whilst the hardware setup is simpler yet; the DATA line on the DDS module is connected to MOSI (Master Out Slave In), and the W_CLOCK line on the DDS module is connected to SCK. MOSI and SCK are found on the ICSP header of the Due.

So - was it worth it?

The "soft SPI" interface between Due and the DDS took 250 microseconds for one frequency change operation. The new "hard SPI" interface achieves the same result in 9 microseconds. Not a bad saving for no cost (other than writing a few lines of code and plugging two wires into different sockets)! In fact, the "traditional" management of the pulse on the FQ_UD line is now probably limiting the speed of the hard SPI transfer - but more on that later.

Whilst the most interesting part of pushing the functionality over to the Due surrounded the DDS, porting the user interface formed by display and tuning was more of a chore - and still requires more work...

The Due has more IO pins than anyone brought up on an Arduino Due (or an RPi) could ever wish for - so I abandoned the I2C interface used previously for the display and reverted to the conventional (nibble-wide) parallel "Hitachi" interface. This is represented in Arduino by the standard 'LiquidCrystal' library and in hardware - in the present instance - by one of the little 2*16 units I picked up in Shenzhen...


The display looks great in real life - but the flash hasn't done it any favours in the photo above. Notice that I've used the same interface board developed for the original Arduino VFO, as this carries the required rotary encoder to tune the system. This is the place I need to do some work - the software supporting the rotary encoder isn't working nearly as sweetly as I'd like on the Due. I'm sure the fix will be easy but tedious!

The entire system now looks like this...


What you see (compared to last time) is a missing Arduino Mega at stage right. What you see instead in the foreground is an early prototype of the Kanga/m0xpd DDS shield (seen "upside down").

The shield is being run on 3.3 Volts (from the Due) and the DDS module (hiding from the camera on the other side of the shield) is receiving its control signals down the colourful ribbon cable. The Tayloe mixer (realised on a 74BCT3253) is still running with a 5V supply, but is happily accepting the 3V3 quadrature clocks from the DDS shield.

Everything is working as intended - apart from the clunky rotary encoder response, which I'll sort out today.

I've put together a new library to make it easy for you to run a DDS module via hard SPI - I'll be publishing that shortly - watch this space!

...-.- de m0xpd

Sunday, 2 March 2014

Arduino SDR II

Last week's fun and games with an Arduino Software-Defined Receiver were just initial feasibility studies - stretching exercises before the competition began. Here's the real deal...


Sure, it looks the same. But things have changed - significantly.

Last week's system was a direct implementation of a conventional superhet receiver - only with everything from IF to AF output implemented in DSP on the Arduino DUE

Superhets are great - but they have a known problem - the "image frequency". The image frequency is that point on the spectrum twice the BFO frequency away from the frequency to which we intend to tune the radio. If there happens to be a strong station at the image frequency it will mask anything at the intended frequency - it is, in effect, a noise source. Usually, in modern receivers, the BFO will be at a few MHz and the image is a long way out-of-band. Its influence can be avoided by filtering.

However, software-defined-radios have a very low BFO frequency - in the kHz range. This means that the image is in band and entirely audible. It is so close to the intended frequency that conventional filtering cannot block it. Something fancy needs to be done...

My new SDR implementaton may look similar to the old one on the bench - but a close-up reveals a different front-end...


Now, instead of using one of the sine wave outputs from the Kanga/m0xpd DDS Shield sitting on top of the Arduino MEGA at stage right, I'm using the pair of quadrature square waves. Despite the tuning indicated on the LCD, these square waves are at a frequency of four times that of the conventional VFO. The addition of IF offset and the four times multiplication is achieved in the controlling MEGA with some trivial changes to the standard VFO code you've seen so many times before.

The square waves make their way down the plaited wires to a 74CBT3253 multiplexer, running as a Tayloe detector, which you've seen before. This mixes the RF from the antenna, after it passes the same 40m bandpass used last week, to produce TWO intermediate frequency signals which are in quadrature relationship (meaning that one is 90 degrees of phase away from the other). This is important - it gives us some extra information about the one incoming RF signal, which will allow us (in software) to discriminate between upper and lower sidebands. The intended and image frequencies are - in one sense - the "upper and lower sidebands" and this ability to discriminate between them will allow us to reject the image from our receiver's output.

The two IF signals pass through amplification and filtering which must be as closely matched as possible - we want our two IFs to differ ONLY in phase and any difference in the front end responses would spoil this. The IF processing happens in the same TL074 quad op-amp as was used last week - but (since we have two IF signals) the circuit has changed considerably.

There is now 40 dB of gain in a first stage and the anti-aliasing filter has now been reduced to 3rd order (as it is only implemented in one stage) PLUS it provides a further 40 dB of gain.

The in-phase ("I") and quadrature ("Q") IF signals are sampled by two inputs to the Adruino DUE's analog multiplexer. I am using the analog to digital converter of the Arduino in standard gain setting, so I need analog input signals of order Volts - that's why I needed the 80 dB of gain.

Once inside the Arduino, the signals are filtered by the intended RF response (a bandpass, with bandwidth appropriate to the mode and centre frequency above or below the BFO, as appropriate to the sideband). The filters for each channel have the same magnitude response, but one is "shifted" by the "Hilbert Transform" response, which advances the phase by 90 degrees for positive frequencies and retards it by 90 degrees for negative frequencies (if the idea of "negative frequency" is new to you don't worry - it is part of the baggage of Digital Signal Processing). All this fancy filter design is achieved inside the Arduino.

Adding the two filtered IF signals  rejects the image frequency (subtracting one from the other would keep the image and reject the "intended frequency"). This is the method employed in a "phasing receiver" - only I'm using it just for image rejection - a phasing receiver might use it to select between LSB and USB mode (which my new SDR receiver is still doing using the conventional method).

All this processing is done in the frequency domain, with 1024-point FFTs, so a further inverse Fourier Transform is required to get back to the time domain - still at IF.

Mixing down to baseband is then implemented in the usual way - with upper or lower sideband selected by the design of our IF filter relative to the "BFO".

It works - boy, does it work!

Along the way, I'm ashamed to tell you that I killed an innocent 74CBT3253. It was mounted on one of my SOIC Carriers, like this one...


(the photo above is of a different chip - a digital potentiometer).

Fortunately I had some spares - not just of the 74CBT3253 (thanks Dennis) but also of my carrier PCB. Unfortunately, my eyesight has been defective since birth and is deteriorating as I mature! But I'd seen how the big boys do hand re-working of invisible surface mount components under fancy microscopes costing thousands of pounds. So...

A few weeks back, I got a USB microscope for pennies (well, a thousand and some pennies) on eBay. Here it is, set up to solder the new 74CBT3253 onto the carrier PCB...


I hold the PCB down with a couple of blobs of BluTack - but the chip itself is pretty much invisible in the photo above - which is just what I (don't) see when sat at the bench. However, if I look up, I see all the action in close-up on the screen - here's the chip during soldering...


Brilliant ! Even I can see that! If you have to play with SMD components and have less-than-perfect vision, get yourself a cheap USB microscope - they work a treat!

Over the next few weeks, I shall be moving the VFO and its user interface from the MEGA onto the DUE, using the few spare cycles the DUE has in between its hefty DSP tasks. I know it will fit - but if it doesn't, I've already got the core code running on an STM32F407 device which clocks at twice the speed of the SAM3X on the DUE and is a fancier processor (an AMR M4 rather than an M3), so if things get too tight I have a fall-back position.

I'll also be thinking about generating rather than just consuming RF - this is going to be a transceiver!

...-.- de m0xpd