[chirp_devel] [PATCH] [px777] fix no-tone identifier. Fixes #363
# HG changeset patch # User Tom Hayward tom@tomh.us # Date 1356733619 28800 # Node ID 54eeec36d292bff0f8ca298fc26e7735d9d9652a # Parent 37b042d567412f3abdceea513a39e13aef344caa [px777] fix no-tone identifier. Fixes #363
diff -r 37b042d56741 -r 54eeec36d292 chirp/puxing.py --- a/chirp/puxing.py Fri Dec 28 07:58:20 2012 -0800 +++ b/chirp/puxing.py Fri Dec 28 14:26:59 2012 -0800 @@ -204,7 +204,7 @@ return True
def _is_no_tone(field): - return field[0].get_raw() == "\xFF" + return int(field) in [0, 16665]
def _get_dtcs(value): # Upper nibble 0x80 -> DCS, 0xC0 -> Inv. DCS
On Fri, Dec 28, 2012 at 3:10 PM, Dan Smith dsmith@danplanet.com wrote:
return field[0].get_raw() == "\xFF"
return int(field) in [0, 16665]
Hmm, can you explain this?
No, I can't explain it. 16665 is the magic number used in the PX-777 to indicate no tone. Here's an example:
struct { rx_freq: 4:[(15390000)] tx_freq: 4:[(15390000)] rx_tone: 2:[(16665)] tx_tone: 2:[(16665)] _3_unknown_1: 0x02 _2_unknown_1: 0x03 (......11b) power_high: 0x01 (.......1b) iswide: 0x01 (.......1b) skip: 0x01 (.......1b) bclo: 0x00 (......00b) _2_unknown_2: 0x01 (.......1b) _4_unknown1: 0x7F (.1111111b) pttid: 0x01 (.......1b) unknown: 0xFF } memory (16 bytes at 0x0590)
struct { name: 6:[0x19,0x0C,0x0F,0x12,0x1B,0x0E] pad: 2:[0xFF,0x00] } names (8 bytes at 0x0B18)
Tom KD7LXL
On Fri, Dec 28, 2012 at 3:24 PM, Tom Hayward esarfl@gmail.com wrote:
On Fri, Dec 28, 2012 at 3:10 PM, Dan Smith dsmith@danplanet.com wrote:
return field[0].get_raw() == "\xFF"
return int(field) in [0, 16665]
Hmm, can you explain this?
No, I can't explain it. 16665 is the magic number used in the PX-777 to indicate no tone. Here's an example:
struct { rx_freq: 4:[(15390000)] tx_freq: 4:[(15390000)] rx_tone: 2:[(16665)] tx_tone: 2:[(16665)]
...and that would be because lbcd 0xFF 0xFF == 16665d.
Should I add a get_raw() method to arrayDataElement? Then do this:
return field.get_raw() in [0, 0xFFFF]
The only reason I'm using int for the comparison is because that's the coercion that's available in arrayDataElement.
Tom KD7LXL
...and that would be because lbcd 0xFF 0xFF == 16665d.
Ah, right, I forgot it was BCD.
Should I add a get_raw() method to arrayDataElement? Then do this:
return field.get_raw() in [0, 0xFFFF]
The only reason I'm using int for the comparison is because that's the coercion that's available in arrayDataElement.
Sure, I think that's much better.
participants (2)
-
Dan Smith
-
Tom Hayward