June 2023 - Developers - lists.chirpmyradio.com

Re: [chirp_devel] Read/Write SD-card? (Declan Rieb)
by Declan Rieb 21 Jun '23

21 Jun '23

Thanks. I’ve done the register, and CHIRP happily will try to write an mmap (since the file isn’t .img or .ftxd, it seems to look OK.) But I cannot convince the CHIRP to read the file. It looks as if it’s trying to decipher the filetype in order to determine the type of radio. I’ve tried enclitics like “sdc1”, “sdc2”, … for each radio but it doesn’t seem that the directory points to any driver. The error is ERROR: <function ChirpMain.open_file at 0x11c6efc40>: Unknown file format which looks as if it comes from chirp/directory.py L171

2 1

[chirp_devel] Read/Write SD-card?
by Declan Rieb 19 Jun '23

19 Jun '23

What’s the best way to convince a driver to read and write from an SD card, while not breaking the existing read/write to .img and radio-specific files? The SD card has a file (BACKUP.dat) that is essentially a binary image of the radio’s memory. It looks to me as if CHIRP can read and write such a file (e.g., FileBackedRadio() is not quite defined, and load_mmap() and save_mmap() look to do the right thing as long as the file enclitic is not .img) The driver already has one call to directory.register_format to introduce its radio-specific files. And the save dialog allows me to choose CHIRP .img or radio-specific formats. I’d like to add read/write from the raw memory image. What magic is needed to get CHIRP and wxui to handle my radio’s second method of data transfer, via SD card?? [There is a probable workaround: modify a copy of the SD card file: prepend the “correct” eight characters to the memory-image file, and ensure that there’s no MAGIC or glob at the end, and it should read as if it were a .img, no?] Thanks. ______ Declan Rieb WD5EQY wd5eqy(a)arrl.net

2 1

[chirp_devel] Reprise of UI problem... HELP, please?!?!
by Declan Rieb 12 Jun '23

12 Jun '23

HELP, please. I sent an earlier version of this message last week, but haven’t seen it in _devel list. I still am soliciting some pointers/help. I still work on the Yaesu FT1D radio, adding in multiple special memories and some digital settings and correcting a setting setup error that exists in the present FT-1D driver. However, I cannot understand what I’ve done to the driver to cause the following problem. I KNOW the problem is my fault, because CHIRP_next does the change correctly, while it behaves incorrectly as described below when CHIRP_next is loaded with my modified driver. As a non-Python-er, I’ve even tried to interact with the driver while running, but haven’t a clue where to look or what to modify to get the output that’ll point to the problem. [I include a debug file from that CHIRP_next test.] Bottom line request for help: How can I have affected the UI without having messed up my driver's structures? Or CHIRP’s mem structure either, AFAICT. Any guesses, please? This UI silliness occurs in spite of the driver passing all tox tests for it: tox shows no syntax errors in the pep8 section, and tox -e driver -- -k Yaesu_FT-1D_R Indicates that my changed driver passes all tests (well, 31 passed and two skipped.) When I load a bare FT1D file (presumably factory-fresh; actually a default file from Yaesu’s ADMS software for the FT-1D), the expected shows in the CHIRP UI: - Memory 1 (first slot, python index 0) has an entry of 145 MHz, FM - Eleven “Home" memories are defined as described in the manual. - The other 1100 memories show as empty [Although the files won’t show in the email summary, I attach two screenshots of that situation, both file labels showing “Bare FT1D”, but have removed them from this reprise.] AFTER attempting to change the second memory slot (python index 1) to show 146 MHz, I expected the UI to auto-populate the rest of the line similar to what showed on the first memory (FM…). BUT: - Memory 2 UI now shows a label with an asterisk (almost surely indicating a change to that line) with the 146 I typed still in the frequency location; the rest of the line is blank - Home3 (!) UI now shows the correct Memory 2 line, along with label “2”, as if it were memory 2 [Two more screenshots labeled with “after mem 1 change” are no longer included but available.] - Looking at the browser, memory index 1 and Home1, Home2 and Home 3 all show the correct register information. [Two more screenshots after the changed include “browser” in the filename are no longer included.]] - This type of problem occurs for every memory line up through 100, although it starts to populate the PMS specials memory lines. BUT: If I save the file, exit and restart CHIRP, everything is in the ‘correct’ place. That’s in keeping with the browser having shown the correct data in the correct place! Debug file, shows information from unmodified FT-1D module, and then the modified one after “load module”: I’ve made significant changes to get_memory and set_memory, to settings sections and to my data structures. (I’m pretty sure the changes as they stand will break the Yaesu FTM3200 driver.) A copy of my modified ft1d.py: ______ Declan Rieb WD5EQY wd5eqy(a)arrl.net <mailto:wd5eqy@arrl.net>

3 4

[chirp_devel] Yaesu FTxD drivers... what's next, please?
by Declan Rieb 08 Jun '23

08 Jun '23

Thanks, Dan for the pointers. You were pretty quick to add the test to help identify my problem. Yay! I’ve updated my copy of the CHIRP drivers for Yaesu FT-1, FT2 and FT3. They pass tox tests and seem to work fine. (Yes, yes: I’m probably missing something obvious.) In the chirp homepage Issues tab, I submitted new bug and feature requests to match what I’ve done (#10628, #10629, the old #6151) and what I hope to do (#7561 and #10630, which refers to #5167.) I refactored my changes into several Git commits, which allowed me to split up the changes into somewhat-manageable chunks. I’ve attached a truncated log (unix text file) of the Git changes. I even think that the Yaesu FTM3200D_R has not broken with the changes (although it may not pass tox driver tests.) I know that I’ve got to get these drivers to the GitHub somehow, sometime. Do I simply git push my branch up to Github? What’s the proper method? Will it keep note of my commits, or does it come as one big push, or must I push each one separately? PS. I’ve a few mechanical questions for future work: - Can banks be made to show connections to special memory registers? That might be an ideal way to handle Yaesu’s bank-accessible preset memories, which are not in any memory available to CHIRP. I believe the Yaesu single-digit line (1, 2, 3, 4, and 7) all use these presets. - The file reading/writing is pretty opaque to me. I’d like to add a new type of file (.dat and/or .img) that is pretty much a memory image with a pretended header. (Not replace the present ADMS format .ftXd files.) Is there a reasonable template for adding a filetype? Thanks. I’m hoping to at least get my changes into some tester hands for these radios. ______ Declan Rieb WD5EQY wd5eqy(a)arrl.net

2 1

Re: [chirp_devel] FT1D and UI... seems to be OK, now. A bit of help still desired.
by Declan Rieb 07 Jun '23

07 Jun '23

> On Jun 7, 2023, at 13:00, chirp_devel-request(a)intrepid.danplanet.com wrote: Thanks for the very prompt attention. I’m trying to add features to the ft2d.py (and ft3d.py) but they’re almost all handled in the ft1d.py, which radio has the same features (along with several other Yaesu radios.) And you’ve described a “feature” of my driver that I am vaguely aware of. In the radio, they are indeed in adjacent slots! So, I looks as if I’ve fixed it by making the number field negative for specials (as I’ve seen in others’ implementations. Doh!) Yay, so far. Tox was still happy with the new driver. (Unless you’re VERY fast, I’ve not done a git pull since this morning.) You pointed me in the right direction. It’s still a bit strange that it only shows up in the UI, but I understand that I confused it. I think it’ll be a wonderful idea to add a tax test to check for my (previous?!) bad implementation. > I haven't debugged your problem, but the reason for the UI disconnect is that you;'re returning an overlapping set of special memories with the regular ones. You need to map your special memories somewhere that does not overlap with the regular numbered memories (i.e. start right after the last regular memory). So when you edit memory 1, you'll notice that "Home2" actually changes waaay down at the bottom of the memory editor. During the initial load, you've returned a special memory with a number=1 and so chirp thinks that's where memory number 1 goes. > > I'll take a todo to write a test to cover this if we really don't already h one. Yes, I’ve made many changes, serially, and only locally. I’ll happily work on the big GitHub. I can also try to separate them, and build a branch on your real master onto GitHub. But: (A big but:) I’ve never used git in a collaborative environment, and am afraid of messing up the big github somehow. I’ve only entered one “issue” in your CHIRP documentation (#6151, asking to add digital settings) and some of my changes attend to that. There is a logic error that prevents CHIRP from initializing settings on a default Yaesu ADMS-x file; I’ve not entered a bug report for it, but it was an easy fix. Adding the specials was a labor of love, since the FT4 driver does it fine. I’ve noticed that #7561 exists, and since I’m aware that the .dat files are essentially the same as the .ftXd files (I think ten bytes’ difference in header) that I can try to fix that one too (that’d be a boon since these radios can save memory to an Scared, using the .dat file format, so folks could handle the radio without having to buy the [ahem: very expensive] Yaesu programming cable, bypassing a lot of headaches for you, I think!) I’ve not started on that. Yaesu has more than 100 preset frequencies for use only on receive (WX channels, maritime VHF, SW broadcast.) Several of their radios have these defined and can be accessed by the VFO AND be referenced in banks. (that’s the root cause of #5167, which is now closed; CHIRP ignores the problem.) I’d like to fix that to actually handle these channels; they’re not in programmable memory, and can really only be accessed via the bank system. Perhaps they can just be specials with really big negative indices (but they do not reside in memory and are all immutable) Is it still necessary to refer to issue numbers, especially in this age of CHIRP_next? I suppose I can add bug and feature requests to cover my efforts. So a little handholding will help me: What’s a PR? I presume that I should make a branch, put in one set of changes, then make another branch based on the first one to add another set of changes, then make another branch based on the second one to add another set of changes, continuing until everything is done. Then some how I communicate to you which change sets are available? Or does one make multiple branches each from the master, each of which changes a smallish set of things? How does one integrate the whole mess, especially with collisions likely? I also believe that FTM3200 radio, which inherits from the FT1D, should not be presently working. (the _mem_params arguments are in the wrong places to work right now. Should I worry about that at all? I tried to contact the driver folk listed in FTM3200.py via email, with no answer, but perhaps it’s not really used and so is moot? >> A copy of my modified ft1d.py:<ft1d.py> > > In the future, a draft github PR (or at least a diff) would be a lot easier to look at and pull down to try. However, you've got a ton of change in your .py file from current master, which makes it really hard to tell what all you've changed. Please do split that up into pieces before you submit, otherwise it'll be really difficult to review. > > --Dan

2 1

[chirp_devel] Is it ok to remove SETTING_LISTS from all drivers?
by Daniele Forsi 05 Jun '23

05 Jun '23

Hello, The flake8 tool detects duplicate keys in the SETTING_LISTS dictionary in some drivers, however those drivers don't use that dictionary and use the different values by checking the model of the radio. That dictionary doesn't seem to be used by any driver. The tests still pass after removing it. Is it ok to remove SETTING_LISTS from all drivers? This is the list of duplicate dictionary keys: ./chirp/drivers/retevis_rt21.py:562:5: F601 dictionary key 'cdcss' repeated with different values ./chirp/drivers/retevis_rt21.py:563:5: F601 dictionary key 'cdcss' repeated with different values ./chirp/drivers/retevis_rt21.py:578:5: F601 dictionary key 'voice' repeated with different values ./chirp/drivers/retevis_rt21.py:579:5: F601 dictionary key 'voice' repeated with different values ./chirp/drivers/retevis_rt21.py:580:5: F601 dictionary key 'voice' repeated with different values ./chirp/drivers/radtel_t18.py:195:5: F601 dictionary key 'sidekey2' repeated with different values ./chirp/drivers/radtel_t18.py:196:5: F601 dictionary key 'sidekey2' repeated with different values ./chirp/drivers/radtel_t18.py:197:5: F601 dictionary key 'sidekey2' repeated with different values ./chirp/drivers/radtel_t18.py:198:5: F601 dictionary key 'sidekey2' repeated with different values ./chirp/drivers/radtel_t18.py:200:5: F601 dictionary key 'sidekey2S' repeated with different values ./chirp/drivers/radtel_t18.py:201:5: F601 dictionary key 'sidekey2S' repeated with different values ./chirp/drivers/bf_t8.py:123:5: F601 dictionary key 'tot' repeated with different values ./chirp/drivers/bf_t8.py:124:5: F601 dictionary key 'tot' repeated with different values -- 73 de IU5HKX Daniele

1 0

[chirp_devel] bitwise struct syntax error
by Craig Jones 01 Jun '23

01 Jun '23

I'm trying to define a block of memory that contains 5 pairs of VFO scan limits (low-high ranges). The storage is the same for the regular 750 channel memories, even though the freq field is the only significant one for the VFO scan limits.. struct channel { bbcd freq[4]; bbcd offset[4]; u8 unknownA:4, tune_step:4; ... u8 unknown24:4, scramble:4; char name[7]; ul16 custtone; }; ... #seekto 0x2000; struct channel memory[750]; ... #seekto 0x7DC0; struct { channel low_limit; channel high_limit; } vfo_scan_limits[5]; This gets me: File "c:\proj\proj_chirp\chirp\chirp\bitwise_grammar.py", line 134, in parse return pypeg_parse(_language, FakeFileInput()) File "c:\proj\proj_chirp\chirp\chirp\pyPEG.py", line 388, in parse raise SyntaxError("syntax error in " + u(file) + ":" + File "<string>", line None SyntaxError: syntax error in input:116: channel low_limit; Is this just a bug in the grammar? Or, is my definition of five pairs too complicated for bitwise? Should I stick to an array of 10 scalars, and do the odd/even math in my code? Easy enough, but not nearly as elegant. #seekto 0x7DC0; struct channel vfo_scan_limits[10]; Thanks -- This email has been checked for viruses by AVG antivirus software. www.avg.com

2 2