Amateur radio, programming, electronics and other musings

Since I created this project more than 6 years ago it has been built by literally hundreds of people. I have made PCBs available to those that wanted them and for the hardcore builder the schematic was available and they made their own implementation on stripboard. There are a number of write-ups online about the project and even a presentation was given by someone at a convention.

Over the years I have added features for either my own requirements or others asking. This round of updates covers two distinct areas with the first relating to features.

V1.1.0

I have added four new screens which show additional information available from the Trimble Thunderbolt.

The first new screen is only available during startup and is displayed directly after the splash. You will briefly be shown the firmware and hardware versions of the connected Thunderbolt. You will also be shown the serial number. I also show the build date as it might be interesting to see how old your Trimble Thunderbolt actually is.

Screen five shows the status of each satellite, the signal strength and how many satellites are being used in a fix/tracked. The signal strength should be easy to understand. I take the reading from the Thunderbolt and map it directly to a number between 1 and 8. This draws a column chart similar to a strength meter you might find on a mobile phone interface.

Each satellite is represented with a status. The statuses I am reporting are as follows:

  • – = The default state, a placeholder if you like.
  • D = Disabled
  • F = Being used to calculate a fix.
  • A = Acquired
  • * = Reopened search
  • T = Tracked

Screen six shows the PRNs of each satellite. GPS signal consists of a navigation message and PRN codes (C/A for civil and P-code for military) which is an identity for the satellite. PRN codes are also used to determine the range between the satellite and the receiver. The navigation message added on PRN code, must be known to find the position of GPS receiver on Earth. Identification of PRN code is the most important process to calculate the receiver’s position.

Screen seven shows you further precision information. We now show PDOP, TDOP, VDOP, HDOP.

PDOP (position dilution of precision) describes error caused by the relative position of the GPS satellites. Basically, the more signals a GPS receiver can “see” (spread apart versus close together), the more precise it can be.

From the observer’s point of view, if the satellites are spread apart in the sky, then the GPS receiver has a good PDOP.

We display all the available values and give you a rough estimate as to if it is good or bad.

The code has also been refactored quite a bit to make some of it cleaner to read.

This set of updates (v1.1.0) have been made available on GitHub and will run on any of the available NETMF 4.3 boards such as Netduino. You just need to download the code, compile and deploy and you should have the new version running.

New Hardware Support, V2.0.0

I have heard a repeating thing from some builders over the years. Comments such as “I can’t find a Netduino”, “Netduinos are so expensive. Couldn’t you just rewrite this for Arduino?” I have put years of work into this project and to start again using the Arduino platform is just not an option for me.

I have however just ported the code to TinyCLR. TinyCLR OS is a modern, managed operating system that brings .NET to embedded devices. It offers garbage collection, threading, and full debugging which allows you to step through code and inspect variables. No costly debugging tools are necessary.

GHI have produced an Arduino compatible board which runs C# and only costs $10. Whilst this isn’t as cheap as the $3 Arduino clone from China, it is much cheaper than the Netduino and should hopefully reduce the barrier of entry for some people.

I purchased one of these boards and spent the day porting the code to TinyCLR rather than NETMF and have labeled it V2.0.0.

TinyCLR is used on the latest Visual Studio 2019 which is much easier for people to get installed. I might even be able to supply precompiled binaries to deploy without even having to install Visual Studio. I’ll investigate this further to see what is involved.

The features are identical to v1.1.0 except for the ability to see the uptime of the unit. I haven’t worked out how to invoke native code yet as uptime is not yet available in the managed libraries.

The other important thing to say is GHI have made TinyCLR available for a number of other boards including Netduinos. So if you have a compatible board, you could flash the bootloader and then flash the TinyCLR version of the code on.

I have not yet updated the instructions on how to flash the TinyCLR version yet, created a GitHub release or even updated the GitHub readme but I will get there eventually. Send me a pull request if you want to help.

All code is available at https://github.com/m1dst/Trimble-Thunderbolt-Monitor

This is all the news for now. If you have any thoughts, feedback or comments, send me a tweet or email.

I presented a talk on 3D printing at the upcoming RSGB Convention. It was one of the first talks on Saturday morning.

I introduced you to the fascinating world of 3D printing where you learned about the different 3D printing methods with a focus on inexpensive FDM machines. You left with an understanding of how the machine works and how 3D printing could be used as a tool to improve your Amateur Radio life. We discussed the tools used to take an idea from your head to become a finished item.

I promised to post slides to the presentation here. I have provided two files. One is just a PDF which is ideal if all you want to do is review the data tables I showed. The second file is over 100MB but contains some of the videos you were not able to see on the day.

Please feel free to send me email or tweets with any feedback.

This past weekend I decided I wanted to enter the IOTA contest. Over the years I have entered with the Swindon Radio Club but more recently we have entered as individual entries.

I decided I wanted to try something different, something hard. What could be harder than being at the bottom of the solar cycle? How about QRP? Yes.

In the UK we’ve had tremendous weather for weeks which meant it was going to be great being outside in the sun, playing radio. What could be better? Then the weather changed just before the contest started. Rain, wind and some occasional lightning.

I set myself the target of 100 QSOs but didn’t quite achieve it. Roll on next year.

Many years ago I created a monitor for my Trimble Thunderbolt GPSDO which I use to lock my K3S and various other equipment to a solid frequency standard. Over the years there has been tremendous interest in the project as I have made the entire thing opensource. If you want to find out more then please see the following links…

Recently I was contacted by Lucas, W6AER who had just finished building his version. He was so pleased he gave a talk to the San Francisco Radio Club. He is using his GPSDO with his Flex radio. He was kind enough to send me some photos and a link to his write up. https://w6aer.com/10mhz-gps-disciplined-oscillator-gpsdo-trimble-thunderbolt/

The MFJ-269 suffers from being accidentally switched on when in the box. Newer models have had a switch guard added as standard. I don’t actually like the design of the official MFJ improvement on the 269B as I find it hard to switch on.

My 269 is not the B revision and required improving to ensure it could only be switched on when required. I designed two different guards.  One is solid and hides the screw heads, the other looks nicer.

The STL files are available here and on Thingiverse.

This weekend I switched on the K3S and operated in the CQWW SSB contest. It wasn’t a serious entry as family life still needs to continue. Sam managed to keep the kids safe, fed and entertained for most of the time allowing me to operate. I had a couple of technical issues at the start of the contst. My Ultrabeam was showing a high SWR which almost stopped me taking part at all. In the end, I remembered there is a calibration routine built into the controller. Once I recalibrated the antenna all was well. The other issue is RS232 stopped working around the time I was fixing the antenna. This turned out to be a hardware fault. I hadn’t screwed the DB9 into the back of the P3 and it had fallen out. Doh! Fixed and no more issues.

My target was at least 400 QSOs, 55K points, 20 Zones and 80 DXCC. I didn’t reach the zone or DXCC targets this time. I made 3 QSOs as a result of a CQ call and the rest were all S&P.

Contest         : CQ World Wide DX Contest
Callsign        : M1N
Mode            : PHONE
Category        : Single Operator - Assisted (SOA)
Overlay         : ---
Band(s)         : Single band (SB) 20 m
Class           : Low Power (LP)
Zone/State/...  : 14
Locator         : IO91CN
Operating time  : 12h15

 BAND   QSO  CQ DXC DUP  POINTS   AVG 
--------------------------------------
  160     0   0   0   0       0  0.00 
   80     0   0   0   0       0  0.00 
   40     0   0   0   0       0  0.00 
   20   400  18  78   0     577  1.44 
   15     0   0   0   0       0  0.00 
   10     0   0   0   0       0  0.00 
--------------------------------------
TOTAL   400  18  78   0     577  1.44 
======================================
         TOTAL SCORE : 55 392

Dupes are not included in QSO counts neither avg calculations

Operators       : M1DST
Soapbox         : A fun but not serious entry.

Many contest groups around the world use a hotel/butler bell to indicate a multiplier has just been worked. Jeeves is a modern, automated replacement for the bell which can be installed in or away from the working area. It also doubles up as 12v lighting for the area.

When a QSO is logged, a packet is broadcast from N1MM+ which Jeeves captures and inspects. Depending on the multiplier status of the QSO, the LED string changes colour and dances to match the 8 possible states. This is ideal for contest sites where the communal area is away from the working area and a bell may not be heard. It allows the non operators the fun of keeping track on the progress of the contest. A bell also sounds for 25ms.

My installation now requires no setup for a contest other than plugging into a 12v source (and mains if the bell is to sound).

Hardware

  • ESP8266 – I used a WeMos D1 Mini ~ £3.50
  • 5V Relay Module ~ £2.50
  • 5M string of WS2812 LEDs (300) (12v) ~ £15
  • 5V DC/DC to power the ESP from 12V
  • Small plastic enclosure – I designed and 3D printed mine including the powerpole clamps. STL available if requested.
  • Smoothing Capacitor – Connect a big capacitor from power to ground (LEDs). A cap between 100µF and 1000µF should be OK.
  • Mains powered bell – a 12V bell is more ideal but I couldn’t find one at a reasonable price. ~ £9.00

It might be possible to use one of the ESP8266 boards available with a built in relay if you can ensure that you can access spare IO pins to run the LEDs.

It is important to use 12v LEDs and power them directly. You will not be able to power these from the ESP device. Also, consider that you can use even longer runs of LEDs by purchasing another string and plugging it into the end of the original. The only thing to consider is the volt drop so be prepared to feed 12v directly into each string. If you don’t then you will find the LEDs may sparkle or not show the colour you are expecting.

Setup

  • Download the code from https://github.com/m1dst/Jeeves
  • Set your SSID and password by changing the const values.
  • Change LED_COUNT to match the number LEDs in your string.
  • Validate that the data pins in the config represent the pins you are connecting to.
  • If you DO NOT want the lights to indicate a non mult QSO was logged, comment out the DISPLAY_EVERY_QSO definition at the top of the sketch.

Video

Future Expansion Ideas

  • Sniff the current score broadcasts and perhaps expose to a responsive web interface.
  • Perhaps post a message to an MQTT queue for further processing.
  • The default state of the LED string is white which is perfect for lighting in a tent. Lighting may not be required during the day. Perhaps use NTP to work out the time of the day and hardcoded/GeoIP to determine the rough location or country.
    With this information, it would be possible to calculate sunrise/sunset and set the brightness accordingly.
    There is no point in white lights showing during a bright sunny day consuming energy.
  • Win-Test – Not currently possible to check multiplier status due to the limited information Win-Test broadcasts via UDP. QSO logged and status should be possible though.