[chirp_devel] [PATCH 1 of 2] [px777] fix no-tone identifier. Fixes #363

[Dan Smith]

> 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!

-- 
Dan Smith
www.danplanet.com
KK7DS

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
Url : http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20121220/02891d53/attachment-0001.bin