Having dipped my toes in to 10GHz EME with an existing antenna rotator I used for VHF/UHF LEO satellites I was faced with the need to upgrade my setup if I wanted to do it more reliably.

It was possible to make contacts with my existing setup, but the instability of it on a thin aluminium pole that moved like a pendulum in wind along with an inaccurate (for microwave use) rotator with a high amount of backlash and tracking errors were were a real annoyance. The rotator wasn’t meant for this sort of use so I am still happy it seen me off to a good start on 10GHz EME without a significant initial expense that may have put me off even trying.

There did not appear to be many commercial amateur radio rotator options at 0.1 degree accuracy with low backlash that I would want for my current, or larger dish, and those that might be suitable came with an eye watering price tag. So I made the decision to try to DIY it, mostly copied from people smarter than me with very few original thoughts.

I later noticed all a commercial option using slew drives from RF Hamdesign but I had the drive and parts here by that point so couldn’t take the easy buy my way out of the problem option.

Dual Axis Slew Drive

Having seen discussion on the moon-net reflector about options, I settled on using a dual axis slew drive rotator which seems to be a very popular choice at the moment. These seem to be mainly provided for use rotating solar arrays so they are fairly common devices, are not expensive and do the trick for radio use very well. It will also be suitable should I upgrade to a larger dish in the future.

The rotator was ordered from CoreSun drive and I settled on the SVH3-62B-RC-24H3033-REV.A as described at: http://www.coresundrive.com/en/product/Solar_Tracking/2019/0729/93.html

In its standard form this is slow for general amateur radio use, requiring a full 21 minutes for a 360 degree rotation, not handy for contests or LEO satellites requiring quick repositioning. They can however be ordered with different gearing to allow faster movement but as I’m using this for the slow moving moon I stuck with the standard option.

After payment was made, air freight took about a week to deliver the small but heavy crate at which point it sat a month or so as I looked at other peoples installations and figured out how I make use of it.

Dual Axis Slew Drive Documentation Errors

One thing that was a bit confusing was the wiring colours on the document supplied with the SVH3 did not match the wiring colours on the SVH3 I received. After some testing found them to be as follows:

Wire Definition

Pin 1 (black) = motor –
Pin 2 (red) = motor + 24V
Pin 3 (grey) = hall GND (marked yellow on document)
Pin 4 (brown) = hall + (5-12V)
Pin 5 (blue) = hall A
Pin 6 (orange) = hall B (marked green on document)
Pin E (green) = GND (marked grey on document)

Additionally, the gear ratios on the document supplied did not match that marked on the drives that arrived! I didn’t pick up on this until everything was mounted and in use so my calculations for pulse counting were initially off causing my some added bother.

Physical Mounting – Dish

I don’t have metal working skills or tooling beyond a wonky bench drill press so chose to create the antenna mount out of aluminium plate and angle that I could easily drill. One of the successful setups I had seen online and liked the look of was that of N5TM and chose to implement a similar mount for the dish with two plates bolted on to the size of the rotator. He describes the mounting setup and provides drawings of what he’s used top and bottom on his website here: http://n5tm.com/index.php/2023/10/30/brackets/

By printing the template to scale and centre punching I was able to mark the positioning of the 6x11mm holes of the rotator on the aluminium arm to check and drill. This wasn’t quick on my drill press but I managed it with only one hole being slightly off requiring enlarging. I chose not to trim the corners of the mounting arms off at this stage as they might be useful for fitting some physical stops later.

The Andrews 120cm dish has four mounting holes in a 14cm rectangle so I chose to use a solid aluminium plate affixed to the two arms with some aluminium angle.

The end result with the coach bolts that will attach it to the dish.

One mistake I made was with the length of the support arms, I reduced them in size a little from the diagrams I was working from purely due to delivery costs on the aluminium jumping up significantly thinking a small change wouldn’t matter with a small dish. Well it does. As a result I can only go down to 5 degrees elevation before making contact with the mounting pole. As I don’t have terrestrial microware possibilities here, and my moon horizon is minimum 8 degrees at 10GHz, it’s not a problem for now.

Rotator Controller – K3NG

I’d seen some commercial controllers mentioned along with some peoples very nice looking DIY setups and settled on the open source K3NG rotator option. This offers a lot of options for customisation, and is well documented.

I decided to use a Nextion touch screen display like I’ve used in other projects using VK4GHZ’s awesome code for the rotator available at https://vk4ghz.com/vk4ghz-nextion-for-k3ng-rotator-controller/ and not have any buttons to simplify things a little. The schematic from N5TM available at github helped me get my head around what was needed quickly.

I initially acquired a very cheap second hand 24v Meanwell PSU to use for the rotator, which turned out to be terrible RF interference wise on HF. Buy cheap buy twice.

I also used an RTC on the Arduino in order to allow the K3NG software to track the moon without needing a computer doing the tracking. This all came together in a big mess on the desk but both axis rotated as expected.

One thing I found was that the K3NG would not work with the INCREMENTAL_ENCODER option as I assumed it might as it requires a Z from the encoders. Patching the requirement out like someone else did made it kind of work but introduced some really odd problems I couldn’t get to the bottom of.

Using PULSE_INPUT with one line seemed to work okay and others have had success with this. Unfortunately it turned out I wasn’t to be one of them.

I designed a case with a sliding lid to house the Arduino, Nextion display, optoisolator, relay board, buck converter and connections and 3D printed it. In the unlikely event someone wants this, the STL is available here.

The Arduino would blip the relays on power up and I couldn’t figure out a way to stop this. I couldn’t detect the rotator moving during the short blips but decided not to chance it and settled on a small relay board with a timer to delay powering the relay board up until after the Arduino had booted.

Here is the mess complete for testing before sorting the cabling out.

Cabling

I picked a small waterproof enclosure with mounting wings that allowed it to be cable tied to the motors and affixed a terminal block inside this along with 4 holes and waterproof cable glands. I will attach it to the support pole when fully set up.

I had decided to use two separate cables for the controller, one carrying the pulse signals, the other power to reduce the risk of pulse signals being messed up, not sure if this actually helped or not. I understand many upgrade the rotator to have absolute encoders for accurate position feedback, or add external elevation detection but I’m going to run with it as is now and I don’t foresee it being too much of a problem with a 1.2m dish. (I was wrong)

Physical Mounting – Base

My setup is a little unusual in that it sits above a flat roof of a garage in order to get over the top of nearby vegetation and my house. Being on a flat roof accessed by a window in the house allows easy access to the setup. In order to have a vertical pole mounted on TK brackets with the pole going to the ground to support the weight, it needs to be 3.8m long with 1.8m of this above the top bracket. The aluminium pole I had been using was not sturdy enough to support the rotator and dish above and had an alarming amount of movement in even moderate winds.

I settled on 10cm steel box section to give me something that wouldn’t move. On asking g4ytl about how he mounted his dish I seen he had used similar box section with metal plates on top, one welded to the box section, the other plate bolted in to the rotator with both connected using bolts. There were a number of variations of this setup online and I liked the simplicity of it so went this route.

The box section will sits on top of an existing 40-50cm deep concrete slab that I can’t dig up to fit any sort of base support.

After deliberating for a few weeks about whether I should take up welding to make something up myself I decided I’d rather my first welds didn’t have a lot of expensive equipment/or me relying on them to hold and instead asked a local metal fabrication shop to do it. I was pleasantly surprised as it ended up costing not much more than the metal would have cost me and on speaking to them about the difficulties in welding thick steel I’m glad I didn’t try. I did however make a mistake with the wall size at 6mm with 10mm plate as it made the section ridiculously heavy requiring me setting up a winch on the side of the house along with some creative guide cables to raise it in to place.

I decided to use existing TK brackets that required drilling out new holes in the arms for the large U bolts to hold the section. As it’s on the inside corner of a wall I’ve also added extra brackets to the adjoining wall to have it fixed in place from two sides using a mix of resin fixings and wall bolts.

The Final Setup

And here it is ready to start testing. Some physical stops will be added once I’m happy everything is okay.

Follow-up

After using the setup for a month including making a number of EME QSOs without many of the difficulties that plagued my previous setup and being far happier with the stability of the setup, I was still having some problems.

The pulse counting seemed to be very quickly losing my position after lots of moon tracking movements as if there was over/under counting going on, especially in elevation. I also had an of instance of an unexpected jump in position that never repeated. To potentially fix the potential pulse counting issue I considered a master/slave setup to reduce the cable length the pulses had to travel.

For the elevation side I also considered getting and using a HH12-Inc for an absolute readout and giving up on the pulses there but failed to acquire one. Additionally one of the relays gave out bringing forward my plan to use H bridges instead of relays. While these problems were in my mind and I was waiting on the H bridge bits arriving I discovered the Arduino itself was causing RFI (I’d assumed it was the PSU) around the IF the 3cm moon beacon I use for testing.

At this point wanting to just get reliably operational quickly I decided to shelve the controller, which I really do like, and I know works for others on 3cm EME so could be made to work better with some more time. I plan to use it with my VHF/UHF satellite setup in the future or for anything else requiring a versatile easily configured controller system.

The new controller system, WinTrak with two MABMPU boards and the controller software running on a touchscreen Pi, has been working well for a few weeks with no obvious issues or requiring adjustments during a moon pass. This solution was pretty much plug and play so I don’t have much to say other than it works!

References

N5TM

K3NG

VK4GHZ

I’ve just added an IC-9700 to the desk alongside the IC-7300, they look very nice together and very similar. Unfortunately the Audio and Serial devices also look very similar in Linux!

Both radio sound cards appear as PCM2901 making it hard to differentiate between them, and my previous udev rule to create a symlink for the IC-7300 ttyUSB device on /dev/ic7300 picked up the 9700 instead.

My previous udev serial rule created a symlink to /dev/ttyUSBx from /dev/ic7300 when a device with the 7300’s serial adapter idVendor and idProduct was seen like so:

SUBSYSTEM==”tty”, ATTRS{idVendor}==”10c4″, ATTRS{idProduct}==”ea60″ SYMLINK+=”ic7300″

This worked fine until the 9700 was plugged in as it also has the same idVendor and idProduct number. We can narrow this down easily as another available attribute is “serial” which contains the radios unique serial number along with its name.

We can get the serial numbers using udevadm  (or better with lsusb below) against each of the /dev/ttyUSBx devices, the 9700 has two serial devices, the first works fine with hamlib for control but not sure what the second serial device at the moment.

$ udevadm info –attribute-walk –path=/sys/bus/usb-serial/devices/ttyUSB4 | grep IC-
ATTRS{serial}==”IC-9700 13000000 A”

$ udevadm info –attribute-walk –path=/sys/bus/usb-serial/devices/ttyUSB5 | grep IC-
ATTRS{serial}==”IC-9700 13000000 B”

$ udevadm info –attribute-walk –path=/sys/bus/usb-serial/devices/ttyUSB1 | grep IC-
ATTRS{serial}==”IC-7300 03000000″

An easier way to get the serial numbers is by running lsusb as root as follows, thanks to PA3MET for the pointer!

# lsusb -vvvvv | egrep "9700|7300"
iSerial 3 IC-9700 13000000 B
iSerial 3 IC-9700 13000000 A
iSerial 3 IC-7300 03000000

We can take these and create appropriate udev rules for adding symlinks for the radios serial devices including the unique serial numbers. Here is an extract from my /etc/udev/rules.d/99-hamlib.rules file:

SUBSYSTEM==”tty”, ATTRS{idVendor}==”10c4″, ATTRS{idProduct}==”ea60″, ATTRS{serial}==”IC-7300 03000000″, SYMLINK+=”ic7300″

SUBSYSTEM==”tty”, ATTRS{idVendor}==”10c4″, ATTRS{idProduct}==”ea60″, ATTRS{serial}==”IC-9700 13000000 A”, SYMLINK+=”ic9700a”

SUBSYSTEM==”tty”, ATTRS{idVendor}==”10c4″, ATTRS{idProduct}==”ea60″, ATTRS{serial}==”IC-9700 13000000 B”, SYMLINK+=”ic9700b”

Take care if copying the above text as the quotation marks are displaying incorrectly in WordPress. If you copy it as is you will need to replace them all with proper quotation marks.

A reload of udev rules with “udevadm trigger” and we have our serial devices available from convenient symlinks so no chasing about ttyUSB device names:

$ ls -l /dev/ic*
lrwxrwxrwx 1 root root 7 Apr 4 14:27 /dev/ic7300 -> ttyUSB1
lrwxrwxrwx 1 root root 7 Apr 4 14:27 /dev/ic9700a -> ttyUSB4
lrwxrwxrwx 1 root root 7 Apr 4 14:27 /dev/ic9700b -> ttyUSB5

Next up is the sound cards. I use quite a lot of different programs and need to easily switch and adjust my audio inputs/outputs using pavucontrol. The problem here is both audio devices have the same name, PCM2901, meaning I can’t easily tell what sound card belongs to what radio.

There’s no way to differentiate the sound cards like with the serial above as they return the exact same information and attributes. The only way to differentiate them from what I can see is with the physical USB port they are plugged in to. This is fine here as it’s a desktop and they will remain plugged in to the same ports. If you plug the radios in to a different USB socket you will need to update the paths again. 

We can list the devices with the following command, this shows both the IC-7300 and IC-9700 sound cards. I’ve removed some other sound cards from the output, as we’re just looking for the “Burr-Brown_from_TI_USB_Audio_CODEC” entries here

$ pacmd list-sources | egrep “name:|sysfs”

name: <alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo.2.monitor>
sysfs.path = “/devices/pci0000:00/0000:00:14.0/usb3/3-2/3-2.4/3-2.4:1.0/sound/card4”
name: <alsa_input.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo.2>
sysfs.path = “/devices/pci0000:00/0000:00:14.0/usb3/3-2/3-2.4/3-2.4:1.0/sound/card4″
name: <alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo.3.monitor>
sysfs.path = “/devices/pci0000:00/0000:00:14.0/usb3/3-3/3-3.4/3-3.4:1.0/sound/card5”
name: <alsa_input.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo.3>
sysfs.path = “/devices/pci0000:00/0000:00:14.0/usb3/3-3/3-3.4/3-3.4:1.0/sound/card5″

We are looking to extract the unique portion from device paths above, here we can see the paths differ at 3-3/3-3.4/3-3.4 and 3-2/3-2.4/3-2.4. We will want to identify which entry belongs to which radio so run it with the USB disconnected then connected to identify which device matches which radio.

We can then run the following to apply a device description of IC9700 to the IC-9700 sound card source and sink which will show against the audio device in pulse applications instead of PCM2901.

The 3-3.4 below is referencing the end of the USB port discovered above.

pacmd update-source-proplist $(pacmd list-sources | egrep “name:.*Burr-Brown*|3-3.4” | grep -B 1 sysfs.path | grep name | sed “s/.*<\(.*\)>/\1/” | grep -v monitor) device.description=IC9700

pacmd update-sink-proplist $(pacmd list-sinks | egrep “name:.*Burr-Brown*|3-3.4” | grep -B 1 sysfs.path | grep name | sed “s/.*<\(.*\)>/\1/”) device.description=IC9700

And the same for the IC7300 with 3-2.4:

pacmd update-source-proplist $(pacmd list-sources | egrep “name:.*Burr-Brown*|3-2.4” | grep -B 1 sysfs.path | grep name | sed “s/.*<\(.*\)>/\1/” | grep -v monitor) device.description=IC7300

pacmd update-sink-proplist $(pacmd list-sinks | egrep “name:.*Burr-Brown*|3-2.4” | grep -B 1 sysfs.path | grep name | sed “s/.*<\(.*\)>/\1/”) device.description=IC7300

The audio devices should now be available using the name we set above in pavucontrol and other applications. This can be put in a script to run manually or at system startup.

I’ve had a smart home alarm system for close to a year now and have been mostly happy with it but for the lack of ability to manage it outside of their mobile applications and online systems. With the help of a Bus Pirate I’ve hopefully solved this problem.

I would like to use Node-Red to interact directly with my alarm unit not using the manufacturers online systems. I would also like options should they decide to turn their service off one day.

The hub device has a web interface on port 80 but you are not provided with a password for it. The service is basic looking and it’s clearly not intended for consumer use. Having a device on your local network with an admin interface you don’t have a password for really isn’t on.

I had previously come across an article that stated they obtained the web interface password from the firmware through the JTAG port but it also said that a firmware update had been released to fix some of the concerns. My device was purchased after that date and has had firmware updates so I wasn’t sure if it would work, but as I had a Bus Pirate already I might as well try.

I decided to open the piggy bank for a cable and a breakout board to connect the Bus Pirate to the on-board JTAG socket. The main chips data sheet can be found here. I used OpenOCD’s kx.cfg as the target via the Bus Pirate. I was however met with this text so it seems they did secure it as suggested in the linked article:

Warn : **** Your Kinetis MCU is in secured state, which means that, ****
 Warn : **** with exception for very basic communication, JTAG/SWD ****
 Warn : **** interface will NOT work. In order to restore its ****

I examined the headers on the bottom left of the board with a Jtagulator but couldn’t identify JTAG or UART on them so I assume they are for an expansion or something. There are unpopulated connectors on the board for USB sockets and other things.

There were three unpopulated holes next to the main chip with one being ground, these connected to pin 31 and 32 on the chip. On looking up the data sheet this pin pair can be configured as UART TX & RX:

I considered taking the board out and putting headers on but the probe clips go through and hold in place so just set up like this:

The data sheet suggested 115200 baud and on starting Minicom, output was immediately visible on the terminal.

The system is sending a lot of information to this interface, device status messages, configuration information, XML from the external XMPP communications and logins/passwords attempted on the web console.

This was interesting but the interface appeared to be for debug output only and I couldn’t find any way to get a response with input at all.

Talking about the nearly but not quite issues to a friend they suggested flash chips and referenced this great write up. So next up was the Winbond 25q32fv chip with SPI!

Now I had a choice here, I should really take the chip out as powering it up may power the board up, and I’m not going to be able to read it properly it if it’s being used. Being lazy I just gave it a go with flashrom but ended up with correctly sized files of garbage.

Guessing the failure to read data might be to do with SPI being used as the device was powered from the Bus Pirate, I removed the chip.

The chip came off cleanly with the heat gun:

I then spent the next ten minutes unable to get anything from it at all while convincing myself I had broken it somehow. I then soldered it back on and powered the device up to be met with it taunting me about my failure with this on the UART:

faile0-faile0-faile0-faile0-faile0-faile0-faile0-faile0-faile0

I removed and then re-soldered it once again in hope it was just my bad soldering to thankfully find the device working again. Now I wanted to remove the chip and try reading again outside of the device, but I’d had it off twice and after the near brick experience I wasn’t keen on doing it again.

When I’d tried reading the flash previously there were constant errors streaming by on the UART due to things being disconnected/powered off. In order to raise odds of getting something useful off the chip while the system was running I removed most of the error conditions to reduce potential use of the chip and tried again.

Binwalk still wasn’t giving any information about the structure of the file though. However on running strings on the output this time, the information I was after, the password, was sitting alongside the admin username. Most of the file was garbage but I had the one bit I needed and could now log in to the web interface.

The password is random alphanumeric so they may have followed the suggestions from the earlier referenced article but without another device I can’t confirm that they are all unique. I would not have been able to brute force this password so thankfully this worked as I might have tried that next.

This wouldn’t have been necessary had they just provided the web interface password. I don’t think it’s acceptable to provide equipment with listening network services while not providing a means to use them.

The device I used here has been updated by the manufacturer so the above may not be possible on the new units.

After reading a Radcom article about a 10MHz locked ADF4351 Arduino controlled  signal generator thanks to Alain Fort F1CJN described here,  it seemed the perfect module for testing equipment locally as I didn’t have anything like this.

Once the pieces arrived from China it worked perfectly with a 10MHz GPSDO input using the instructions from Alain’s page above and the black ADF4351 board after disconnecting the on-board 25MHz clock.

When connected, the above worked fine and did okay on the desktop it wasn’t suitable for moving about or with the jumper cables for long term storage/use. A box was ordered large enough to place all of the bits in and to allow SMA & DC inputs as well as another shield that didn’t have the headers I’d put on the above one.

The Arduino LCD/Button shield works well but doesn’t lend itself at all well to being installed in a box. The LCD brightness adjustment trimmer is too big, there are some header pins sticking up to the LCD level and the buttons are too far recessed for access through a box. Some discussion on the ukmicrowaves mailing list gave pointers for getting around these problems.

Firstly the buttons were all removed and the trimmer was moved to the other side of the PCB.

 I wasn’t sure of the size of buttons to replace the originals with to allow them to be pressed when mounted in the case so I had also ordered a mixed pack on eBay to allow picking the appropriate size. I also ordered some white caps for the tops which would eventually be glued on. I eventually settled on the combination lush with the LCD.

Now came the part I wasn’t looking forward to, drilling and cutting the case. The LCD shape along with the four mounting holes was drawn out based on measurements from the board and cut. I don’t have any nice tools for the LCD rectangle cut so cut two sides with with a hand hobby saw and others with a rotary tool to compare the finish as wasn’t sure of the best approach. The rotary tool was fast but gave a terrible finish, the hobby saw plus sanding gave by far the better result.

The more tricky bit was the button measurements and I couldn’t find a PCB diagram for the board. Putting some fabric tape on the inside of the case and ink on the top of some temporary placed buttons I pushed the LCD in to it’s fitting which after a couple of goes left an imprint on the inside.

This allowed me to drill an initial hole from the inside before turning over to drill an appropriate sized hole from the other side.

Once I had validated the holes were lined up, they were expanded to fit the white caps using a drill and a deburring tool. I then checked the button lengths for the best match, soldered the buttons to the board and glued the white button caps to them.

Three holes were drilled in the side for two SMA and a DC input and some stickers added to make it look better by hiding the messy top cut made by my bad effort with the rotary tool…

The inside has the LCD shield and Arduino attached to the lid using machine screws and some spacers to hold things in place. The Arduino needed it’s DC socket removed to fit flush with the LCD shield. Wires were soldered directly in to the Arduino for the output to the resistor divider and DC input.

In the picture above the DC input is going to the Arduino DC input. However the regulator in the cheap Arduino Uno copy I’d obtained from eBay turned out not to work with a 12v input in the same way as the genuine Uno I tested with had. To sort this I skipped the regulator by putting a small buck converter in the case to let it regulate the voltage to 5v and connected it directly to the 5v on the Arduino.  As well as solving the problem, the converter gives better a 6-20v input range potentially at the expense of the converter introducing noise.

The harmonics produced are strong enough to provide an accurate marker at 10GHz and likely beyond.

Background

Continuing with using Node-RED to handle messaging for radio related things I’ve created some flows for using with the interactive chat service at www.on4kst.com.

This web and Telnet based messaging service is invaluable for VHF+ users for contests, scheduling and band related chat.

The web interface is great for using while at home but when out portable using a mobile device it is a bit fiddly. Additionally, during contest/activity days, the messages can be flying by so quickly a page of text can scroll past in a moment and it’s easy to miss out messages even when directed at you with the /cq prefix. After my last outing portable I returned home to see I had been called but hadn’t noticed.

Prompted by some discussion of this on the ukmicrowaves mailing list and a mention of IRC which I use a lot I thought I should have a go at sorting something out for myself and others if interested.

There are applications that can be used to access KST chat such as the contest logging software tucnak for raw access to the telnet interface and the Windows application kst2me which runs wellin Linux with Wine. Kst2me is great and would be the likely solution for most people with a computer to hand but it’s doesn’t solve my mobile device and alerting requirements.

Using Node-RED & IRC

By pulling the ‘kst chat in to Node-RED my intention was to filter messages to channels on an IRC service based on their content:

• A channel for all chat, effectively a mirror of whatever chat it’s connected to.
• A channel for nearby DXCC entries. As I’ll be using this for microwave outings I have some filtering if required during busy periods.
• A channel for direct messages sent to me with the /cq prefix so I have everything directed to me in one area.

I also want to be able to send messages to KST from my own IRC client via the channels above. A two way set-up is intended for a single user and care needs to be taken to ensure that messages sent to KST are coming from the legitimate logged in user.

I’ve used IRC here because I am comfortable with it and have clients connected to IRC servers 24/7 and can connect to these clients from any device to pick up where I left previously. This means I can leave the Node-RED flow running at home on a contest day and connect to the IRC server as I need and have a full view of everything that has happened in each of the channels. This also means I don’t have to worry about disconnections or leaving it running all the time running batteries down.

Node-RED is however  extremely flexible and allows the messages to be sent to pretty much anything such as an MQTT broker, SMS messages, DMR SMS messages, Web APIs, TCP/UDP servers etc so the use of IRC here should just be taken as an example use.

I have also set the flow up to have CQ messages directed to me on KST to send me a direct message on Twitter to gain my attention on my mobile device when not viewing the IRC channel. I could have used SMS here but the Twitter application with alerts works as well and doesn’t require using a paid for SMS service.

Interfacing With KST Chat – Login

There are two interfaces to the KST chat, the web interface and the Telnet interface, there’s no API that I’m aware of. In this instance I’ve used the Telnet interface to interact with the service as it’s the least complicated for scraping purposes.

In order to log in via Telnet we need our username, password and the band chat we wish to connect to, once these have been provided we are placed in to the selected band chat room. The Telnet outout is shown below connecting to the quiet Warch chat number 11 for test purposes.

Free text at this point will appear in the chat channel and commands need to be prefixed with a forward slash, for instance /quit.

We can log in to the Telnet interface easily with Node-RED using built in nodes and very little customization.

The flow above will initiate the connection to the ON4KST Telnet interface and log in. The nodes do the following:

1. The first node is set to execute on start-up and contains three values, username, password and the chat number.
2. The function node takes the user, pass and chat, splits them and sends the username to output 1, the password to output 2 and the chat room number to output 3.
3. These three outputs are then connected to a TCP Request node, this node takes a hostname and port number, http://www.on4kst.info:23000 in this instance. This node allows both input to and output from the TCP connection.

We also have two delay nodes, as the user, password and chat are entered separately and prompted one after another, we insert a delay after the username and password to allow the next prompt to be displayed. If they are all sent at the same time the ‘kst Telnet interface will not accept them.

If we connect a debug node to the output of the TCP request node we will see the output from the telnet session.

Remember that anything sent to the interface will be immediately sent to the channel so take care not to send your password to an already connected interface. This has caught me out already!

Interfacing With KST Chat – Output

The output from the TCP request node is fed straight in to a function node with four outputs. The function node filters and alters data and directs it to the correct outputs. The four outputs link the function node to three IRC channels and one Twitter output.

The Process Output function node does a number of things. It firstly converts the utf8 input from the TCP node in to a string and strips out newline characters. This allows us to work with it easily.

It then splits the incoming messages up if they are identified as normal messages. The message format is as follows with TOCALLSIGN being the optional CQ message and the NAME being of a variable length:

TIME FROMCALLSIGN FROMNAME > (TOCALLSIGN) MESSAGETEXT

Once we have each of the above split in to variables we start to make decisions as to what to do with the incoming messages based on regex matches.

We have three IRC channels set up for this test, one for all KST chat, one for local KST chat and one for CQ messages directed at us.

If a message matches our callsign, when someone send’s a /CQ message to us, the message is sent to all of the four function outputs resulting in it appearing in all IRC channels and a message to our user on Twitter.

If a message matches a list of prefix’s local to me (2/M/G/EI) they are filtered to the local area IRC channel and also to the all KST IRC channel. This means I have filtered IRC channel containing British Isles chat, which for me in GI matches what I’m able to work, if I was in a position to work other countries it’s easy to add them to the list.

If a message is not a CQ directed to me or in the list of filtered prefixes it is placed in the all KST channel which can be monitored when traffic isn’t heavy.

Interfacing With KST Chat – Input

I have two Input types set up to send text to the KST Telnet interface.

The first was set up for testing purposes in the Node-RED interface and consists of buttons that will send commands when clicked. These buttons send the text to a function node than adds line breaks then forwards them to the TCP request node input.

The second takes input from the IRC channels I’ve configured Node-RED to connect to and carries out some validation of observed messages, processes them then forwards to the add line feed node for sending in to the TCP node.

The Process IRC node checks incoming messages and matches them with some rules. It requires that incoming messages originate from the channels the IRC node is connected to and from a username that matches my IRC clients username.

Once this incoming messages are validated, the node checks the content for commands before actin. For instance it will parse “CQ CALLSIGN Good evening”, prefix the CQ with a forward slash and send it to the telnet service  and it will appear as a valid “/CQ” command on the KSTchat.

Wrap Up

IRC is just a single communication method here, we could do this using any other messaging platform and integrate in to applications easily enough and make this more interesting easily enough. Node-RED allows easy control of messaging and simple coding in JavaScript to manipulate things.

I hope to try the described setup while portable with my microwave setup some time and imagine that the messaging ability to alert me to calls, and the use of a persistent IRC client to interact with people should allow me to keep track of KST chat in a manner I’m more comfortable with. (I did try this in a contest weekend up a hill and it worked just fine!)

My code is a horrible mess but I can forward it to anyone that would like to try something like this out. Here’s the whole thing:

Please have a look at some other Node-RED posts for more amateur radio uses if interested in the above:

• WSJT-X monitoring with py_wsjtx & Node-RED
• DMR SMS alerts using the SharkRF openSPOT and Node-RED
• Node-RED module for DMR SMS using an openSPOT