Amateur radio, programming, electronics and other musings

All posts in Projects

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/

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.

I received an email from someone in the US who had just built one of my Thunderbolt Monitors. He casually asked if there was a way of showing EST rather than UTC on the display. Whilst on a computer this would be easy, it is a little harder on NETMF due to the fact it doesn’t understand timezones. It isn’t just a case of subtracting 5 hours from the UTC time as we also need to consider daylight savings time.

After some research, I put together a code change which appears to work for him and should handle the daylight savings rules too. Before I share the code I must warn you that this is a little rough but solves the problem. I will not be releasing this in the main branch but you should be able to hack it in if you really want it.

Add the following to the end of the class of program.cs.

public static bool IsDaylightSaving(DateTime dt)
{
    var dow = (int)(dt.DayOfWeek);

    // January, February, and December are out.
    if (dt.Month < 3 || dt.Month > 11) { return false; }

    // April to October are in
    if (dt.Month > 3 && dt.Month < 11) { return true; }

    var previousSunday = dt.Day - dow;

    if (dt.Month == 3 && dt.Day >= 8 && dt.Day <= 14 && dow == 0)
    {
        return dt.Hour >= 2;
    }

    // In March, we are DST if our previous sunday was on or after the 8th.
    if (dt.Month == 3) { return previousSunday >= 8; }

    if (dt.Month == 11 && dt.Day >= 1 && dt.Day <= 7 && dow == 0)
    {
        return dt.Hour >= 2;
    }

    // In November we must be before the first Sunday to be DST.
    // That means the previous Sunday must be before the 1st.
    return previousSunday <= 0;

}
 
public static DateTime ConvertToEasternTime(DateTime dt)
{
    var utcOffsetHours = -5;
    if (IsDaylightSaving(dt))
    {
        utcOffsetHours += 1;
    }
    return dt.AddHours(utcOffsetHours);
}

Change references of :

string mode = _thunderbolt.TimingMode == TimingModes.UTC ? "U" : "G";
_lcdshield.WriteLine(0, DateTime.UtcNow.ToString(@"dd-MMM-yy " + mode + " HH:mm:ss"));

to

string mode = "E";
_lcdshield.WriteLine(0, ConvertToEasternTime(DateTime.UtcNow).ToString(@"dd-MMM-yy " + mode + " HH:mm:ss"));

I changed the U/G to an E to signify Eastern time but feel free to ignore that or even replace it with just a space instead.

A number of people have had trouble sourcing the Netduino boards and asked me for help. I have now added support for the GHI FEZ Lemur board which is a perfect replacement for the Netduino devices. They seem to be in stock from places like Mouser which is also handy.

In theory, we should be able to get this working on any pin similar board such as the GHI Panda III or Cobra III etc. If you have a board you need support for, let me know and I’ll roll out a new project. I have simplified the projects to use shared files and ifdefs so it is quite quick.

See: https://github.com/m1dst/Trimble-Thunderbolt-Monitor

For the PCB see https://www.m1dst.co.uk/shop/

You may find your Trimble Thunderbolt Monitor is showing the incorrect date at the moment.  It could be showing the year as 1997.  This is due to the date in the Thunderbolt being reported incorrectly.

GPS Time is a continuous counting time scale beginning at the January 5, 1980 to January 6, 1980 midnight. It is split into two parts: a time of week measured in seconds from midnight Sat/Sun and a week number. The time of week is transmitted in an unambiguous manner by the satellites, but only the bottom 10 bits of the week number are transmitted. This means that a receiver will see a week number count that goes up steadily until it reaches 1023 after which it will “roll over” back to zero, before steadily going up again. Such a week rollover will occur approx. every 20 years. The last week rollover occurred in 1999 and the next one will be in 2019.

The Thunderbolt manual states…

The ThunderBolt adjusts for this week rollover by adding 1024 to any week number reported by GPS which is less than week number 936 which began on December 14, 1997. With this technique, the ThunderBolt will provide an accurate translation of GPS week number and TOW to time and date until July 30, 2017.

The Thunderbolt can now not be trusted to give the accurate date and time and the responsibility of the time correction has now been forced onto the hardware/software which is reading data from the Thunderbolt.  I have written a fix and released v1.0.4 which attempts to correct the time.  Please visit https://github.com/m1dst/Trimble-Thunderbolt-Monitor and download the latest version.  Give it a try and report back any issues.

It is very likely I will have to patch again when the GPS system rolls its week over on April 6th 2019.

I would just like to advise any recent / future purchasers of the Thunderbolt Monitor PCBs that I ordered the PCBs almost 1 month ago and they have yet to arrive. I have followed up with the supplier and they are going to repeat the order.

Very sorry for the delay but I will post as soon as they arrive.