All posts by M1GEO

Batteries, Engineering

Fogstar Drift PRO Battery Interfacing

I recently purchased a Fogstar Drift PRO battery to use in my motorhome for leisure power. The battery has RS485 and CAN connectors on the top. This page documents what combination of things worked for each interface.

At the moment, this is just a dumping ground of what works and what doesn’t. The plan is to update this information as I get more working.

It appears the BMS version is ‘JBD-SP04S060-300A-L4S’.

CAN bus

Controller Area Network, or CAN, bus interface is a robust vehicle bus standard that enables communication between electronic control units (ECUs). It has grown widely and is commonly used in industrial control.

RJ45 connection: CAN socket on battery

Pair:

  • CAN-H: Brown/White (RJ45 pin 7)
  • CAN-L: Brown (RJ45 pin 8)

Speed: 500k

If the BMS is asleep, you must send data to field ID 0x35E to wake the BMS and to let it know there is a controller present. Documentation I found suggested sending 8 bytes of 0xFF to the field, but it didn’t seem to mind what the data was. Once awake the BMS will stream for about 20 seconds before sleeping again. Guidance seems to be to periodically send something to field ID 0x35E to keep the BMS awake.

I tried to parse the data from the CAN interface using the Victron protocols. The data isn’t fully VE.Can compliant, but sends “Victron compatible” data, including fields such as 0x351 (battery status), 0x355 (voltage limits), 0x356 (temperature & capacity), 0x35A (cell voltages), and the aforementioned 0x35E (kick message, sent to BMS from host).

The protocol seems to be a broadcast only protocol (after the kick message to wake the BMS) following a JBD telemetry scheme.

I did play around with the data, but got less useful results than with RS485, so I stopped and moved on. Here’s as far as I got; you can see that there is some nonsense…

Field IDRaw Data (8-bytes)Notes
0x00000351
(battery status)		93 00 70 17 70 17 6c 0093 = charging permitted, discharging blocked.
00 = no errors
70 17 = 0x1770 = 600A max charge
70 17 = 0x1770 = 600A max discharge
6C = 108% state of charge (!?)
0x00000355
(voltage limits)		50 00 64 00 00 00 00 0000 50 = 0x0050 = 8V max charge voltage (!?)
64 00 = 0x0064 = 10.0V min discharge voltage
0x00000356
()		42 05 32 00 dd 00 00 00Temperatures?
0x0000035a a8 aa 82 02 a8 aa 82 0aCell voltages, 24-bit?
0x0000035e 44 72 69 66 74 50 72 6fASCII: “DriftPro”
0x0000035f 00 00 42 00 e1 01 00 00Status/capacity?
E1 01 = 0x01E1 = 481 Ah, battery capacity
0x00000370 45 50 4f 43 48 00 00 00ASCII: “EPOCH”

RS485 & ModBus

RS485, also known as TIA-485 or EIA-485, is a standard defining the electrical characteristics for serial communication. It’s commonly used in industrial settings due to its ability to transmit data over long distances and in electrically noisy environments.

The first option to explore is to use ModBus over RS485 to see what we can find. ModBus is a client/server data communications protocol in the application layer, originally designed for use with programmable logic controllers (PLCs). It has become a de-facto standard communication protocol for communication between industrial electronic devices in a wide range of buses and networks. For this reason, it’s a good bet to start with on our BMS.

RJ45 connection: RS485 socket on battery

Pairs:

  • A+: Brown/White (RJ45 pin 7)
  • A-: Brown (RJ45 pin 8)

Speed: 9600

Protocol: ModBus

Slave ID: 1

Can read registers and the data seems accurate. Used a simple MAX485 part coupled to a UART with a test Python script that scanned baudrates, and slave IDs trying to read registers.

The image below shows QModMaster scanning Modbus registers using function code 0x03 (read holding registers):

Guessing at some register values:

Register AddressRaw DataNotes
03700Cell OVP, 3700mV
13500Cell OVP release, 3500mV
22500Cell UVP, 2500mV
32600Cell UVP release, 2600mV
41470Pack OVP, 14.7V
51440Pack OVP release, 14.4V
61080Pack UVP, 10.8V
71100Pack UVP release, 11.0V
1660000Maximum charge/discharge current, 600.00A
1760000Maximum charge/discharge current, 600.00A
181345Battery voltage, 13.45V
19508Battery current, charging 5.0A
2038562Current battery capacity, 385.62Ah
21-243364-3366Individual cell voltages, ~3.365V
25-370Unsure? Always 0
3948185Maximum battery capacity, 481.85Ah
4080Battery state of charge, 80%
413FETs status:
bit-0: Charge FET (on)
bit-1: Discharge FET (on)
420Changes with reg-41 (went to 4096 when discharge was disabled)
????NTC1, 25.1C
????NTC2, 22.1C
????NTC3, 22.1C
????Cycle Count, 13

RS485 & JBD Proprietary Protocol

The JBD BMS application seems to parse some data from the JBD-SP04S060-300A-L4S BMS, as can be seen below. Note that not all data is parsed correctly, as the Drift Pro likely has custom firmware.

The opensource bms-tools project also parses the data from the JBD-SP04S060-300A-L4S BMS, and looks remarkably similar to the JBD tool, though it is written in Python. This makes it a great resource for copying sections of code!

My end goal is to make a display for use in my campervan showing the key metrics from the battery. Using ModBus, I couldn’t find registers containing the number of cycles or the temperatures. I would like to have these displayed.

It is clear the values I want are present in the datastream, all that remains is to parse the JBD protocol to get it.

CW, Ham Radio

An easy-to-build interface for Morse Paddles & Keys…

I recommend Ham Radio Duo’s video on Morse Code Tools: CW Practice and Games (N4BKY & N4FFF) for a more detailed overview. Most of the tools here are covered in their video!

When learning CW there are many online practice tools:

  • Morse Invaders (KE6EEK) – a simple game for practicing sending morse in a space-invaders style – very addictive!
  • Morse Code AI Chat Bot (N4BKY & N4FFF) – an AI chatbot that sends and receives CW
  • V-Band () and Vail () – online ham-band platforms where you can practice CW with others
  • Morse Code Battleships (N4BKY & N4FFF) – an interactive battleships game with CW interface

I really also like MorseWalker (W6NCY), a joke on the contest practice software MorseRunner (VE3NEA). I really enjoy using MorseWalker – but it’s receive practice only.

For those that need CW paddle input, you really want to be using an interface – that way, you can connect your favourite key (or, failing that, the key that you’ll be using) to your computer and practice sending with that key…

Interfacing Options

There are a couple of existing interfaces:

  • The Vail Adapter is a full project with custom PCBs, etc., and works well.
  • The VBand Adapter can be purchased from their site.

Because I am impatient and had the parts, I decided to build my own.

The Build

I took inspiration from the OZ1JHM’s hamradio-solutions-vband-interface code. I am mainly interested in the paddle operation, but, you could modify this code easily to just send a single keyboard-button press for the straight key.

It’s important to note that you’ll need an Arduino where USB is directly connected to the Arduino chip and not via an UART IC since these only support UART ports and can’t emulate a keyboard. This means that you cannot use devices based around the Atmega328P.

The code below is for an Arduino Pro Micro (I used a USB C version) which is based on the Atmega32U4:

You’ll also need a way to connect your key easily. I used a moulded 3.5mm (1/8in) stereo socket on a short cable (available online cheaply) to create a nice connection, that would allow me to easily plug & unplug my key.

It is then fairly straightforward to make the 3 solder joints needed:

  • Black: GND
  • Red: A2 (dit)
  • White: A3 (dah)

You may have to tinker around with the connections a little bit to get your radio, the adapter and your key to work interchangeably. Above is what it ended up being for me.

Above, taken from the manual of my Icom IC-7610. I have wired the Arduino to have the same polarity as the radio, assuming this to be the standard. Note, the radio uses a 6.35mm (1/4in) jack, not the smaller 3.5mm (1/8in) as we’re using.

And you’re ready to program the MCU! We’ll finish up with the hardware once we’ve checked it works!

Arduino Pro Micro Code

// Include the keyboard drivers
#include <Keyboard.h>

// Pin Definitions: Where the paddle pins connect.
// Note: Closing the contact should ground these pins.
# define DIT_PIN 2
# define DAH_PIN 3

// Arduino setup code
void setup() {
  pinMode(DIT_PIN, INPUT_PULLUP); // en internal pullup (dit)
  pinMode(DAH_PIN, INPUT_PULLUP); // en internal pullup (dah)
  Keyboard.begin(); // start keyboard runtime
}

void loop() {
  // While no paddle button is pressed, release all keys.
  while (digitalRead(DIT_PIN) == HIGH && digitalRead(DAH_PIN) == HIGH){
    Keyboard.releaseAll();
  }
  
  // On DIT pressed, send LEFT CONTROL key, else release
  if ( digitalRead(DIT_PIN) == LOW){
    Keyboard.press(KEY_LEFT_CTRL);
  } else{
    Keyboard.release(KEY_LEFT_CTRL);
  }
  
  // On DAH pressed, send RIGHT CONTROL key, else release
  if ( digitalRead(DAH_PIN) == LOW){
    Keyboard.press(KEY_RIGHT_CTRL);
  } else{
    Keyboard.release(KEY_RIGHT_CTRL);
  }
  
  // Wait 5ms
  delay(5);   
}

Tidying it up!

Once you’re happy it is working as you wish, an optional step for longevity is to protect the PCB. I did this by first applying a dot of super-glue to the cable and attaching it to the back of the PCB (note how I brought the wires out on that side).

Next I used some heatshrink tubing to cover the board, protecting everything.

And, you’re good to go!

With that, you’re ready! Connect your key, connect your USB cable, and you can practice until you’re CW is perfect!

Ham Radio, POTA, Software

Finding Local Unactivated POTAs

The information on this page has been superceeded by my web-app: george-smart.co.uk/pota/unactivated

The rest of this page us left for interest…

The earlier page…

With Parks on the Air (POTA) becoming a relatively new thing in the UK, I decided to activate a few local parks. It quickly became apparent that many of the local parks had never been activated before. I decided that I would concentrate on those.

I suspect that they hadn’t been activated before because they required a bit of a walk to get to. What with it being winter and wanting to get out of the house, I kitted up my backpack with my Icom IC-705, my EcoWorthy 8Ah LiFePo4 battery (see my notes on IC705 power vs voltage) and a few antenna options. Over the course of a few evenings, heading to a different park each night after work, I activated the parks I had seen on the POTA App Map. I wanted a way to find any parks that were local, but that hadn’t been activated.

With services like SOTL.AS for Summits on the Air (SOTA), it’s easy to filter the map to only show specific things, like removing summits you’ve activated, or setting a minimum number of activator points, or showing only summits that haven’t been activated before. Unfortunately no such service exists for POTA (yet). If you’re reading this and considering doing something similar, check out SOTLAS first 🙂

The POTA website does offer all_parks.csv (list of all POTAs) and all_parks_ext.csv (list of all POTAs with location information). However, neither of these files have the information I was looking for: the number of activations or attempted activations. Disappointing, but I didn’t give up that easily! I did some digging!

By searching the POTA ParkList for parks in my country, in my case “GB-ENG”, I was able to see the information I needed. At this stage, you could just sort the columns by activations, and skim through looking for close places. However, I wanted to do better than that! I wanted to create a program that would list them by how close they were to me.

The observant amongst us will have noticed the “DOWNLOAD” button, that yields a CSV file for us. You may have to be logged in to see this, as it contains information personal to you (your activations, and hunts). I missed this the first time and subsequently copied and pasted the information manually from the webpage into a spreadsheet and exported it to a CSV which took about 5 minutes!

Regardless of how you chose to obtain the information, you’ll end up with a CSV file. Mine was called “England.csv”. The data inside is really useful and includes the latitude and longitude of each marker. Any program would just need to work out how far each site is from a given location (say, your home QTH) and then sort the output by distance. It could filter on attempts or activations, too.

The Program

So I set about writing a simple Python program (really more of a script) that lets you explore your POTA CSV file and (most importantly for me) find the closest unactivated POTA parks.

The code can be found on GitHub: https://github.com/m1geo/POTA-Finder. It runs in a command terminal window on any OS that will run Python3. It has a simple help function, and minimal error checking as it was an evening project. The source code should be easy enough to tinker with should you wish to add, change, remove functionality.

Calling the program with the -h help flag will output the above information to help you get started. You can set the --max-activations to 0 to show unactivated parks, like this:

You can also use the shorter command-line options as below, and supply a lat/long as here:

And with that, you can pack your kit in the car and head out for a POTA activation…

Ham Radio, Holiday, SOTA

Measuring the Icom IC-705 RF Power vs DC Input Voltage

Introduction

In the summer of 2024 during a Camb-Hams trip to Friedrichshafen, I was drawn into the world of SOTA (summits on the air). A key requirement for SOTA activations is a compact, lightweight and effective station.

When I got started, I was able to use Rob M0VFC‘s Elecraft KX2 portable transceiver. However, from our third SOTA activation of the holiday I was taking my own Icom IC-705. My CW is not great, and so I was activating on SSB mainly on HF (and some FM on VHF/UHF). The IC-705 was a little easier than the internal microphone on the KX2. Rob M0VFC was kind enough to loan me use of his 3S LiPo battery, but I noted that as soon as the voltage dropped a little from full (4.2V * 3S = 12.6V), the IC-705 power was reduced considerably. This was also apparent on the KX2, but isn’t usually an issue because the SOTA pro’s use CW. Anyway, a challenge to know what I needed to do was born… I needed to understand how the IC-705’s RF output power changed as a function to the DC input voltage. I set up a simple test…

The radio specification states 13.8V ± 15%, which gives us an absolute voltage range of 11.73V (13.8V-15%) to 15.87V (13.8V+15%).

Setup & Method

The test setup was simple. My IC-705 connected to a high quality lab power-supply (Rigol DP821), accurate voltage and current readings for DC input power (two Keysight 34401A multi-meters) and a way to measure RF output power (Keysight N9010B spectrum analyser & 30dB attenuator).

The input voltage and current could be measured and adjusted in real time and the input power would be calculated for each test. The RF output power was measured at the frequency of interest.

During all testing the external battery was removed from the radio so that the battery charging current did not confuse measurement. To generate RF, the radio was set into RTTY mode at 100% power (thus creating a pure tone at full power). Each test was automated, and tested quickly to avoid heating issues in the PA.

Initial Results

I measured things at both ends of HF (160m and 10m), and on 6m, 2m and 70cm. The results were consistent with the drop of output power I had noted. More importantly for the initial results, I could see that the behaviour was consistent across all bands, so I could concentrate testing on a single band, and take more detailed steps without creating extra work.

In every test, the power above 13V was very consistent, likely due to ALC on the PA. The efficiency slowly dropped as the input voltage increased. Below 13V, the power was observed to fall.

Further Testing

After the initial testing, I started digging a bit more into what happens between 11 and 13 Volts input. Working downwards from 13V there is a clear linear drop-off until around 11.8V where the software senses the falling voltage and drops to the 5W mode. At 11.6V the radio alternates between the 5W battery limit and the higher power (about 7.5W). This 11.73V threshold that the specification mentions (13.8V-15%).

For useful purposes, we need to keep the DC IN voltage above 11.8V (and below the maximum of 15.87V).

Battery Choices

Assuming we want to keep with a modern battery technology (so, excluding NiCd and NiMH), we have two obvious choices of lithium-ion battery:

  • Lithium Polymer (LiPo) battery
  • Lithium Iron Phosphate (LiFePO4) battery

For each battery pack, there are different combinations of series (S) and parallel (P) configurations, detailed using this “S” and “P” notation. For example, you may see a “3S4P”, referring to three series sets of four parallel batteries. Parallel-ing the batteries increases current handling and overall power, and the voltage is unchanged. Series-ing the batteries increases the voltage and overall power, but the current is unchanged.

Each battery technology has a different nominal voltage (the assumed cell voltage), charged voltage (the maximum cell voltage) and the discharge voltage (the minimum cell voltage). A battery will often have a BMS (battery management system) to take care of protecting the battery from over-charging, over-discharging, balancing (keeping the voltage across series cells equal), etc., but these are out of scope for this page.

LiPo

Typical Lithium Polymer (LiPo) cells have a nominal voltage of 3.7V. Fully charged, each cell is 4.2V. Fully discharged, each cell is 3.2V.

See more on LiPo cells on Wikipedia.

LiFePO4

Typical Lithium Iron Phosphate (LFP, or more commonly LiFePO4) batteries have a nominal voltage of 3.2V. Fully charged, each cell is 3.65V. Fully discharged, each cell is 2.5V.

They have a higher cycle rating than standard LiPo batteries, meaning they can be charged and discharged more many more (>60% more) times before they start to fail.

See more on LiFePO4 cells on Wikipedia.

Why not use X?

I have tried to limit my choice to batteries that are widely known and in production. I have seen AliExpress selling Sodium-Ion batteries and other similarly novel battery technologies, but without easy access and known reliability, I didn’t include them.

See more experimental battery types on Wikipedia.

Battery Comparison

From the IC-705 testing and the specification as well our two battery choices, we can see what options are available.

Extrapolating from the two battery types above, we can see that configurations in the right kind of area are as follows:

Unfortunately, there is no ideal solution with these battery technologies. It is kind of disappointing that Icom did not consider this when designing the radio – a small design tweak to take 17V would have allowed LiPo 4S battery packs to be used. Instead, the best option is LiFePO4 4S. However, as the battery discharges, the lower voltage becomes an issue.

From the tables above it is possible to see that the only real options are LiPo 3S and LiFePO4 4S since the other combinations have the ability to supply excessive voltage (>15.87V) to the radio. Of these two, the LiFePO4 4S has a higher maximum voltage (14.6V vs LiPo 3S at 12.6V). For this reason, the LiFePO4 4S is my preferred choice. LiFePO4 has the added advantage of a higher cycle count and increased safety too, so those are further marks on the LiFePO4 scorecard.

The voltage decision is made: LiFePO4 4S. Now for the capacity of the battery…

Battery Capacity

The 4S battery fixes the pack voltage to a nominal 12.8V. For the capacity, it’s just a case of estimating how much current the radio will draw and then using this to infer the battery capacity you require in “Amp-Hours”.

The IC-705 draws around 220mA (0.22A) in receive from the external power supply at 12.8V (our nominal LiFePO4 4S voltage). If we would like the radio to run on receive for an evening, say 6 hours, we’d need a battery to run 0.22A * 6h = 1.32Ah.

In reality a SOTA activation will be around 50% transmit (at ~2.1A) and 50% receive (at ~0.22A). However, the activation will probably be quite short, perhaps 30 minutes, perhaps 2 hours. By working out the average current used during an hour, an approximate runtime can be calculated for any battery or a battery capacity specified for a given desired operating period.

The final, and perhaps most important consideration for battery capacity is weight! The typical way to expand the current capability of the battery is to parallelise cells; which in effect means doubling the number of them – in our case, doubling or 4-series-connected cells, thus creating two interconnected strings of 4 cells, totalling 8 cells. This becomes a 4S2P battery pack as we discussed earlier. The capacity is doubled. But, so is the weight!

So, what did I buy?

In the end I bought a LiFePO4 4S1P battery made from 3Ah cells. This gives me a 12.8V nominal, 3Ah battery which will run the IC-705 on receive for around 13 hours, or a mix of SSB TX and receive for around 4 hours.

Feeling Brave? Try a LiPo 4S?

Shortly after writing this, I was on a discussion online and someone told me that they had run their IC-705 on a 4S LiPo pack for years and the radio had been fine. They mentioned that it stops charging the battery when the input voltage was above 16V (already out of spec) but that they had happily used 16.8V inputs (actually in excess of 17V) with no damage to the radio.

In a moment of madness, I tried 17V input and noted that (a) the IC-705 does stop charging the internal battery, (b) the HF noise floor was quieter (likely due to the battery charger powering off) and (c) that the radio didn’t explode and still delivered 10W. The radio’s voltage readout caps at 16V on the meter display and the voltage quick menu shows “Hi Voltage” instead of a number. See the two images below showing the difference at 16.9V input (from my 4S LiPo pack).

Maybe not the best thing to do long term, but it could help get you that that much needed QSO on a wet and windy SOTA…

Computers, Ham Radio, Measurement, Retro-Computing

Marconi 2955 Firmware Upgrade

At Friedrichshafen Ham Radio flea-market 2022, I bought an old tired Marconi Instruments Radio Communications Test Set 2955 which I have spent a bit of time restoring. I now have it passing all of it self test, and the functionality seems good.

During the time I spent digging through the service manuals (link here) for the unit and my time exploring the Marconi Instruments GroupsIO, I noticed there was an updated firmware for the unit. Mine shipped with the very earliest V10 firmware. I saw ROM files in the forum Files section for V16. There are some upgrades from V10 to V16, though, rumour has it that anything above V13 isn’t much of an upgrade unless you’re using some of the cellular testing accessories. The V16 firmware files can be found here inside the Marconi Instruments GroupsIO Files section (along with many other useful things). Definitely a very useful group with knowledgeable people inside!

Below, we see the original version 10 firmware, dated 1986.

The EPROMs which need upgrading are IC9, IC10, IC11 & IC12 on the processor board. These are three of 27C128 128kbit (16kByte) EPROMs [IC9-IC11] and one of 27C64 64kbit (8kByte) EPROM [IC12]. I replaced all mine with the larger 128kbit 27C128 parts, copying the 27C64 binary image into both the lower (offset 0x0000) and upper (offset 0x2000) halves of the EPROM, so irrespective of the state of pin A13, the data output would be the same.

Rather than UV erase the original EPROMs in the machine, I purchased additional ones online (I got mine from AliExpress, but eBay, etc., all sell them). Mine ended up being brand new, never used, but previous ones I’ve bought were pulled from old equipment and needed erasing beforehand.

Using an EPROM programmer, I programmed the four 16kB ROMs onto the blank chips. This took around 10 seconds each using my TL866ii+ programmer.

To change the EPROMs in the Marconi 2955, you need to remove the top cover to be greeted with the insides of the 2955. The CPU board (AB4) we need is inside the locked metal cover. These are rotate-clips, not screws, so go easy on them!

Once you’re inside the metal screening box, you’ll see some boards stacked into the main motherboard along the bottom. We need CPU board AB4, which is the 3rd board up from the bottom of the picture (closest the screen). Use the ‘ears’ on the side to help lever the board from the motherboard socket below and slide the board out.

The CPU board AB4 is shown below. You can see the manufacturer stickers on 3 of the 4 larger EPROMs and the smaller flash EEPROM. From left to right, the 4 stickered devices are IC13, IC12, IC11, IC10 and the final, rightmost is IC9 with missing sticker (it had fallen off inside the machine).

IC13 is a flash chip (Xicor X2816AP) with your unit’s calibration data stored within – don’t overwrite this one any online! You can of course read/back up your calibration data if needed. I decided to copy my flash EEPROM IC13 into a new part, so that I could keep all of my older V10 PROMS together. I was worried that if something went wrong and the V16 firmware had ‘updated’ the formatting of the data in IC13, I may not be able to go back. I used a CSI CAT28C16AP that I had in the shack as I wasn’t originally intending to touch IC13. If you decide to replace IC13 also, I would suggest getting the exact part used in case it matters. These early flash chips are a bit fussy with timings, etc., and so interoperability isn’t guaranteed. That said, mine has been fine.

The 5 devices were replaced. I used a label printer to sticker each ROM as I wrote and verified its contents. The original chips were placed inside an antistatic IC tube, and wrapped in ESD-safe bubble-wrap , which I tucked inside the machine between the screened box and the power supply cabling on the motherboard. They sit nicely there, can’t move, and will be available should anyone wish to revert the machine.

After reassembling the unit, I fired the test-set up, and to my relief it booted straight up!

I was able to confirm the firmware upgrade had worked – below we see the software version is now version 16 (dated 1992).

Pressing the self-test button confirmed the basically functional. Excellent!

Construction, Design, Engineering, Ham Radio, Measurement, PCBs

Symmetricom GPSDO Enclosure

While tinkering with a homebrew GPSDO project, I spent a bit of time searching the depths of the internet for information and parts for my project. I found a PCB for a Symmetricom GPSDO (specifically the Symmetricom 089-03861-02 as per the PCB silkscreen in my case, although the firmware reports itself as 090-03861-03). The board was cheap because the OCXO was missing – I suspect it had aged beyond where the error voltage range was specified, making it unusable. But the board was around £15 GBP delivered from AliExpress, so I took a chance on it based on the fact it had a Furuno GT-8031F GPS receiver which is a GPS module specifically designed for timing applications which “delivers highly accurate GPS timing”. The module also had a CPU (Renesas F2317VTE25V-H8S/2317) with accompanying flash and RAM ICs as well as a Xilinx Spartan-3 FPGA (XC3S200).

Besides the missing OCXO module, my board worked perfectly. I was able to piece most of the information together from the following two resources:

I saw that some people had put their units into Hammond Manufacturing project boxes, and that gave me a few ideas. It would be nice to box the unit up with some ancillary electronics to share the UART (57600 baud, 8N1) over Ethernet TCP/IP. However, my experience of UART to Ethernet modules has always been poor and friends reported similar, so I opted for an FTDI-based USB interface (namely the FT232RL, as the cheapest/easiest part during the chip shortage of 2019-2022). I was tempted to use a Maxim MAX232 device to perform the necessary conversions, but, in the end opted for two NPN transistors – a bit hacky, but much cheaper. I may well come back to the Ethernet option in the future.

The carrier takes 5V at around 2A input on a 2.1mm x 5.5mm DC power socket, a USB-B connector and holds five LEDs: four main LEDs from the GPSDO (which are connected to test-points on the PCB, I can’t find the LED signals on any connector), plus one LED from the FTDI device showing USB activity.

The image below shows where the LED signals are taken from. For reference, the big IC in the centre is the Xilinx Spartan FPGA:

The LED signals are all common anode, fed from +3.3V taken from the board. The LEDs are fed through a resistor, and the individual cathodes connect back to either the CPU or FPGA through another of the wires:

  • RED: +3.3V supply used to power the LED anodes
  • BROWN: Alarm
  • WHITE: Activity
  • YELLOW: Heartbeat (DS2)
  • ORANGE: Error (DS1)

There are two other LED signals (DS3 and DS4) which aren’t connected.

From here, I created a carrier board which had the correct mounting holes for the Symmetricom module, and offered front LEDs to show status, an easy 5V interface and a USB-UART interface to the module control port. The final board looks as below:

With the module fitted, the board looks more like the following. Note, this was an earlier version of the PCB:

The project was designed to fit inside a Hammond Manufacturing 1455N1601BK case which takes a 160mm long by 100mm wide PCB, and the designed PCB fits the case nicely. By default, the Hammond case comes with either aluminum or plastic end plates, but I went to the effort to make PCB front and rear plates to enclose the case. Using PCB meant I was able to use tools I was familiar with to create the end places, and use the same order as the main carrier PCB. The copper on the PCB could be used to create a metal Faraday screen to enclose any electrical switching noise, and the silkscreen could be use to add legends, logos and decals.

I prototyped the designs as below in the PCB package and then used my laser cutter to test them out for fit. A test fit of the front panel is shown below:

The below picture shows the PCB end boards as they arrived and the cardboard cutouts. There are some small tweaks, between the two, but overall the process worked well. One thing to note is that the internal cutouts for the BNC connectors are a little bit tight – in future I need to add an extra 0.5mm or so clearance (in addition to the 0.5mm clearance I left already). However, the connectors pushed in even if a little tightly.

Final assembly went well, and I am very pleased with the results:

Computers, Construction, Design, Engineering, PCBs, Retro-Computing

Erasing EPROMs in 2021

While chatting to a friend recently about an old Z80 CP/M machine I built based on Grant Searle’s Z80 CP/M machine, I decided to fire the machine up for a demonstration and give it a try.

No description available.

The machine had been in a shelf in my conservatory for well over a year since I last powered it, and when I connected the power, it was clear that there were signs of life, but, the machine was not happy at all! I could see bus conflicts on the data bus as well as very ‘broken’ behaviour.

After probing around, I decided to check a couple of logic gate (those controlling the address and read/write lines) using my TL866ii+ programmer which conveniently supports logic gate testing and RAM testing. All of the logic gate ICs confirmed to be working correctly, as did the 128Kx8 RAM chip. Checking the EPROM yield a different story!

Forgetful EPROM

Some of the bits towards the end of the ERPOM had been erased (with UV erased parts, this means a ‘0’ bit had become a ‘1’ bit). The snapshot below shows in red bytes that had failed the verification.

The first 0x2012 bytes were completely unaffected with 324 differences in total (just under 2% of the 0x3FFF bytes in the 16KB ROM) mainly concentrated in the end of the address range.

This teaches me to always cover the UV window with something opaque as per the datasheet’s advice. I know people say that sunlight can erase such devices, I never really believed them. As an aside, others have looked into this, which I had not seen until now: see this hack-a-day article for a timelapse of EPROM data when exposed to sunlight.

And, secondly, it left me in a quandary as to how I should restore the ROM code.

Initially I thought I should just be able to reprogram the device over the top of the existing code, since the changed bits would be reprogrammed back to ‘0”s from their current ‘1’ state. But, this turned out not to work. I’m not sure why, but the programmer would fail at 50% – just about the time the corrupt bits arrived.

I decided the next thing to do was to try and erase the IC – but how!?

Erasing UV EPROMs

I didn’t have one of the classic EPROM eraser boxes with a timer and a nice antistatic mat. I’d have to improvise. Essentially tinker around until the PROM was erased (reading 0xFF in all locations).

Eprom Eraser UV141 Professional made by Industrial electronics Ltd. UK

My first attempt was with a DSLR camera flash. I had seen these cheap EPROM erasers online that look like a xenon flash tube, so figured it was worth a shot. However it made no difference at all – I assume the camera flash has an UV filter.

My second attempt was with a UV LED, inspired Charles Ouweland‘s investigations along similar lines. Charles reports that this took 48 hours to erase the PROM. Like always, I was in a rush, so this didn’t really work for me. I could have driven a roundtrip to my parents (Dad has a proper UV eraser) in less then 4 hours including a cup of tea and a chat with Mum!

The third attempt was to use a UV insect-o-cutor which features UV fluorescent tubes as in the UV141 eraser pictured above. I placed the chip on the desk mat and put the UV insect-o-cutor directly on top such that the finger guard was on the top of the IC and the bars were not obscuring the window.

The scary part of this was that the high voltage aspect of the bug-zapper was popping on occasion with small insects – thankfully, the insects popping did not obscure the IC window nor cause ESD damage! After 20 minutes (the usual time I run the UV141 for) the IC was exactly the same. No additional bits had be cleared to logic ‘1’s. I suspect the output is UV-A and not the required UV-C.

Making a UV-C EPROM Eraser

I went back to the second approach with the LED, this time consulting the EPROM datasheet (extract below), and noted that the recommended wavelength for erasure is 2537Å (253.7nm). This puts the UV light required to erase the EPROM in the UV-C spectrum.

I set about trying to find an LED with the correct wavelength. Some more digging showed up the VLMU35CB20-275-120 UV-C (270-280nm peak) LED offering a typical 13.5mW. Such wavelengths are common for curing acrylic nails and for sterilising surfaces in medical applications. At the time of writing, one such LED costs around £4.50 with VAT.

Constant LED Current

These LEDs appear to require between 5.0 and 7.5V at 120mA. I opted to create a simple constant current device using an LM317 set to 120mA and the two LEDs in series. This should work fine when supplied with at least 18V (7.5V + 7.5V + 3V [LM317 dropout voltage]). A SOIC8 LM317 is capable of 200mA and low profile enough to allow the LEDs to be close to the EPROM without catching. R1 is chosen to cause a voltage drop of 1.25V (the LM317 reference voltage) at the desired current. See this TI flashback for more details.

R1 = 1.25V/I = 1.25/120mA = 1.25/120e-3 = 10.4Ω. The closest easily available value is 10Ω, which checking backwards would give a current of 125mA. Since the datasheet mentions 150mA supply giving increased power, I have chosen to go with 10Ω as this will not damage the LED.

We should also consider the size of R1. The power dissipated in the resistor is easily calculated:

P = I^2 x R = (125mA)^2 x 10Ω = 120e-3^2 x 10 = 0.144W = 144mW.

So, a standard ¼-Watt through-hole resistor would be fine. For surface mount, 0805 resistors are typically 100mW, so a combination of multiple resistors should be used to handle the power. This could be four 10Ω parts in series-parallel, two 22Ω resistors in parallel (making 11Ω [114mA in the LEDs]), or two 4.7Ω resistors in parallel (making 9.4Ω [133mA in the LEDs]). I’ll opt for two 4.7Ω resistors since this is still below the maximum recommended working current of 150mA.

Designing the PCB

Initially I had considered tacking two wires on the LED and using a lab power supply to power the LEDs. However, I figured if I was making a constant current supply – mainly to avoid a “oops!” moment and pop £8 worth of LEDs – I would make a PCB to house it all. This way, I could keep the board with the EPROM programmer in the programmer box. The design brief would be simple. The PCB should fit inside the EPROM programmer (TL866ii+) box. The PCB should be (maximally) 110x50mm. I figured 100x50mm would be a nice size. A 5.5×2.1mm DC jack would allow for easy connection to wall-wart PSU or other power source. The rest was just two LEDs, and LM317, two resistors and a decoupling capacitor or two!

Since the PCB is quite simple, I figured it would be a good candidate to make with a laser cutter. Above shows an overlay of the Gerber edges and the layer to be etched. The back areas are there copper is to be removed. The white areas will remain copper.

The board was created by coating a standard single-sided FR1 copper PCB blank with black paint from an aerosol can. This will be used as the etchant mask. The laser cutter is then able to remove the mask by burning away the paint layer, exposing the copper to the etchant.

No description available.

Typically, I’d also cut a solder mask from mica sheet to help apply paste, but for such a simple board, it isn’t worth the extra effort and waste materials.

The next job is to etch the PCB in ferric chloride – you should strive to make a much better job than I did!

I completely over-etched by board by having the etchant too cold and leaving it far too long! But hey, it’s been 10 years since I last made a PCB in my (parents) kitchen sink!

No description available.

From the image above you can see that my 10 thou track has completely disappeared in the right etch, and has almost completely disappeared in the left. I then proceeded to make a mess of drilling the connector holes, misreading a 4mm drill as a 2 mm. The board ended up as a total mess, but, I got it working!

No description available.

My apologies for making such a mess of the board. However, as you can see, the two LEDs are lit and a current of 117.3 mA flows through the series LEDs. I may tweak the resistor values to get an extra 10mA or so, but for now, the result is good enough!

So, now to erase the EPROM

With the PCB made up, I eagerly put the EPROM back into the reader and loaded the old ROM code in. I reverified it to see that indeed 324 mismatches showed up, just as before. Confirmation that all my previous attempts had failed!

I held the newly made PCB above the UV window and gave the EPROM a 1 minute ‘blast’. I read the EPROM again, curious to see how many extra bytes failed verification. Too my surprise, 1088 byte failed verification – considerably more than before. I looked through the data and could see a pattern; the EPROM was blank. Sure enough, the 1 minute blast was enough to clear the EPROM!

I guess it just goes to show what having the right tools for the job can do!

Now will the computer boot?

Since I was on a roll, I reprogrammed the EPROM with the Z80 CP/M code and went for a test boot.

And we’re back to life! This is a machine based on Grant Searle’s Z80 CP/M machine.

Construction, Engineering, Ham Radio

Laser engraving metal using zinc spray

While looking for a way to create front panels and detailing on homebrew equipment, I was pointed to a YouTube video by Mark Presling entitled Metal Finishing With Mark – Metal Engraving 101.

In the video, Mark explains how cold galvanizing zinc spray, when ‘excited’ by a laser, burns at a high temperature to permanently mark the surface of the material onto which the zinc was sprayed. Mark suggests that this only works on stainless steel, however, other videos show how it can be used on ceramics, glass and similar substrates to burn or melt the substrate. I’m not exactly sure of the process, but, it certainly does leave a controllable, visible mark on the surface, which is exactly what I was after!

The box above shows markings for the 144 MHz antenna, GPS antenna, and status LEDs for an APRS transmitter I happened to be working on at the time. The effect is to leave a darker surface on the Hammond diecast box, which (at least to my testing) is very hard wearing and does not come off with use of solvents…

Here’s how

Firstly you’ll need to coat the surface to be etched with a liberal spray of zinc cold galvanizing compound. I used MOTIP Zinc Spray because it was the cheapest I could find on eBay and it works just fine – perhaps I got lucky but I’ve seen several videos on YouTube each swearing by a different make of spray, and they all appear to work. The important thing is that it is high in zinc. It’s an epoxy based aerosol, so, spray outside using the appropriate precautions. The spray should be quite thick, I spray on about 4 heavy coats one over the other and then let it ‘dry’ for around 5 minutes, just until the main solvent has evaporated.

While the spray is drying, design your artwork. I’m making a line drawing of the car along with my callsign to put on the box, mainly to see how it comes out – I’m keen to see if the line drawing comes out well or not – so watch this space! My design looks like the following:

Next we get to put the metal into the laser cutter. I use a 60W CO2 laser cutter, with the power set to around 50%. Others have reported success using 10W diode lasers. I found that 50% was about right for my machine. Going slowly helped a lot, I reduced the machine to around 5mm/second. Where possible, vector engrave as the laser power is continuous and more controlled than raster scanning, but for large areas, such as the text, raster scanning works fine. I always reinforce text with a vector engrave around the outer.

You’ll need to focus the machine as you’d normally do in order to cut the surface.

Once focused, frame the metal on the cutter bed. My laser cutter has a spotting laser which really helps with this.

At this point, you’re ready to go! When the paint is hit with the laser, it goes a very burnt/sooty black. The process generates some very nasty fumes, which you are well advised not to breath – this includes metal vapors which are incredibly dangerous.

Once the engraving is done, leave the work in the cutter’s fume extraction for a short while to be sure that the chamber is clear of toxics, and then remove the work. Mine looks like this:

The final stage in the process is to use a paint remover to remove the paint from the metal to reveal the final design. I use cellulose thinners, which works well. Be sure to do this in a well ventilated space, otherwise you end up with a headache (like I have now, as I write this!).

I think you’ll agree that the final result looks very clean and tidy, and has retained all of the detail present in the original design.

This process is quick and easy to do if you have a laser cutter, uses a cheap-ish (around £6) can of zinc spray, and produces good, repeatable results with minimal fuss. It’s very useful for creating front panels and similar.

You may also find that spraying another colour of paint over the top, and then sanding down very lightly will further accentuate the design.

Construction, Measurement

An ESP8266 based Air Quality Sensor

Some time ago I had reason to log the quality of air in a room. We needed to know what the levels of carbon monoxide and carbon dioxide were at a given time. I quickly produced a thing on a strip of veroboard that would use an ESP8266 to log over WiFi to the ThingSpeak platform. This proved to be useful, and so I made a couple more on a PCB for various other locations.

The sensor uses a  CCS811 (a low-power digital gas sensor) , BME280 (sensor measuring relative humidity, barometric pressure and ambient temperature) and DHT22 (capacitive humidity sensing digital temperature and humidity) sensors, with an OLED display and a small 5V 40mm fan to waft some air around prior to taking a reading. In reality the project no longer needs the DHT22 sensor, since the BME280 device provides better temperature and humidity measurements and adds air pressure readings. But it is included for historical reasons on my project. Feel free to omit it!

The project is very simple, as it just hooks up modules purchased from eBay. The modules cost less than £2 each at the time of writing and came from eBay or AliExpress.

Since this time, others have asked me for the design files, and so I have now shared them on GitHub: github.com/m1geo/ESP8266-Air-Quality-Sensor. The link contains everything you need to create your own! PCB files, source code and schematic.

If you follow the GitHub link above, you fill find two folders. These are explained in the subsequent sections below.

Code

The code folder contains the Arduino code which runs on the ESP8266 device. You’ll need to source libraries for the SSD1306 OLED, the DHT22 (or cheaper DHT11), the Adafruit BME280 module, and the Adafruit CCS811 module. All these are available inside the Arduino IDE.

The MCU board used is a ESP8266 NodeMCU 1.0. This, and all the modules are easily sourced from the usual places (eBay, AliExpress, etc.), and are cheap. You’ll need to create a ThingSpeak account and then enter your API Key and channel number into the source code, as well as your WiFi name and passcode.

Board

The board folder contains an example schematic design and basic PCB gerber files. You can use these gerber files to have a PCB made. All the cheap PCB houses will produce this board fine. The board files supplied are for the board shown above.

Files

All files are on GitHub: github.com/m1geo/ESP8266-Air-Quality-Sensor

Contest, CQWW, Digimodes, Ham Radio, Software

Using CW Skimmer with Hermes Lite 2 SDR (and 10-slice Receive Gateware)

1 Comment

As I was unable to take part in the CQWW CW Contest 2020 due to Coronavirus COVID-19 regulations, I decided to experiment with using the wideband SDR of the Hermes Lite 2 SDR (HL2).

The process appeared to be quite smooth, however upon completion, the CW Skimmer’s Skim Server (SkimSrv) would report that the SDR connection had timed out. This transpired to be the hardware watch dog timer (WDT) timeout inside the FPGA on the Hermes Lite 2 – a precaution to stop the SDR from being stuck in transmit should the connection to it drop:

The solution was two-fold:

  • Update the HL2 gateware to a version allowing the WDT to be adjusted/disabled
  • Update the SkimSrv DLL plugin to a version using the WDT configuration

Getting the Latest HL2 Gateware

The gateware of the HL2 is a bit like what you may consider as firmware. Only, firmware is code that runs on a CPU or microcontroller, and gateware is code that configures the internal connections of an FPGA. This difference is immaterial here, but it is useful to know.

There are many versions of gateware available for the Hermes Lite 2. You are best advised to hunt around Steve Haynal KF7O’s project repositories for the Hermes-Lite2 under the gateware\bitfiles folder and find a version that best suits your needs. It is important to note that some of the gateware files in these folders are compiled with special features and are often not recommended for general use. Here I will cover two versions that I find interesting. The first is the standard gateware that supports both transmit and receive on 4 slices. The second receive only gateware swaps the transmit logic for extra receive logic, resulting in 10 receive-only slices.

One final note, the links I provide are for Hermes-Lite 2.0 build5 and later. If you have an earlier build, then there are different files required which are also present in the variants folders.

Standard 4-slice TX/RX gateware

I started off by finding the latest “testing” version of the HL2 gateware, which can be found in the repositories mentioned above. At the time of writing the original article “testing/20201107_72p5” was the latest version that was recommended for more general use. Since the original publication of this post, this has been rolled into the stable/20201212_72p8 release.

Once you have read the readme and are happy with the notes supplied with the version of the bitfile (the actual compiled file the FPGA is sent to configure itself), then you are ready to go.

Use stable/20201212_72p8/hl2b5up_main/hl2b5up_main.rbf (direct link to download) which supports up to 4 receiver slices, but also includes transmit and is suitable for general use – again – read the notes that are supplied! They are important. Whatever you chose, you may need to rename the “.rbf” file to “hl2b5up_main.rbf” to allow it to be flashed by SparkSDR. Quisk doesn’t seem to care what the file is called.

No transmit 10-slice receive gateware

My actual reason for changing the gateware was to try the 10-slice receive gateware for use with SparkSDR as a grabber for CW Skimmer, as well as all of the other digital modes (RTTY, PSK, WSPR, FT8, JT65, etc.).

For this, stable/20201212_72p8/variants/hl2b5up_cicrx/hl2b5up_cicrx.rbf (direct link to download) which supports 10 receiver slices but does not include transmit. This is meant for multiband skimmers.

Programming the Gateware

To program the gateware there are two options. I opted to use SparkSDR2 by Alan Hopper M0NNB. The process is easy and SparkSDR2 supports Windows and Linux. Run SparkSDR, press the discovery button (the rotating arrow on the left) until your Hermes Lite 2 is discovered, and then right-click and select firmware. From there, navigate from the downloaded and renamed file “hl2b5up_main.rbf” and press program. It should take around a minute.

You are also able to use Quisk by James Ahlstrom N2ADR. From the Config dialogue, select your radio, and then select “Program from RBF file”. The update should not take long.

Once the upload is complete, you should power cycle the Hermes Lite 2 SDR, and then check in your favourite program that the update was successful. I checked that the radio still worked, and I could see that the revision gateware had changed to what I expected within SparkSDR: “Version 72 Patch 5” (now superseded by stable 72p8) and that I did indeed have 4 receivers available. If you used a different gateware version, you should see different results here:

Installing the recompiled HermesIntf.dll

Originally, the HermesIntf.dll file was provided by Vasiliy Gokoyev K3IT on the GitHub page HermesIntf. However, this DLL does not take advantage of the extra WDT options available in the HL2 gateware we just updated. To make such updates, this required the original DLL supplied by Vasiliy K3IT to be recompiled, incorporating changes from Steve KF7O’s gateware.

I was beaten to doing this by Robin Davies G7VKQ, who kindly shared the rebuilt DLL file with me on Twitter (thanks!!). This DLL file can be downloaded here: HermesIntf_G7VKQ.zip. There’s also a version by KV4TT (released Jan 2021) which I would suggest using as it has some further tweaks for handling the watchdog timer. This file is then to be copied into the SkimSrv folder, typically located within “C:\Program Files (x86)\Afreet\SkimSrv\” on a modern 64-bit version of Windows. You will of course need to install SkimSrv by Afreet Software from here. A trial version is available – you’ll need the Skim Server, not the standard CW Skimmer.

Once you’ve copied the DLL into the installation folder, you are ready to fire-up the SkimSrv. SkimSrv has a little icon in the system tray, as shown below. Click on this to open the SkimSrv settings dialogue.

From here, you can use the Skimmer tab to set up the frequencies, sample rates, radios, etc., to use. This is all as you would expect and is pretty straight forward. Above, you can see I am using the 4 receivers available in the gateware version of the HL2 I chose. The image at the top of the page shows operation during CQWW CW 2020, where there were huge numbers of signals present on the bands.

You can connect a telnet program to “localhost” on port “7300” to connect to the Skimmer Server by default. This acts like a DX Cluster with spotting information.

Uploading to PSKReporter

One of the most easy way is use CW Reporter by Philip Gladstone N1DQ. Philip runs PSKReporter, and, offers the CW Reporter application to interface between CW Skimmer Server and PSKReporter. It is easy to set up, working almost out of the box, and translates the DX Cluster style Telnet spots into reports for PSKReporter.info.

One comment to note here is that you should have calibrated your receiver’s frequency before doing this – otherwise, you may be spreading incorrect frequency information.

Finally, it is possible to see, on a map, using appropriate filters, what stations I have heard on CW over the past 24 hours:

Click any image to enlarge.

Thanks to everyone who offered help and suggestions along the way!