Sunday, 4 September 2016

New ESP8266 Board

Kanga UK and I have been developing a new board and I can bring you some pictures of the first engineering sample...


You can well see it is an engineering sample, because I'm squeezing the wrong size packages into locations (quarter Watt resistors where eighth Watt components should be, etc) and using a mishmash of different component types, but you'll forgive me, I'm sure.

The new design presents the Expressif ESP8266 device on an Arduino-sized board, supported by a full USB programming interface and power supply.

I should be careful to explain - this is not a "shield". It does not sit on top of an Arduino. It REPLACES the Arduino. It IS the processor - and a whole bunch more...

Of course, there's all the interfacing headers you'll need to connect it to other expansion devices ("shields") from the Arduino ecosystem. This is nothing new - it is already available in commercial platforms out there, such as the WeMos D1 R2 (indeed, I made this new board largely compatible with WeMos' digital I/O pin allocations).

Of more relevance to fellow amateurs, this new board includes a DDS system, capable of generating stable, controllable RF, using the AD9834 device.

You have here a powerful processor - significantly more capable than that on (e.g.) the basic Arduino UNO - with a full, on-board DDS system. All with access to the advantages of the Internet (time servers, geolocation, remote control, ...). All on one little board.

The overall architecture is seen in the image below...


The output from the DDS module is taken to the header on the upper left hand edge of the board in the orientation of the photo above - which is the m0xpd RF bus I've defined previously for other shields. This facilitates the first application for the new board: to implement a beacon system, using the Kanga/m0xpd Sudden Transmitter shield, which can simply plug on top of the new board to make a complete beacon assembly.

The USB interface is implemented using a genuine FTDI chip, with the hope that interface problems should be minimised. However, I've just had all sorts of problems after upgrading the operating system of my MacBook Air to El Capitan, after which it seems incapable of operating reliably with ANY external peripheral - not just the FTDI devices.

The new board has flexible power supply options. It can be powered off the USB connection. It can derive power from the 5V supply from the Sudden Tx shield in the beacon application described above or it can be powered through the d.c. power jack visible at bottom left of the photo.

Of course - the collaboration with Kanga signals that this board - or the final production version - may soon be available for purchase as a kit. With the experience of the m0xpd Si5351 shield, we have discovered that many Kanga customers are not great fans of surface mount technology. Accordingly, this system has been designed with the intention that key SMD elements could be delivered pre-fitted...


leaving the kit buyer to fit only thru-hole components, one large voltage regulator and the ESP8266 module itself.

Here, finally, is the engineering sample, plugged into a Sudden Tx shield (itself a prototype) for the very first time to run my beacon code as a "stack"...


The little OLED display on the breadboard at bottom right is there just as a sign of life.

Although not so good these last two or three days, when it has been harder to burst far out of Europe, the same technology has been running WSPR and QRSS all over the globe for the past couple of weeks, as recent posts testify.

I hope that this new board might tempt some more radio hams to look toward the ESP8266 and the"Internet of Things" for inspiration and fun.

...-.- de m0xpd




Wednesday, 24 August 2016

USB Mini Breakouts

If, like me, you ever fool around with USB hardware and choose to do so in the context of solderless breadboards, you might well need a little breakout board for one of the several types of socket - in my present case the USB mini-B receptacle.

There are, of course, lots of lovely commercial ways to scratch this itch, available - for example - on our favourite auction site...


but I wanted one now, rather than in a day or two's time (or longer, if it had to take the slow boat).

Of course, I'd been getting by with the usual solution of a butchered cable with a type A plug at one end and some pins on the end of bare tails I'd made at the other...


but I wanted to get rid of this 'trailing wire' and fit a neat socket.

I had some surface mount mini-B receptacles in the junk box and noticed that the connector pitch was close enough to the 0.95mm spaced pads on one side of a 10-pad SOT23 DIL carrier...


So, with a little judicious bending of the outer pair of pins, a 5-way strip of male header pins and some solder, I soon had my own USB mini breakout...


Here it is in action on the beacon...


I don't think I'll even bother to order any from the Far East - they're too easy to make!

...-.- de m0xpd

  

Friday, 19 August 2016

ESP8266 Geolocation

The ESP8266 device, used as the heart and soul of my new beacon, knows its place in the world...


This post describes a couple of techniques for 'Geolocation' on the ESP8266 and uses them to derive the location information my beacon needs to broadcast (e.g.) a valid WSPR message.

Readers may remember I grafted a GPS module onto an earlier beacon system here in the shack - mainly for time synchronization - but don't know how much trouble I had with it (a north facing window made GPS reception VERY difficult).

Having my new beacon sat on the 'Internet of Things' opens up a new possibility for obtaining not just time (which I've already reported) but also position information, using geolocation. So - I decided this was a worthy avenue for experiment, both for the practical end of getting the location by other means than GPS and as an interesting learning exercise.

It turns out that Geolocation, by the methods I'll describe below, is a standard alternative to positioning via GPS in those places where a satellite signal cannot be obtained (indoors, underground etc.).

I'll describe two broad methods - and present working ESP8266 code to illustrate each.

The first uses your own IP address to provide a rough estimate of location, using a service such as Freegeoip. Adafruit has posted a very good example of how to use this service here and I've modified their code to provide a stand-alone application for the ESP8266.

The code on the github link above is presented as a sketch for the Arduino IDE. You'll need to modify it to include your own WiFi network's ssid and password before it will work. It will print the results into a Serial Monitor window (at 115200 baud).

I included an elaborated version of this code in my beacon, to generate the following location estimates on the little screen...

  
Clearly, it knows I'm in Manchester (!), but the map reference turns out to be quite a bit off...


It places me at a location about 8 km away from my actual QTH, as seen in the map above (the erroneous location is seen - not my home - this isn't an invitation for thieves).

All this might not matter too much, but for the fact that it is actually in the wrong (six-character) Maidenhead locator square...


This shows an incorrect placement in IO83uk when actually I'm in IO83tk.

Not too serious - but a reflection of the poor absolute accuracy of the location estimation afforded using this first IP-based Geolocation method. Remember - it is 8km out. In fact, as I write, freegeoip.net is returning a location estimate which is much poorer than that - bang in the middle of London!

An alternative method clearly is needed to accurately resolve the correct locator square.

The second method, known as the WiFi positioning system or WPS, uses a scan of all the WiFi Access Points visible to the ESP8266. The result of this scan is uploaded to a Geolocation API, such as those offered by Google or Mozilla.


Both these services are entirely free to use, but Google make you jump through a lot of hoops to get an API Key. Mozilla is hoop-free.

I've written some code which shows how to access these services using the ESP8266 here.

The important part of the sketch is shown in this extract...

 
After setting up the important credentials for accessing the API (Host, Page and access key), the HTTPS client needs to be instantiated (it needs to be the Secure version of the WiFi client - so this won't be easy or even possible to run on a lesser processor than the ESP8266).

After this, the POST is fairly conventional (see, for example, the example at the bottom of this page) but it did take me a long time to figure out exactly how to get it working!

Here's the beginning of the result of the WiFi scan, as produced at my QTH, showing some of the WAPs visible here...


It is in the JSON format produced by the code and required for submission to the Geolocation APIs.

WPS databases operate in context of the mobile telephone industry and require that the header includes some parameters which spoof the API into believing that the request is coming from a mobile device with GSM capability. I used a Mobile Country Code and Network Code associated with a local network provider in the UK (which I looked up in a table). If you're not in the UK, you should probably choose a different MCC and MNC.

I also used the ArduinoJson library to handle the result from the Geolocation API.

With this method, location results have an accuracy of order metres, so an elaborated version of the code was implemented in my little proto-beacon...


Now we're in the building (actually, we're in a house at the bottom of my garden, but that sort of error I can live with).

With location and time (from the NTP servers, as previously reported) I have all the ingredients required to automatically generate a WSPR message, instead of going through the chore of generating it ahead of time in a command-line utility on the PC and uploading it as a constant into the beacon...

I looked at Gene, w3pm's on-line materials, among which are several Arduino sketches including a function 'void wsprGenCode()' which generates WSPR messages. This works perfectly well, but calls several other functions and isn't the easiest item to work with.

Fortunately, a further quick search produced John Newcombe's elegant WsprMessage c++ class, which I am now using. It is producing my WSPR message very efficiently...


Credit where it is due: both Gene's function(s) and John's class (/library) draw heavily on the work of Andy Talbot, g4jnt, who has produced a detailed explanation of the WSPR coding process.

The entire beacon now is literally turn-on and go, in any location with a WiFi connection. It ran last night on 30m with an unusually strong performance into S America...


although this seemed to be at the expense of contacts into the antipodes.

I hope others are as excited by this collision between amateur radio and the Internet of Things as I am - it seems alive with possibilities.

...-.- de m0xpd

Monday, 25 July 2016

OLED Display on the ESP8266 Beacon

My good friend and benefactor, g6ybc, just sent me a couple of little OLED displays to play with...


Since it is sitting here buzzing away on the bench, what better 'test bed' for the new display than the ESP8266 / AD9834 beacon, recently described?

I downloaded the Adafruit SSD1036 Library and I already had the GFX Library (and using the latter with the ESP8266 is a lot less of a headache than with the UNO, as memory isn't about to run out any time soon).

I soon had the little display plumbed into the proto-beacon (it only needs power and a couple of interface lines)...


and we were displaying useful status information (which previously had required a link to the PC and a Serial Monitor window)...


I did find one useful little wrinkle...

You need to define a 'reset line' for the display - even though you're not going to use one. Rather than waste one of the few precious GPIOs of the ESP8266, I tried defining one which doesn't physically exist.

It worked - program compiles and runs FB. Here I'm using GPIO 20 which (as ESP8266 users will know) isn't there - on the outside, at least!


If everything goes pear-shaped in a few days, I'll tell you.

I can even relate the pictures of my display with the results of other peoples' efforts in receiving my transmissions...


This is a cute little display, super-easy to link to the ESP8266 (or an Arduino) with only two lines. Plus, it makes a genuinely useful addition to the beacon.

...-.- de m0xpd


 

Sunday, 24 July 2016

AD9834 / ESP8266 Beacon

Well - the connected ESP 8266 beacon is now running with its new AD9834 heart pumping pure RF sinewaves...


Last week's report was made in good faith - but I hadn't realized at time of posting that the DDS was only being controlled to VERY poor frequency resolution. In fact, I could only adjust the frequency in something like 3kHz increments. Obviously, something was very wrong!

I wasted a lot of brain cycles trying to track down the problem and ended up abandoning the AD983X library (which I could not get to work properly with either an Arduino UNO or Mega - much less the ESP8266).

Instead, I took inspiration from Diz Gentzow, w8diz's work (well reported by Bruce Hall, w8bh) and Akio Mizuno's Arduino AD9834 DDS and I went back to my old "Soft SPI" approach.

This paid dividends - after doing the initial development work with an Arduino UNO and a logic analyser, both of which you can see in the photo below, which shows the proto-beacon on the bench...


You can also see the amplifier I'm using for the beacon (it is the original prototype of the m0xpd / Kanga Sudden Tx shield) and the filter on the amplifier output.

As well as (correctly) controlling the AD9834, the ESP8266 connects to the internet to get the time from an NTP server, as has been described previously. This allowed the beacon to be heard immediately on its very first 'shout', with no intervention whatsoever from me.

Here are the reports from wsprnet.org of that first shout this morning...

and the same in visual format...


As well as transmitting WSPR, the beacon is transmitting other QRSS modes which could be received on "grabbers", such as that operated by Steen, la5goa in Norway...


(my callsign, 'm0xpd', seen twice in the red box).

I left the beacon running for a few hours and now there's a fuller 'net' of signal reports for the new beacon - here's the complete set of (WSPR) Rx reports since turn-on...


The next step is to turn the pile of spaghetti on the bench into something a little more permanent.

...-.- de m0xpd






Sunday, 17 July 2016

AD9834 and the IoT Beacon

I've been playing with a new RF generator for the IoT beacon...


Actually, I do myself a disservice, because I've done rather more than just play with the RF generator.

First, I've replaced the little USB to serial dongle which I used to program the original system and built a complete interface, using the same FTDI chip which was on the original dongle. The thinking behind this is to avoid the requirements for a clumsy interface to some of the more unusual UART lines (such as RTS and DTR), which are not taken out to the nice big header pins on a standard USB-Serial device.

Then, I've changed the RF generator - moving from the AD9850 DDS module as used previously to the AD9834 chip. You can see the hardware here...


Getting the FT 232R device talking to the ESP8266 was easy. But arranging the interface to the AD9834 was a little less straightforward.

I have the AD9834 on a DIL carrier (thanks Dennis) and I built the master clock oscillator on some "prototyping area" at the top of that carrier board, as you can see in the photo below...



The hardware all seemed to work FB - so all that was needed was some code for the ESP8266.

Fortunately, Nick Johnson has written an Arduino library to control the AD983x, which is available here .

Unfortunately, the library didn't work with the ESP8266 (I can't say whether it works with anything else as I didn't try it).

I did some head scratching and ended up writing some code which implemented a software SPI interface between the ESP8266 and the AD9834 and got that running OK.  That was enough to allow me to see that the problem with the library appeared to be an issue with the specification of the SPI Mode...

I played with a little test program for SPI on the ESP8266...


Setting the SPI DataMode to 2 (which was the mode used in the library) results in a data transfer in which the data is read at upward transitions of the clock signal, as demonstrated by this capture of the output of one burst from the test program above on the logic analyser...


(I've added the red annotation to the logic analyser screen to try to show what's going on - the arrows define the time instants when the data is valid and the binary data speaks for itself).

If the DataMode is changed to 1, the data is valid on the falling transitions of the clock ...


Certainly, the AD9834 data sheet specifies that the serial data should be valid on downward transitions of SCLK (see Figure 5, page 6).

Suddenly, the AD9834 was working fine, producing nice sine waves at its output...


What you can't see from the clumsy photo of my 'scope screen above is that the frequency is actually being changed once a second - the ESP8266 can control the AD9834.

A note of caution: there are some known 'holes' in the ESP8266's implementation of the SPI Modes (mainly with the clock 'polarity' - not with clock phase). I don't know if what I've described above relates to ALL applications of the ad983x library - or just to its use with the ESP8266. I haven't the time (or the need) to test with other controllers. If you use it elsewhere, take care.

All that I care about is that the FT 232R / ESP8266 / AD9834 combo is now ready to work as the 'brain' of a QRSS beacon.

...-.- de m0xpd




Wednesday, 13 July 2016

getting there on Kindle

Those of you with an ecological objection to Treeware, those of you who baulk at the price of a physical object or its delivery, and all tablet-toting neophiles might be interested to hear that my little book is now available on the Kindle platform...


You can find the new electronic edition on the same amazon.com, amazon.co.uk, etc pages as before.

Perfect summer holiday reading!

...-.- de m0xpd