- Developers - lists.chirpmyradio.com

[chirp_devel] [PATCH] [ui] Default file name to include model and date. #3753
by Tom Hayward 15 Jun '16

15 Jun '16

# HG changeset patch # User Tom Hayward <tom(a)tomh.us> # Date 1466036303 25200 # Wed Jun 15 17:18:23 2016 -0700 # Node ID 975df4b3f7b6d94280d7dc1800aab841772b80e6 # Parent cd4630e4151a435810e1eb3089f63927dfe2c626 [ui] Default file name to include model and date. #3753 During Save As, default the filename to {vendor}_{model}_{date}.img. The user is free to edit the field to their liking before saving. In case you don't like {vendor}_{model}_{date}.img, a new configuration variable "default_filename" is provided. By setting this variable in your config file, you can reorder or omit parts of the default format. Example: [global] default_filename = {vendor}_{model} This omits the date. Example: [global] default_filename = Tom's_{vendor}_{model}_{date} This begins each filename with my name. diff -r cd4630e4151a -r 975df4b3f7b6 chirp/ui/mainapp.py --- a/chirp/ui/mainapp.py Tue Jun 14 12:05:41 2016 -0400 +++ b/chirp/ui/mainapp.py Wed Jun 15 17:18:23 2016 -0700 @@ -14,6 +14,7 @@ # You should have received a copy of the GNU General Public License # along with this program. If not, see <http://www.gnu.org/licenses/>. +from datetime import datetime import os import tempfile import urllib @@ -433,6 +434,13 @@ vendor=eset.radio.VENDOR, model=eset.radio.MODEL) + defname_format = CONF.get("default_filename", "global") or \ + "{vendor}_{model}_{date}" + defname = defname_format.format( + vendor=eset.radio.VENDOR, + model=eset.radio.MODEL, + date=datetime.now().strftime('%Y%m%d')) + types = [(label + " (*.%s)" % eset.radio.FILE_EXTENSION, eset.radio.FILE_EXTENSION)] @@ -445,7 +453,8 @@ types += [(_("VX5 Commander") + " (*.vx5)", "vx5")] while True: - fname = platform.get_platform().gui_save_file(types=types) + fname = platform.get_platform().gui_save_file(default_name=defname, + types=types) if not fname: return

1 0

Re: [chirp_devel] [chirp_users] Chirp's new Alias feature.
by Robert Morris 15 Jun '16

15 Jun '16

1 0

Re: [chirp_devel] [chirp_users] Chirp's new Alias feature.
by Tom Hayward 15 Jun '16

15 Jun '16

On Wed, Jun 15, 2016 at 7:28 AM, Pavel Milanes (CO7WT) <pavelmc(a)gmail.com> wrote: > So my recommendation is that you NAME the image file like your radio > vendor/model; this way you will get get a "tip from the past" when months in > the future you hit with this odd behavior. You know, we could automate this in the Save dialog. Maybe default to something like %(userinput).%(vendor)_%(model).img. Tom KD7LXL

2 3

[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