- Developers - lists.chirpmyradio.com

python-3.13 is dropping future
by zbox＠atlas.cz 02 May '24

02 May '24

Hi, python-3.13 will drop "future". It seems most of the drivers which use it have conditional import, but tox still hard requires it. For support of the python-3.13 the tox "future" requirement will have to be dropped/relaxed. I tried to drop it in my fedora-41 python-3.13 test build and it seems it builds/tests OK thanks & regards Jaroslav

2 1

FS-T3 unnecessary seek warnings
by Charles Terrell 19 Apr '24

19 Apr '24

Almost done adding support for Radioddity FS-T3. Currently all tests pass for the files I touched, except for a few like this: XFAIL tests/test_drivers.py::TestBitwiseStrict_Radioddity_FS-T3::test_bitwise_unnecessary_seek After commenting out "#seekto 0x0000" the Retevis RB18 driver that I'm using as a superclass passes, but it still complains about mine. At run time it says "Unnecessary #seekto 0x0630" when downloading as FS-T3 but not as RB18. Apparently it's because they have the same memory size but different channel ranges. With fewer than 99 channels (RB18 = 22ch) it needs the #seekto to find the settings. With 99 channels the end of channel memory meets the start of settings, making the #seekto unnecessary. Setting channels to 98 silences the warning. Commenting out the 0x0630 line in the memory map causes an index out of range error for RB18. Is there a preferred way to handle this conflict? Officially the FS-T3 is marketed as a 22 channel radio, but Radioddity's own software allows 99 channels by default. It's a nice feature for keeping 1-22 pristine while leaving room for group channels. Does anyone have a Baofeng BF-T12 for testing? It looks very similar and Baofeng's official software (also 99 channels) works with my FS-T3. I've already heard from someone who has a Radioddity PR-T3. For user convenience I added lightweight subclasses for these models. ---- Charles Terrell <tachyon(a)pobox.com>

2 1

Style checker annoyance
by Charles Terrell 19 Apr '24

19 Apr '24

Radioddity FS-T3 family lacks roger beep capability. To avoid confusing users, in drivers/radtel_t18.py I enclosed the roger beep setting in an "if" statement. That meant it needed another level of indenting. if self.MODEL != "BF-T12" and self.MODEL != "FS-T3" and \ self.MODEL != "PR-T3": rs = RadioSetting("rogerbeep", "Roger beep", RadioSettingValueBoolean(_settings.rogerbeep)) basic.append(rs) (Pretend there are 12 more spaces at the start of each line.) Ran "tox -e style" to test for code standards. Error message: ./chirp/drivers/radtel_t18.py:873:80: E501 line too long (80 > 79 characters) One character too long! Backed off the RadioSettingValueBoolean indent by one space. Ran it again: ./chirp/drivers/radtel_t18.py:873:34: E128 continuation line under-indented for visual indent So it can meet style standards for line length or visual indent, but not both at the same time. Tried to trick it by adding \ to the previous line, turning it into a continuation that might have different indent rules. Didn't work. ./chirp/drivers/radtel_t18.py:872:62: E502 the backslash is redundant between brackets How much of a problem is this really? Any suggestions to make it pass tests? ---- Charles Terrell <tachyon(a)pobox.com>

2 2

Welcome to the new list
by Dan Smith 22 Mar '24

22 Mar '24

Hi all (again), I'm emailing you via the new mailing list on the new domain. The site for the new list software is: https://lists.chirpmyradio.com You should be able to do the "forgot password" routine if you want to log in and change your settings. I've imported the old subscription list, as well as the archives which are viewable in the new software as well. I don't want to generate too much noise for people, but if at least a few people could reply and indicate that this worked (as well as any other issues like it landing in spam) I'd appreciate it. Thanks! --Dan

8 9

[chirp_devel] Introduction
by Eric Poole 13 Mar '24

13 Mar '24

Good morning all, from a new CHIRP user and new member of the developer's reflector. (Incidentally, is it CHIRP or Chirp or chirp? I've seen all three used. What is the proper way to refer to the product?) I've joined the developer's reflector because I would like to contribute to CHIRP by writing drivers for the Icom IC-746PRO and IC-706MKIIG. I'm a retired software developer with 40+ years experience, mostly in C with some assembly language and C++. I have almost no experience with Python, have just done some minor modifications on existing programs. I do understand object-oriented design and programming. I have only limited experience with Git, having used it on only two projects, mostly used Subversion on past projects. I'm wondering if any of you have any recommendations for a good tutorial, available on the net, for someone like me who wants to learn enough Python to be effective in writing drivers for CHIRP. I know there are many such tutorials out there and wanted to find out if you have any recommendations for one over the others. I'd appreciate any suggestions, and meanwhile I'll be around the reflector as I go about figuring out how to do this correctly. Thanks... Rick WA1RKT Londonderry, NH Catch me on 14.300 MHz Intercon / MMSN most days See my QRZ page

2 5

[chirp_devel] Radioddity FS-T3 seems related to Retevis RB18
by Charles Terrell 05 Mar '24

05 Mar '24

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(a)pobox.com>

4 6

Re: [chirp_devel] Introduction
by Dan Smith 01 Mar '24

01 Mar '24

> The IC-746 driver is a bit of an oddball insofar as it's the only one of the Icom CI-V drivers that doesn't appear to define its own memory format. Whether that's because it was the first of these drivers, and therefore got to define the core classes, I don't know. Nope, it was actually the third (after the 7200 and then the 7000)! FWIW, I think it _does_ actually have its own frame format, it just calls it "DupToneFrame" because it was like the earlier ones, but.. had duplex/tone which the 7200 doesn't. I think that at that point we were probably thinking that the memory format would be more consistent among models. Nothing else actually uses that except the 746, if I'm reading correctly. > As such, though, it's perhaps not the best place to start. Following the design of the IC-910 driver is likely a better bet, though you'll probably want to look at others for tips on what the format might look like. Given that I've seen the IC-746Pro referred to as the IC-7400, it's possible that you may get tips from looking at the IC-7300 format. I wrote the IC-910 driver, and am happy to help with questions. Perhaps just one reason to look at the 746 instead is that it's very bare-bones and the 910 has a lot more features and the 23cm probing thing. But yeah, fair point that starting with (or at least consulting) one that has gotten much more love over the years is probably a good idea. --Dan

2 1

[chirp_devel] Baofeng/5RM Power-On Image
by Henry Grasman 26 Feb '24

26 Feb '24

Hi, I'm toying with the idea of adding the ability to upload custom power-on images to the 5RM (and presumably all the other similar devices). I've started picking at Baofeng's software to see how it works, and I'd like some help before I commit to anything: -1) Should I bother/ has someone tried this already? 0) These are "clone mode" radios, and I don't see a change in memory after changing welcome screens with BF's sw. Would that be CHIRP ignoring/not reading the relevant memory section? Or is there precedent for baofengs to have settings that are not part of the normal clone? Probably for Dan: 1) Would it be accepted for CHIRP to have this feature? Is it absent for some reason, or simply because nobody has implemented it? If I were to be the first to implement this, how would you like to architect it into the SW? Part of the driver? New functions for UI? 2) I have reverse engineered the encoding and some header info for the image write. Where should I look for details on the existing reverse engineered protocols for this device? I am hoping my answer to question 0 is "chirp is probably just not touching the memory we care about" and I only have to make minor changes, but this info will help in any case. 3) Does anyone have other radios that have similar features to consider while designing how this will work? I have plenty to keep me busy between work and life, so I appreciate any advice and help that might make this easier. Thank you, Henry Grasman K2KNO

2 2

[chirp_devel] TH-UV88 Optional signaling implementation Feature #1110
by Cyril Velter 10 Feb '24

10 Feb '24

Hello, I just commited optional signaling in my chirp repo : https://github.com/velter/chirp/tree/th_uv88-optsignaling Some things might still be polished (dynamicly show/hide/clear encode/decode settings based on chanel activation for example). But everything is functional and all tests are passing. This branch contain an updated image file for TYT-UV88 with more complete parameters coverage Before I make a pull request, it would be nice to have some feedback : - Currently the code is activated for TYT UV-88 but also for Retevis RA89 and QRZ-1. It seems from the docs that RA89 support optional signal but I'm not sure for QRZ-1. Test images for both models contains correct datas but from the docs it seems QRZ-1 does not support optional signaling. Can someone with access to these radio can test and tel me ? - While I do software development for more than20 years I'm pretty new to python. Some coding might probably be improved - More tests will be welcomed When this change will be commited I propose to also work on : - Handling the vfo settings ("VFo Ch" tab from the original software) - Handling the Frequence range settings ("Frequency Range" tab from the original software - Reorganize Basic/Advanced/Work mode settings in the UI (for exemple the 3 VOX settings are scattered around in 3 different place from 2 differents tabs. I would propose to group the settings in 3 categories UI, Radio and Work mode - Other small fixes (scramble value 8 not handled properly) cyril

2 3

[chirp_devel] TH UV88
by Cyril Velter 07 Feb '24

07 Feb '24

Hello, My name is cyril it's my first post to this list. I'm working on improving the th_uv88 driver to fix small issues and adding support for optional signaling (dtmf, 2tones ans 5 tones). I've two questions : 1) I have submited a first Pull Request which have now been merged in the main repo but I'm having trouble to submit a second one as github try include all the previous commit since I do the fork. I'm certainly doing something wrong (I'm not used to git) can someone point me in the right direction ? 2) Implementing optional signaling, i already have all the values in the memory tree. Now I'm working on the UI in the settings tab. I need to display some list of tuples (for exemple dtmf code/type/name). Is there a way to display an array instead of just a list of name/value pairs in the right panel of the settings tree ? I have not found any driver doing this. thanks, cyril

4 4