[chirp_devel] Radioddity FS-T3 seems related to Retevis RB18
Trying to get Chirp to talk to my Radioddity FS-T3 (same as PR-T3). Using a typical USB cable with FTDI chip. Proprietary software from Radioddity runs well in Win 10, and tolerably in Fedora using "bottles". Using plain wine is more complicated due to .net DLL errors. Based on earlier FCC filings and similar appearance, it could be a rebadged Baofeng BF-T12.
Could not find a free working serial port capture solution for Win 10. Linux capture scripts from chirp docs yielded a pcap file but nothing parsed out. Finally just loaded the pcap file into wireshark. Confirmed baud and flow settings. Exported as plain text from there, grepped for "payload", cleaned it up with my own perl script.
What I found: PC sends "PROGRAL" and radio replies with "P3107". Digging through existing chirp code, Retevis RB18 driver (radtel_t18.py) has both PROGRAL and P3107.
Tried it: Yes! Radioddity FS-T3 actually works with RB18 driver. But it's not perfect. It's limited to 22 channels, while the real radio can handle up to 99 memory channels. 22 seems to be hard-coded in the RB18 driver. This is sort of a big deal because the radio offers no way to change squelch tones / codes without using a computer. Sometimes it's easier just to add another channel for a particular group or event.
Also, the radio can do separate RX/TX freqs via its original software, making it GMRS repeater compatible. (Note that it is not marketed as GMRS. Based on signal reports, I suspect it forces narrowband for GMRS repeaters. Possibly because repeater inputs are in the same general freq range as FRS channels 8-14.) But the RB18 driver forces simplex.
Haven't tried other drivers yet, but at least 3 other files mention P3107. This is a good start though. As it is now, the RB18 driver gives the functionality one would need for pure FRS-only usage. I think we can do better for GMRS / PMR446 / 70cm ham / extra FRS channels, which the mfg's software already can do.
I'll check my dev tools setup and see what I can come up with.
---- Charles Terrell tachyon@pobox.com
Tried it: Yes! Radioddity FS-T3 actually works with RB18 driver. But it's not perfect. It's limited to 22 channels, while the real radio can handle up to 99 memory channels. 22 seems to be hard-coded in the RB18 driver. This is sort of a big deal because the radio offers no way to change squelch tones / codes without using a computer. Sometimes it's easier just to add another channel for a particular group or event.
Excellent, glad you looked to see if it was already similar to an existing radio before just starting a new one. Too many drivers are near copies of each other and I'm trying to crack down on that.
Also, the radio can do separate RX/TX freqs via its original software, making it GMRS repeater compatible. (Note that it is not marketed as GMRS. Based on signal reports, I suspect it forces narrowband for GMRS repeaters. Possibly because repeater inputs are in the same general freq range as FRS channels 8-14.) But the RB18 driver forces simplex.
Haven't tried other drivers yet, but at least 3 other files mention P3107. This is a good start though. As it is now, the RB18 driver gives the functionality one would need for pure FRS-only usage. I think we can do better for GMRS / PMR446 / 70cm ham / extra FRS channels, which the mfg's software already can do.
Sounds like you may be able to just subclass the existing driver and implement a different get_features() function which sort of defines the "rules" for the radio to add things like duplex or whatever. At least it'll be a start, and potentially just adding some functions to the base driver that your subclass can leverage even though the rules are tighter on the other models works well. There are also some examples of radios that have a "GMRS-only" variant of a ham/commercial radio you might look at for other inspiration.
--Dan
Tried it: Yes! Radioddity FS-T3 actually works with RB18 driver. But it's not perfect. It's limited to 22 channels, while the real radio can handle up to 99 memory channels. 22 seems to be hard-coded in the RB18 driver. This is sort of a big deal because the radio offers no way to change squelch tones / codes without using a computer. Sometimes it's easier just to add another channel for a particular group or event.
Just like there are other radios supported by this driver with 5, 16 and 30 channels, you can add one that supports 99 channels.
The channels for the RB18 appear 'hard coded' because "GMRS = True". For a 'full band' radio, just make sure that none of the specially supported services are set to True.
_frs = _frs16 = _murs = _pmr = _gmrs = False
If you base your subclass on the Radtel T18 model, you will get this for 'free'.
Jim KC9HI
Just like there are other radios supported by this driver with 5, 16 and 30 channels, you can add one that supports 99 channels.
The channels for the RB18 appear 'hard coded' because "GMRS = True". For a 'full band' radio, just make sure that none of the specially supported services are set to True.
Thanks for the info!
Already got it to show 99 channel rows and did a successful import from a radio with 39 channels in use. Still trying to figure out how to make it do separate TX and RX freqs.
Bonus outcome: After setting up venv and finding a wheel for wxPython, I actually got chirp to run natively in Linux. Until now I've been using the windows version in wine. Fewer dependency hassles... I like how it feels faster running natively though.
---- Charles Terrell tachyon@pobox.com
I found official PC programming software for the almost identical looking Baofeng BF-T12. It recognized my Radioddity FS-T3 as one of its own and allowed me to program a pair of local 70cm repeater channels. On 70cm simplex it received a clear signal from my UV-K5 well outside the PMR range.
This is interesting because the (also almost identical looking) Radioddity PC software strictly enforces upper and lower freq limits for FRS and PMR. This means at least some of the enforcement happens in software and not on the radio itself.
Wonder if any chirp users have actual BF-T12 hardware for testing...
Hello Charles,
I have the PR-T3 model.
If you open a GitHub pull request I can test your patch.
I checked here: https://github.com/kk7ds/chirp/pulls but I dont see a PR for the FS-T3/PR-T3
Thanks
Saverio
Il giorno mar 5 mar 2024 alle ore 01:22 Charles Terrell via chirp_devel chirp_devel@intrepid.danplanet.com ha scritto:
I found official PC programming software for the almost identical looking Baofeng BF-T12. It recognized my Radioddity FS-T3 as one of its own and allowed me to program a pair of local 70cm repeater channels. On 70cm simplex it received a clear signal from my UV-K5 well outside the PMR range.
This is interesting because the (also almost identical looking) Radioddity PC software strictly enforces upper and lower freq limits for FRS and PMR. This means at least some of the enforcement happens in software and not on the radio itself.
Wonder if any chirp users have actual BF-T12 hardware for testing... _______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
On Tue, Mar 5, 2024 at 01:38 Saverio Proto zioproto@gmail.com wrote:
I have the PR-T3 model.
If you open a GitHub pull request I can test your patch.
I checked here: https://github.com/kk7ds/chirp/pulls but I dont see a PR for the FS-T3/PR-T3
It's not quite ready to commit yet. Still a few details to finish.
Good to know someone has the European model for testing though. I think both models are likely to be the same except for wall plugs, factory channel settings, and a few small identifying stickers. But I could be wrong about that.
---- Charles Terrell tachyon@pobox.com
participants (4)
-
Charles Terrell -
Dan Smith -
Jim Unroe -
Saverio Proto