- Developers - lists.chirpmyradio.com

[chirp_devel] Yaesu question: Digital mode
by Declan Rieb 14 Jan '23

14 Jan '23

Thanks for finding and putting in the “DN” mode. Interestingly, on the FT-2D, the “automatic” mode is displayed as DN or FM with a line over the characters, meaning that the radio will default to trying the letter-configured mode but will automagically convert itself to the opposite one if appropriate. (It doesn’t always revert back to that automatic mode after changing itself, AFAICT.) The Yaesu FT-1 and successors are able to handle YSF and Wires-X digital data in the DN or bar-above-FM mode. I have mapped much of the memory space for configuring these (sub?) modes, and even tried to create a settings capability via the old TK GUI interface. Although I doubt there is a burning need for this, wouldn’t it be nice to be able to at least access the settings? Is there any walkthrough to help one use drive the CHIRP data model and GUI to display and configure top-level as well as hierarchical settings? Clearly, Somebody already has done that for the APRS data. and I tried using that as a model, but there’s no easy hierarchy in there. If it looks to be not-useless to others, I may submit a ticket for this and a proposed but incomplete solution. ______ Declan Rieb WD5EQY wd5eqy(a)arrl.net

2 1

[chirp_devel] Yaesu question: fixed memory
by Declan Rieb 14 Jan '23

14 Jan '23

Many Yaesu models (FT-1, FT2, FT-3, and probably others) have some fixed memory data (frequencies for SW broadcast, Weather, Marine and GMRS/FRS) pre-installed. In the FT-1 and above, these fixed memories are accessed via flags in the memory module (one flag bit per type of location). That makes the memory locations appear much bigger than the ‘real' channel memory; ‘real’ channels are at the moment accessed by stripping off the flag bits, and not saving any such data in the CHIRP model. This has caused at least one error request to be submitted and fixed when a Yaesu FT-2D user entered a WX channel into his radio by hand and tried to use CHIRP to help modify and save his memories; CHIRP died until I did the masking and prevented CHIRP from reading or saving such a memory. BUT I’d like to find an adjunct to the CHIRP model so that the fixed memories can be accessed. Are “immutable” memories an appropriate mechanism? I have no idea where the fixed memories are stored in the actual radio. I presume that one would build several tables of “immutable” memories that can be pre-defined and accesssed. The fixed memory definitions are listed in the Yaesu manuals, and seem to be identical between models. Is there an easily-accessible memory model that would allow this to “just work”??? Please and thank-you. ______ Declan Rieb WD5EQY wd5eqy(a)arrl.net

2 1

Re: [chirp_devel] Mode designator for YSF?
by Mathias Weyland 11 Jan '23

11 Jan '23

On 2023-01-11 02:17, Dan Smith via chirp_devel wrote: > Wow, yeah. It sounds to me from the above (correct me if I'm wrong) > that maybe DN encompasses two things, sort of layer 1 and layer (or > 7). Layer 1 being the lowest protocol and Layer 7 being some of the > voice/data/codec stuff , and that VW mode would reuse a lot of layer 1 > but swap out more of the Layer 7 stuff than just "twice as many voice > packets" (so to speak). Maybe? I'm not sure if it helps if I lay this out but we can try... So basically every single digital Fusion transmission has the following structure; each frame is 0.1 s and 960 bits: Header Frame, Frame, Frame, Frame, ..., Frame, Termination Frame All frames have the same structure, which is as follows: frame sync (40) -- frame information (200) -- payload (720). For DN, the payload of 720 bits comes in two variants. Variante (I) consists of 10 sub-frames with 72 bits each. Except for the header and termination frame, the payload sub-frames are voice data and metadata sent in an alternating fashion. The voice data sub-frames are produced by algorithm "A" and the metadata sub-frames are produced by algorithm "X". Alternatively, (II) the payload consists of 5 digital voice sub-frames of 104 bits and 5 metadata sub-frames of 40 bits, again arranged in alternating fashion. The voice sub-frames are produced by algorithm "B" (this is not documented by Yaesu and is the part that I reverse engineered) and the metadata sub-frames are produced by algorithm "Y". "X" and "Y" are very similar and which of the two variants is used depends on the amount of metadata that is to be sent. For VW, the first non-header frame is special and contains metadata produced according to algorithm "Z" wich is similar to "X" and "Y". The remaining regular frames have a payload that consists of five voice sub-frames of 144 bits each, back to back. They are produced by algorithm "C". "A" and the algorithm used in DMR to create digital voice frames are the same. Algorithms "A" and "B" are moderately similar (we can discuss the details but there's probably no point in doing that here...). "C" is very different from "A" and "B", yet still based on the MBE speech model like all the other ones... Is that somehow compatible with your layer concept? In my world, the layers would be as follows: 0: Physics 1: Modulation scheme 2: Structure of frames 3: Structure of payload into sub-frames 4: "Algorithms" > Well, I'm not planning to actually expose these as columns in the main > editor, but options in the RightClick->Properties dialog, like D-STAR > stuff is now. I see. What bothers me the most about this approach (and I guess that is more important than the technobabble from above): At least around here, some repeaters are multimode analog & digital and some others are digital only. With the solution you propose, I would want to set the multimode ones to DN with the default AMS and the digital only ones to DN with no AMS. I would definitely not want to leave AMS on for the latter ones, as that would leave me with random analog squelch openings when I hit QRM, or it would require met to set up some kind of mock-TSQL to avoid that. But what I should do instead is turn AMS off. And entering a context menu and property dialog to do that would annoy me quite a bit in particular if I would not see the current setting in the main editor. Regards Matt

2 1

[chirp_devel] Mode designator for YSF?
by Dan Smith 10 Jan '23

10 Jan '23

Hi all, I'm not a Yaesu guy and thus not very YSF-literate. It looks to me like the YSF radios call their digital mode "DN" when enabled (as opposed to "FM"), like D-STAR has DV. Is that right and does it make sense to use that in chirp's mode list for editing these channels? I had originally thought "YSF" like "DMR" would make sense, but now I'm not sure after looking at a radio. Yaesu's documentation doesn't seem to be super clear on this. It also seems like maybe the convention is to actually set the radio to Auto mode because of the dual FM/digital nature of YSF repeaters, is that right? If we add support for this, does that mean "Auto" is really what we should be setting in most cases? There's also a "VW" mode, but it seems to be sort of an additional flag, more so than just a mode. So does it make sense to set a channel to FM/DN (or Auto) and then have VW be a separate flag via extra/properties? If there's someone that is YSF-literate that might be able to test some stuff in the coming week or so, speak up :) --Dan

3 5

[chirp_devel] NoneType object has no attribute 'Enable'
by Tony Fuller 06 Jan '23

06 Jan '23

Hey Dan, I thought you might be able to debug this faster than I can but the tip of master does not run from source. wxui/main.py line 850 throws a `NoneType object has no attribute 'Enable'` error. The line before that is assigning `None` to `menuitem` so something with `ident=101` is not being found. Is anyone else seeing this? Tony

2 1

[chirp_devel] Here we go...
by Dan Smith 03 Jan '23

03 Jan '23

Just a heads up, the master branch is now python3 (what was the py3 branch), the legacy branch is now python2 (what was the master branch). I'll be reconfiguring the build system for the -next builds to use master going forward. No turning back now. I'm also planning to rebase this on master and apply soon: https://github.com/kk7ds/chirp/pull/310 Dropping more py2 tox targets, gtk, etc stuff from -next. I need to do that at least a couple days before I announce to users so we can make sure that doesn't break any build stuff (although I think it's okay). --Dan

5 22

[chirp_devel] IC-2730A Strange Behavior
by Rick (AA0RD) DeWitt 26 Dec '22

26 Dec '22

Here's a weird one- My IC-2730 (with icf.py IcomCloneModeRadio) Py3 driver fails uploading AFTER any previous radio I/O. I've got all the bytes/ord/chr stuff working fine. IC-2730 has new booleans: _raw_frames= true, _highbit_flip=true, Munch_clone_resp=true (works if false, too) The radio downloads fine, repeated access, even after good or bad upload. The first upload after CHIRP Open > Load File or Radio > Reload Driver works fine. Upload after download, or upload after first upload fails. The failure is in get_model_data (the first radio I/O); the radio echoes the send model command byte by byte, but does not send the data frame. I have sniffed the USB bus and can see that the outbound packets are identical for both a good and bad upload. Any ideas? Remember: good downloads, good initial upload after driver load/reload; so commands, frames and decodings are OK. --

3 3

[chirp_devel] Does the py3 version generate a log file?
by Ran Katz 23 Dec '22

23 Dec '22

If so where can I find it? (on a Mac) Thanks!

3 5

[chirp_devel] Call for help
by Dan Smith 19 Dec '22

19 Dec '22

Hi all, In case you haven't been seeing the activity lately, much progress is being made on the py3 branch in github: https://github.com/kk7ds/chirp/commits/py3 Thanks to a lot of help from @sv1 and @KC9HI, all of the drivers are now at least syntax-compatible with python3, running automated tests, and progress is being made to test (with real hardware) as many as possible to iron out remaining incompatibilities: https://github.com/kk7ds/chirp/blob/py3/tests/Python3_Driver_Testing.md As of today, about 38% have been tested, so we've got some work to do. I think it's unrealistic to get all of them tested in the short term, but we should at least shoot for the major brands and popular models as much as possible. So, the first call for help item is: 1. If you have a radio in that list not marked as tested, please test and record it in tests/py3_driver_testers.txt with a PR At the end of this email is a list of radios we have leads on for testing. Feel free to claim one of those, but the real prizes are the major models not on that list. Next up is UI parity. I've been doing a lot of work on the wx UI lately and I'm pretty happy with it, so much that I've been using it exclusively for my personal programming for a while now. There are still some gaps missing that I need to take care of, and my current todo list is wrapped up here: https://chirp.danplanet.com/versions/21 There are some things I'm not planning to pull into the new UI at all, and some things that can come later. So, the second call for help item is: 2. Please test the new UI, help brainstorm what needs to be implemented (or fixed) before we start looking for more regular users to start using it I've got one-off test builds here: https://trac.chirp.danplanet.com/chirp_next/ and will continue to generate those regularly until we get to the point of doing them automatically. The new macos build is much better than it has ever been, IMHO. It feels very native and will have universal2 intel/arm support the next time I roll it. Testing the bundled builds is important for sure, but getting a development environment running is also easier. You pretty much just need a recent python3 (3.10 recommended) and: $ pip install -r requirements.txt ...should get you there. Please file issues for things you find, and select "chirp-py3" for "target version" and "chirp version" to help keep track of bugs only in the py3 version. I've been keeping the py3 branch in sync with changes to master for several months and even though it's doable, it's majorly not fun. I think the light is visible at the end of the tunnel at this point, so I'd really like to make 2023 the year we freeze work on the current py2 branch and get people moving to the new stuff. I'd like to be able to start getting "power users" testing the new builds early next year, which hopefully will help fill out the model testing edges. Thoughts on the plan? If you've got a radio on the list that needs testing, please speak up here so we at least know which ones are potentially testable. Thanks! --Dan List of drivers for which there is known likely tester already: Abbree_AR-518 iradio_uv_5118.py AnyTone_OBLTR-8R anytone_ht.py AnyTone_TERMN-8R anytone_ht.py BTECH_GMRS-V1 gmrsvu1.py BTECH_GMRS-V2 gmrsv2.py BTECH_MURS-V1 mursv1.py BTECH_UV-50X3 vgc.py BTECH_UV-5X3 uv5x3.py Baofeng_BF-T1 bf-t1.py Baofeng_UV-6R uv6r.py Explorer_QRZ-1 th_uv88.py LUITON_LT-316 retevis_rt22.py LUITON_LT-580_UHF th9000.py LUITON_LT-580_VHF th9000.py LUITON_LT-725UV lt725UV.py MTC_UV-5R-3 uv5x3.py Radioddity_GA-2S h777.py Radioddity_R2 radioddity_r2.py Retevis_H777_Plus h777.py Retevis_RB15 retevis_rb15.py Retevis_RB17P retevis_rb17p.py Retevis_RB615 retevis_rb15.py Retevis_RT1 retevis_rt1.py Retevis_RT22 retevis_rt22.py Retevis_RT22FRS retevis_rt22.py Retevis_RT23 retevis_rt23.py Retevis_RT26 retevis_rt26.py Retevis_RT6 baofeng_wp970i.py Retevis_RT622 retevis_rt22.py Retevis_RT76P retevis_rt76p.py Retevis_RT85 th_uv88.py Retevis_RT87 retevis_rt87.py Retevis_RT9000D_136-174 th9000.py Retevis_RT9000D_136-174 th9000.py Retevis_RT9000D_136-174 th9000.py Retevis_RT98 retevis_rt98.py Rugges_RH5R-V2 rh5r_v2.py TDXone_TD-Q8A tdxone_tdq8a.py TID_TD-M8 retevis_rt22.py TYT_TH-UV88 th_uv88.py TYT_TH9000_144 th9000.py TYT_TH9000_220 th9000.py TYT_TH9000_440 th9000.py WLN_KD-C1 retevis_rt22.py Wouxun_KG-UV6 wouxun.py Yaesu_FT70D ft70.py Yaesu_FTM350 ftm350.py Zastone_ZT-X6 retevis_rt22.py

12 37

[chirp_devel] Plans to get the users involved
by Dan Smith 18 Dec '22

18 Dec '22

Thanks to everyone that has tried (and/or still plans) to help test the new UI and radios under py3. The testing matrix is looking pretty decent: https://github.com/kk7ds/chirp/blob/py3/tests/Python3_Driver_Testing.md I know there are still things on there that people here have plans to test/fix, so please keep those coming. With the help of some stats, it looks like we're almost at the point at which 90% of the radios that get used regularly are in the "tested" or "probably works" category. Honestly, that's higher than I was really thinking we'd get, so that's cool. I like straight edges, right angles, and easy-to-remember dates. So, I'm thinking that first thing in January would be a good time to send out announcements to the users, looking to expand the testing to a wider audience. I think an initial blast to the chirp_users list would be good, see how that goes, and then start offering both on the download page. I also think the plan should be to effectively freeze the py2 branch for anything other than bug fixes at that point, and expect all new drivers to be against the py3 branch only. I feel like we've got some inertia now and we had better capitalize on it. At one point in the past I tried to say "new stuff has to work in py3" but I don't think we were close enough to really make that work (sorry Rick!). But now I think we've got builds, they're clearly usable, and saying that new radios will only be available in the new builds is actually reasonable. If anyone feels this is premature or not the best plan, speak up here and we can discuss. Actually, please speak up regardless, even if it's "yes, seems reasonable" or "friggin finally". There will be some bumps for sure, but I think if people can continue using the legacy builds for radios that don't yet work on the new stuff, we should be okay. I've started generating periodic builds here: https://trac.chirp.danplanet.com/chirp_next I've also started on a couple of docs on the website for "why are we doing this": https://chirp.danplanet.com/projects/chirp/wiki/ChirpNextBuild as well as explaining some differences between the old and new UI: https://chirp.danplanet.com/projects/chirp/wiki/ChirpNextBuildChanges If you have comments, edits, or suggestions on these, let me know. --Dan

8 9