[chirp_devel] [PATCH 0 of 2] Puxing PX777 fixes
I tried to reprogram a Puxing PX-777 today and ran into a few issues. These fixes resolve them.
Tom KD7LXL
# HG changeset patch # User Tom Hayward tom@tomh.us # Date 1355706045 28800 # Node ID 2fe6ec6bf7bc5add754476e9dfd4eea5aec6d5da # Parent 49c2ca133e8652aa17cdf8d79ce3717009803892 [px777] fix no-tone identifier. Fixes #363
diff -r 49c2ca133e86 -r 2fe6ec6bf7bc chirp/puxing.py --- a/chirp/puxing.py Fri Nov 16 16:02:11 2012 -0800 +++ b/chirp/puxing.py Sun Dec 16 17:00:45 2012 -0800 @@ -204,7 +204,7 @@ return True
def _is_no_tone(field): - return field[0].get_raw() == "\xFF" + return field[0].get_raw() in ["\x00", "\xFF"]
def _get_dtcs(value): # Upper nibble 0x80 -> DCS, 0xC0 -> Inv. DCS
Thanks!
# HG changeset patch # User Tom Hayward tom@tomh.us # Date 1355706045 28800 # Node ID 2fe6ec6bf7bc5add754476e9dfd4eea5aec6d5da # Parent 49c2ca133e8652aa17cdf8d79ce3717009803892 [px777] fix no-tone identifier. Fixes #363
This one doesn't pass the tests...
On Mon, Dec 17, 2012 at 4:52 PM, Dan Smith dsmith@danplanet.com wrote:
Thanks!
# HG changeset patch # User Tom Hayward tom@tomh.us # Date 1355706045 28800 # Node ID 2fe6ec6bf7bc5add754476e9dfd4eea5aec6d5da # Parent 49c2ca133e8652aa17cdf8d79ce3717009803892 [px777] fix no-tone identifier. Fixes #363
This one doesn't pass the tests...
I'm not really sure how to make this one pass the tests. It appears there are two values the radio interprets as no-tone, 0x00 and 0xff. Channels programmed for no-tone with the Puxing software will have the value 0xff. Channels programmed for no-tone from the PX-777 front panel will have the value 0x00. When reading the radio, Chirp breaks when it encounters the 0x00 value. Hence my patch. When Chirp writes/copies a new channel, it sets the tone value to 0xff, just like the Puxing software. This means a copy operation changes 0x00 to 0xff. The radio doesn't care, but this breaks the Chirp tests.
Tom KD7LXL
I'm not really sure how to make this one pass the tests. It appears there are two values the radio interprets as no-tone, 0x00 and 0xff. Channels programmed for no-tone with the Puxing software will have the value 0xff. Channels programmed for no-tone from the PX-777 front panel will have the value 0x00. When reading the radio, Chirp breaks when it encounters the 0x00 value. Hence my patch. When Chirp writes/copies a new channel, it sets the tone value to 0xff, just like the Puxing software. This means a copy operation changes 0x00 to 0xff. The radio doesn't care, but this breaks the Chirp tests.
If you look at why it breaks, I think you'll see the problem. Just change your check to looking at the low-order (i.e. field[1]) byte instead, which is never zero in a normal case. The way they store their tone, a 100.0 tone will be 0010, which triggers the "no tone" case the way you had it.
Ideally, we'd check both bytes for in [0x00, 0xFF] to be more explicit.
Thanks!
# HG changeset patch # User Tom Hayward tom@tomh.us # Date 1355706094 28800 # Node ID d433080159a115ac023b083bf469c437534b25f1 # Parent 2fe6ec6bf7bc5add754476e9dfd4eea5aec6d5da [px777] add - and space characters. Fixes #364
diff -r 2fe6ec6bf7bc -r d433080159a1 chirp/puxing.py --- a/chirp/puxing.py Sun Dec 16 17:00:45 2012 -0800 +++ b/chirp/puxing.py Sun Dec 16 17:01:34 2012 -0800 @@ -159,7 +159,7 @@ rf.valid_tmodes = ["", "Tone", "TSQL", "DTCS"] rf.valid_modes = ["FM", "NFM"] rf.valid_power_levels = POWER_LEVELS - rf.valid_characters = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ" + rf.valid_characters = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ- " rf.valid_name_length = 6 rf.has_ctone = False rf.has_tuning_step = False
participants (2)
-
Dan Smith -
Tom Hayward