Sunday 23 November 2014

Arduino SDR 3

When I was pulling together the "slides" for my recent talk on the Arduino Software-Defined-Radio at Rishworth, I realised just how long it had been since I had touched the code - or, indeed, any technical aspect of this interesting radio. I had, indeed, left undone what I ought to have done.


I decided this weekend it was time to make amends - I started by practicing what I have preached over the past few posts and added some 100nF capacitors on the tuning rotary encoder...


That trivial job done (and tuning duly improved -  although the SDR is not as good as my other rigs as the processor is groaning under a close-to 100% computational load), I went on to awaken a dormant "feature" of the code: the ability to implement variable receive bandwidth.

Early in my relationship with the Arduino DUE, I described experiments with variable bandwidth filter design. I used this same filter design routine - at IF - in my software-defined radio experiments. Previously, I never exercised the capability to interpret the edges of the bandpass filter in the radio as variables. Now, it was time to warm that feature up...

I had previously used an analog input on one of the ADC lines of the DUE to control the filter design algorithm - this was repeated in slightly modified form with the double (quadrature) inputs from the Tayloe detector...



My code reads the voltage developed on the bandwidth control potentiometer into a variable called POTO. If this does not change, the code doesn't respond. But if a change is observed, the new voltage is read and used to design upper and lower frequencies for a bandpass filter.

At the lowest setting, (POTO = 0) this will yield a VERY tight CW filter, centred on 600Hz. On the widest setting (POTO = 4096), this will yield a VERY wide SSB filter.

Here's the code that responds to the POTO values...


[No - I'm still not showing you FilterDesign( ) !!]

The rig is no longer "shackled" to a PC - but I can still connect a computer to the USB port for programming and diagnostic duties. That's why there are Serial.print( ) calls in the code segment above. Here's what happens when I adjust the new bandwidth control...

If we steal something like the "hairpin" crescendo / diminuendo idea from musical notation and rotate it through 90 degrees (see the red lines below), you can see what happens when I increase bandwidth from "normal" to "wide" SSB and back again...


Similarly, you can see what happens when I pull back to a really tight CW bandwidth...


All this is all very well - but what does it SOUND like?

Well - I know from the earlier "baseband" (that's to say, audio frequency) filter experiments that the filtering works and sounds fine. But the filter design takes a finite time - so filter re-design isn't instant. Accordingly, I tried stopping the audio when the filters were re-designed, by turning off the interrupts. That made a clear break in the audio, which was pretty disruptive.

Then I got bold and just let it happen. Sure  - you can hear an odd "digital" noise when the filters change, but it isn't objectionable. In fact, it is much LESS objectionable than muting the signal,

Then I decided I would try to make a recording, so you could hear it. I set up to record dj2xb reading the RSGB news this morning on 40m. But there was all sorts of trouble and the beginnings of a Anglo-French war over some ungentlemanly QRM that I decided not to dignify by recording.

You'll have to wait to listen to the sound of my variable bandwidth system - suffice to say, it works.

Update (30/11/2014): there are some measurements which show the receiving bandwidth here.

Here is the new bandwidth control, implemented - for the moment - on a little trimmer.



More to follow - I'm beginning to enjoy playing with SDR again!

...-.- de m0xpd

1 comment:

  1. Good stuff. These are explorations I wish I had time to make, too, but I will satisfy my curiosity by reading what you did. :-)

    Shunt capacitors are not the best solution for debouncing. They do little on the falling edge, have an excessive rise time (which can make CMOS inputs oscillate), and still let bounces through. Jack Ganssle has done a study of different methods of debouncing thatyou might find interesting. Do a Google search for "Jack Ganssle switch debouncing" to read it.

    73,
    Stephen KK7ZD

    ReplyDelete