June 2016 - Developers - lists.chirpmyradio.com

[chirp_devel] Random double ACK during upload
by Jim Unroe 17 Jun '16

17 Jun '16

I am working with a radio that I am having a problem with the upload procedure. Normally, after a "frame" is sent, the radio replies with an ACK and the programming software sends the next "frame", another ACK is received and so on. The problem is that randomly the radio with reply with 2 ACKs instead of 1. Currently my upload progresses fine until the double ACK is encountered. My upload code is below. Does anyone have any suggestions for how I can bypass these occasional extra ACKs? Thanks in advance, Jim def _upload(radio): """Upload procedure""" MEM_SIZE = 0x7000 # put radio in program mode and identify it _do_ident(radio) # UI progress status = chirp_common.Status() status.cur = 0 status.max = MEM_SIZE / BLOCK_SIZE status.msg = "Cloning to radio..." radio.status_fn(status) # the fun start here for addr in range(0, MEM_SIZE, BLOCK_SIZE): # sending the data data = radio.get_mmap()[addr:addr + BLOCK_SIZE] frame = _make_frame("W", addr, BLOCK_SIZE, data) _send(radio, frame) # receiving the response ack = _rawrecv(radio, 1) if ack != "\x06": msg = "Bad ack writing block 0x%04x" % addr raise errors.RadioError(msg) # UI Update status.cur = addr / BLOCK_SIZE status.msg = "Cloning to radio..." radio.status_fn(status) _exit_program_mode(radio)

2 1

[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