Quantcast
Channel: m0xpd's 'Shack Nasties'
Viewing all 220 articles
Browse latest View live

Listen Up!

$
0
0
Yesterday we were back on our favourite highway (the one that goes straight to Laramie)...


This time, we were headed out of PA into Ohio...


Then we took the Ohio Turnpike to Portage County and the City of Kent, OH, to meet up with Tom, wb8lcd. Tom and I had met last year at FDIM and we had arranged that - if ever I were in Portage County - I should look in at the Portage County Amateur Radio Service. Yesterday was my chance...

I gave a presentation about audio in amateur radio, which I'd entitled 'Listen Up!'...


On the evidence of last evening's meeting (and on seeing the excellent newsletter, the 'Radiogram') PCARS is a lively, active club, covering the whole breadth of our hobby and reflecting the service which PCARS members pours back into the local community.

It was a pleasure to meet with members and to be able to make my little presentation, which they appeared to enjoy (they neither lynched me or threw anything!)...


In fact, the welcome was so warm that I was elected an Honorary Life Member of PCARS during the meeting - I am proud and delighted to be associated with this fine club. Trouble is, it is going to be rather expensive to get to many meetings (but it is another good motive to attend the Dayton events!).

In addition to the warmth and kindness of all PCARS members and the extraordinary hospitality which Mary, Jennifer and Tom are extending to Deborah and me, I want to say a special thanks to Chuck, w8pt for the personal gift he gave me.

73 from Portage County.
...-.- de m0xpd



Author Event

$
0
0
Earlier this week we went back to Saint Marys, OH, to visit with Larry Kramer - owner of Saint Marys Hobby Center. We had first met a year back, when we parked our rental car - by chance - outside the same store on Wednesday, 13th May, 2015 and heard Larry tell the story of the Miami and Erie Canal, which runs through Saint Marys and explains the nearby Great Lake.

It was Larry's infectious enthusiasm for history and his natural gifts as a storyteller which turned my intentions to keep a private journal into the idea to write something more public - so, naturally I wanted to thank Larry and give him a copy of my book...



Larry had already read the library's copy of my book (!) but I wanted him to have his own, personal copy. Larry was even promoting my book on his store front...



The next day, we visited some more of the remains of the canal, particularly in the nearby town of New Bremen, which boasts restored lock in the centre of town and a lock-keeper's cottage, now used as a museum and the offices for the Chamber of Commerce...



Then I was pleased to give a talk about my book at an 'Author Event' at Saint Marys Community Public Library, in which I picked up the theme of the local canal and the importance of waterways to the opening up of the entire US economy - the same story taught me by Larry, repeated in chapter 11 of my book and picked up again as the story was repeated on our journey west last year.

I was fortunate that my talk was attended by a talented reporter from The Daily Standard, Claire Giesige, who gave my talk a really nice write up in the next day's edition...


Thanks to Beth and all the staff at the Library who made the event possible - I had a great time.

...-.- de m0xpd

FDIM and the WBB

$
0
0
FDIM 2016 is well under way ...



I gave my presentation, "Occam's Scrip", as part of the seminar series yesterday and I seem to have got away with it! (I'll post copies of both the written paper and the slides online when I get back to the UK). I also sold some copies of my new book during the vendors' event last evening.

Yesterday afternoon, delegates had opportunity to participate in what was billed as "The World's Biggest Buildathon" (WBB), organised by FDIM stalwart Rex Harper, w1rex, (of Tuna and QRPme fame).

The WBB was an opportunity for all to make a simple 20m transmitter, distinguished by the fact that no soldering was required.

Rex and his helpers had done a heroic job to put together 300 kits...


which were passed out to the assembled multitudes


and Rex (and some helpers) gave personal assistance to get everybody going with the 'plug in' build.

Here's Rex in action...


Very soon, some working transmitters were assembled - one of the first I spotted was completed by Harold, ke6ti...


As if all the efforts of yesterday weren't heroic enough, Rex is running another 'regular' Buildathon even as I type - I'll go down and take a look at how things are progressing.

Respect and kudos to w1rex - his contributions to FDIM over the years continue to amaze!

...-.- de m0xpd

Hamvention 2016

$
0
0
Did a long day at Dayton Hamvention yesterday...


where we had a mix of rain and overcast, exactly as on the Saturday of last year.

Once again, we Brits were represented by the RSGB stand in its familiar location...


Walking around the flea market I was delighted to bump into Kristen, kb3oqv


Kristen is known as Antenna Hair Girl (she's not just standing in front of a tower - it is worked into her hair) and, what's more, it was working as an antenna for the HT she's holding up in the photo!

Best of all, Kristen is a fellow member of Portage County Amateur Radio Service - she came to my talk a few weeks back. Her folks farm Buffalo and (as I can confirm personally) those animals sure taste fine!

Make sure you visit the Dayton Hamvention at least once in your Amateur radio career.

...-.- de m0xpd

Icelandic Radio Amateurs

$
0
0
I was pleased to be able to meet with the guys of Íslenskir radíóamatörar last evening, who have a neat clubhouse next to the Domestic Airport in Reykjavik.


They allowed me to gave a presentation about some of my activities in homebrewing and operating beacons...


in the comfortable surroundings of what was once a Shell Oil facility...


I wasn't the only overseas visitor - there were some DF hams on their way back from Dayton and Dave, ei9fbb and Col, MM0NDX were on Iceland for an IOTA activation...


Dave gave a great presentation about the S79C DXpedition to Coëtivy Island in the Seychelles after my talk...


Col was on the team for the S79C trip with Dave.

After my talk, we sold the few copies of my book that remained after the North American sector of the trip (and the two 'sample' copies).

Thanks to all members of the IRA, their visitors (especially Dave and Col) and, particularly, to Jon Th. Jonsson, TF3JA, for arranging my visit.

...-.- de m0xpd


Dayton Presentation Materials OnLine

$
0
0
Having got back home, I've just posted my materials from FDIM 2016 online - so anybody who missed the show live can 'catch up' ...


The written notes and a low-res copy of my presentation slides are available here.

...-.- de m0xpd

Another kd1jv rig

$
0
0
After being fortunate to acquire the kd1jv Tri-Bander at last year's Dayton jaunt, seen here with the American Morse paddle riding shotgun...


and seen here being worked on the banks of Lewis and Clark reservoir, SD, I was delighted recently to pick up another little rig designed by Steve Weber, kd1jv.

This one, the five band 'Mountain Topper', is marketed by LNR Precision Inc under the name 'MTR5B'. The rig, which measures only 108 x 80 x 30 mm, is seen here next to my Palm key...


Unfortunately, there's neither a free flat surface (nor any magnetic material) to fix the key on the rig!

The Mountain Topper needs dc power - but the applied voltage must not exceed 12V, or the magic smoke will escape from inside the rig.

I decided to measure the power output from the rig using my Sandford power meter on both 12V and a more conservative 9V supply...


Here are the results...


If you are chasing the very last ounce of output, then some kind of 12V regulator in the lead would be a good idea - but otherwise, a 9V supply would be the safe option.

I haven't really had opportunity to try the rig on air yet (and certainly haven't had the inclination to drag myself up any mountains) but I did just call a single CQ on 40 whilst I had the rig on 9V...


I must get in contact with Colin, m1buu, and the other Mountain Topper specialists to learn how to really use this neat little rig.

...-.- de m0xpd

getting there on Kindle

$
0
0
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

AD9834 and the IoT Beacon

$
0
0
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




AD9834 / ESP8266 Beacon

$
0
0
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






OLED Display on the ESP8266 Beacon

$
0
0
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


 

ESP8266 Geolocation

$
0
0
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

USB Mini Breakouts

$
0
0
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

  

New ESP8266 Board

$
0
0
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




ESP8266 Production PCB

$
0
0
The first sample of the production version of the PCB for the ESP8266 / DDS system arrived a couple of weeks ago.



As you see, it follows the plans established in the earlier prototypes, with the surface mount components already fitted (such that tyros don't need to face the challenge of dealing with these pesky little things).

I've been detained by work and by a short break up in M-land, where I stayed on the banks of the River Nith, playing at being mm0xpd/p. However, now I'm home, I've stuffed the new board - this time with the intended 1/8th Watt resistors:


I set her up for a quick test yesterday morning, programming the ESP8266 with my beacon code and plugging a Kanga / m0xpd TX shield on top of the new PCB. Here are the WSPR spots accumulated on 30m in the first thirty minutes (from 09:00 GMT):


Looks like things are working FB.

I had a nice time working CW, PSK-31 and even a little SSB on my TS-480 yesterday, so the station was out of commission for beacon operation for most of the day. But I turned the beacon back on in the evening and let it run overnight.

Here are the accumulated 24 hours of spots on 30m ...


(It looks even better as I write, 'cos I'm also down to Stewart, w4mo in Venice, FL - but you've got to draw the line somewhere).

I hope it won't be long before Kanga can offer the new board as a kit to anybody interested in playing similar games.

...-.- de m0xpd

SNA Junior

$
0
0
I have (finally) got round to building my own instance of DuWayne, KV4QB's prize-winning Scalar Network Analyser Jr:


and a great little instrument it is too!

DuWayne and I have been corresponding for a couple of years, sharing mutual interests. I was pleased to be able to give his work a shout in both the printed and  'spoken' version of my talk at this year's Four Days in May event in Dayton and - more importantly - to catch up with the man in person for a quick eyeball QSO. I also got a PCB for SNA Jr, which has been sitting on the bench for months - until last week.

The SNA board finally bubbled up to the top of the pile and I looked around for the bits I needed to complete it. Perhaps I should explain (to those of you who don't know) what's involved...


DuWayne's baby uses an AD9850 in one of our familiar modules to generate RF, under the control of an Arduino NANO. You can read on DuWayne's blog how the SNA Jr is the descendant of earlier experiments in which an Si5351 was used as the signal source.

In the SNA Jr, the output from the DDS is fed to the device under test and the returned signal is observed in a detector system. DuWayne has 'history' in using simple diode detectors in this role (and I was praising kv4qb for this minimalist approach in my talk at Dayton) - again, you can read about this lineage. However, the SNA Jr now replaces the earlier simple diode detector with a fancy AD8307 detector, in the well-known Wes Hayward, w7zoi, circuit. This gives superior performance in terms of dynamic range and 'linearity'. Also, with the availability of cheap AD8307s (of dubious parentage) from China, this option is also becoming attractive for cheapskates like me! [I have some Chinese AD8307s on order and will report back on performance when the slow boat docks.]

You can's see the detector in the photo above, because it lurks under the screen - so here's another shot (with apologies for my wayward handling of some of the SMT devices):


The detector is supposed to be enclosed in a screening can, which I haven't made yet - so final performance will be better than I'm going to show you below.

The DDS RF source and measurement of the RF level returned from the device under test are all under the control of the little Arduino NANO, which runs a sketch provided by DuWayne. This sketch compiled for me under Arduino 1.6.12. The user interface is provided through just a rotary encoder and the 1.8 inch TFT screen.

I found I had everything needed to build SNA Jr in the 'junk box' - except the screen and a spare NANO, so these were quickly ordered through usual suppliers.

The result, as you see above, was simple to put together and works very well.

DuWayne's software offers a number of options, including a 'signal generator' mode, in which the output of the DDS module is set at a single frequency, whilst the returned RF amplitude is displayed numerically and on a bar display (useful when the numerical display is flicking between two values). This mode is illustrated in the graphic below, which shows the system driving a simple switched attenuator, seen in the graphic, with and without 20dB of attenuation switched in (two 10 dB stages).


I'm sure the (in)accuracy of the -20dB step is down to my cheapskate attenuator (with its low tolerance resistors, lack of screening etc.), rather than SNA Jr.

Another, more important series of modes sets the DDS module generating RF sweeps, which result in graphical displays. These are illustrated below, in which I've contrived a test of the low pass filter which has been conditioning the output of the 'connected beacon' (Blogs passim) on 30m.


SNA Jr can also be used with various 'attachments' such as a 40dB tap (with which DuWayne's software allows it to function as an RF Power Meter) or a Return Loss Bridge, with which it can perform SWR Scans.

Here's a scan looking into my (g5rv) antenna, with (right) and without (left) the Made-from-Junk 'Deluxe' Versa Tuner II switching in tuning appropriate for operation at the CW end of 40m...

As you see from my additional labeling in the graphic above, the scan was set up to run from 6 to 8 MHz. I reported an equivalent measurement on my own system in one of my slides at FDIM (although it was presented in terms of Reflection Coefficient, rather than SWR)...



There's even more to SNA Jr - it can even locate minima to impersonate a dip meter (but I haven't been able to try this yet).

I said at the beginning of this post that SNA Jr is 'prize winning'. DuWayne won the 'Best in Show' award at  the homebrew competition at FDIM (which is no mean feat, given the very high standard of the submissions I saw there, in several widely different categories). The prize was well-deserved.

The project was written up in QRP Quarterly (vol 57(3)  pp 22:25, July 2016) :


which is nice to read. But the best thing to do is to get the information from DuWayne's blog and build an SNA Jr for yourself  - or take the inspiration to build something similar.

Great fun - thanks, DuWayne.

...-.- de m0xpd

Occam Going Dutch

$
0
0
Kees, pa5cw, has produced a new variant of my 'Occam's Dirk' software for a multi-band CW transceiver.


'Occam's Dirk' was a multi-band development of the original 'Occam's Microcontroller' concept, adding automated 'CQ' calls and one or two other little refinements (like RiT, VFO A/B, etc). The original 'Dirk' was presented with an Si5351 in the RF generating role (as I wanted to try using the then new Kanga / m0xpd Si5351 shield).

Kees has decided to revert to the AD9850 DDS for his version of the code, which makes the architecture similar to that introduced in my 'Kanga VFO' demo software (and elsewhere).

Kees has also added some new functionality: the means to change keyer speed using a voltage input to A0, most conveniently generated by a potentiometer. The original code had speed change as a software function under the menu system - which works, but isn't immediately accessible for a quick change.

I've always built keyers into my software (and provided both a paddle and a straight key input) but - if I'm honest - I've seldom used these keyers in anger. Here at the shack, I usually drive all my rigs (via their straight key input) from the old faithful "Funky Keyer", which has its own physical speed control. Thus, menu-based speed adjustment of the software was never a big handicap for me. But Kees' approach certainly is convenient (at the expense of one knob).

Any of you interested in trying Kees' code can find it here on the Occam's Software page. I haven't tried running it - but I have confirmed that it compiles correctly.

Many thanks to Kees for sharing his work,
...-.- de m0xpd

A WiFi-Controlled VFO

$
0
0
Now that I have placed a DDS on a board with Wireless connectivity, it is only obvious to set it up as an AP Web Server and allow remote control via a 'soft' user interface...


When I first started to play with the AD9850 DDS, I made some beacons and wrote the Kanga VFO demonstrator code (as application code to support the Kanga / m0xpd DDS shield). Well, now I've produced this new internet savvy AD9834 DDS board, I've followed the same pattern; I've done the beacon thing and now - in this post - I'm covering the VFO. Only, of course, this VFO won't have physical knobs and buttons like its predecessor. Understand, it could have all the physical controls if you wanted it to - but that's not the point. Instead...

When  the new code fires up, the ESP8266 sets itself up as an access point and offers a new wireless network:


which you can join from any phone, tablet, computer or similar wireless enabled device. This will provide the interface to the VFO. The network name 'm0xpd Kanga DDS 94TD' is formed of a generic part ('m0xpd Kanga DDS') and a four character index associated with the particular board (such that two VFOs in the same area could operate independently).

Opening a browser and going to the VFO's 'web page' will open the simple control interface seen below, which reports the frequency at which the oscillator is running, offers 'buttons' to adjust the frequency and 'buttons' to change band:


The picture above is a photo of my iPad mini screen, controlling the VFO. I've added the red annotations to make it clearer for you.

The web page is generated entirely by the m0xpd / Kanga ESP8266 - AD9834 board - the iPad is just interpreting it (as HTML).

Clicking on any of the 'Adjust Freq' hyperlinks will cause the VFO frequency to change according to the label. Clicking on any of the 'Select Band' hyperlinks has the obvious effect.

All this is rather dynamic and needs a video to demonstrate (which I haven't provided) - so here are some rather dull 'stills' of the system on 40 metres


and 80 metres...


And here's a 'sniff' of the requests received from the web page of sequential increments and decrements in frequency whilst on 80m, along with the resulting frequencies...


This code will be released as an application 'demo' for the new m0xpd / Kanga ESP8266 - AD9834 board (along with a multi-mode beacon).

Of course, the demo code above is intended only as an illustration of what is possible. The rather dry web page could be replaced by an application, written specifically to control a different piece of VFO code, etc.. This is just a start point - but it sure gets me thinking...

There are other exciting opportunities to be exploited via this access point - watch this space!

...-.- de m0xpd

Noisy ESP8266

$
0
0
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

ESP8266 Kit Released

$
0
0
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


Viewing all 220 articles
Browse latest View live