Radtel RT-880 Development

The Radtel RT-880, RT-880G and iRadio UV-98 Pro is currently being worked on by myself for custom firmware. During development of the APRS capability I discovered that I can stream audio in both direction over a fast serial connection to a host device. If I protocolize this and add rudimentary CAT control, TX, CoS etc.. it would then be theoretically possible for a host to connect to this radio and the radio provide everything needed for node operation with just a serial cable, eliminating the need for extra interface hardware.

I can complete the radio side without too much trouble, but I don't really have the time to develop the neccessary driver for Asterisk (in fact I'd be completely clueless). So if anyone is interested in this angle, I'd be willing to work with them with respect to protocol etc...

Let me know
Marcus

1 Like

Neat discovery! You'd likely just want to "connect" to Asterisk/app_rpt via USRP, using the existing chan_usrp channel driver. You can do this easily with a little bit of script.The documentation around chan_usrp is extremely poor, but there are other people that have used it.

I recently contributed to this project, which makes use of a lightweight Python USRP bridge to Asterisk/app_rpt, and might serve as a starting point for anyone who wants to work on this.

1 Like

Hi Marcus,

Amazing work you did on the TIDRadio H3 nicFW. Your GUI and features are vastly superior to the stock firmware, and it’s still the only HT I know of that will support a hardware COS output.

BTW do you have a webpage summarizing what radios you’ve done FW for? I see your nicsure · GitHub has 35 repos, is that the best place to get the H3 and other FW/apps? And have you considered doing any development for the LinHT project? I think within about 1 year the LinHT is going to make most other ham HTs obsolete, and your skills would be a huge asset to that project.

What were your reasons for selecting the RT-880 for a next project? Presumably it has more CPU, flash and RAM than the H3, the larger color display looks great, and support for audio over it’s USB-C is great. What options does it have for bit rate and depth? 8Ksps 16-bit is what Asterisk and ASL use and if the 880 could provide a direct digital path to the transceiver that would definitely help maximize audio quality and simplify levels optimization.

Can the 880 use “flat” preamphasized audio where ASL would do squelch and CTCSS encode and decode, or it just filtered speaker audio I/O? (If flat audio could be supported then no COS line would be needed to ASL.) And is the 880’s USB-UART bridge a standard eg. CH343 type of IC? Does the 880 tie PTT and COS to eg. RTS and DCD?

LMK what you think of the USRP suggestion, I have been planning to look into that soon to support a Pluto+ SDR or LinHT, and it should be easy enough to do some Python or C code to move the serial data between the serial port and USRP. I believe DVSwitch also uses USRP to link to ASL. It would also be easy to modify the SimpleUSB or USBRadio channel driver to read and write from a COM port rather than a USB device.

Thanks,
David NR9V (allscan.info)

1 Like

Hi David

It's just an ADC reading of the pre-amplified audio path in the radio. However, I could only stream the audio data when squelch is opened which I believe is what you mean by "flat"? As far as PTT it would be a simple case of just sending a serial command back to the radio to engage and disengage the PTT. Only thing to look out for in this configuration would be the RF energy during TX crashing the serial chip in the comms cable. USB devices do like to stop working when in close proximity to RF energy.

As for the USRP, I have no idea. This is why it would need to be a collaboration as I have no real experience or knowledge of this side. I can make the radio do and send whatever is needed, but I need someone else to work out the Asterisk side and just tell me what they want the radio to do.

You can find a list of supported radios on my Patreon Page. You don't need to be a paid member to access the TD-H3, RT-890 and RT-900 releases of nicFW, they're all free to download and the source code to the TD-H3 and 890 versions is on my GitHub. All of which support ASL CoS.
I'm not sure about posting links here, but my Patreon is easy enough to find.

As for the audio quality. Yes I can easily stream 16 bit @ 8kHz although the ADC is 12 bit, so it would be "stretched" to 16 bit, but audio quality is fine at 12 bit (AOIC etc..). TX audio is created by PCM bit banging a stray GPIO that happens to couple to the microphone audio. But this side is actually specific, it needs to be the 880G model, not the plain 880 and also needs to be a later model as the earlier G models have different ICs for APRS (this is what I'm using to inject TX audio)

“flat” audio is raw audio from the FM discriminator or equivalent, before any preemphasis, squelch or filtering. Most HTs use RF SoC’s that don’t make that available outside the IC so I wouldn’t expect that here but if an HT could provide that it would enable ASL to do the squelch and CTCSS decode and thus can give more flexibility and higher audio quality.

If the audio over serial is 12-bit for the ADC and then PWM (?) to the mic I wouldn’t see any audio quality advantage there over going through the K1 jacks and a 16-bit URI, and the URI then provides other advantages eg. status LEDs, thorough RFI filtering and isolation, and can provide DC power for the HT (node radios ideally should not be dependent on an HT battery and charger). With the RT-880 being close to $100 it would seem better suited as a client radio than a node radio. BTW I have an RT-890 which are very nice and low cost radios and will give your FW a try on that. And I see the RT-900 is pretty inexpensive and has Bluetooth - personally I prefer wired interconnects when possible but it would be interesting if ASL could interface to one of these radios through Bluetooth.

Well it's not really about audio quality per se. it's about eliminating that audio interface and just using a serial cable. The audio quality is going to be arguably worse, that's the trade-off. But if you're happy with it that way it's fine. I'll go back to firmware development, it was just an idea.