February 2024 - Developers - lists.chirpmyradio.com

[chirp_devel] Introduction
by Eric Poole 13 Mar '24

13 Mar '24

Good morning all, from a new CHIRP user and new member of the developer's reflector. (Incidentally, is it CHIRP or Chirp or chirp? I've seen all three used. What is the proper way to refer to the product?) I've joined the developer's reflector because I would like to contribute to CHIRP by writing drivers for the Icom IC-746PRO and IC-706MKIIG. I'm a retired software developer with 40+ years experience, mostly in C with some assembly language and C++. I have almost no experience with Python, have just done some minor modifications on existing programs. I do understand object-oriented design and programming. I have only limited experience with Git, having used it on only two projects, mostly used Subversion on past projects. I'm wondering if any of you have any recommendations for a good tutorial, available on the net, for someone like me who wants to learn enough Python to be effective in writing drivers for CHIRP. I know there are many such tutorials out there and wanted to find out if you have any recommendations for one over the others. I'd appreciate any suggestions, and meanwhile I'll be around the reflector as I go about figuring out how to do this correctly. Thanks... Rick WA1RKT Londonderry, NH Catch me on 14.300 MHz Intercon / MMSN most days See my QRZ page

2 5

[chirp_devel] Baofeng/5RM Power-On Image
by Henry Grasman 26 Feb '24

26 Feb '24

Hi, I'm toying with the idea of adding the ability to upload custom power-on images to the 5RM (and presumably all the other similar devices). I've started picking at Baofeng's software to see how it works, and I'd like some help before I commit to anything: -1) Should I bother/ has someone tried this already? 0) These are "clone mode" radios, and I don't see a change in memory after changing welcome screens with BF's sw. Would that be CHIRP ignoring/not reading the relevant memory section? Or is there precedent for baofengs to have settings that are not part of the normal clone? Probably for Dan: 1) Would it be accepted for CHIRP to have this feature? Is it absent for some reason, or simply because nobody has implemented it? If I were to be the first to implement this, how would you like to architect it into the SW? Part of the driver? New functions for UI? 2) I have reverse engineered the encoding and some header info for the image write. Where should I look for details on the existing reverse engineered protocols for this device? I am hoping my answer to question 0 is "chirp is probably just not touching the memory we care about" and I only have to make minor changes, but this info will help in any case. 3) Does anyone have other radios that have similar features to consider while designing how this will work? I have plenty to keep me busy between work and life, so I appreciate any advice and help that might make this easier. Thank you, Henry Grasman K2KNO

2 2

[chirp_devel] TH-UV88 Optional signaling implementation Feature #1110
by Cyril Velter 10 Feb '24

10 Feb '24

Hello, I just commited optional signaling in my chirp repo : https://github.com/velter/chirp/tree/th_uv88-optsignaling Some things might still be polished (dynamicly show/hide/clear encode/decode settings based on chanel activation for example). But everything is functional and all tests are passing. This branch contain an updated image file for TYT-UV88 with more complete parameters coverage Before I make a pull request, it would be nice to have some feedback : - Currently the code is activated for TYT UV-88 but also for Retevis RA89 and QRZ-1. It seems from the docs that RA89 support optional signal but I'm not sure for QRZ-1. Test images for both models contains correct datas but from the docs it seems QRZ-1 does not support optional signaling. Can someone with access to these radio can test and tel me ? - While I do software development for more than20 years I'm pretty new to python. Some coding might probably be improved - More tests will be welcomed When this change will be commited I propose to also work on : - Handling the vfo settings ("VFo Ch" tab from the original software) - Handling the Frequence range settings ("Frequency Range" tab from the original software - Reorganize Basic/Advanced/Work mode settings in the UI (for exemple the 3 VOX settings are scattered around in 3 different place from 2 differents tabs. I would propose to group the settings in 3 categories UI, Radio and Work mode - Other small fixes (scramble value 8 not handled properly) cyril

2 3

[chirp_devel] TH UV88
by Cyril Velter 07 Feb '24

07 Feb '24

Hello, My name is cyril it's my first post to this list. I'm working on improving the th_uv88 driver to fix small issues and adding support for optional signaling (dtmf, 2tones ans 5 tones). I've two questions : 1) I have submited a first Pull Request which have now been merged in the main repo but I'm having trouble to submit a second one as github try include all the previous commit since I do the fork. I'm certainly doing something wrong (I'm not used to git) can someone point me in the right direction ? 2) Implementing optional signaling, i already have all the values in the memory tree. Now I'm working on the UI in the settings tab. I need to display some list of tuples (for exemple dtmf code/type/name). Is there a way to display an array instead of just a list of name/value pairs in the right panel of the settings tree ? I have not found any driver doing this. thanks, cyril

4 4

[chirp_devel] Issues in bitwise.py
by Daniele Forsi 07 Feb '24

07 Feb '24

Hello, the driver kyd_IP620.py has a channel memory structure of 16 bytes but printing it shows a length of 15 bytes. I get this output: struct { memory: struct { rx_freq: 4:[(0)] tx_freq: 4:[(0)] rx_tone: 0x0000 tx_tone: 0x0000 unknown_1: 0x00 (....0000b) busy_loc: 0x00 (......00b) n_a: 0x00 (......00b) unknown_2: 0x00 (.......0b) scan_add: 0x00 (.......0b) w_n: 0x00 (.......0b) lout: 0x00 (.......0b) n_a_: 0x00 (.......0b) power: 0x00 (......00b) unknown_3: 0x00 unknown_4: 0x00 } memory (15 bytes at 0x0000) } (anonymous) (15 bytes at 0x0000) using the following script === from chirp import bitwise defn =""" struct { // Channel memory structure lbcd rx_freq[4]; // RX frequency lbcd tx_freq[4]; // TX frequency ul16 rx_tone; // RX tone ul16 tx_tone; // TX tone u8 unknown_1:4, // n-a busy_loc:2, // NO-00, Crrier wave-01, SM-10 n_a:2; // n-a u8 unknown_2:1, // n-a scan_add:1, // Scan add n_a:1, // n-a w_n:1, // Narrow-0 Wide-1 lout:1, // LOCKOUT OFF-0 ON-1 n_a_:1, // n-a power:2; // Power low-00 middle-01 high-10 u8 unknown_3; // n-a u8 unknown_4; // n-a } memory[1]; """ data = bytearray(b"\x00" * 16) tree = bitwise.parse(defn, data) print(tree) === I do not own such a radio but the same issue could be present in other drivers. I think that the reason is that n_a is used twice, so I reduced the definition to this defn =""" struct { u8 n_a:2; u8 n_a:1; } memory[1]; """ but this throws a RecursionError exception at .../chirp/bitwise.py", line 878, in do_bitfield LOG.warn("WARNING: %i trailing bits unaccounted for in %s" % I would submit a pull request but I don't know how to handle the following issues in bitwise.py: * line 878 doesn't correctly handle the name that it needs to print, but I don't know how to fix it * the __repr__ of class structDataElement and possibly 4 other lines of code shouldn't use the integer division self.size() // 8 or the size should be automatically padded to the next multiple of 8 with a dummy member? * should there be a warning for reused names of struct members or an exception? thanks -- 73 de IU5HKX Daniele

2 2