November 2024 - Developers - lists.chirpmyradio.com

New driver and the memmap.MemoryMapBytes
by kg7hf1＠gmail.com 27 Nov '24

27 Nov '24

Hello all, TIA for any help you can give me below ;) Firstly, great software, really useful, Thanks! Secondly, I'm not an accomplished python programmer, but have spend a while doing embedded C on micro's. So most likely I'm going to ask a naive question. Third, I'm attempting to get a new driver for an ICOM M710, it's a commercial HF Marine SSB radio that has limited support, but there are a few of us still using them. That said, I've got part of the driver stood up, I can query it over the UART and get the memory dump. I've done a fair amount of sleuthing through the data and have a mild handle on the formatting of the data blob that comes out during download. I get a little less that 10,000 8 bit bytes from the rig, it's almost like a memory dump. Is the intent of MemoryMapBytes to hold an "image" of that dump, but provide some structure to the blob for easier access? It appears there are two channels per "record", there seems to be a record start marker with some channel information, 2x rx frequency, mode, name, and tx frequency then a checksum and end of record marker. I've setup my memory format like this: MEM_FORMAT = """ struct mem_struct{ char rx_freq[9]; char mode; char name[14]; char tx_freq[8]; }; seekto 0x0000; struct { char unknown_SOR[11]; struct mem_struct channels[2]; char checksum[2]; char unknown_EOR; }memory[2]; """ So, to detail my question a bit more. I have a byte array that holds the incoming image that might look something like this: annotated with comments #Channel 0 RX 12345.6 TX 27654.3 USB ABCDEFG FE FE EF EE E4 45 30 32 30 32 30 #?? start of record?? 31 32 33 34 35 36 30 30 30 #12345.6 30 #USB = 30, R3E = 31, AM = 32, LSB = 33, AFS = 34, FSK = 35, CW = 36 34 31 34 32 34 33 34 34 34 35 34 36 34 37 #ABCDEFG 32 37 36 35 34 33 30 30 #27654.3 #channel 1 RX 11111,1 TX 22222.2 31 31 31 31 31 31 30 30 30 #11111.1 30 #USB = 30 LSB = 33 34 38 34 39 34 41 34 42 34 43 34 44 34 45 #HIJKLMN 32 32 32 32 32 32 30 30 #22222.2 46 30 #?? this chaned when the mode changed checksum? FD #?? end of record ??? def do_download(radio): """This is your download function""" #this is working, but no reason to keep hammering the radio right now #todo uncomment this later #init_download = bytes([0xFE, 0xFE, 0xEE, 0xEF, 0xE2, 0x16, 0x32, 0x00, 0x01, 0xFD]) #send(radio, init_download) #ack = radio.pipe.read(10) #check the ack #todo read until FDFEFEEFEEE5FD is received. #data = bytes() #for _i in range(0, 9838): # data += radio.pipe.read(1) # this is just what part of what the incoming data looks like, this is record 1 memory_image = ( [0xFE,0xFE,0xEF,0xEE,0xE4,0x45,0x30,0x32,0x30,0x32,0x30,0x31,0x32,0x33,0x34,0x35, 0x36,0x30,0x30,0x30,0x30,0x34,0x31,0x34,0x32,0x34,0x33,0x34,0x34,0x34,0x35,0x34, 0x36,0x34,0x37,0x32,0x37,0x36,0x35,0x34,0x33,0x30,0x30,0x31,0x31,0x31,0x31,0x31, 0x31,0x30,0x30,0x30,0x30,0x34,0x38,0x34,0x39,0x34,0x41,0x34,0x42,0x34,0x43,0x34, 0x44,0x34,0x45,0x32,0x32,0x32,0x32,0x32,0x33,0x30,0x30,0x46,0x32,0xFD]) print(memory_image) data = b"" data = memory_image print(data) #return data return memmap.MemoryMapBytes(data) //////////////////////////// output ////////////////////////////// [254, 254, 239, 238, 228, 69, 48, 50, 48, 50, 48, 49, 50, 51, 52, 53, 54, 48, 48, 48, 48, 52, 49, 52, 50, 52, 51, 52, 52, 52, 53, 52, 54, 52, 55, 50, 55, 54, 53, 52, 51, 48, 48, 49, 49, 49, 49, 49, 49, 48, 48, 48, 48, 52, 56, 52, 57, 52, 65, 52, 66, 52, 67, 52, 68, 52, 69, 50, 50, 50, 50, 50, 51, 48, 48, 70, 50, 253] [254, 254, 239, 238, 228, 69, 48, 50, 48, 50, 48, 49, 50, 51, 52, 53, 54, 48, 48, 48, 48, 52, 49, 52, 50, 52, 51, 52, 52, 52, 53, 52, 54, 52, 55, 50, 55, 54, 53, 52, 51, 48, 48, 49, 49, 49, 49, 49, 49, 48, 48, 48, 48, 52, 56, 52, 57, 52, 65, 52, 66, 52, 67, 52, 68, 52, 69, 50, 50, 50, 50, 50, 51, 48, 48, 70, 50, 253] ERROR: Failed to clone: Traceback (most recent call last): File "G:\Projects\HamRadio\Repo\chirp\chirp\wxui\clone.py", line 93, in run self._fn() File "G:\Projects\HamRadio\Repo\chirp\chirp\drivers\icom_m710.py", line 202, in sync_in self._mmap = do_download(self) ^^^^^^^^^^^^^^^^^ File "G:\Projects\HamRadio\Repo\chirp\chirp\drivers\icom_m710.py", line 121, in do_download return memmap.MemoryMapBytes(data) ^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "G:\Projects\HamRadio\Repo\chirp\chirp\memmap.py", line 26, in __init__ assert isinstance(data, bytes) ^^^^^^^^^^^^^^^^^^^^^^^ AssertionError WARNING: Stopping clone thread

2 14

Bank-with-specials
by Declan Rieb 14 Nov '24

14 Nov '24

It works with the Yaesu presets, which fit just fine into the ft1d.py driver. Thank you for your help. It’s not quite ready for prime time; I do have a UI issue. In the Banks tab, regular memories are selected and stored correctly. These special memories are stored correctly, but they must be selected by pressing on the check-box on the second row UNDER the one I want. It seems to be consistent about that for all bankable specials. Add_memory_to_mapping seems to receive a memory number two too low. Re-selecting a checked box (to turn it off) doesn’t work for the specials; I’m still debugging. Remove_memory_from_mapping is getting called, usually with the correct. Remove_memory_from_mapping is getting an incorrect number, usually one from the end of the specials. I’m confident that I’ve not touched wxui/. Any suggestions? Maybe this is all moot, anyway. My immutable Yaesu preset specials show up in the memory list, and I can copy them out into regular memories, which folks can select in the bank as normal. Is there any way to convince python to ignore a multiple-inheritance class like SpecialBankModelInterface if it doesn’t exist (such as in the present mainline.) The code would work in the way just mentioned, and the little bit of extra coding would never get called. ______ Declan Rieb WD5EQY wd5eqy(a)arrl.net

2 1

Tox test for immutable specials
by Declan Rieb 14 Nov '24

14 Nov '24

The following test, invoked by tox, fails: self = <tests.TestCaseEdges_Yaesu_FT-1D_R testMethod=test_get_set_specials> … self = <Memory WX1(1111): freq=162550000,name='WX1PA7',vfo=0,rtone=67.0,ctone=67.0,dtcs=23,rx_dtcs=23,tmode='',cross_mode='To...p=5.0,comment='',empty=False,immutable=['extd_number', 'name', 'freq', 'mode', 'duplex', 'offset', 'comment', 'empty']> name = 'freq', val = 162555000 def __setattr__(self, name, val): if not hasattr(self, name): raise ValueError("No such attribute `%s'" % name) if name in self.immutable: > raise ImmutableValueError("Field %s is not " % name + "mutable on this memory”) E chirp.chirp_common.ImmutableValueError: Field freq is not mutable on this memory Will always fail for specials that have immutable freq field (and perhaps other immutable fields too) when the test tries a SET on that special. Perhaps that can become an XFail ???? Or even a Skip (for the Setting portion of the test) if immutable is already set for specials.?

2 1

Copy To Clipboard Error
by Joseph Scanlan 14 Nov '24

14 Nov '24

I’m (still) working on support for the Icom IC-F521/F621. Now I have a traceback that has me stumped. I get the error when I try to copy a memory to the clipboard. I’m running Chirp on Ubuntu 24.04.1 LTS (noble). Traceback (most recent call last): File "/home/joseph/Devl/chirp/chirp/wxui/memedit.py", line 1716, in <lambda> self.Bind(wx.EVT_MENU, lambda e: self.cb_copy(cut=False), copy_item) ^^^^^^^^^^^^^^^^^^^^^^^ File "/home/joseph/Devl/chirp/chirp/wxui/memedit.py", line 1953, in cb_copy self.cb_copy_data(self.cb_copy_getdata(cut=cut)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/joseph/Devl/chirp/chirp/wxui/memedit.py", line 1936, in cb_copy_getdata memdata.SetData(pickle.dumps(payload)) ^^^^^^^^^^^^^^^^^^^^^ AttributeError: Can't pickle local object 'Processor.do_bitfield.<locals>.bitDE' What might I have done (or failed to do) in my driver that has memedit so upset? I did look through memedit.py and read about the pickle module (even played with making variables global) but no flash of enlightenment. Second question. Which Icom drivers make good examples? I’m using ic2820.py only because I have an IC-2820 radio. — Joseph(a)n7xsd.us — n7xsd(a)yahoo.net — +1-702-896-0507

2 2

Tox "exit 5"
by Declan Rieb 13 Nov '24

13 Nov '24

For new elecraft driver… I can read and display radio memories. Can’t set ‘em yet. BUT: I’ve started tox running successfully, and it starts up workers and generating an html report. It describes >1000 warnings, and then gives an exit 5. The html contains preface but no results. I’ve NO idea what is causing it to die. Is there a timeout (it takes 10s of seconds to read the memories)? Error is ... 8 workers [0 items] scheduling tests via LoadScheduling --- Generated html report: file:///Users/declan/darchirp/driver_report.html ---- =========================== 1139 warnings in 16.93s ============================ driver: exit 5 (17.43 seconds) /Users/declan/darchirp> pytest --disable-warnings --html=driver_report.html -v tests/test_drivers.py -n auto -k Yaesu_Elecraft_KX3 pid=77757 .pkg: _exit> python /usr/local/lib/python3.11/site-packages/pyproject_api/_backend.py True setuptools.build_meta __legacy__ driver: FAIL code 5 (28.39=setup[10.96]+cmd[17.43] seconds) evaluation failed :( (28.55 seconds)

3 3

ProgressDialog
by Declan Rieb 11 Nov '24

11 Nov '24

Is there any (acceptable) way to cause a wx.ProgressDialog to be started and updated from a user driver? If not, is there an acceptable way to call and manage the wuxi/common implementation? ______ Declan Rieb WD5EQY wd5eqy(a)arrl.net

2 1

ProgressDialog, cont
by Declan Rieb 11 Nov '24

11 Nov '24

I presume of course that if there’s no wx panel, I should not try to do a wx.ProgressDialog. How (if) can one tell if there’s a window to scribble on? Thanks ______ Declan Rieb WD5EQY wd5eqy(a)arrl.net

1 0

Yaesu presets, again.
by Declan Rieb 03 Nov '24

03 Nov '24

I remember why I didn’t like treating Yaesu presets as SPECIALS… SPECIALS do not show up in my Banks tab. Is there a setting somewhere that can force them to be listed in Banks? Is ‘my' driver (ft1d.py) not doing something right in banks? I definitely have not studied the BANK_MODEL at all, so I’ve no clue where to start. Furthermore, is there a convenient way to keep the Banks tab from showing all memories (the list is 1000+ long even if all-but-one memories is empty, and only then do the SPECIALS show.) It’d be nice to have empty memories blank the corresponding Banks line, UNLESS that Banks line has bank selections. ______ Declan Rieb WD5EQY wd5eqy(a)arrl.net

2 5

Updating TD-H3 for more recent variants
by Michael K Johnson 03 Nov '24

03 Nov '24

Hi! I'm new to ham radio in general and chirp in particular, so please bear with me. I have a new TD-H3 that allows me to enable 1.25m TX. I tried to chirp it to set up some local 1.25m repeaters, but could not because of the _txbands limitation. (It also allows setting TX on some bands that aren't ham bands in the US.) I would like to chirp those 1.25m repeaters into the unit, which would require me to update chirp. It seems obvious to this naive newcomer that the approach is to dump images modifying each of the settings not currently present to reverse them, and add them to the MEM_FORMAT, then add them to settings handling, after which I should be able to update _txbands to include frequency ranges that have been enabled on the particular HT being chirped, including setting those TX modes in settings. However, I'm confused about how to deal with at least two things. 1. While the menu on the HT has setting 42. Version "AM_240316 I don't see anything like that in the image I downloaded, so it's not clear to me whether I can make the new settings conditional on some new-enough firmware version. 2. There's only one MEM_FORMAT for the radios supported in tdh8.py and I have no idea whether the formats have diverged between radios because I have only a TD-H3 to play with. I'm aware that I don't know what I don't know and haven't tried modifying anything yet.

2 16

Please tell me more about VARIANTs?
by Declan Rieb 02 Nov '24

02 Nov '24

I’m still mulling over how to get the Yaesu-defined preset (broadcast) memory addresses into the Yaesu drivers. These are NOT amateur frequencies, but some of general listening interest such as weather, VHF marine and HF AM broadcasts, especially good for radios that can receive more than the amateur bands. These presets are NOT mutable, or in the accessible memory image, and can only be accessed by front panel or referenced in the memory banks (they can be referred to in a bank, along with “regular” memories. The presets have one of three high bits set in the memory number.) In fact, a Yaesu radio user has included a weather station in one of his banks which caused a problem when CHIRP read the radio. The drivers have a workaround of sorts for now. AFAICT, the Yaesu documentation shows the same set of presets for multiple radios. I’ve now found the sub_devices settings, and see several drivers that use them. Since the sub_devices seem to display a Memory and Banks tab for each variant, they’d essentially be perfect: there could be a “normal” variant that works the way it does presently, and a “presets” variant that only displays the data for the Yaesu-defined preset addresses. Since the driver is implementing the banks model, it should be able to handle both cases easily, and the preset memories could be marked as immutable. To start an implementation, it appears that one needs to: 0) NOT change the VARIANT definition. I thought VARIANT was being used to denote versions of the radio type (e.g. FT-1DR vs FT-1DE) rather than sub-devices. Thus most of the Yaesu drivers I’ve worked on have been overriding the value to one specific to Yaesu. Bzzzzt! wrong! 1) set the radio feature has_sub_devices= True 2) add a new class for each sub_device. E.g. add to my Radio class @directory.register class Radio(chirp.common.CloneModeRadio): class Radio_subA(Radio): VARIANT = ’Sub A' class Radio_subB(Radio): VARIANT = ’Sub B' 3) The VARIANT is pre-defined in chirp_common.py as a null string ‘’. Each sub will redefine it as a new string, which will be appended in parentheses to the Memory and Banks tabs. 4) Each sub-device can have new methods to replace (or augment) the previously-defined methods. It appears that one of the methods that’s required is a new get_features() that turns off the “has_sub_devices”. Is this required? 5) Add a method to the driver’s registered class def get_sub_devices(self):0 if not VARIANT: return [Radio_subA(self._mmap), Radio_subB(self._mmap)] else: return [] This effectively has CHIRP “call” each sub-class into use, and returns a null list when called inside each sub_class. My big question: why is each sub-class “called” with self._mmap as a “parameter”? How IS the “parameter” to be used in the sub-class? I would have thought that parameter should just be self, the way it's used throughout the Radio class. Furthermore, several existing drivers send other objects through this “parameter” … what gives? I realize that for the ft1d driver (which is inherited for several other radios) this will be too simple. But, for a template.py “radio", a minimal implementation with only two entries in the B sub-radio now looks like the following, and “works” as expected*: @directory.register class TemplateRadio(chirp.common.CloneModeRadio): . . . def get_sub_devices(self): if not VARIANT: return [Radio_subA(self._mmap), Radio_subB(self._mmap)] else: return [] class Radio_subA(Radio): VARIANT = ’Sub A’ def get_features(self): rf = TemplateRadio.get_features(self) # ensure the top class features are set rf.has_sub_devices = False return rf class Radio_subB(Radio): VARIANT = ’Sub B' def get_features(self): rf = TemplateRadio.get_features(self) rf.has_sub_devices = False rf.memory_bounds = [0, 2] return rf. These are derived from observations of other drivers. Here’s a summary of questions: - Does the features sub_devices have to be changed to false? I figure I should call the immediate parent get_features() rather than the one from the ft1d, so super should be involved, right? - What SHOULD the passed parameter be? I’m pretty sure a null parameter doesn’t work. - If I wanted to implement this in ft1d.py for all radios that subclass from it, what considerations should I make in coding? - Would it make sense to try to fit this into YaesuCloneModeRadio? Or would it make sense as a hypothetical adjunct to that class such as a new class YaesuPresetsRadio, so that a radio could inherit from both classes to get this functionality (I presume the second sub-radio would ONLY define handle the presets, which would be common to several Yaesu radios, and be defined in the new class.) * Template.py does need to be changed to allow this: the directory line uncommented, and it also needs from chirp import directory . ______ Declan Rieb WD5EQY wd5eqy(a)arrl.net

2 2