April 18, 2025: TIDRADIO TD-H3 cloning and upgrading, WPSD hotspot updating, hear ARRL Audio News on your AllStar node, new AllScan nodes coming, resurrecting an old router.
Regarding the "ARRL Audio News on Your Allstar node" segment, a recent update to the service now allows each connection to receive its own complete audio feed, separate from other connections. So the paragraph about "The first node to connect starts the audio news playback..." no longer applies. Information and updates about this service are posted on https://ARRLNews.rfnet.link
Feeding separate audio to each connection is somewhat of a workaround due to the fact that Allstar RPT() requires the remote node to respond to the connecting node using RPT() within a few seconds. Otherwise, the connection is dropped by the calling node. Allstar does not provide full audio routing control in RPT() from either side of a connection (e.g. mute, monitor, link/conference, etc.). This meant that all connections to a node are conferenced and generally hear the same audio/transmissions. This was why, originally, whatever node first connected to 516229 would start the playback audio, and other connections would hear whatever was playing at the time they connected.
I would have preferred to use Asterisk methods to answer and play/send the audio to each connecting node, without actually running RPT(). This is actually supported by at least some "Web Transceiver" Allstar applications, like DVSwitch Mobile. I can send the audio streams to each Web Transceiver connection separately using only commands in extensions.conf, without running RPT() or shell scripts for those connections.
For Allstar nodes, I discovered I could create multiple private nodes on the ARRLNEWS Allstar server, and call RPT(<private_node_number>), using the next available (inactive) private node number. If 516229 is busy with playback to a node, the new incoming node is connected to the next available private node instead. I set global variables in extensions.conf and rpt.conf events to flag which nodes are in use, or available.
Events in rpt.conf run a shell script to send (playback) audio, and pauses, to connected nodes. There are other scripts to manage the audio file weekly updates and conversion to ulaw, as well as splitting news segments. It is helpful that ARRL News audio includes distinctive breaks between segments, unlike Amateur Radio Newsline (ARNews).
I am testing a new playback feed for ARNewsline on node 516228. This is almost identical to ARRLNEWS except the breaks in transmission are simply every couple of minutes, and it rewinds a few seconds of audio when it resumes playing after a pause. There is no reliable automated method to break between news segments in ARNewsline audio.
I am wondering if the 55553 audio test server could use similar methods to separate incoming connections, so connecting nodes do not conflict with each other while testing their audio levels.? I am a big fan of the 55553 audio test service, but I do not have any details on how it is configured.
Excellent information, thank you. I did think about trying to detect silences or "K" characters sent in Morse as a way to split the incoming audio, but quickly realized that was beyond my skill level. Splitting on an arbitrary regular time schedule sounds like a very workable solution.
Multiple private nodes! That is a creative solution!
I believe Patrick KE4DYI is the driver behind 55553.
Tom - Great newsletter as always! I just received two TD-H3s so your cloning and updating info was timely for me. The issue of consumer Wi-Fi Access Points, especially older units (Goodwill, cheap on Amazon) being targets for botnets or direct hacking is very real. One way to potentially use them safely is to flash OpenWRT software onto them IF they are supported by OpenWRT. OpenWRT software is safe and maintained. You can see if a specific device is supported by OpenWRT by checking their list: https://openwrt.org/supported_devices.
Absolutely right about OpenWRT software on old routers. Thank you for adding that. My GL.iNET Flint 2 router runs a fork of OpenWRT (https://openwrt.org/toh/gl.inet/gl-mt6000) and I find it great as long as one doesn't mind digging into it a bit!
Stay tuned as I just ordered a TD-H8 radio, on the suggestion of a subscriber. Looking forward to it. For the record, I've had very little trouble with my two TD-H3 Ham radios. On one I messed something up and simply reset the radio to fix it. The other has been flawless (meaning I didn't fumble finger that second radio).
Between the TIDRADIO TD-H3 and and the Retevis RT-85 radios, I don't think we've ever seen such capable, inexpensive handhelds. Time will tell how reliable and sturdy they are, but for the price, it feels like it is worth giving these radios a try.
One other thing I love about the TD-H3 is the USB-C charging! That is SO sane - no custom power adapters needed any more (though it's nice that they include 2x USB-C cable and USB-C wall wart in the package with the drop in charging base.
Me. too. Right now, I'm recharging the TD-H3 I took with me on my morning walk, clipped to my belt under my jacket, with a monaural earphone in one ear while the W6EK net on node 51018 was going on. Being able to charge with a USB-C cable is a blessing as I don't have to (a) make space for a special charger and (b) find room for it!
Regarding the "ARRL Audio News on Your Allstar node" segment, a recent update to the service now allows each connection to receive its own complete audio feed, separate from other connections. So the paragraph about "The first node to connect starts the audio news playback..." no longer applies. Information and updates about this service are posted on https://ARRLNews.rfnet.link
Thanks!
David, WD5M
That is great news! I'm curious how that was done, but I don't really need to know that to enjoy the ARRL Audio News! Thank you.
Feeding separate audio to each connection is somewhat of a workaround due to the fact that Allstar RPT() requires the remote node to respond to the connecting node using RPT() within a few seconds. Otherwise, the connection is dropped by the calling node. Allstar does not provide full audio routing control in RPT() from either side of a connection (e.g. mute, monitor, link/conference, etc.). This meant that all connections to a node are conferenced and generally hear the same audio/transmissions. This was why, originally, whatever node first connected to 516229 would start the playback audio, and other connections would hear whatever was playing at the time they connected.
I would have preferred to use Asterisk methods to answer and play/send the audio to each connecting node, without actually running RPT(). This is actually supported by at least some "Web Transceiver" Allstar applications, like DVSwitch Mobile. I can send the audio streams to each Web Transceiver connection separately using only commands in extensions.conf, without running RPT() or shell scripts for those connections.
For Allstar nodes, I discovered I could create multiple private nodes on the ARRLNEWS Allstar server, and call RPT(<private_node_number>), using the next available (inactive) private node number. If 516229 is busy with playback to a node, the new incoming node is connected to the next available private node instead. I set global variables in extensions.conf and rpt.conf events to flag which nodes are in use, or available.
Events in rpt.conf run a shell script to send (playback) audio, and pauses, to connected nodes. There are other scripts to manage the audio file weekly updates and conversion to ulaw, as well as splitting news segments. It is helpful that ARRL News audio includes distinctive breaks between segments, unlike Amateur Radio Newsline (ARNews).
I am testing a new playback feed for ARNewsline on node 516228. This is almost identical to ARRLNEWS except the breaks in transmission are simply every couple of minutes, and it rewinds a few seconds of audio when it resumes playing after a pause. There is no reliable automated method to break between news segments in ARNewsline audio.
I am wondering if the 55553 audio test server could use similar methods to separate incoming connections, so connecting nodes do not conflict with each other while testing their audio levels.? I am a big fan of the 55553 audio test service, but I do not have any details on how it is configured.
Enjoy!
David, WD5M
Excellent information, thank you. I did think about trying to detect silences or "K" characters sent in Morse as a way to split the incoming audio, but quickly realized that was beyond my skill level. Splitting on an arbitrary regular time schedule sounds like a very workable solution.
Multiple private nodes! That is a creative solution!
I believe Patrick KE4DYI is the driver behind 55553.
Tom - Great newsletter as always! I just received two TD-H3s so your cloning and updating info was timely for me. The issue of consumer Wi-Fi Access Points, especially older units (Goodwill, cheap on Amazon) being targets for botnets or direct hacking is very real. One way to potentially use them safely is to flash OpenWRT software onto them IF they are supported by OpenWRT. OpenWRT software is safe and maintained. You can see if a specific device is supported by OpenWRT by checking their list: https://openwrt.org/supported_devices.
Absolutely right about OpenWRT software on old routers. Thank you for adding that. My GL.iNET Flint 2 router runs a fork of OpenWRT (https://openwrt.org/toh/gl.inet/gl-mt6000) and I find it great as long as one doesn't mind digging into it a bit!
Stay tuned as I just ordered a TD-H8 radio, on the suggestion of a subscriber. Looking forward to it. For the record, I've had very little trouble with my two TD-H3 Ham radios. On one I messed something up and simply reset the radio to fix it. The other has been flawless (meaning I didn't fumble finger that second radio).
Between the TIDRADIO TD-H3 and and the Retevis RT-85 radios, I don't think we've ever seen such capable, inexpensive handhelds. Time will tell how reliable and sturdy they are, but for the price, it feels like it is worth giving these radios a try.
One other thing I love about the TD-H3 is the USB-C charging! That is SO sane - no custom power adapters needed any more (though it's nice that they include 2x USB-C cable and USB-C wall wart in the package with the drop in charging base.
Me. too. Right now, I'm recharging the TD-H3 I took with me on my morning walk, clipped to my belt under my jacket, with a monaural earphone in one ear while the W6EK net on node 51018 was going on. Being able to charge with a USB-C cable is a blessing as I don't have to (a) make space for a special charger and (b) find room for it!