- Developers - lists.chirpmyradio.com

[chirp_devel] Fix #3737 - model detection for TH-7800 and TH-9800 too loose
by Nathan Crapo 14 Jun '16

14 Jun '16

TH-9800 users would get the th7800.py driver instead of th9800.py. This should fix that. -Nathan

2 1

[chirp_devel] [PATCH][Feature] Add the know clones of the btech with the new alias feature, fixes #3749
by Pavel Milanes (CO7WT) 14 Jun '16

14 Jun '16

This patch explicitly adds the following Btech clones to the UI: * Jetstream JT2705M * Juentai JT-6188 Mini * Juentai JT-6188 Plus * Sainsonic GT-890 This radios do show properly now in the download/upload dialog as vendor/model, this will ease the handling of clones in the user side. But it has a catch and the users will be notified on the chirp_user list: when you opens a saved image of a clone it will show in Chirp as the real radio, not the clone. -- 73 Pavel CO7WT.

1 0

[chirp_devel] [PATCH][Feature] Make the driver engine support radio clones as aliases, fixes #3747
by Pavel Milanes (CO7WT) 14 Jun '16

14 Jun '16

This is a modification to the driver management part of Chirp to allow the drivers to support clones as aliases. This was handled by a patch suggestion by Dan a few time ago in the devel list. -- 73 Pavel CO7WT.

1 0

[chirp_devel] Need help reading a radio.
by Jim Unroe 13 Jun '16

13 Jun '16

All, I am trying to read a new radio. Here is the problem. A request for data is made like this. 52 1D 80 40 Then usually 68 bytes (4 header bytes and 64 data bytes) are returned like this: 57 1D 80 40 + {64 data bytes} But every once in a while the radio will return 69 bytes (the command byte is sent twice increasing the header to 5 bytes) like this: 57 57 1D 80 40 + {64 data bytes} Got any advice how I can deal with this extra byte being introduced randomly. The OEM software apparently has no problem handling this. Jim

2 2

[chirp_devel] [PATCH][BTECH] Support for pySerial 3+ in this driver, fixes #3725
by Pavel Milanes (CO7WT) 13 Jun '16

13 Jun '16

Add support for the pySerial 3+ lib -- 73 Pavel CO7WT.

2 2

[chirp_devel] [PATCH][KT-8900R] Fix the second ID to cope with a new variant, fixes #3547
by Pavel Milanes (CO7WT) 13 Jun '16

13 Jun '16

The latest added variant has the second ID without the leading spaces, instead it's filled with '123456' We removed the leading spaces as the ID is the same of the others but they changed the leding spaces. -- 73 Pavel CO7WT.

1 0

Re: [chirp_devel] TH7800 Support
by Dan Smith 11 Jun '16

11 Jun '16

(adding the list back in) > The model detection code for TH-9800 is overly simplistic to start with: > > def match_model(cls, filedata, filename): > return len(filedata) == cls._memsize and filename.endswith('.dat') Yeah, that filename check is probably not a good call either because chirp doesn't enforce that, and defaults to .img. But yeah, default for all radios is the size check. > _Unfortunately_, the TH7800 I worked on is programmed with TH9800 as its > model name. Strange, right? I'm guessing they use the same radio and > change its mode with different firmware or a HW jumper or something. > Looks like they don't do a very thorough job of switching the model name. Are the sizes the same too? Maybe size + model would do it? > I can think of two things to possibly do at this point: > 1) Try switching off something that is unique between the two. I can > compare a TH-9800 file to see if I can figure something out. Off-hand, > I think the band limits might be a good way to do it. I got that > working on the TH-7800 and I'm pretty sure it differs from the TH-9800. > 2) Require TH-7800 users to change the model name in their radio. I > think this can be done with the OEM software. The OEM software _sucks_ > in so many ways, though. I don't really like this idea. Yeah, #2 is not really a solution I think. Hopefully we can find something to key off of though. What if we change the model in the image when we save it? If they are cloning from the radio they have already picked one of the models, which means we can save the known model in the image at that point. Then we will change the model string in the radio I guess, but maybe that's not so bad. Anyway, this should be the last resort if we can't find anything else, because people with existing images get screwed too. > Thoughts? I'm going to pursue #1 above and update the TH-7800 > model_match() code. Yep, thanks, I think we should try #1 until we run out of ideas. We haven't had any other cases where we failed to find something to distinguish models, so I'm hopeful. --Dan

1 0

[chirp_devel] TH7800 Support
by Nathan Crapo 11 Jun '16

11 Jun '16

Here's my next patch submission after an initial review from Dan. Changes from last submission: * make pep8 tester happy * move "common" code to settings.py for review Regards, Nathan

2 3

[chirp_devel] [PATCH][TK-760G] Support for the pySerial 3+ in this driver, fixes #3729
by Pavel Milanes (CO7WT) 09 Jun '16

09 Jun '16

Add support for pySerial 3+, also make an update on the authors email. -- 73 Pavel CO7WT.

1 1

[chirp_devel] [PATCH][KT-8900R] Add a new discovered variant, fixes #3547
by Pavel Milanes (CO7WT) 09 Jun '16

09 Jun '16

A new variant of this radio was found on the wild. Also my IDE (Geany) has a strict policy for leading spaces, so it removed automaticaly some of them. -- 73 Pavel CO7WT.

1 0