Bug #6719
closedUV-5R and UV-5RX3 get VFO offsets wrong (entering 999.999 results in 99.99 when saved/uploaded)
100%
Description
I have a UV-5R and a UV-5RX3. If I set the VFO A or VFO B offset to @999.999000@ in CHIRP and upload the image to either radio, the radio interprets the values as @099.990@ (observable in each radio under menu item 26). If I save the image from CHIRP, close it, and then reopen it in CHIRP, I see @99.990000@ as the value in CHIRP.
I can set the value manually in either radio to @999.999@ (which is useful if you want to configure the radio to prohibit transmission in VFO mode). I'm pretty sure that if I set it manually in the radio and then read the configuration from the radio using CHIRP it will also show up as @99.990000@ in CHIRP.
Other values have even weirder results (e.g., @666.666@, @555.555@, @444.444@, etc.). Sometimes entering one value (e.g., @300@), saving the file, then entering a prior value (e.g., @444.444@) will result in a different value than what was saved with @444.444@ before. It seems non-deterministic.
It sounds like a similar symptom to #4635 (but that's for a different radio/code base).
Updated by Bernhard Hailer about 4 years ago
- Status changed from New to Closed
Are you sure the radio actually can take offsets such as the ones you are trying?
Common values (in the US) are 600 kHz or 5.0 MHz; in the European region 7.6 MHz.
I'm closing this ticket due to its uncommon nature. Please let us know if it needs to be reopened.
Updated by Jim Unroe about 4 years ago
- Status changed from Closed to In Progress
- Assignee set to Jim Unroe
- Target version set to chirp-legacy
- Platform changed from MacOS to All
This is because the radios for which the original driver was developed were limited to a offset of 69.950 MHz (which only required 4 bytes set aside in memory to store the value). The currently shipping models allow an offset up to 999.999 MHz (and 6 bytes of memory to store). The change allows setting the VFOs up for cross-band operation (which was not possible on the earlier models).
Jim KC9HI
Updated by Jim Unroe about 4 years ago
- Status changed from In Progress to Resolved
- % Done changed from 0 to 100
Patch submitted.
Jim KC9HI
Updated by Anonymous about 4 years ago
- Status changed from Resolved to Closed
Applied in changeset commit:597332505d7a.