Looking to expand the device capability I stumbled across a really interesting little project that is still in the early stages of development but, is functional and worth trying out.
The TC²-BBS Meshtastic Version is a simple BBS system that runs on a RaspberryPi, Linux PC or virtual machine (VM) and can connect to a Meshtastic device via either serial, USB or TCP/IP. Having my M0AWS-1 Meshtastic node at home connected to Wifi I decided to use a TCP/IP connection to the device from a Linux VM running the Python based TC²-BBS Meshtastic BBS.
Following the instructions on how to deploy the BBS is pretty straight forward and it was up and running in no time at all. With a little editing of the code I soon had the Python based BBS software M0AWS branded and connected to my Meshtastic node-1.
M0AWS Meshtastic BBS Main Menu accessible on M0AWS-1 node.
The BBS system is very reminiscent of the old packet BBS systems of a bygone era but, it is ideal for the Meshtastic world as the simple menus and user interface are easily transmitted in seconds via the Mesh using minimal bandwidth.
The BBS is accessible by opening a Direct Message session with the M0AWS-1 node. Sending the letter H to the node will get you the initial help screen showing the menu above and then from there onwards it’s just a matter of selecting the menu item and following the BBS prompts to use the BBS.
The BBS also works across MQTT. I tested it with Dave, G4PPN and it worked perfectly via the Meshtastic MQTT server.
This simple but, effective BBS for the Meshtastic network will add a new message store/forward capability to the Mesh and could prove to be very important to the development of the Meshtastic mesh in the UK and the rest of the world.
Following on from my last article on improving the Heltec ESP32 v3 antennas I found during the installation of the 90 degree SMA connector that the device was very sensitive to stray capacitance from things around it. After reconnecting my VNA I found the SWR curve would change substantially depending on what the device was near and so I set about rectifying this.
I decided to remove all the insulation from the single radial inside the unit and then added two more radials to increase the ground for the antenna to tune against. I then removed the N type plug with the antenna connected to it and made a new antenna from a piece of 1.5mm solid core insulated mains wire connected directly to the N type socket, without using an N type plug. Tuning to resonance was much easier than before and I soon had the SWR down to 1.2:1. Moving the device around and placing near to other objects the SWR curve was now much more stable than before with only very slight changes in curve shape.
M0AWS Updated 868Mhz Antenna
Making this change to the 868Mhz antenna has shown an improvement in signal strength from my node-1 device of almost +0.5dB, every dB counts when you only have 100mW to play with!
The Bluetooth antenna update has made a massive improvement to the usability of the device via the iOS Meshtastic app. Being able to have a reliable, solid connection from anywhere in the house is great and I no longer lose messages because I’ve strayed outside the range of the Bluetooth connection.
I now have 2 new Heltec ESP32 v3 devices on the way to me and will be getting those configured and operational outside with external antennas in the hope of hearing some nodes locally to me.
Meshtastic is a relatively new thing in the internet of things (IOT) world and is gaining traction in the U.K. at the moment.
So what is Meshtastic?
Meshtastic is an open source, off-grid, decentralised mesh network built to run on affordable, low-power devices on the 868Mhz industrial, scientific, and medical (ISM) band. (Some devices can also run on the 433Mhz 70cm HAM band.)
The ISM band is licence free but, has limits on the RF power levels that can be used. The one plus over the HAM bands is that you can legally transfer encrypted messages over the ISM band making it secure.
The best way to think of Meshtastic is a radio version of the online decentralised Matrix chat system but, without the large server requirements and ever growing database!
Heltec ESP32 v3 Wifi, Bluetooth and 868Mhz device for Meshtastic
There are quite a few Meshtastic compatible devices on the market today with many costing around the £20 mark whilst others like the LillyGo T-Echo costing over £100 in the U.K. even though they are less than half the price in the USA.
Since I’m just starting out on my Meshtastic adventure I thought I’d start with a pair of Heltec ESP32 v3 devices that are normally readily available on Amazon but, due to the current push to build a U.K. wide mesh, they are currently out of stock pretty much everywhere.
Loading the Meshtastic firmware onto the devices is fairly straight forward and can be done using the web installer via either the Edge or Chromium web browsers. (Note: If using Windows O/S you will need to install some drivers from the Meshtastic website to be able to communicate with the devices)
Having neither of the two browsers and being a Linux command line junkie I decided to use the Python programme to load the firmware onto the two devices. It’s worth noting that you don’t need any drivers to be able to communicate with the devices if you’re using either Debian or one of the many Ubuntu flavours of Linux O/S.
Using the Python command line program sounds like a more complicated approach but, in reality it’s super simple, extremely reliable, quick and if like me you use a Linux PC in the radio shack then you most likely already have most of what you need to get the job done. Just follow the simple steps as laid out on the Meshtastic web site and you’ll have the firmware loaded in no time at all.
Installing the Meshtastic firmware onto my Heltec ESP32 v3 using the Python command line tool
The firmware takes less than a minute to copy across to the Heltec device and is automatically rebooted ready for configuration once the transfer has completed.
It is possible to configure the device via the command line tool however, since there is a nice GUI app for both Apple iOS and Android devices I decided to install the Meshtastic app on my iPad and connect to the device via Bluetooth to configure it.
Once you’ve got the Meshtastic app installed on your device and have connected via Bluetooth you’ll be ready to start configuring the device to join the mesh. The first thing you want to do is set the region. This is different in each country but, in the UK we use the EU_868 region settings. This will set the device to use the 868Mhz ISM band which is the band being used to build the U.K. wide mesh.
View of the Meshtastic app on iOS showing the configuration options for the Heltec ESP32 v3
There is a multitude of configuration options within the app which I will go into in greater detail in a series of articles at a later date.
Heltec ESP32 v3 running Meshtastic Firmware
For those of you that, like me aren’t near any other nodes you can connect the devices to the internet and use the Meshtastic MQTT server to communicate with other nodes. This of course isn’t off-grid but, it will get you started until the mesh grows into your local area at which point your device will automatically start communicating with the other nodes over radio.
Meshtastic MQTT connectivity
Once you are connected to either the MQTT server or other nodes via radio you will see the other node details appear in the Meshtastic app. It’s interesting to look at the information and see signal strengths and traffic levels etc for each node.
View of the Meshtastic app on iOS showing Nodes in the Mesh and Device Metrics for the M0AWS-1 Node
There are a multitude of cases available for the Heltec v3 devices, especially if you have access to a 3D printer. One of the nicest cases I have seen is the Bender from IKB3D (I know, it’s a strange name!) but, it really is a super little case for the Heltec series of devices.
Bender case for Heltec ESP32 v3 devices
You can either buy the 3D print files for £8.99 and print it yourself or just order a pre-printed and assembled case directly from the website although, due to demand there is a long lead time currently.
Many years ago I had an MFJ-259B antenna analyser that I used for all my HF antenna projects. It was a simple device with a couple of knobs, an LCD display and a meter but, it provided a great insight into the resonance of an antenna.
MFJ-259B Antenna Analyser
Today things have progressed somewhat and we now live in a world of Vector Network Analysers that not only display SWR but, can display a whole host of other information too.
Being an avid antenna builder I’ve wanted to buy an antenna analyser for some time but, now that I’m into the world of QO-100 satellite operations using frequencies at the dizzy heights of 2.4GHz I needed something more modern.
If you search online there are a multitude of Vector Network Analysers (VNAs) available from around the £50.00 mark right up to £1500 or more. Many of the VNAs you see on the likes of Amazon and Ebay come out of China and reading the reviews they aren’t particularly reliable or accurate.
After much research I settled on the JNCRadio VNA 3G, it gets really good reviews and is very sensibly priced. Putting a call into Gary at Martin Lynch and Sons (MLANDS) we had a long chat about various VNAs, the pros and cons of each model and the pricing structure. It was tempting to spend much more on a far more capable device however, my sensible head kicked in and decided many of the additional features on the more expensive models would never get used and so I went back to my original choice.
Gary and I also had a long chat about building a QO-100 ground station, using NodeRed to control it and how to align the dish antenna. The guys at MLANDS will soon have a satellite ground station on air and I look forward to talking to them on the QO-100 transponder.
M0AWS – JNCRadio VNA 3G PackagingM0AWS – JNCRadio VNA 3G in box with connectors and cables
Initially I wanted to check the SWR of my QO-100 2.4GHz IceCone Helix antenna on my satellite ground station to ensure it was resonant at the right frequency. Hooking the VNA up to the antenna feed was simple enough using one of the cables provided with the unit and I set about configuring the start and stop stimulus frequencies (2.4GHz to 2.450GHz) for the sweep to plot the curve.
The resulting SWR curve showed that the antenna was indeed resonant at 2.4GHz with an SWR of 1.16:1. The only issue I had was that in the bright sunshine it was hard to see the display and impossible to get a photo. Setting the screen on the brightest setting didn’t improve things much either so this is something to keep in mind if you plan on using the device outside in sunny climates.
(My understanding is that the Rig Expert AA-3000 Zoom is much easier to see outside on a sunny day however, it will cost you almost £1200 for the privilege.)
A couple of days later I decided to check the SWR of my 20m band EFHW vertical antenna. I’ve known for some time that this antenna has a point of resonance below 14MHz but, the SWR was still low enough at the bottom of the 20m band to make it useable.
Hooking up the VNA I could see immediately that the point of resonance was at 13.650Mhz, well low of the 20m band and so I set about shortening the wire until the point of resonance moved up into the band.
JNCRadio VNA3G showing 20m Band EFHW Resonance
With a little folding back of wire I soon had the point of resonance nicely into the 20m band with a 1.35:1 SWR at 14.208Mhz. This provides a very useable SWR across the whole band but, I decided I’d prefer the point of resonance to be slightly lower as I tend to use the antenna mainly on the CW & FT4/8 part of the band with my Icom IC-705 QRP rig.
Popping out into the garden once more I lengthened the wire easily enough by reducing the fold back and brought the point of resonance down to 14.095Mhz.
JNCRadio VNA3G showing 20m Band EFHW Resonance 14Mhz to 14.35Mhz Sweep
The VNA automatically updated the display realtime to show the new point of resonance on the 4.3in colour screen. I also altered the granularity of the SWR reading on the Y axis to show a more detailed view of the curve and reduced the frequency range on the X axis so that it showed a 14Mhz to 14.35Mhz sweep. With an SWR of 1.34:1 at 14.095Mhz and a 50 Ohm impedance, the antenna is perfectly resonant where I want it.
It’s interesting to note that the antenna is actually useable between 13.5Mhz and 14.5Mhz with a reasonable SWR across the entire frequency spread. Setting 3 markers on the SWR curve I could see at a glance the SWR reading at 14Mhz (Marker 2) , 14.350Mhz (Marker 3) and the minimum SWR reading at 14.095Mhz (Marker 1).
Following on from my initial article on plotting realtime WSJT-X decodes on a Node Red map I’ve made a few enhancements to the flow so that it includes even more data then before.
The additions to the flow now enables collection of status information from WSJT-X so that the flow is able to capture the frequency that the radio is tuned to and also the mode that WSJT-X set to. Neither of these two bits of data are in the decode message payload and so a separate mini-flow has to be created to collect the data from the status payload along side the other main flow.
Node Red flow showing additional sub flow in the top left corner of the flow editor screen
Since the status information needs to be available to all other flows I used flow variables to store the status information in so that it can be addressed directly from any of the other flows in the Node Red app.
If you’d like to use the flow in your radio room then I have put a download link below for a file that you can import into Node Red and build the flow in an instant.
Following on from my other Node Red exploits I’ve put together a flow that creates an interactive map of contacts that is generated from the WSJT-X ADI log file.
The flow is fairly straight forward and self explanatory so I won’t go into detail here but, will make a copy of the flow available for download at the end of this article.
Node Red Flow for processing the WSJT-X ADI Log file
The flow is incredibly quick at generating the map with all the pins on it, one for each station worked. The pins are colour coded, blue for FT8 and green for FT4. If you want to add other modes then just create a new colour entry in the Dynamic Icon Colour function.
The resultant map is fully interactive with each pin being clickable showing the QSO information in a tiny popup.
Node Red map generated from the WSJT-X ADI Log file
You can download the flow and try it yourself using the link below.
Following on from my previous article on Enhancing Digital modes with Node Red I’ve now got to a point where I have realtime decode information from the WSJT-X digital application being plotted on a Node Redworld map not just for CQ calls but, for stations in conversation too.
The flow has become somewhat more complex than it was originally as more and more functionality has been added. I have deliberately split out the flow process into more nodes than are really necessary so that the flow is easier to understand. Anyone from a programming background like myself will soon realise that a lot of the nodes could actually be combined into one big node however, the overall flow process wouldn’t be so easy to understand for the Node Red newcomer and would possibly put people off from trying it out.
Current WSJT-X Node Red flow
Above is a screenshot of the flow as it currently stands. It’s pretty easy to understand what is happening in the flow due to the fact that the processes are broken out into small, easy to digest blocks.
From the top down we connect to WSJT-X via UDP port 2237 and listen for the data stream. As the data is received it’s passed directly into the WSJT-X-Decode node that converts the information into a Node Red compatible format. The data is then filtered with only the information required being passed onto the next node. There are two outputs from the filter node as we require two different streams of information, namely “CQ” and “TX1” data. All the rest of the data from WSJT-X is ignored as it’s not required at this time.
The “Get freq & SNR + Others” node builds a decode message payload with all the correct data, in the right format ready to be passed on along the flow. This node also sets a number of parameters required by the map node to be able to control the display of the data.
The next node along is “Set msg.payload”, this brings together all the necessary data into a single message payload that is then worked on by all the nodes further along the flow.
The next 3 nodes perform the simple task of moving some of the data into the objects defined by the world map node, if the data isn’t moved into these specific objects the map will not plot anything.
Now we get onto the slightly more difficult bit that might put off those who aren’t from a programming background. The next 7 nodes are all javascript functions which I have created to perform tasks that cannot be done via the standard Node Red pallet.
At this point it’s worth noting that I’m not a javascript programmer, I’ve used Python, Rust, Go, C and many other languages during my 40 plus year career but, javascript has never been one of them. I’m sure any seasoned javascript programmer will most likely raise an eyebrow at my attempt at javascript programming but, you need to remember that I’m doing this in my retirement and my enthusiasm for learning yet another programming language has wained somewhat!
So, getting back to the flow, each javascript function does just one task each of which is as follows:
Set rx_time – Sets the time the data was received/processed
Remove RR73 in tx1 – Remove decodes where RR73 is in TX1 instead of a valid callsign
Set Dynamic Icon Colour – Sets the icon colour depending on what type of call is decoded
Maidenhead to LON/LAT – Converts Maidenhead locator codes into LAT/LON Coordinates
Calc Distance – Calculates the distance between “My QTH” and the DX station
Calc Bearing – Calculates the bearing/beam heading to the DX Station from “My QTH”
Generate Search URLs – Generates the URLs for QRZ and my own online log lookups
Editing the Calc Distance function with debug info in the far right panel
Once all the functions have run the resultant data set is forwarded on to the WSJT-X Stations Map node where it is plotted real time on a world map.
To view the map point your web browser at your PC running Node Red as follows:
http://radiopc.your.domain:1880/worldmap/
Or if you haven’t got a DNS setup at home then just use the IP Address of the PC instead:
http://192.168.100.10:1880/worldmap/
Don’t forget that for all of this to work you must configure WSJT-X to send data via UDP on port 2237 otherwise the flow won’t be able to connect and listen for the decode data.
You may have noticed that there are 3 other nodes that I haven’t mentioned yet. The two green greyed out nodes are Debug nodes that can be enabled when required to help see what is going on in the flow. These debug nodes will display data in the debug panel on the right of the flow editor screen when they are enabled, they are extremely useful for debugging!
The third is the blue My QTH node, this contains data pertaining to my QTH that is plotted on the map using an orange icon. You can easily edit this node to point to your QTH instead.
WSJT-X Node Red map showing orange icon denoting my QTH
Once the flow is deployed you’ll be surprised how quickly the data starts to be plotted on the map. Stations calling “CQ” are shown by Green icons and stations that are in a QSO with another station are denoted by the Red icons.
Each icon is clickable and will present all the information collected by WSJT-X for each station viewed.
WSJT-X Node Red World Map showing FT8 stations realtime on the 12m Band
The popup also has two clickable entries, one will take you to the qrz.com page for the station being viewed and the other will search my logs to see if I have worked that station already and if so it will open a new tab showing the information.
Node Red Function Editor showing the Generate Search URLs function
You can edit the “Generate Search URLs” node so that it points to your online logs search engine so that you can view your own log data instead of mine.
Below is a close up of the popups that are displayed when each icon on the map is clicked. The popups show the information collected from WSJT-X for each station plotted on the map.
Left – Green “CQ” Popup and Right – Red “TX1” in QSO popup
If you fancy trying this out for yourself but, don’t fancy creating all the nodes in the flow manually then I have made an export of the flow available for download. All you have to do is download the file, unzip it and then import it to Node Red and you’ll have everything built ready to play with.
For a couple of weeks now I’ve been playing with Node Red to add functionality to my digital mode applications.
To get to know how it all works I initially used Node Red to create a series of dash boards for my servers and virtual machines to show realtime information on CPU temperature, CPU load, memory usage and storage etc.
Node Red Flow to collect information from a virtual machine (VM)
This worked very well and I was soon able to generate the information I needed in a palatable format. This was a great way to get to know Node Red flow building and introduced me to using gauge and graph nodes in flows.
The resultant Node Red Dashboard for one of my Virtual Machines
Once I had mastered creating dashboards for servers/virtual machines (VMs) I then started to investigate using Node Red to plot data from WSJT-X on a map.
I currently use the PSKReporter website to see stations that I hear on a map as WSJT-X sends the data to the site automatically however, this information is always 5mins or more old. For some time I’ve been wanting to see the information realtime as it is received and so I was hoping to be able to achieve this via Node Red.
Node Red has nodes available for a multitude of applications all easily installed via the Manage Palette menu in the flow editor.
I installed the WSJT-X Decode and World-Map nodes and set about building a flow to capture the data and plot it on a world map.
Building a Node Red Flow to decode WSJT-X data and plot it on a World Map
Putting the building blocks of the flow together is fairly straight forward and easily achieved using the excellent flow editor built into Node Red.
I configured WSJT-X to make the decode data available via UDP on port 2237 and then started the flow by creating a UDP node that connects to WSJT-X using the same port. The data immediately started flowing and I could see the information via a debug node.
I can’t stress enough how useful debug nodes are in Node Red. You can add debug nodes onto any output on any other node to capture the data as it flows. This gives you the ability to check what you’re getting is what you expected and also to see the format the data is in. The debug data is displayed in the debug panel on the right of the flow editor in realtime and gives you a great view of what is going on in your flow.
I decided to start with capturing the data for stations calling CQ as this was easily identifiable in the JSON object coming out from WSJT-X.
Passing the output from the WSJT-X-Decode node into a switch node I added a rule that filtered out data containing “type: “cq” and passed it onto the next switch node that created a payload consisting of the station callsign, maidenhead grid square and type so that it could be passed onto the next node for processing.
The next node in the flow is a function, this is where it gets a bit tricky. To be able to plot data on the map we need the Lat/Lon coordinates of the station making the CQ call. Since WSJT-X uses maidenhead locator data I needed to convert this to Lat/Lon coordinates before passing the data to the map node to be plotted.
Since Node Red is written in Java all the functions have to be written in javascript. The problem here is that I am not a javascript programmer and so this meant I’d need to learn yet another programming language. Unfortunately Node Red doesn’t allow functions to be written in C, Rust, Go or Python, all languages that I know well and after retiring from over 40 years in the UNIX/Linux/IT world my enthusiasm for learning yet another programming language has wained somewhat.
Being so close to having a working solution I pressed on and after much head scratching I finally put together some javascript that converts the maidenhead locator information in to good old fashioned Lat/Lon coordinates. I’m sure a seasoned Javascript developer wouldn’t be impressed with my code but, it works and does what I need and so I’m happy with it for the time being.
WSJT-X FT8 stations calling CQ on the 60m Band plotted on a Node Red World Map
Once I had the location information converted it was just a matter of passing the data to the world map node in the correct format for it to be plotted realtime.
As you can see on the screenshot of the map above, it worked extremely well with stations popping up as they were decoded by WSJT-X.
I now need to refine the data sent to the map so that it shows the frequency the station is calling on, the time they made the CQ call and the mode (FT8/FT4 etc) being used.. I would also like to add the distance from my QTH to the station calling CQ to round the information off however, this will mean writing another javascript function which, I’m not sure I want to dive into just yet.
I also need to add into the mix stations that aren’t calling CQ but, who’s callsign and grid square are passed on from WSJT-X. This will mean I will then be able to add to the map those stations that are actively working other stations and maybe I might even be able to show a line between the two stations that are in QSO.
This has been a fun but, steep learning curve however, it will certainly add some great functionality into my radio room and enhance my radio HAM addiction even further.
Many years ago I purchased a Funcube Dongle Pro+ (FCD) SDR. Since it’s arrival it has just been stored in my “Get round too it” drawer.
It’s been many years but, today is the day it comes out into the light and finally gets powered up.
Funcube Dongle Pro+ USB SDR
I’m hoping to be able to use the FCD as the receiver in my QO-100 satellite ground station setup.
The output from the 10Ghz dish mounted LNB is around 739Mhz, well within the FCD receiver range of 150khz to 2Ghz. This will save me from having to transvert from 739Mhz to 430Mhz (70cm band) on the receive path.
This will also give me full duplex operation as I will use my Icom IC-705 on the 2m band (144-146Mhz) to drive the 2.4Ghz transverter for the satellite uplink whilst listening to my own signal via the 10Ghz downlink fed into the FCD.
Before I can even start to build the QO-100 satellite ground station I need to get to grips with the FCD, get the software installed, configured, resolve audio routing via virtual audio cables and get it decoding FT8/JS8/WSPR etc.
Checking the Ubuntu repo’s I found that GQRX v2.12 is available for installation.
sudo apt install gqrx-sdr
Once installed I fired up GQRX and set about configuring it. Initially it appeared to have automatically detected and configured the FCD however, when I started the FCD the software ran for 5 seconds and then just hung.
Diving into the configuration settings I found that the FCD actually appears twice in the list of available devices and all I had to do was select the other one in the list and start the software again and all was well.
I connected my 20m Band EFHW Vertical antenna and trawled up and down the band. The receiver performed well even with fairly strong signals so, I spent some time listening to a few of the stations coming in from the USA.
Next I wanted to sort out the configuration for digital modes. I already have a couple of virtual audio cables in the form of loopback audio devices configured on my Kubuntu PC as this is how I connect the audio between WFView for the IC-705 and WSJT-X/JS8CALL.
Sadly, GQRX doesn’t recognise the loopback audio devices that already exist and so I had to do a little further research to get to the bottom of the issue.
Digging deeper I discovered that GQRX requires loopback audio devices created using Pulse Audio and not the kind I had already created at the O/S level. A quick read of the pactl man page and some further searching online I found all the info I needed to create the correct kind of loopback audio devices.
Two commands are required to create the pulse audio server audio loopback devices:
Once I’d created the loopback audio devices I was able to select the gq2jt devices in both GQRX and WSJT-X/JS8CALL so that the audio was routed correctly.
GQRX SDR and WSJT-X working with the Funcube Dongle Pro+
The overall solution works well and doesn’t put much load on the CPU of my Kubuntu PC, leaving plenty of horse power for me to do other things at the same time.
So I now have the Funcube Dongle Pro+ working perfectly on my Kubuntu PC, all I need now is a 1.2m dish, a 10Ghz LNB and some high quality coax cable.
UPDATE: I decided to leave the FCD connected to the 20m Band EFHW Vertical overnight and monitor FT8 on the 40m band. The EFHW antenna isn’t anywhere near resonant on the 40m band and so I thought it would be interesting to see how well the FCD performed on a completely non-resonant antenna.
To my surprise it did exceptionally well, stations from all over the world were heard with ease, the FCD really is an excellent little SDR receiver.
Map showing stations heard on 40m Band FT8 over night 16/17 Jan 2023
If you’re looking for a relatively cheap but, effective receiver for FT8/WSPR monitoring then I can highly recommend the FCD. If paired with a RaspberryPi then it would be a really cheap to purchase/operate solution for any HAM operator or short wave listener (SWL).
I’ve now added my JS8/JS8CALL logs to the website for both QRO (25w Max) and QRP (<10w) QSOs.
The JS8 logs are available from the Logs menu above.
I’ve updated the adi2html program to now be capable of processing the JS8CALL log file and will be releasing it into the public domain soon.
M0AWS QRP JS8 Online Log
More soon …
We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.Ok
