- Developers - lists.chirpmyradio.com

New file format
by Declan Rieb 22 Aug '24

22 Aug '24

I’m able to get the FT-1D, FT2D and I think FT-3D to read Yaesu’s SD-card format. [Only the FT2D is for sure tested.) I’m not really confident in the ability to correctly write such a file, so I’ve marked it as readonly=True in the directory. Since the Yaesu manual gives directions for writing an SD-card but not for the Adms programmer, it makes sense to me to be able to at least read such a card. A new user can save original state and memories without having to resort to a serial cable (that does NOT come with the radio by default.) The Yaesu Adms formats (.ft1d, .ft2d, .ft3d) are already handled by CHIRP. My “difficulty” is twofold: Yaesu by default writes a file on the SD-card called BACKUP.DAT (at least for FT2D) The file does not have (AFAICT) any explicit identifier indicating which type of radio was used. So, I’ve set the drivers to use filetypes .sdc1, .sdc2 and .sdc3. To make that work, the user will need to rename the file or copy it to a file with an appropriate filetype to use it with CHIRP. These new filetypes are described as “[radio] sdcard” in the open dialog Is there any reasonable way to give help to users by describing the process inside CHIRP? I’m thinking pop-up context-sensitive box. Or even to apprise them of the new capability? ______ Declan Rieb WD5EQY wd5eqy(a)arrl.net

2 1

Tox deprecation/warning
by Declan Rieb 22 Aug '24

22 Aug '24

I’m consistently seeing the following warning when I run tox. I doubt there’s anything new here, but it might be a problem in the future. $ pytest --disable-warnings --html=driver_report.html -v tests/test_drivers.py -n auto -k Yaesu_FT-1D_R ~/chirp/.tox/driver/lib/python3.11/site-packages/pytest_html/report_data.py:49: DeprecationWarning: 'render_collapsed = True' is deprecated and support will be removed in the next major release. Please use 'render_collapsed = all' instead. warnings.warn( BTW, Thanks for the earlier help. ______ Declan Rieb WD5EQY wd5eqy(a)arrl.net

2 1

Debug file? Developer mode?
by Declan Rieb 20 Aug '24

20 Aug '24

The CHIRP-next has a menu item allowing to show the debug log. It seems to be in a private /tmp location with a name starting “chirp_debug" When I run “./chirpwx.py” from my development copy of CHIRP (with developer mode turned on) … NOW where can I find the debug log? If I knew its name, I suppose I could run find(1) to get it. If it needs to be named in some parameter so I can access it, what’s the parameter? Does it require a redirect from stderr? I have been using developer mode simply to browse the state of my data. That’s pretty useful. I see there’s also an option to “interact with the driver”, which gives me a python “>>>” prompt with an introduction: WARNING: Going to interact with radio at the console Locals are: main, radio What are interesting things one can do with the driver interaction? Can one set breakpoints? Modify code on-the-fly? Inspect or change program state other than the data seen by the browser? I am just barely aware enough to ask python for "dir(radio)” and for individual items in my driver… what next? Thanks for any direction or suggestions. ______ Declan Rieb WD5EQY wd5eqy(a)arrl.net

2 4

IC-R6 failing Tox test_sync_out
by John Bradshaw 03 Aug '24

03 Aug '24

Hi everyone, The new IC-R6 driver is failing one test: Failed tests/unit/test_icom_clone.py::Test_Icom_IC-R6::test_sync_out 1 ms self = <tests.unit.test_icom_clone.Test_Icom_IC-R6 testMethod=test_sync_out> def test_sync_out(self): self.radio._mmap = memmap.MemoryMapBytes( bytes(b'\x00') * self.radio.get_memsize()) self.radio._mmap[50] = bytes(b'abcdefgh') self.radio.sync_out() > self.assertEqual(b'abcdefgh', self.simulator._memory[50:58]) E AssertionError: b'abcdefgh' != b'' tests/unit/test_icom_clone.py:78: AssertionError Memsize looks fine, though the exported image has a trailing base64 string which decodes as: {"mem_extra": {}, "rclass": "ICR6Radio", "vendor": "Icom", "model": "IC-R6", "variant": "", "chirp_version": "py3dev"} Some other Icom image files such as Icom_IC-W32E.img end with the standard Icom_IC-W32E.img<null> but I see Icom_ID-80H.img also has base64 at the end: {"mem_extra": {}, "rclass": "ID80Radio", "vendor": "Icom", "model": "ID-80H", "variant": "", "chirp_version": "py3dev"} Perhaps that's OK? Saved the image file back out as ICF and it loaded fine in Icom's CS-R6 - had to change one value from 000000 to 002A to get "#EtcData=002A" but that's related to US/Europe variant. Haven't tried writing to my radio yet. Using the standard library ICF3 code, don't have sync_out() in the IC-R6 class. Thoughts on why test_sync_out() could be failing please? Regards, John.

2 1

Icom IC-R6: Auto Tuning Steps
by John Bradshaw 19 Jul '24

19 Jul '24

Hi everyone, Making progress on the IC-R6 driver - https://chirpmyradio.com/issues/2795 Figured out some of the the frequency mappings thanks to the mention of 6.25k steps in Rich Cochran AG6QR's R2 code. The radio is jumping between 5k, 6.25k and 9kHz multipliers (so that 9th steps of 5kHz jumps that is out of sequence is coded as a multiple of 9kHz, not 5kHz and the pattern therefore repeats every 45kHz). Rest should be fairly easy now the pattern is obvious. Back to frequencies and steps... two queries: Dave provided an ICF on 2795 I'm seeing an "Auto" TS option in CS-R6 for the channel memories (value 14). Chirp doesn't seem to like that. When I enter a frequency it's changing TS from "Auto" to "5" - which is index 0 of my STEPS list). I can set the TS back to "Auto" manually as it's my STEPS list. Is there a way to allow "Auto" TS in Chirp? Or let me set it based on entered frequency? Or block it from the GUI but allow it to be read from the radio/ICF? Looks like Chirp is coded for floats only (some %.2f seen). Also CS-R6 rounds frequencies to the nearest valid value (based on TS - but if it's "Auto" it's more generous - for example will accept valid multiples of 6.25kHz as well as 5, 10, ...). I quite like that approach rather than rejecting the entered frequency. My frequency mapping coded isn't written yet so haven't tried a CSV import with invalid values but wondering if Chirp has a switch to enable frequency rounding? Need to add more validation in the IC-R6 driver (radio only accepts 9kHz TS over a small AM broadcast range) but not up to playing with the core code... prefer to get the frequency coding done and raise a pull request. The driver should be 90% done at that point (some bank channels and and a GUI for the device settings still needing written) but good enough for beta testing. Should I force TS to a numeric value on reading/opening and also accept that Chirp is designed to reject invalid frequencies rather than round to nearest valid one? Thanks. John.

2 2

FM broadcast radio
by Jacek Lipkowski 18 Jun '24

18 Jun '24

Hi, Chirp contains a standard concept of channels and generally what an old analog radio looks like: frequency, shift, tones etc. And indeed this is what most radios look like more or less, so it's good that it's standardized. There are two other things that are very often present in modern radios: broadcast fm receiver and flashlight. We often make fun of that, but it's everywhere and it turns out people actually use that (yes, i was surprised too). So what do you think about a standardized fm broadcast radio concept in chirp? (not sure about the flashlight :) This is just an idea (initially wanted to post this on april 1st). I'm expecting an answer of no. VY 73 Jacek / SQ5BPF

3 3

Retevis RT40
by brian.mattey＠outlook.com 17 Jun '24

17 Jun '24

Hi, I see the RT40B is supported but I don’t see any mention of the RT40. Can you confirm whether or not the RT40 is supported? Thanks, Brian

2 1

Icom IC-R6 frequency coding
by John Bradshaw 07 Jun '24

07 Jun '24

Hi everyone, Made progress with the Icom IC-R6, most things now coded, except for one rather important field (frequency). One that's sorted just the device settings GUI to code before the first pull request, hopefully get some user feedback and test images at that stage. Would appreciate some fresh eyes on the frequency encoding. Can still code this but would like to understand why they've done this and how it relates to the hardware. Columns below: - F0-F2 are the 3 coded bytes in memory (F0 is the least significant, below is "radio order" per the ICF) - Freq in MHz (each row increments by 5kHz in this example - the smallest CS-R6 allows) - Dec and Hex are the decodes of F0 to F2. Every 9th row breaks the expected pattern (i.e. 99.990 MHz isn't 1E 4E 00 but 66 2B F0). I see the lower 6 bits of F0 increment by 1 but why set the 2nd highest bit? Why toggle bits in F1 as well as setting 4 bits high in F2? Why every 9 rows? | F0 | F1 | F2 | Freq MHz | Dec | Hex | | -- | -- | -- | -------- | -------------- | ------------------------------ | | 16 | 4E | 00 | 099.950 | <22><78><0> | <00010110><01001110><00000000> | | 17 | 4E | 00 | 099.955 | <23><78><0> | <00010111><01001110><00000000> | | 18 | 4E | 00 | 099.960 | <24><78><0> | <00011000><01001110><00000000> | | 19 | 4E | 00 | 099.965 | <25><78><0> | <00011001><01001110><00000000> | | 1A | 4E | 00 | 099.970 | <26><78><0> | <00011010><01001110><00000000> | | 1B | 4E | 00 | 099.975 | <27><78><0> | <00011011><01001110><00000000> | | 1C | 4E | 00 | 099.980 | <28><78><0> | <00011100><01001110><00000000> | | 1D | 4E | 00 | 099.985 | <29><78><0> | <00011101><01001110><00000000> | | 66 | 2B | F0 | 099.990 | <102><43><240> | <00011110><00101011><11110000> | | 1F | 4E | 00 | 099.995 | <31><78><0> | <00011111><01001110><00000000> | | 20 | 4E | 00 | 100.000 | <32><78><0> | <00100000><01001110><00000000> | | 21 | 4E | 00 | 100.005 | <33><78><0> | <00100001><01001110><00000000> | | 22 | 4E | 00 | 100.010 | <34><78><0> | <00100010><01001110><00000000> | | 23 | 4E | 00 | 100.015 | <35><78><0> | <00100011><01001110><00000000> | | 24 | 4E | 00 | 100.020 | <36><78><0> | <00100100><01001110><00000000> | | 25 | 4E | 00 | 100.025 | <37><78><0> | <00100101><01001110><00000000> | | 26 | 4E | 00 | 100.030 | <38><78><0> | <00100110><01001110><00000000> | | 6B | 2B | F0 | 100.035 | <107><43><240> | <01101011><00101011><11110000> | | 28 | 4E | 00 | 100.040 | <40><78><0> | <00101000><01001110><00000000> | | 29 | 4E | 00 | 100.045 | <41><78><0> | <00101001><01001110><00000000> | | 2A | 4E | 00 | 100.050 | <42><78><0> | <00101010><01001110><00000000> | | 2B | 4E | 00 | 100.055 | <43><78><0> | <00101011><01001110><00000000> | | 2C | 4E | 00 | 100.060 | <44><78><0> | <00101100><01001110><00000000> | | 2D | 4E | 00 | 100.065 | <45><78><0> | <00101101><01001110><00000000> | | 2E | 4E | 00 | 100.070 | <46><78><0> | <00101110><01001110><00000000> | | 2F | 4E | 00 | 100.075 | <47><78><0> | <00101111><01001110><00000000> | | 70 | 2B | F0 | 100.080 | <112><43><240> | <01110000><00101011><11110000> | | 31 | 4E | 00 | 100.085 | <49><78><0> | <00110001><01001110><00000000> | | 32 | 4E | 00 | 100.090 | <50><78><0> | <00110010><01001110><00000000> | | 33 | 4E | 00 | 100.095 | <51><78><0> | <00110011><01001110><00000000> | | 34 | 4E | 00 | 100.100 | <52><78><0> | <00110100><01001110><00000000> | | 35 | 4E | 00 | 100.105 | <53><78><0> | <00110101><01001110><00000000> | | 36 | 4E | 00 | 100.110 | <54><78><0> | <00110110><01001110><00000000> | | 37 | 4E | 00 | 100.115 | <55><78><0> | <00110111><01001110><00000000> | | 38 | 4E | 00 | 100.120 | <56><78><0> | <00111000><01001110><00000000> | | 75 | 2B | F0 | 100.125 | <117><43><240> | <01110101><00101011><11110000> | | 3A | 4E | 00 | 100.130 | <58><78><0> | <00111010><01001110><00000000> | | 3B | 4E | 00 | 100.135 | <59><78><0> | <00111011><01001110><00000000> | | 3C | 4E | 00 | 100.140 | <60><78><0> | <00111100><01001110><00000000> | | 3D | 4E | 00 | 100.145 | <61><78><0> | <00111101><01001110><00000000> | | 3E | 4E | 00 | 100.150 | <62><78><0> | <00111110><01001110><00000000> | | 3F | 4E | 00 | 100.155 | <63><78><0> | <00111111><01001110><00000000> | | 40 | 4E | 00 | 100.160 | <64><78><0> | <01000000><01001110><00000000> | | 41 | 4E | 00 | 100.165 | <65><78><0> | <01000001><01001110><00000000> | | 7A | 2B | F0 | 100.170 | <122><43><240> | <01111010><00101011><11110000> | | 43 | 4E | 00 | 100.175 | <67><78><0> | <01000011><01001110><00000000> | | 44 | 4E | 00 | 100.180 | <68><78><0> | <01000100><01001110><00000000> | | 45 | 4E | 00 | 100.185 | <69><78><0> | <01000101><01001110><00000000> | | 46 | 4E | 00 | 100.190 | <70><78><0> | <01000110><01001110><00000000> | | 47 | 4E | 00 | 100.195 | <71><78><0> | <01000111><01001110><00000000> | | 48 | 4E | 00 | 100.200 | <72><78><0> | <01001000><01001110><00000000> | Thanks, John.

3 4

Python requirements.txt question
by Declan Rieb 06 Jun '24

06 Jun '24

I am still not much of a python wonk. BUT: having only now started using the venv package, I find that chirp/requirements.txt is insufficient to start development with. In a newly-defined virtual environment under python 3.12.3 (yes, I know that’s too far) wxpython will not load when using requirements.txt. I find that I MUST have pre-installed wheel and attrdict. Furthermore, pip is not finding wxpython at 4.2.0 for my MacOS system, so I’ve installed 4.2.1 (yes, I realize that you’ve restricted wxpython to 4.2.0 or less.) [I can get it to work by installing packages serially and by hand. But you DID define requirements.txt for us!] SO: I recommend prefixing the new packages wheel and attrdict, and changing the non-linux python to be >=4.2.0 I am not planning to submit this as a change, and it’s something that I consider too global a modification for my pay grade, and I surely don’t understand what ramifications of using wxpython > 4.2.0 could be! My new chirp/requirements.txt: wheel attrdict wxPython>=4.0,<4.2.0 ; platform_system=="Linux" # See https://github.com/wxWidgets/Phoenix/issues/2225 <https://github.com/wxWidgets/Phoenix/issues/2225> wxPython>=4.2.0 ; platform_system!="Linux" pyserial requests pywin32; platform_system=="Windows" suds yattag And, if one wants to run tox before trying t submit changes, you’ll need to install tox (but that’s not an absolute requirement.)

2 1

Supported radios on Wiki
by Alexandre Raymond 28 May '24

28 May '24

Hi everyone, I noticed what seems to be a duplicate in the list of supported radios, on the main page of the wiki: ---8<--- Rugged RH5R RH5R-V2* RH5X Rugged Radios RH5R, RH5R-V2 (use Baofeng UV-5R) --->8--- Is this on purpose? Alexandre

3 2