August 2024 - Developers - lists.chirpmyradio.com

New file format
by Declan Rieb 23 Aug '24

23 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 23 Aug '24

23 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 21 Aug '24

21 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