June 2016 - Developers - lists.chirpmyradio.com

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

Re: [chirp_devel] Adding TYT TH-7800 Support. Fixes #3477
by Dan Smith 09 Jun '16

09 Jun '16

> Okay, I changed up the formatting and found one other section of code I > forgot I wanted to change. I also moved the common code to > settings.py. I also ran the unit tests and opened a few TH7800 img files. > > LMK what you think. Happy to explain my thoughts on any of the "common" > stuff. Can you send this to the list please? My patchbot pulls from there and it's useful for other reviewers. Thanks! --Dan

1 0

Re: [chirp_devel] Adding TYT TH-7800 Support. Fixes #3477
by Dan Smith 09 Jun '16

09 Jun '16

(adding the list back in) > The APO code you're referring to is included in many drivers. I wasn't quoting the APO code for any reason other than as an example for the long line. > The potential changes to settings.py seems like a tougher discussion. > It updates a common API in a way I think is very useful, but you may not > like exactly how I've done it. Did you see anything there you didn't like? I'll look at it in the context of the rest of the file in a patch that puts it there. > I'll work on the formatting. How would you like me to send an updated > patch? Maybe I can just submit it to this email thread? Updated patches go to the list just like normal ones. Always against current tip until something gets committed. Thanks! --Dan

1 0

Re: [chirp_devel] [chirp_users] TK-790 users, developer need help from you...
by Tom Hayward 09 Jun '16

09 Jun '16

On Wed, Feb 24, 2016 at 2:51 PM, Pavel Milanes (CO7WT) <co7wt(a)frcuba.co.cu> wrote: > Hi Tom, > > I think I nailed, attached is the first beta driver for the Kenwood TK-790. > > Please try it if you have the time, any comments will be appreciated, also > if you encounter any error the debug.log will be very useful (zip it please) > > Cheers, Pavel CO7WT Hi Pavel, I've been working through the TK-790 driver you sent me and made a number of changes. Downloads are now working for me fast and consistently. I'm not sure if you encountered this problem, but often when I would put the radio into PROGRAM mode, I would not immediately see an ack. This would abort the download. It seems this radio likes to send serial data for every possible event, so often when I would go to read the ack there would be 100+ bytes in the input buffer (and this is after clearing the buffer immediately before issuing the PROGRAM command!). Consistently, however, I would see the ack at the end of all this garbage. I noticed that the information frames (the "garbage") all ended in 0xFF, so I added a way to chew through them: _raw_send(radio, "PROGRAM") ack = _raw_recv(radio, 1024) while ack: if ack[0] == ACK_CMD: break ack = ack[ack.index('\xff')+1:] else: radio.pipe.write("E") raise errors.RadioError("Radio didn't acknowledge program mode.") This will look for the ack after the garbage/information frames, but never inside them! One issue down... The other problem I encountered was very slow downloads. In many cases the code was requesting more bytes than the radio was sending, so we had to wait for the timeout to expire. I refactored _recvl() and _recvh() such that they now only request as many bytes as needed. This makes downloads very fast! This negates the need for short timeouts and sleeps, so I removed those. I haven't tested upload. I noticed the tests crash on the bank code, but haven't looked into it. Attached is my updated tk790.py. Disclaimer for those on the sidelines: it's very much a work in progress! Tom KD7LXL

2 1

[chirp_devel] Adding TYT TH-7800 Support. Fixes #3477
by Nathan Crapo 08 Jun '16

08 Jun '16

This is my first submission to the project. Hopefully I'm following the process well enough. I tested this driver fairly thoroughly with the radio when I had it, but no longer have access to it. Wasn't sure how to include the binary file for unit tests, which I ran. I attached it to this email. Please let me know if I can provide anything else. Regards, Nathan

2 3

[chirp_devel] [PATCH] [ui] Dismiss shift dialog with enter key. Fixes #3695
by Tom Hayward 01 Jun '16

01 Jun '16

# HG changeset patch # User Tom Hayward <tom(a)tomh.us> # Date 1464827431 25200 # Wed Jun 01 17:30:31 2016 -0700 # Node ID ddae9e31bdac726b8908f81febb44c75a1339eb8 # Parent 1bf5865b79b205268e605b1bfced8ece3a7b7838 [ui] Dismiss shift dialog with enter key. Fixes #3695 diff -r 1bf5865b79b2 -r ddae9e31bdac chirp/ui/shiftdialog.py --- a/chirp/ui/shiftdialog.py Mon May 30 10:48:54 2016 -0400 +++ b/chirp/ui/shiftdialog.py Wed Jun 01 17:30:31 2016 -0700 @@ -47,8 +47,6 @@ self.thread = None - self.set_response_sensitive(gtk.RESPONSE_OK, False) - def _status(self, msg, prog): self.__labl.set_text(msg) self.__prog.set_fraction(prog)

1 0

[chirp_devel] [PATCH] [ui] Default memory editor view to 0-999 (was 0-25). Fixes #3629
by Tom Hayward 01 Jun '16

01 Jun '16

# HG changeset patch # User Tom Hayward <tom(a)tomh.us> # Date 1464827404 25200 # Wed Jun 01 17:30:04 2016 -0700 # Node ID d79f9e180c20ed54221d02d389f65466c901ee4a # Parent a954c5ca5c74f76d86d25f277a3225308d216c2a [ui] Default memory editor view to 0-999 (was 0-25). Fixes #3629 diff -r a954c5ca5c74 -r d79f9e180c20 chirp/ui/memedit.py --- a/chirp/ui/memedit.py Tue May 31 12:41:14 2016 -0700 +++ b/chirp/ui/memedit.py Wed Jun 01 17:30:04 2016 -0700 @@ -1181,7 +1181,7 @@ lostart = self._config.is_defined(lokey) and \ self._config.get_int(lokey) or min histart = self._config.is_defined(hikey) and \ - self._config.get_int(hikey) or 25 + self._config.get_int(hikey) or 999 self.lo_limit_adj = gtk.Adjustment(lostart, min, max-1, 1, 10) lo = gtk.SpinButton(self.lo_limit_adj)

1 0