- Developers - lists.chirpmyradio.com

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

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

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 08 Jun '24

08 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