- Developers - lists.chirpmyradio.com

[chirp_devel] Newbie to this, trouble with edits I think...
by wcurlew＠juno.com 28 Oct '23

28 Oct '23

I'm hacking up the FT450D driver to include support for the FT450 and FT450AT. At the same time I'm trying to improve the MODES to include the digital modes. I do NOT have Automatic Edits enabled. I've added a new column for the extended modes, and that is working fine. When I get a data mode (USER-U, USER-L, RTTY) I set the main MODE to DIG and update the value in the DATA MODES column. This is working great when I download from the radio or load up a saved image. The GUI seems to display everything OK. Some issues I am having are: On an existing memory, sa y a straight USB memory, If I change the MODE from USB to DIG, is if I change the MODE from anything to DIG, nothing happens, and the column still says USB. The debug log shows it is trying to set the right value, but something else is going on under the covers. No error messages in the log. Then, again on an existing memory, again USB, I change the DATA MODE from N/A to USER-U. Magically the MODE becomes DIG (who did that? Not me!) Now I can't put the mode back to USB, nor can I set the DATA MODE to N/A. I can change an existing , non-data mode to any other mode that has DATA MODE as N/A, but as soon as I try DIG, I am stuck. Can someone point me to this might be happening. This is the last major hurdle I need to get over. Thanks, Bill

2 1

[chirp_devel] Baofeng BF-5R = Baofeng BF-888 minus some features
by KC9MHE Eric Muehlstein 11 Oct '23

11 Oct '23

Hi all, Now I'm playing with a Baofeng BF-5R. I can successfully clone and write to the radio with the BF-888 driver but there isn't feature parity so I'm attempting a new class for the BF-5R. I was hoping that setting the following _has_ variables to False would make them disappear from the UI but they haven't. I have the opposite problem with my BF-C50 driver where I need to add a side-tone setting to the UI. Does anyone have any pointers for me? I feel like I'm pretty close on completing drivers for the BF-5R and BF-C50. Thanks! @directory.register class BF5R(H777Radio): VENDOR = "Baofeng" MODEL = "BF-5R" ALIASES = [] VALID_BANDS = (400000000, 470000000) _has_fm = False _has_sidekey = False _has_scanmodes = False _has_scramble = False POWER_LEVELS = [chirp_common.PowerLevel("Low", watts=3.00), chirp_common.PowerLevel("High", watts=5.00)] @classmethod def match_model(cls, filedata, filename): # This model is only ever matched via metadata return False

2 1

[chirp_devel] Radioddity PR-T3
by Saverio Proto 08 Oct '23

08 Oct '23

Hello Folks, I noticed I am not the only one with Radioddity PR-T3: https://chirp.danplanet.com/issues/10536 I wanted to give it a try to implement the support for this radio. I am following instructions here: https://chirp.danplanet.com/projects/chirp/wiki/DevelopersAdd_a_Radio and here: https://chirp.danplanet.com/projects/chirp/wiki/DevelopersUSB_Sniffing_in_L… I was able to capture the USB traffic, and I have pcap files of a read and a write with the original software for Windows from Radioddity. I can't find BAUD READ or WRITE strings in my captures. I share here my pcap files: https://www.dropbox.com/scl/fo/p2eb7bn3ig0cypkny20zq/h?rlkey=t8re5i0xil2jzt… Could please anyone confirm the captures are done correctly ? I am stuck at the moment, I need to understand what to do next. Thanks Saverio

2 1

[chirp_devel] Baofeng BF-C50 Work In Progress
by KC9MHE Eric Muehlstein 07 Oct '23

07 Oct '23

Hi All, I've been working on a driver for the Baofeng BF-C50 based on a T18 radio. I am able to upload/download from the radio, I have the settings memory map done, and I'm trying to tie up some loose ends. Maybe someone here can point me in the right direction... 1) I'm collecting a "side tone" from the settings; however, it's now clear how I add this to the radiosettings so that it's available in the UI. 2) I don't understand what the how the _frs and _grms settings work on T18Radio classes (do they validate that a frequency/width/power is appropriate for a band?). When I set them both to False I avoid problems with some memories being uneditable. 3) What is a jumpcode? I collect that on a per memory basis but I can't find any documentation on what it actually means/does. Attached, you'll find the partially complete driver file for reference. The driver as well as several reference images are available on github: https://github.com/emuehlstein/baofeng_bfc50 Regards, Eric KC9MHE

2 1

[chirp_devel] Old Newbie question
by Paul L. Schmidt 10 Sep '23

10 Sep '23

Chirp Development Gurus, I haven't done any formal software development/maintenance for years (I'm retired), and am only vaguely familiar with git (I can download code with it). Yeah, I'm from the dark ages of RCS, CVS, SVN, etc. I've got code to add the Retevis RT20 to the existing radtel_rt18.py driver. There's an existing (5 year old) request to add the RT20 in the system (#6067). I added to the existing request to indicate I've got working code, and uploaded a .diff file (yeah, nobody does that any more, but I didn't want the work to get lost...). Is there a brief tutorial on how to submit a proposed change with git? (Yeah, when I was working on my RT-21V, I sent the changes to Jim, KC9HI, who was kind/patient enough to add it... but I'd like to move into the 21st century and learn how to do it right.) 73, Paul, K9PS -- Yeah, I'm an old timer. That's not even a vanity call :-)

4 3

[chirp_devel] UV17 Pro GPS
by Matthew Carroll 23 Aug '23

23 Aug '23

Hi there, I saw that there's a request in for support for the newer Baofeng HT's already, including the UV17 Pro GPS. I was wondering if anyone has started working on integrating that into Chirp? If so, I'd be happy to help. If not, I might take a stab at it myself. I've not worked on the Chirp codebase before or trying to figure out the programming instructions for a radio, but I'm a developer, have some python experience, and a radio I'd like to use Chirp with! (I see the online guides for getting started with support for a new radio, this is just really asking if anyone's already working on it.) Thanks Matthew

3 3

[chirp_devel] Live mode questions
by Declan Rieb 09 Aug '23

09 Aug '23

I’m starting on the CHIRP-to-radio writing programming on a live radio model. CHIRP seems to call set_memory for every possible change to the screen display of a memory. Is there a way to defer writing until all changes have been made? With something like a “write the selected memory now” button, and using the “memory modified” flag that’s available in the live model. For that matter, can one request selective reads as well (as opposed to reading the whole radio). I’m under the impression that the radio manufacturer would prefer to have as few write cycles as possible. On another matter, is there a reasonable way to instantiate the data model that bitwise.parse can do in a live radio? I got really used to having symbolic access to bitfields in a clone-mode driver, and it might help with the live model as well. (Although NamedTuple and unpack()/pack() seem to be pretty easy to handle at the moment.) ______ Declan Rieb WD5EQY wd5eqy(a)arrl.net

2 1

[chirp_devel] New Driver Questions - New Dev
by Andy Knitt 04 Aug '23

04 Aug '23

I've put together a driver for the TYT TH-8600 that's working for both read/write for memories and basic settings (I haven't yet reversed the 2tone/5tone/dtmf signalling settings). This my first attempt at a driver and I have a few questions: 1. Should I have beta testers of my driver test from my fork prior to submitting a PR, or is there a better/preferred approach to this? 2. The manufacturer's software saves the memory map in a pretty easy to read .icf format. I've noticed that some drivers have a "File" class in addition to the Radio class (for example TYTTH7800File). Is this the mechanism to use to implement the ability for CHIRP to read the manufacturer's memory map files in, if desired? 3. I'm having some issues with tests and am not confident that my driver is actually being tested. This is my first experience with tox, so I'm fumbling a bit. 1. When I run py -3.10-64 -m tox all tests pass, though it takes a really long time to complete. However, I see no mention of my driver in any of the printed output. 2. When I run py -3.10-64 -m tox -e fast-driver all tests pass and it seems to recognize my file as a "touched driver". However, I still see no mention of my driver in any of the tests being run, though I do see mention of some Baofeng models that I haven't touched. Not sure what's going on there. 1. The H777 driver was causing the fast-driver test to fail due to some Chinese characters in the code comments. I had to remove those characters from the H777 driver to get it to run to completion. Not sure how the H777 driver passed. 3. When I run py -3.10-64 -m tox -e driver -- -k th8600 it fails but I'm struggling to understand why: ================================================= test session starts ================================================= platform win32 -- Python 3.10.7, pytest-7.1.3, pluggy-1.2.0 -- C:\chirp\.tox\driver\Scripts\python.EXE cachedir: .tox\driver\.pytest_cache metadata: {'Python': '3.10.7', 'Platform': 'Windows-10-10.0.22621-SP0', 'Packages': {'pytest': '7.1.3', 'pluggy': '1.2.0'}, 'Plugins': {'html': '3.2.0', 'metadata': '3.0.0', 'xdist': '3.3.1'}} rootdir: C:\chirp, configfile: tox.ini plugins: html-3.2.0, metadata-3.0.0, xdist-3.3.1 created: 8/8 workers 8 workers [0 items] scheduling tests via LoadScheduling ------------------------------ generated html file: file:///C:/chirp/driver_report.html ------------------------------- =============================================== 1056 warnings in 14.88s =============================================== driver: exit 5 (15.56 seconds) C:\chirp> pytest --disable-warnings --html=driver_report.html -v tests/test_drivers.py -n auto -k th8600 pid=50384 .pkg: _exit> python C:\Python_310_64\lib\site-packages\pyproject_api\_backend.py True setuptools.build_meta __legacy__ driver: FAIL code 5 (33.72=setup[18.16]+cmd[15.56] seconds) evaluation failed :( (34.16 seconds) Any advice is appreciated. Thanks, Andy

2 2

[chirp_devel] Developers' wiki page
by Declan Rieb 29 Jul '23

29 Jul '23

Dan, [These thoughts were written to augment the existing page at https://chirp.danplanet.com/projects/chirp/wiki/DevelopersAdd_a_Radio. They may be TMI for many of you experienced folks, but beginners might appreciate lessons-learned. And I’ve not written anything yet about how a Git noob can make your life miserable. Declan Rieb, WD5EQY(a)arrl.net <mailto:WD5EQY@arrl.net> ] Write get_memory(number: int | str) This is called to get your driver to populate the CHIRP memory model with the data for one radio memory. On startup, it’s called once for each memory register you’ve delimited for your radio and once for each special memory. Later it will be called as needed. - get_memory() returns a populated CHIRP memory object that the driver creates as a new instance of the chirp_common.Memory structure. You’ll want to become familiar with the fields in the Memory structure (presently specified in the source tree in the source file chirp/chirp_common.py). - The number of memories is specified in chirp_common.RadioFeatures.memory_bounds, which is a pair of numbers (first memory register number, last memory register number.) get_memory will be called with an integer parameter for regular memory with a value up to the last memory register number. - Special memories are radio-specific registers that can hold special meaning in the radio (such as scan limits, home registers, skip registers, etc.) They are specified in your driver as members of the list that you set at chirp_common.RadioFeatures.valid_special_chans. get_memory() will be called with a string containing the name of the special register, and you must set the Memory.number field of the resulting memory object to an index that is greater than the last memory register number and different than other special memories without holes in the sequence. Subsequent calls to get_memory() may receive either the index or the name. Do read the example driver at chirp/chirp/drivers/template.py. There is a commented stub version of this routine in chirp/chirp.common.py. Your driver is expected to overload it. Write set_memory(memory: chirp_common.Memory) This is called whenever CHIRP wants your driver to set the radio’s memory according to the fields described in the specific chirp_common.Memory parameter. The driver will presumably need to determine the specific radio memory based upon the value of memory.number (e.g. integer less than or greater than last memory number.) The driver should not change the memory structure. There is no special return to CHIRP required. Do read the example driver at chirp/chirp/drivers/template.py. There is a commented stub version of this routine in chirp/chirp.common.py. Your driver is expected to overload it. Radio memory settings that are not included in CHIRP chirp_common.Memory. CHIRP can (optionally) manage and display other settings for each memory. These are stored in a separate subject chirp_common.Memory.extra, and are handled during the get_memory and set_memory by calling _get_mem_extra(mem, _mem) and _set_mem_extra(mem, _mem), respectively. “mem” is the CHIRP memory structure, and “_mem” is the corresponding radio memory structure. You’ll get to write code to handle them similar to “RadioSettings.” Run tests Read the wiki page at https://chirp.danplanet.com/projects/chirp/wiki/DevelopersPython3Environment Tox is a separate application used to run tests for CHIRP. (I got it by “pip install tox” and it installed into my Python instance.) It will check syntax and stylistic features of the python source. It will also run many logic tests on all drivers that have changed in your tree since the last time it was run. Use: $ tox -e style You may then wish to run the driver test only on your driver. It appears that you can do so by executing $ tox -e driver -- -k Vendor_Model Or (to only test drivers with changes:) $ tox -e fast-driver When your new driver gets to the GitHub and a Pull request is made, the CHIRP folks will cause even more extensive tests to be run on it, so try to pass these tests first. Things not said elsewhere: Some of the following are hinted at in the example driver “chirp/chirp/drivers/template.py.” CHIRP has a “directory” structure of all the radios it should know about. Your driver will have one or more “(a)directory.xn--register-kq3d statement, wherein a class is defined for each radio you’re working on. They can inherit from each other (even other models and vendors) once the classes are read by CHIRP. The directory is sorted by text (vendor, model) pairs. That class will have definitions (and some redefinitions) for your radio. It will also implement a function get_features() -> chirp_common.RadioFeatures() You get to return basic information about your radio in the structure that CHIRP defines in chirp/chirp_common.py and you instantiate. Any existing driver should have one for you to copy and modify. CHIRP calls it fairly often when starting, so it’s expected to be lightweight. You probably don’t want this function to be querying the radio each time it’s called. Modes: CHIRP has a predefined set of “modes” available for each memory entry. Whatever your radio defines as modes, they MUST map into the CHIRP model. If the radio’s modes don’t fit into CHIRP’s model, you’ll get to add some translation into your driver. The current list (as of 2023-07-28 from chirp/chirp_common.py) is: MODES = ("WFM", "FM", "NFM", "AM", "NAM", "DV", "USB", "LSB", "CW", "RTTY", "DIG", "PKT", "NCW", "NCWR", "CWR", "P25", "Auto", "RTTYR", "FSK", "FSKR", "DMR", "DN") Live drivers A more-official description can be found at https://chirp.danplanet.com/projects/chirp/wiki/FAQ. Most radios seem to have a mode for which memory can be read or written as a large block, and their drivers reflect that. A few radios can only be accessed on what is effectively memory-by-memory reads/writes. These radios will almost surely need to be written as “live”. An example driver is at chirp/chirp/drivers/kenwood_live.py. Several other Kenwood drivers inherit from that one (at least ts480.py, tmd710.py, ts2000.py.) These drivers do not use the same radio-memory model as most of the others, but can keep a kind of cache. ______ Declan Rieb WD5EQY wd5eqy(a)arrl.net

2 1

[chirp_devel] Subject: Re: Elecraft KX3?
by Declan Rieb 28 Jul '23

28 Jul '23

> You could put the second VFO in the offset field and support only simplex and split for the duplex column. That's kinda how commercial radios (and copies of them) do it. But no, there's no other way and I think exposing it in mem.extra would be less than ideal. OK. I understand. Is there a way to expose the labels of the columns from the UI so that a driver could change “offset” to “VFOB” for example? I don’t much like the mem.extra idea, either. > Yes, get_features() is called all over the place and is assumed to be very lightweight. If you need to ask the radio stuff to generate the features, do it once and cache it. Ideally, you wouldn't talk to the radio at all during get_features() because it'll hang whatever part of the UI hits it first while you do. Thanks. That’s “a good thing” for driver authors to know. I’ve started a compendium of what I consider useful hints that I’ve encountered in working a driver that I wish I’d known earlier. It’s probably not ready for real publication, but I an email the rtf or text it to others if desired. > You don't get to just arbitrarily define modes as a driver. This is so that we have consistent importing between radios. I dunno what "AM-S/LSB" is supposed to be, but you'll need to coerce that into one of the standard modes. Optionally you could expose part of that through mem.extra potentially, but the better thing to do is just coerce it to something standard. CHIRP is an abstraction, which means we can't support absolutely every non-standard detail of every radio. OK. I understand that, too. That, is also a “a good thing” to know ahead of time. ______ Declan Rieb WD5EQY wd5eqy(a)arrl.net

2 1