- Developers - lists.chirpmyradio.com

[chirp_devel] Getting started with development
by David Purrington 21 Sep '16

21 Sep '16

I’d like to contribute but I’m having a hard time getting started with builds and tests. Are there notes anywhere on how to get going (e.g., installing prereqs)? I’ve looked all around for them, including in the repo and haven’t been able to locate them. run_all_tests.sh fails, so I know I’m not ready to start making changes. setup.py also fails because I’m missing libxml2, although I have installed it. FWIW, I’m on OS X - El Capitan. Maybe it’s not even possible on this OS (although that would be weird since I can actually run CHIRP on it). Thanks for any help you can offer, Dave KC1GES

2 1

[chirp_devel] support 'split'/'-'/''/'+' frequency modes on only some channels and still pass unit tests?
by Leo Bärring 21 Sep '16

21 Sep '16

Writing a driver for the Puxing PX-888K HT I'm wondering if there is a way to support that not all channels support all duplex modes. More to the point, there are 128 regular memories, as well as three special channels, VFO-A, VFO-B, and CALL. The call channel is equal to the memory channels in all but storage location and how to access it on the radio hardware: they always operate in 'split' mode, that is two numbers are stored, rx and tx frequencies. The vfo channels on the other hand, always operate in '-'/''/'+' mode, the rx frequency is stored and the tx frequency is determined by an offset and a sign. So far so good. The problem is that what modes to support is declared once, and for the whole radio, so for rf.valid_duplexes I put all of them, and if the user tries to set a mode that is not supported for that particular memory, it is converted to one that is, e.g: > Memory#1: freq = 456.0, offset = 0.7, duplex = '+' when stored to the memory map, turns into: > Memory#1: freq = 456.0, offset = 456.7, duplex = 'split' This of course messes up testing, because when reading back that memory from the map, things will have changed from when it was put there from a high level perspective. One solution would be to only support one of the either split, or non-split modes. I'd like to avoid that, and have so far instead opted for a more hacky solution, which is to store extra data about the chosen mode in some junk/unused bytes of the memory map. This is of course not really a good solution either, the assumption that the bytes used for the setting is not used by the radio hardware is made from reverse engineering and a sample of one. As of now, the setting is easily enabled/disabled from a single boolean, so one could enable it to pass testing, and then disable it for real use with real hardware. A related issue is what tone modes to support, on a radio that from a hardware perspective always operates in 'cross' mode, there is no way to discern between e.g. 'Tone' and 'Cross'+'Tone->' which is also something that is tested. Again, the available solutions are either restricting the feature set, or hope that some thought-to-be-unused locations do not store the hitherto unactivated spectacularly-blow-up-the-radio setting. Another solution I didn't think of before beginning on writing this mail, so it has not been tested, would be to create extra member fields in the radio class, this would have the effect of not storing the extra settings between instantiations of the class, but on the other hand no risks are taken with the radio hardware either. I could certainly use some advice on the matter... // Leo

2 2

[chirp_devel] [PATCH] [ft60] Update download message to match reality, fixes #3979
by brian.maybe＠gmail.com 21 Sep '16

21 Sep '16

# HG changeset patch # User Brian Dickman <brian.maybe(a)gmail.com> # Date 1474432885 25200 # Tue Sep 20 21:41:25 2016 -0700 # Node ID c58c845ec6ee53bdcf209f1a0c1a48e882bd78ed # Parent a1b8b53606f6025fc1ad727331837cfc7759f178 [ft60] Update download message to match reality, fixes #3979 diff -r a1b8b53606f6 -r c58c845ec6ee chirp/drivers/ft60.py --- a/chirp/drivers/ft60.py Sat Sep 10 11:34:01 2016 -0400 +++ b/chirp/drivers/ft60.py Tue Sep 20 21:41:25 2016 -0700 @@ -357,7 +357,8 @@ radio on. 4. Rotate the DIAL job to select "F8 CLONE". 5. Press the [F/W] key momentarily. -6. <b>After clicking OK</b>, press the [PTT] switch to send image.""")) +6. <b>After clicking OK</b>, hold the [PTT] switch + for one second to send image.""")) rp.pre_upload = _(dedent("""\ 1. Turn radio off. 2. Connect cable to MIC/SP jack.

1 0

[chirp_devel] [PATCH][btech.py] This patch handle the bug on Linux OS for this driver, fixes #3993
by Pavel Milanes Costa 20 Sep '16

20 Sep '16

Linux OSes has problems with some variants of the radios supported by this driver, Michael Wagner OE4AMW, discovered that delaying the writes fixes the bug. Further investigation revealed that for this radios the OEM software do delay the writes and even restart the download when the fault condition arose. This patch fixes a bunch of open issues about synthoms of this bug, I will link them in the CMS to get them closed. Michel proposed this patch that has proved to fix this bug (and retry when the bug is detected), so this patch is in his name (with some cosmetics from my side) Look in the issue thread for more details Thanks to Michael Wagner OE4AMW.

1 0

[chirp_devel] [PATCH] [btech] Delayed retry on writing to radio in case of errornous response. Needed mostly on linux. Fixes issue #3993
by Michael Wagner 20 Sep '16

20 Sep '16

1 0

[chirp_devel] Testing, please ignore
by Pavel Milanes Costa 20 Sep '16

20 Sep '16

Testing, please ignore

1 0

[chirp_devel] [PATCH 0 of 4] RFC MD-380 WIP
by Tom Hayward 16 Sep '16

16 Sep '16

I have been working on completing Travis Goodspeed's MD-380 driver. It's still unfinished, but I haven't touched this code in a week or two and wanted to share it rather than let it rot on my system. There are a few things about the MD-380 that add complexity to the Chirp driver: - It is a DMR radio, which means in addtion to channels and banks, a contact/talkgroup editor is required. - It uses USB DFU for upload/download, which has never been done before in Chirp. Here is the current state: - Memory map is complete. - get_memory() works - I think I finished set_memory(), but don't take my word for it. - Bank/zone editing works based on Travis' earlier implementation. - There's no contact editor. - Can read .rdt files from MD-380 OEM software - Can read .img files from md380tools - No attempt has been made to support upload/download, yet, although Travis' implementation in md380tools works. Porting this is on my to-do list. - Copy/paste of DMR channels doesn't work, because the "extra" settings aren't copied. With DMR radios there is essential stuff here. This looks rather involved to fix, because Chirp doesn't pass the full Memory object during copy/paste. - It's difficult to read the channel list because color code, timeslot, and talkgroup/contact are all hidden. I'm not sure the best way to add this to Chirp. There's some other interesting stuff in this patchbomb: - Import repeater list from DMR-MARC. Unfortunately this doesn't include talkgroup data, so it's not really useful for programming the radio. - Support for reading and writing files that contain img data between a header and footer. I've noticed this is pretty common with other radio programming software, so I created a generic way to support it. - A fix for a bug that has broken a Chirp feature for about 3 years. I guess I'm the only one who uses multiple memory maps! Please comment. Tom KD7LXL

1 4

[chirp_devel] [PATCH] second try, since the attachment was scrubbed, for issue #4031
by Leo Bärring 16 Sep '16

16 Sep '16

# HG changeset patch # User Leo Bärring <leo.barring(a)protonmail.com> # Date 1473987633 -7200 # Fri Sep 16 03:00:33 2016 +0200 # Node ID c8e5761ed19d77f2fecf38decb2152011c23d309 # Parent a1b8b53606f6025fc1ad727331837cfc7759f178 Renames value to mem_val, fixes issue #4031 Also a "hello world" patch for me. diff -r a1b8b53606f6 -r c8e5761ed19d chirp/settings.py --- a/chirp/settings.py Sat Sep 10 11:34:01 2016 -0400 +++ b/chirp/settings.py Fri Sep 16 03:00:33 2016 +0200 @@ -242,7 +242,7 @@ index = self._mem_vals.index(mem_val) self.set_value(self._options[index]) else: - raise InvalidValueError("%s is not valid for this setting" % value) + raise InvalidValueError("%s is not valid for this setting" % mem_val) def __trunc__(self): """Return memory value that matches current user option"""

1 0

[chirp_devel] [PATCH] [btech] Delayed retry on writing to radio in case of errornous response. Needed mostly on linux. Fixes issue #3993
by Michael Wagner 16 Sep '16

16 Sep '16

# HG changeset patch # User Michael Wagner <michael.wagner(a)gmx.at> # Date 1474015004 -7200 # Fri Sep 16 10:36:44 2016 +0200 # Node ID d6ee4a5066611703778f4b341b0c8b3d5c51e1b4 # Parent a1b8b53606f6025fc1ad727331837cfc7759f178 [btech] Delayed retry on writing to radio in case of errornous response. Needed mostly on linux. Fixes issue #3993 If radio responds with the infamous '0x05', driver now retries, but delays after each sent byte. Happens mostly on linux, and on several radios of this family (found on a KT-8900R). Might also affect/fix also #3587 and #3635. Many Thanks to Pavel Milanes for his support (analysis, explainations of the driver, sharing his knowledge about this and similar bugs, helping me with python-codestyle), and for encouraging me to contribute this patch. Michael Wagner, OE4AMW diff -r a1b8b53606f6 -r d6ee4a506661 chirp/drivers/btech.py --- a/chirp/drivers/btech.py Sat Sep 10 11:34:01 2016 -0400 +++ b/chirp/drivers/btech.py Fri Sep 16 10:36:44 2016 +0200 @@ -21,6 +21,7 @@ LOG = logging.getLogger(__name__) +from time import sleep from chirp import chirp_common, directory, memmap from chirp import bitwise, errors, util from chirp.settings import RadioSettingGroup, RadioSetting, \ @@ -236,7 +237,7 @@ # this var controls the verbosity in the debug and by default it's low (False) # make it True and you will to get a very verbose debug.log -debug = False +debug = True # Power Levels NORMAL_POWER_LEVELS = [chirp_common.PowerLevel("High", watts=25), @@ -334,6 +335,9 @@ # magic string for all other models MSTRING = "\x55\x20\x15\x09\x20\x45\x4d\x02" +# this variables controls the forced delay and retry on Linux OS mainly. Added by OE4AMW to workaround Issue 3993 +NEEDS_DELAY = False +RETRY_DELAYED = False def _clean_buffer(radio): """Cleaning the read serial buffer, hard timeout to survive an infinite @@ -383,6 +387,11 @@ if len(data) < amount: LOG.warn("Short reading %d bytes from the %d requested." % (len(data), amount)) + # This problem can be and expression of the MCU getting stuck + # so from now own we must delay the write operations. + global NEEDS_DELAY + NEEDS_DELAY = True + LOG.debug("Delaying future writes.") except: raise errors.RadioError("Error reading data from radio") @@ -396,11 +405,26 @@ try: for byte in data: radio.pipe.write(byte) + # Some OS (mainly Linux ones) are two fast on the serial and + # get the MCU inside the radio stuck in the early stages, this + # hits some models more than others. + # + # To cope with that we introduce a delay on the writes but only if + # we detect this problem, this was found by Michael Wagner who + # proposed a patch for it, well done. + if NEEDS_DELAY: + # 10 msec is proved to be safe, is better to be slow and right + # than fast and some times wrong. (5 msec is tested ok) + sleep(0.010) # DEBUG if debug is True: + if NEEDS_DELAY: + LOG.debug("This write was delayed") + LOG.debug("==> (%d) bytes:\n\n%s" % (len(data), util.hexprint(data))) + except: raise errors.RadioError("Error sending data to radio") @@ -435,9 +459,21 @@ # header validation c, a, l = struct.unpack(">BHB", block[1:5]) if a != addr or l != BLOCK_SIZE or c != ord("X"): - LOG.debug("Invalid header for block 0x%04x" % addr) + LOG.error("Invalid header for block 0x%04x" % addr) LOG.debug("CMD: %s ADDR: %04x SIZE: %02x" % (c, a, l)) - raise errors.RadioError("Invalid header for block 0x%04x:" % addr) + + global RETRY_DELAYED + if not RETRY_DELAYED: + # first try with header problems, forcing a write delay + LOG.warn("Failure occured, trying once again with delay") + RETRY_DELAYED = True + global NEEDS_DELAY + NEEDS_DELAY = True + return False + else: + # second try, now we fail. + LOG.debug("This was already a retry") + raise errors.RadioError("Invalid header for block 0x%04x:" % addr) # return the data return block[5:] @@ -613,6 +649,16 @@ # read d = _recv(radio, addr) + if d == False: + # retry to get that block of data. + msg = "Previous block request failed." + msg += " Cleaning buffer and trying again." + LOG.info(msg) + _clean_buffer(radio) + d = _recv(radio, addr) + global RETRY_DELAYED + RETRY_DELAYED = False + # aggregate the data data += d @@ -821,7 +867,16 @@ def sync_in(self): """Download from radio""" - data = _download(self) + try: + data = _download(self) + except errors.RadioError: + msg = "First download-attempt failed." + msg += " Retrying the whole procedure with delayed writes." + LOG.error(msg) + global NEEDS_DELAY + NEEDS_DELAY = True + data = _download(self) + self._mmap = memmap.MemoryMap(data) self.process_mmap() @@ -1284,7 +1339,7 @@ if self.MODEL in ("UV-2501", "UV-5001"): vfomren = RadioSetting("settings2.vfomren", "VFO/MR switching", RadioSettingValueBoolean( - _mem.settings2.vfomren)) + not _mem.settings2.vfomren)) advanced.append(vfomren) reseten = RadioSetting("settings2.reseten", "RESET", @@ -1569,6 +1624,8 @@ if element.has_apply_callback(): LOG.debug("Using apply callback") element.run_apply_callback() + elif setting == "vfomren": + setattr(obj, setting, not int(element.value)) elif element.value.get_mutable(): LOG.debug("Setting %s = %s" % (setting, element.value)) setattr(obj, setting, element.value)

1 0

[chirp_devel] Patch for issue #4033
by Leo Bärring 16 Sep '16

16 Sep '16

This is also a very minor change. Due to the diff environment in the patch showing the line affected in my patch for #4031 I'm not sure what will happen if the patch in this submission is applied before that patch. /Leo Bärring

1 0