via the ARRL: Solar Cycle 25 Producing Record High Sunspot Numbers
![](../themes/icons/grey.gif)
Β
(Disclaimer)
I do not claim to be knowledgeable in Space Weather (forecasting).
Β I consider myself a Space WeatherΒ enthusiast.
The sun shines bright in my old Kentucky home as it does over most of the earth during Solar Cycle 25.Β
For several weeks now it seems no matter what region of the Sun is facing Earth, the Sun is having a hissy fit with solar flares, solar storms, CMEs and radio blackouts.Β How has Solar Cycle 25 affected, if any your Amateur Radio operating?
In anticipation of Solar Cycle25, during the Pandemic shutdown I delvedΒ into areas of Amateur Radio that I was familiar with but wanted to expand my knowledge.Β One area is Space Weather and the effects the sun has on Amateur Radio operating.Β Β
During the shutdown, IΒ probed the far reaches of the internet searching for any content, instructions, courses, papers, blogs, social media posts and videos for information on space weather.Β I knew a little about how the sun effects radio propagation from my Amateur Radio exams over the years. One thin I did know from spending many hours in TV weather sets during my broadcasting career, that Space Weather is just as unpredictable as Terrestrial Weather. One thing I wasn't aware of,Β Space Weather forecasting is basically in its infancy in comparison to Terrestrial Weather.Β Β Especially in the area of Solar Cycles, since they come basically every 11 years.Β Satellites and computer models data models have definitely aided in space weather forecasting.
My internet search turned up many people with vast knowledge in Space Weather andΒ Space Weather forecasting.Β The person who caught my eye and provided ME with an easy understanding of Space Weather and Forecasting is "The Space Weather Woman:, Dr. Tamitha Skov.Β
Dr. Skov's YouTube channel's wide range of Mini courses, her "Live" presentations and "Q & A" sessions along with updated Space Weather forecast have served ME well in my Space Weather and Forecasting education.Β Here are some of the sites pertaining to Dr. Tamitha Skov.
https://www.spaceweatherwoman.com/
https://www.facebook.com/spaceweatherwoman
https://x.com/tamithaskov
https://www.instagram.com/tamithaskov/
https://www.youtube.com/@TamithaSkov/featured
I don't have a hard fast RULE of whether I allow a Space Weather forecast determine if I am going to operate that day. Basically, I use Space Weather forecast data as a means to determine what antenna I may use, QRP or QRO rigs, what mode I may use (SSB, CW, or Data) or if I'm operating Parks on the Air, what park and what area of a park I'll operate from. I use this data just as I would a Terrestrial weather forecast that may forecast a 30% chance of rain.Β Do I need to carry an umbrella
After several months of trying to determine what works for me. Here areΒ some of the places I visit almost daily.
National Oceanic and Atmospheric AdministrationΒ (NOAA)
Space Weather Prediction Center
https://www.swpc.noaa.gov/communities/radio-communications
https://www.facebook.com/NWSSWPC/
https://x.com/nwsswpc
Space Weather LIVE
https://www.spaceweatherlive.com/
https://www.facebook.com/SpaceWeatherLive
https://x.com/_SpaceWeather_
https://www.youtube.com/@Spaceweatherlive
Solar Ham
https://www.solarham.com/
https://www.facebook.com/SolarHam/
https://x.com/SolarHam
https://www.youtube.com/user/ve3en1
Sometimes I will check band conditions at the following sites.
https://pskreporter.info/pskmap.html
WSPR Net
I would love to hear from those who follow other sites. Leave message in comments.
Following on from my article about my QO-100 Satellite Ground Station Complete Build, this article goes into some detail on the Node-RED section of the build and how I put together my QO-100 Satellite Ground Station Dashboard web app.
The Node-RED project has grown organically as I used the QO-100 satellite over time. Initially this started out as a simple project to synchronise the transmit and receive VFOβs so that the SDR receiver always tracked the IC-705 transmitter.
Over time I added more and more functionality until the QO-100 Ground Station Dashboard became the beast it is today.
Looking at the dashboard web app it looks relatively simple in that it reflects a lot of the functionality that the two radio devices already have in their own rights however, bringing this together is actually more complicated than it first appears.
Starting at the beginning I use FLRig to connect to the IC-705. The connection can be via USB or LAN/Wifi, it makes no difference. Node-RED gains CAT control of the IC-705 via XMLRPC on port 12345 to FLRig.
To control the SDR receiver I use GQRX SDR software and connect to it using RIGCTL on GQRX port 7356 from Node-RED. These two methods of connectivity work well and enables full control of the two radios.
The complete flow above looks rather daunting initially however, breaking it down into its constituent parts makes it much easier to understand.
There are two sections to the flow, the GQRX control which is the more complex of the two flows and the comparatively simple IC-705 section of the flow. These two flows could be broken down further into smaller flows and spread across multiple projects using inter-flow links however, I found it much easier from a debug point of view to have the entire flow in one Node-RED project.
Breaking down the flow further the GQRX startup section (shown below) establishes communication with the GQRX SDR software via TCP/IP and gets the initial mode and filter settings from the SDR software. This information is then used to populate the dashboard web app.
The startup triggers fire just once at initial startup of Node-RED so itβs important that the SDR device is plugged into the PC at boot time.
All the startup triggers feed information into the RIGCTL section of the GQRX flow. This section of the flow (shown below) passes all the commands onto the GQRX SDR software to control the SDR receiver.
The TCP RIGCTL -> GQRX node is a standard TCP Request node that is configured to talk to the GQRX software on the defined IP Address and Port as configured in the GQRX setup. The output from this node then goes into the Filter RIGCTL Response node that processes the corresponding reply from GQRX for each message sent to it. Errors are trapped in the green Debug node and can be used for debugging.
The receive S Meter is also driven from the the output of the Filter RIGCTL Response node and passed onto the S Meter function for formatting before being passed through to the actual gauge on the dashboard.
Continuing down the left hand side of the flow we move into the section where all the GQRX controls are defined.
In this section we have the VFO step buttons that move the VFO up/down in steps of 10Hz to 10Khz. Each button press generates a value that is passed onto the Set DeltaFreq change node and then on to the Calc new VFO Freq function. From here the new VFO frequency is stored and passed onto the communications channel to send the new VFO frequency to the GQRX software.
The Mode and Filter nodes are simple drop down menus with predefined values that are used to change the mode and receive filter width of the SDR receiver.
Below are the HAM band selector buttons, each of these will use a similar process as detailed above to change the VFO frequency to a preset value on each of the HAM HF Bands.
The QO-100 button puts the transmit and receive VFOβs into synchro-mode so that the receive VFO follows the transmit VFO. It also sets the correct frequency in the 739Mhz band for the downlink from the LNB in GQRX SDR software and sets the IC-705 to the correct frequency in the 2m VHF HAM band to drive the 2.4Ghz up-converter.
The Split button allows the receive VFO to be moved away from the transmit VFO for split operation when in QO-100 mode. This allows for the receive VFO to be moved away so that you can RIT into slightly off frequency stations or to work split when working DXpedition stations.
The bottom two Memory buttons allow you to store the current receive frequency into a memory for later recall.
At the top right of this section of the flow there is a Display Band Plan Info function, this displays the band plan information for the QO-100 satellite in a small display field on the Dashboard as you tune across the transponder. Currently it only displays information for the satellite, at some point in the future I will add the necessary code to display band plan information for the HF bands too.
The final section of the GQRX flow (shown below) sets the initial button colours and starts the Powermate USB VFO knob flow. Iβve already written a detailed article on how this works here but, for completeness it is triggered a few seconds after startup (to allow the USB device to be found) and then starts the BASH script that is used to communicate with the USB device. The output of this is processed and passed back into the VFO control part of the flow so that the receive VFO can be manually altered when in split mode or in non-QO-100 mode.
The bottom flows in the image above set some flow variables that are used throughout the flow and then calculates and sets the RIT value on the dashboard display.
The final section of the flow is the IC-705 control flow. This is a relatively simple flow that is used to both send and receive data to/from the IC-705, process it and pass it on to the other parts of the flow as required.
The IC-705 flow is started via the timestamp trigger at the top left. This node is nothing more than a trigger that fires every 0.5 seconds so that the dashboard display is updated in near realtime. The flow is pretty self explanatory, in that it collects the current frequency, transmit power, SWR reading, PTT on/off status and S Meter reading each time it is triggered. This information is then processed and used to keep the dashboard display up to date and to provide VFO tracking information to the GQRX receive flow.
On the left are the buttons to change band on the IC-705 along with a button to tune to the VOLEMT on the 60m band. Once again there two memory buttons to save and recall the IC-705 VFO frequency.
The Startup PTT Colour trigger node sets the PTT button to green on startup. The PTT button changes to red during transmit and is controlled via the Toggle PTT function.
At the very bottom of the flow is the set transverter IF Freq function, this sets the IC-705 to a preselected frequency in the 2m HAM band when the dashboard is switched into QO-100 mode by pressing the QO-100 button.
On the right of the flow there is a standard file write node that writes the 2.4Ghz QO-100 uplink frequency each time it changes into a file that is used by my own logging software to add the uplink frequency into my log entries automatically. (Yes I wrote my own logging software!)
The RX Audio Mute Control filter node is used to reduce the receive volume during transmit when in QO-100 full duplex mode otherwise, the operator can get tongue tied hearing their own voice 250ms after theyβve spoken coming back from the satellite. This uses the pulse audio system found on the Linux platform. The audio is reduced to a level whereby it makes it much easier to talk but, you can still hear enough of your audio to ensure that you have a good, clean signal on the satellite.
As I said at the beginning of this article, this flow has grown organically over the last 12 months and has been a fun project to put together. Iβve had many people ask me how I have created the dashboard and whether they could do the same for their ground station. The simple answer is yes, you can use this flow with any kind of radio as long as it has the ability to be controlled via CAT/USB or TCP/IP using XMLRPC or RIGCTL.
To this end I include below an export of the complete flow that can be imported into your own Node-RED flow editor. You may need to make changes to it for it to work with your radio/SDR but, it shouldnβt take too much to complete. If like me you are using an IC-705 and any kind of SDR controlled by GQRX SDR software then itβs ready to go without any changes at all.
More soon β¦
Ever since my QO-100 ground station has been operational Iβve been using my NodeRed QO-100 Dashboard to control my IC-705 and GQRX SDR software to drive my NooElec SmartSDR receiver. This gives me a full duplex ground station with both transmit and receive VFOβs synchronised.
This solution has worked incredibly well from the outset and over time Iβve added extra functionality that Iβve found to be useful to enhance the overall setup.
The latest addition to the ground station solution is a Sennheiser Headset that I picked up for just Β£56 on Amazon (Much cheaper than the Heil equivalents at the HAM stores!) and have found it to be excellent. The audio quality from both the mic and the headphones is extremely good whilst being light and comfortable to wear for extended periods.
To incorporate this into the ground station the headset is connected to my Kubuntu PC and the audio chain to the IC-705 is sent wirelessly using the latest version of WFView. This works extremely well. The receive audio comes directly from the GQRX SDR software to the headphones so that I have a full duplex headset combination.
Audio routing is done via pulse audio on the Kubuntu PC and is very easy to setup.
Since I no longer have a mic connected to the IC-705 directly I found that I needed a way to operate the PTT wirelessly and this is where the latest addition to my NodeRed QO-100 Dashboard comes in.
Adding a little functionality to the NodeRed flow I was able to create a button that toggles the IC-705 PTT state on and off giving me the ability to easily switch between receive and transmit using a simple XMLRPC node without the need for a physical PTT button.
The PTT state and PTT button colour change is handled by the Toggle PTT function node shown in the above flow. The code to do this is relatively simple as shown below.
The entire QO-100 Dashboard flow has grown somewhat from itβs initial conception but, it provides all the functionality that I require to operate a full duplex station on the QO-100 satellite.
This simple but, effective PTT solution works great and leaves me hands free whilst talking on the satellite or the HF bands when using the IC-705. This also means that when using my IC-705 it only requires the coax to be connected, everything else is done via Wifi keeping things nice and tidy in the radio shack.
The image above shows the QO-100 ground station in receive cycle with the RX/TX VFOβs in split mode as the DX station was slightly off frequency to me. The PTT button goes red when in TX mode just like the split button shown above for visual reference.
As you can probably tell, Iβm a huge fan of NodeRed and have put together quite a few projects using it, including my HF Bands Live Monitoring web page.
More soon β¦
![]() |
256 KB Gimix Static RAM board, sans battery. |
In one closet, we discovered something unusual. It was a complete Gimix III "Ghost" system. This was a Β 2 MHz 6809 system sporting a fifteen-slot SS-50 motherboard and eight SS-30 slots and floppy disks: a top-of-the-line 6809 system from the early 1980s.Β
By 1991, the company had no use for this equipment. I had the impulse to take the entire system home, but I didn't have room. My wife and I were living in a small house and the garage was already packed. She would not have been happy if I brought home a bunch of equipment.Β
Instead, I salvaged exactly one board -- a Gimix 256K CMOS Static RAM board. It sported 256 KB of memory, with several options, including battery backup. The rest was scrapped by an electronics recycler.Β
Obtaining the board, I tried it out in my system. I was able to map in 4 KB blocks of memory and test them. They all worked. I might use the additional memory as part of a virtual disk drive.Β
In 1994, I moved, and the entire system was stored away for over 25 years. Looking at it recently, I found it needed repair. Over the years, the backup battery failed and leaked electrolyte on the board and motherboard. Several Molex connectors are damaged, and need to be replaced. Some of the components show signs of corrosion from the battery electrolyte.Β
I removed the failed battery. I do hope the rest of the board still works once the repairs are complete. Perhaps I'll fix it in my retirement.
![]() |
MC6809 CPU card, version 2. |
![]() |
Back side of MC6809 V2 card. |
![]() |
WD2797 controller card for 5 1/4"Β drives |
![]() |
5 1/4" Drive Cabinet |
I learned about OS-9 in early 1983, when it was new. What I heard mainly concerned BASIC09 and at that time BASIC didn't interest me. That was unfortunate. OS-9 is a miniature Unix clone, optimized for the 6809.
![]() |
Baud rate generator and counter/timer board |
By the summer of 1985, my original CT-64 terminal felt limited. Sixteen rows of 64 characters didn't seem like enough. Especially when at work I regularly used screens with at least 25 rows of 80 characters. In 1977, terminals with such capabilities were around $1000 -- way beyond my modest budget. By 1985, much more capable terminals were available for about half that price. It was time to upgrade.
August of 1985, I purchased a Wyse-85 terminal for about $700 -- a good price for the time. The terminal offed a DEC VT-220, VT-100 and VT-52 emulator, so it was plenty capable. It sported 24 or 25 rows of 80 or 132 columns on the screen. I purchased the green phosphor screen.
The most important thing, however, about the Wyse-85 compared to the CT-64 was speed. The CT-64 was limited to a paltry 1200 bps. The Wyse-85 had a top speed of 38400 bps. Thirty-two times faster. The CT-64 would take more than eight seconds to write every character on the 16 x 64 screen. The Wyse-85 could write an entire 25 x 132 screen in less than a second.Β
The Wyse-85 was such a joy to use compared to the CT-64, I couldn't believe I hadn't done this sooner.Β
I did have trouble with this terminal when I tried to use it in the shack back in the late 1980s. The keyboard scan generated a fair amount of RFI. Putting several ferrite toroids on the keyboard cable helped a little, but did not eliminate the problem.Β
I still have this terminal. It's been stored in the original box since November of 1994. I hope it still works.
![]() |
WD2797 controller card for 8" Pertec drives in the Icom Peripherals FD360 |
![]() |
Back side of the 8" controller |
September 1985, I purchased a Kenwood TS-430S and became more active in amateur radio. In the apartment where I was living, I snuck wires out of a second floor window and began to make contacts.Β
In October, I got the notion to try some Radio Teletype (RTTY). I built a demodulator using a circuit I've forgotten. Perhaps it used a couple of NE567 chips. Having a demodulator, I needed to translate the five-level Baudot characters into ASCII that I could display on the terminal.
(I purchased a Wyse 85 VT-220 emulator terminal in August of 1985, so I was no longer constrained by the 64x16 screen and 1200 bps limitations of the CT-64)
I wrote a program for Flex09 to decode 45 Baud RTTY by bit-banging a PIA pin. I couldn't use the MC6850 ACIA, because it does not support 5 bit characters.
A delay loop established character timing:Β
Each pass through the loop consumes 8 clock cycles. With the right value loaded in X, fairly precise timings could be accomplished. A value close to 250 would be 1 ms on a 2 MHz machine. By calling this loop repeatedly, timings of 11 and 22 ms are measured.Β
I connected the demodulator output to PIA Port B, pin 0. The program looks at this pin, waiting for a zero. Finding one, it calls the delay loop for 1 ms and checks again. If the pin is still zero, it waits 10 ms and checks Port B pin 0. A continued zero at this point indicates a start bit. The 11 ms total delay places us right in the middle of the start bit.
The next sequence waits 22 ms and then samples of value of Port B, pin 0. It does this five times. These samples are shifted into a byte value, which used to look up an ASCII character in one of two tables -- one for letters, and one for figures -- according to the shift mode. This character is then sent to the terminal, and we go back to waiting for a start bit.
The resulting program is about 300 bytes long. Despite the simplicity, Β I had little success decoding RTTY signals.Β
In hindsight, there are several reasons for this.Β
At some point, I distinctly copied "RY RY RY RY RY RY RY" from someone, but not much else. Later, I figured out this meant my program, at least, was working.Β
In November 1986, I decided to use serial chip that could do five-level Baudot. The MC6850 only allows 7 and 8 bit characters, so I needed a different chip. The NS8250 could do 5, 6, 7 and 8 bit characters, and sports a programmable bit rate generator for all the common RTTY rates. Hence, I added an NS8250 UART to the baud-rate generator board.Β
Funny, though -- I never wrote software to use the NS8250. In February 1989, I removed the NS8250 and its associated circuitry.Β
I didn't become active in RTTY on the air until 2005, using Cocoamodem.
![]() |
Digital Research Computers 64 KB SS-50 Board |
Digital Research Computers marketed an SS-50 card designed by Tanner Computers in the early 80s. It sported thirty-two sockets for 2 KB RAM or ROM chips. These 2716-compatible chips were quite popular at the time.
I bought a kit for about $225 with a full 64 KB of RAM in June 1984.
Assembling the kit was straightforward, along the lines of the SWTPc kits. The board worked right away, with no soldering issues -- largely due to the excellent solder mask on the board.
For SS-50 systems, this board has several flexible options. The first 48 KB presents as three 16 KB banks that are enabled individually. Each 2 KB segment in the top 16 KB is enabled individually, allowing one to navigate conflicts in the C, D, E and F blocks of memory. This allowed for I/O on the motherboard, or perhaps RAM or ROM on the CPU board.
The board supports extended addressing on the S0-S3 pins. When enabled, the entire board responds as one 64 KB block. Each socket can contain either RAM or ROM chips, selectable by the jumper next to each chip.
Initially, I used this board without extended addressing as a 56 KB board. I later enabled extended addressing to access the full 64 KB, after modifying the MP-B motherboard to decode the 20-bit address for the I/O slots. This allowed me to use that 8 KB of RAM for a virtual disk drive, briefly.
I discovered some Β extended memory issues between BBUG/Flex09 and OS-9, so I disabled the MP-B decoding.
As pictured, the board has the E000 and E800 blocks disabled, with F000 enabled, and F800 disabled. This configuration was appropriate for the MC6809E V1 CPU board and MP-B motherboard without the 20-bit address decoding, although, technically, the E800 block could be enabled, and the F000 block would not be accessible after I modified the MC6809E V1 CPU board for a 4K ROM.
![]() |
The massive ICOM "Frugal Floppy" FD360 |
![]() |
Data plate from the Icom FD360 |
![]() |
SWTPc DC-2 Controller |
![]() |
SWTPc 6800 front panel, sporting sixteen LEDs. EachΒ LED indicates a 4 KB address block access. You can also see a yellow power LED was added. |
![]() |
Board holding 74LS154 and LEDs. |
This socket has address pins A12-A15 from the CPU, the VMA* signal, the DAT write decoder signal, +5 volts, and ground. The VMA* and DAT write signals go to the two Enable* pins on the 'LS154. This means the address must be valid, and not writing to the DAT to enable.
The LEDs anodes are connected together to a resistor to +5 volts. Originally, this was a 470 ohm resistor. I found that the LEDs lit very dimly. Each LED is not asserted all the time. VMA* is not asserted at all times, and pulses every clock cycle, which limits how bright the LED can illuminate. I decreased the resistor value and experimentally arrived at a value of 22 ohms.
The resulting front panel is informative. I can see when the CPU is busy-waiting on I/O ports, if it is crunching away at some calculation, or if it has crashed entirely. And if the CPU executes a CWAI instruction to wait for interrupts, all the LEDs go dark.
Cool.
![]() |
The bare board that held the HB 6809 V1 circuitry.Β Waiting for the next SS-50 project. |
![]() |
Bit Rate Generator Board |
![]() |
BBUG and OS-9 EPROMs |
In the early 1980s, I was excited about the MC6809 processor. I wanted one. But my student budget couldn't afford it. I studied all material about the MC6809 I could get my hands on.
In 1981, I obtained the source code to SBUG-E, the SWTPc ROM monitor for the MP-09 board. I was familiar with the source code to the MC6800 ROM monitors MIKBUG and SWTBUG. SBUG-E demonstrated the elegance of the MC6809 processor.
As I understood SBUG-E, I wasn't satisfied with it. I began to modify the source to suit my own purpose. Β I called this resulting monitor BBUG.Β
I worked on BBUG for a couple of years, off and on. My earliest printout is from April 1981. I wrote code using a cross-assembler and pour over the listings. I hunted for ways to make BBUG compact, as it had to fit in a 2 KB ROM. But the code never ran until I built the Homebrew MC6809 CPU board in mid-1983. (Which is another story)
BBUG's command structure is similar to SBUG-E, as is a lot of the code. Here are the differences.