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