Santa Stopped Here

Unwilling to go to the trouble of watching out, not crying, not pouting and - worst of all - being nice rather than naughty, the kids round here resorted to posting stop signs, exhorting Santa to call at their gaffs yesterday.

Not wanting to be outdone by the little darlings, I joined in...

and - glad tidings of great joy - it worked!

I've never really had anything to complain about before, but Santa really excelled himself this year (aided and abetted by the XYL), providing the Rigol DS1054Z I've been sniffing around for a while...

Here are some proud boasts of a kid with a new toy first impressions, formed after opening the box and looking at some of the functions offered by this inexpensive instrument.

There's a great colour display and four input channels. There's the temptations of some software hacks to increase the available bandwidth above the cited 50MHz. There's also the promise of digital connectivity, which means an end to all those ugly oscilloscope screen photographs, which have blighted the pages of  'Shack Nasties' over the years.

Getting some screen images onto the computer was the first thing I tried - which involved downloading the two lumps of freeware which Rigol provide to accompany my new toy: UltraSigma and UltraScope.

With these pieces of code in place on the shack PC, I could hook up immediately to the new 'scope and see the screen. I achieved this first through the ethernet connection (just because I could) and then went back to the planned option of USB...

All of this was anticipated - I expected to be able to 'echo' the screen and its controls on the PC. What I didn't expect was that the PC display could provide different information to that presented on the (already more than adequate) seven inch screen of my new 'scope.

I can - for example - set up some measurements on the PC (making it do service as a multimeter and counter/timer)...

Here you can see that the sinewave I'm shoving into the 'scope to give you something to look at has frequency of 4.386 kHz and you can check its RMS value. You can do all sorts of other stuff as well - but we're only just getting started here!

Given the frequency content, it might be interesting to open an FFT window on the PC (you can do this on the 'scope too - but the bigger PC screen makes the additional graphical information easier to consume, whilst keeping up the conventional time-domain display on the instrument)...

Here (above) is the expected peak in the magnitude spectrum at the correct frequency. The FFT was being computed at something like 1 MHz sample rate, but I've changed the display to make things easier to see (which explains why the frequency resolution isn't so great). Here's the same signal, sampled at a lower rate (i.e. with the horizontal timebase slower), making the frequency resolution higher...

I've had this new toy for thirty six hours and I've been playing with it for a few minutes. It seems to me to be bursting with possibilities and it is absolutely amazing value for money. Plus, the XYL (who acted as Santa's little helper in this transaction) tells me that the UK agent was really helpful and good to do business with.

Here's one little boy who's been very lucky.

I hope you've been lucky too and I wish you all a very Happy Christmas,

...-.- de m0xpd

Forty-9er Shield

I've been tinkering with a quick lash-up of Wayne Burdick, n6kr's famous 'Forty-9er' receiver, implemented on an Arduino shield and tuned by one of my DDS systems.

Regular readers will remember how I tried running my Kanga / m0xpd Sudden-inspired receiver shield under the control of the new DDS on the Internet of Things board and found the latter to cause a lot of noise problems. I stripped out unnecessary active stages in the Rx shield to try to manage some of the receiver's susceptibility to the hostile EM environment generated by the ESP8266 and realised that I was left with something which resembled not only a Sudden but also any other SA602 / LM386 receiver - including the Forty-9er.

Interestingly, there's a guy in Asia who produces a CW transceiver with an ESP8266, available as a kit or as an assembled unit through our favourite auction site. This transceiver is rock-bound, and is offered with an app for an Android phone, which allows automated sending of CW. There's some implication that it was supposed to allow automated copying too but, from what I gather, that side of things isn't working too well. The transceiver is based on - you guessed it - the Forty-9er. (He also makes units based on Rock-mites etc.)

I figured that the combination of my beacon work (which does all the transmit side stuff) and my WiFi controlled VFO already adds up to way more than the simple CW transceiver mentioned above, which was what motivated me to investigate the IoT DDS / Receiver combo. But - as readers recall - I found it impractically noisy.

Well - if the commercial unit is offered and (one idealistically supposes) works with the Forty-9er, perhaps I should try the Forty-9er circuit too...

I found that I could take an empty prototype Sudden Rx shield PCB (with tracking for the DIL format 602, rather than the production version SMD) and bodge it for the Forty-9er circuit. The Sudden and the Forty-9er receivers are so similar that the PCBs can be re-worked to serve both roles with almost no effort.

Here's my new kludged Forty-9er receiver, atop the Sudden Tx prototype shield (which is only serving as a power supply, so most of the pins aren't connected) - the new ESP8266 / AD9834 board lurks behind the stack:

Here are details of what I've implemented on the shield:

Those familiar with the original Forty-9er will notice I've been forced (by the PCB) to deviate from the original recipe in a few ways:

1. My input filtering network is implemented off-board
2. I'm taking the output from the 612 OUT_B (pin 5), rather than OUT_A; simply an inversion
3.  I'm applying the input to the 386 inverting input (pin 2) rather than the non-inverting input; another inversion
4. I've added the 10uF capacitor between pins 1 and 8 of the 386; experiment showed I needed more gain to drive the speaker 

 All of these measures are not significant departures from the letter or spirit of the Forty-9er design (excepting 1 - which does have an impact which cannot be avoided in terms of layout).

The limited experiments to date show that the Forty-9er is better than the original Kanga / m0xpd HF shield (with its extra active stages) and possibly marginally better than the 'bare' Sudden. However, there is still a clearly audible clicking, which isn't yet - by any means - perfect. But, at least we're now at the point where I have a usable receiver.

I've not yet got a big enough inductor on the input to the 386 (the 'junk' box didn't stretch that far), so there is some performance gain to be expected in the original circuit when I get the correct magnitude inductance. Also, there is more to be done in experimentation with shielding / positioning, etc..

I've also searched the 'net for any mention of the clicking in discussion of the performance of the  lxqqfy.com receivers - but to no avail. These devices have a very narrow (crystal) filter on their input and may derive some benefit from that strategy. If any reader has any direct experience of these units - or can point me to any evidence - please get in touch.

Now I'm off to continue with the tinkering, to listen to more clicking and - in between it all - to get lost in last minute preparations for Christmas,

...-.- de m0xpd

Homebrew WiFi Shield

Having just finished development of the new m0xpd / Kanga ESP8266 - AD9834 board, I find myself with a few WiFi components knocking about on the bench - so I figured it would be fun to try to make a WiFi shield for an Arduino...

Using an ESP8266 (in a module, such as an ESP-12) as a WiFi shield for an Arduino is a little like using the proverbial 'steam hammer to crack a nut' - but these modules are frighteningly cheap and I do want a WiFi shield (which are surprisingly expensive).

I have a spare ESP-12 module on a nice breakout board with 0.1 inch pitch headers, just crying out to be used once again (it having done service in the early stages of the development of the connected beacon etc)

This could be a great opportunity to press the module back into some useful work and to teach myself something new.

I found a nice page about Sparkfun's ESP8266 WiFi shield and realised I could easily make a cut-down version with the module. Here's my schematic...

All that's needed is a power supply to ensure the current demands of the ESP8266 (on transmit) don't frighten the Arduino and a level converter for the software serial interface.

Regular readers will recognise my old favourite level converter, originally used in the Si570 board and later developed in quad and octuple parallel versions (although this time I'm using the familiar 2N7000 device, as I did in the level converter for the display driver in Occam's Dirk, rather than the fancy surface mount BSS138). To be perfectly honest, I'm not absolutely sure this level converter is required (I've seen some folks doing without it ) but it only takes a couple of shakes to build it and it only costs two FETs and four resistors, so it may as well go in!

Here's the completed circuit taking up almost no space on a prototyping shield:

 and here's the shield with the actual ESP module plugged in:

I fiddled around for a while with the code and eventually got the Arduino UNO (underneath the shield in the photo at the head of this post) to serve up a very simple web page, via the WiFi shield, on which it reported the analog levels read at each of its six analog input pins:

The response above is produced with A0:A4 floating (open circuit) and A5 grounded (hence the zero).

This success was obtained using 'brute force' AT commands (I started from the code prototype given here). My attempts to use WiFi AT libraries - including SparkFun's, - have not yet been completely successful. I don't yet know why - given that the shield is obviously working.

All-in-all, an interesting exercise and a nice way of getting a WiFi shield for 'nothing'.

...-.- de m0xpd

ESP8266 Kit Released

The m0xpd / Kanga ESP8266 - AS9834 board, 'A DDS on The Internet of Things,' is now available for purchase as a kit, with the three SMD devices supplied already installed on the PCB...

The kit is provided (as usual) by the board's co-developer, Kanga Products UK.

Although this board is no more complicated than any other of my Arduino shields, it is rather different in scope and application. As such, I have set up a small website to support the board. The site provides details of the board's hardware and how to go about assembling and interfacing it.

More importantly, it provides some support to help new users get going with applications of this board. There are instructions for integrating the ESP8266 into the Arduino IDE and some test and application code for the new board - including a basic version of the multi-mode QRSS beacon.

I wish to thank Kanga for their continued support and encouragement in bringing my work to a wider audience. I hope that this board will be of interest to many experimenters who wish to explore the interface between ham radio and The Internet of Things.

...-.- de m0xpd

Noisy ESP8266

Having enjoyed a lot of success transmitting and having produced a usable VFO, I decided it was time to try using the new m0xpd / Kanga ESP8266 - DDS board in a receiving application. I soon discovered just how noisy the ESP8266 is.

Above, you see the new board sitting on top of my old Leslie 825. The Leslie is next to the bench, which is too full of work and other projects to host a little game like this - so the impromptu receiver has spilled out onto the nearest flat surface.

Next to the IoT processor and DDS is an early prototype of the Kanga / m0xpd HF receiver shield (it differs from the production versions sold as kits only in that the SA602 is a lovely old original DIL version, as opposed to the SOIC surface mount versions supplied on the PCBs of the kits).

The receiver shield is actually on top of the transmitter shield used in recent beacon exploits (which includes a buffer for the local oscillator signal for the receiver - an inheritance from the 'Occam's Micro' days - you can ignore that for the purposes of this story).

To the left of the receiver shield is a filter system, originally developed for the "Occam's Dirk" rig (that recently had a Dutch makeover), which provides switchable input and output filtering for 40 and 20m.

I fired up this little combo, with the ESP8266 - DDS board running the recently reported WiFi controlled VFO system.

The result was a working receiver, with tuning from my iPad, marred by a horrible clicking sound. 'Marred' is an understatement. I should say 'made un-usable'.

Here is a segment of the receiver shield schematic, including one point where I'm going to report a voltage...

I powered up the system with the antenna input connected to a dummy load and recorded the voltages at the point 'MEASURED HERE' in the schematic above (conveniently available on a header at the edge of the receiver shield). Here it is, (with apologies for the nasty oscilloscope screen photo), explaining the horrible clicking sound:

There are short clicks every 100ms, of amplitude reaching at least -300mV. Remembering that there is another active stage (at 0 dB gain) and then the final LM386 stage (at 46 dB gain) after this, you'll understand that the output is driven to saturation on its power rails every tenth of a second, making the 10Hz clicking, which dominates the output. The miracle is that it is possible to hear activity on the band at all against all this bad behaviour!

First of all, the origin: Remember that the ESP8266 is being asked to establish an access point in order to run my WiFi controlled VFO program. Well, every 100ms, the system comes to the end of its 'beacon interval' in servicing that access point and makes some wireless activity (such as broadcasting its SSID). It is that which is causing the noise - but how is it getting into my receiver?

I found (somewhat to my surprise) that the greater part of the noise wasn't being received via the SA602 (this discovery was made by removing the chip - the reason I was using the early prototype version of the shield with a DIL mixer - and grounding the input to the Op-Amp). Instead, the greater part of the noise is actually generated by the twin Op-Amp package, where it was being directly detected / demodulated to AF. Some little of this 'detection' is also happening in the LM386 - but the op-amp seems to be the greater culprit.

The receiver actually seems closer to usable (notice I say 'closer to usable' rather than 'usable') without the op-amp in circuit at all - just taking the output straight from the SA602 to the LM386 (just like the original Sudden). Some part of the clicking which remains is directly demodulated in the audio frequency circuitry (the LM386). In the shield (unlike some implementations of Sudden-inspired DC receivers) this is operated with an unbalanced input. This experience of a very hostile EM environment caused by the ESP8266 might occasion a re-think of the receiver shield design. The remaining part of the clicking appears to enter through the intended (i.e. tuned) RF input...

Either switching the input filter to the other band or (equivalently) switching the VFO to the other band causes a big drop (>20 dB) in the clicking amplitude.

All the above is pretty disappointing; the ESP8266 and a simple receiver are uncomfortable bedfellows. There needs to be some careful layout and some circuit re-design before a WiFi module and a simple DC receiver can sit next to each other easily. This isn't exactly news (noise problems have been reported before in trying to close-couple an ESP8266 and a 2m transceiver) but it sure puts the brakes on some plans I had for the next few weeks.

Finally, for something really wierd...

I re-programmed the ESP8266 with some code which just set the DDS frequency. No access point, no WiFi activity. Nothing. Just a quick set-up of the DDS on 40m and then just sit there in an endless loop, twiddling its thumbs.

The result?

You guessed it - exactly the same 10Hz noise!

The chip is still pumping out noise pollution, even when the code hasn't asked it to do anything fancy. I don't know if this is a failing of the IDE (I was using the Arduino IDE, and I don't know if the compiler doesn't turn off the WiFi resources if they've previously been turned on in an earlier program). I don't even know if it is POSSIBLE to turn off the WiFi resources (though I believe it is). All I know is that a piece of code written to evoke NO WiFi functionality at all is producing the massive noise fields around the device as are present due (presumably) to WiFi activity. Wierd.

So - I have a working, WiFi tuned HF receiver running. It is just ruined at present by some nasty 10Hz clicking, which makes it just about worthless. I don't know if it can be fixed.

It has certainly put a dent in my enthusiasm for the ESP8266.

...-.- de m0xpd