I'm don't believe I understand what "try with integers" means.

Here's the portion of code that I think the problem is in. More specifically the 'def convert_freq_to_bytes(real_freq) part.

+ def convert_bytes_to_freq(bytes): + real_freq = 0 + for byte in bytes: + real_freq = (real_freq * 10) + byte + return real_freq / 100000.0 + + def convert_freq_to_bytes(real_freq): + bytes = [ 0 for x in range(0,8) ] # init list with 8 times 0 + real_freq = int(freq * 100000) # it has to be integer + for i in range(7, -1, -1): # go from 7 to 0 + bytes[i] = real_freq%10 # extract last digit + real_freq /= 10 # throw away last digit + return bytes +

So would integer mean, don't do the division and multiplication by 100000?

I've attached the original patch in case someone wants to take a look at it.

Jim

On Mon, Jan 28, 2013 at 4:16 AM, IZ3GME Marco iz3gme.marco@gmail.comwrote:

Hi Jim I really dont like this solution, did you try with integers as Andrew suggested?

73 de IZ3GME Marco

On 27/01/2013 16:58, Jim Unroe wrote:

...

All,

I gave up on using the RadioSettingValueFloat(RadioSettingValue) feature. So none of that code supplied by Dan has been included.

Being able to enter a floating point frequency looked nice but even after quite a bit of research, I wasn't able to overcome the floating point to binary conversion error (setting a frequency of 146.940 always resulted in 146.390 (actually 146.39999 but I have step set to 10.0KHz)).

I think what I have provided here is very usable. I wish there was a way to limit the 100's of MHz selections to 1, 4 & 5 and the 100's of Hz settings to 0, 2, 5 and 7. At list I have them limited to their lowest and highest settings.

I'd be willing to revisit this, but for now I'd like to review my todo list and see what additional things I can add to CHIRP for the UV-5R.

Thanks for everyone's help. I learned a lot from everyone.

Jim Unroe

---

chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs:

http://chirp.danplanet.com/projects/chirp/wiki/Developers

...

---

chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers

Right!

in other words Jim: - use RadioSettingValueInteger to store freq as tens of Hz - remove / 100000.0 from convert_bytes_to_freq - remove whole real_freq = int(freq * 100000) line from convert_freq_to_bytes

73 de IZ3GME Marco

P.S. Sorry I don't have the time to write and test code myself today

On 28/01/2013 12:55, Andrew Errington wrote:

On Mon, 28 Jan 2013 19:33:44 Jim Unroe wrote:

...

I'm don't believe I understand what "try with integers" means.

Hi there,

Sorry to be so mysterious.

By using integers I mean you should store the frequency as a whole number with no decimal part (i.e. an integer). Integers are handled accurately by Python (or any language) but floating point numbers are a 'representation' of the number, so they can sometimes differ slightly (although they are usually close enough). The problem you are having seems that 146.940 cannot be stored accurately and instead gives you 146.939 (which I think is what you meant to write in your message as 146.390 would be *way off*). As you can see, 146.939 is 'close enough'.

So, internally to your code, treat the frequency as an integer, maybe a whole number of Hz or kHz.

146.940 MHz is a floating point number. 146940000 Hz is the same value as an integer 146940 kHz is the same value too.

This will always be accurate, and will always convert to a string of digits the same as what you thought you stored. As a programmer you have to remember where the decimal point goes when you display the value to the user in MHz, which is a good reason for choosing Hz as your unit. If you are constantly juggling between Hz, kHz and MHz you will make a mistake somewhere.

When you display it as a string you can insert a decimal point in the right place. When you ask for user input you can treat it as a string of digits, strip out the decimal point and convert to an integer number.

Anyway, that's my attempt at explaining my meaning, but I just did a quick check in Python and I can accurately store and retrieve the value 146.94 in a variable, and convert it to an exact string representation so there must be something up somewhere else. Probably a rounding error somewhere.

73,

Andrew _______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers

Andrew, Marco and everyone,

The weekend has finally arrived and I have been able to put in some more time into this project.

I got it switched to integer numbers like we discussed. I wasn't that hard to do once I got going again.

It definitely looks much better that my previous attempt. As expected it eliminated the floating point conversion problem I was having.

I had it all fancy where the frequency limits that you could enter was based on the vhf/uhf lower and upper limits set on the Other tab. It was pretty cool but it could get in trouble if you changed the band setting without keying in the appropriate frequency. I think that problem would go away if you could use the entered frequency to automatically set the correct band.

If you don't mind, take a look at it and let me know if there is anything else I should do or if anything is missing. This it the trickiest thing I've done so far and I want to make sure it is right before I submit it to Dan.

Thanks, Jim

On Mon, Jan 28, 2013 at 7:10 PM, Jim Unroe rock.unroe@gmail.com wrote:

Marco, I'll see if I can't give this another look this weekend. Jim

On Mon, Jan 28, 2013 at 7:16 AM, IZ3GME Marco iz3gme.marco@gmail.comwrote:

...

Right!

in other words Jim:

• use RadioSettingValueInteger to store freq as tens of Hz
• remove / 100000.0 from convert_bytes_to_freq
• remove whole real_freq = int(freq * 100000) line from

convert_freq_to_bytes

73 de IZ3GME Marco

P.S. Sorry I don't have the time to write and test code myself today

Marco, Thanks so much

chirp.hg_1836.patch*

*There is also code in settings.py and settingsedit.py can probably be cleaned up. Like the 'float' code that Dan provided. I started to take some of it out and quit in fear that I would break something. Who knows, it may be useful for something else. I'll leave that decision for Dan to make.

chirp.hg_1837.patch*

*You don't know how bad I wanted to get rid of the BAND settings. I was actually working on trying to figure out a way to do it. At least now I know I was looking in the right place. I would never have thought the solution would have been as simple as yours.

chirp.hg_1837.patch*

*Yes. That does read better. And, yes, 17399750 is as close as you can get to 17400000 without wrapping around to 13600000.

Jim *

* On Sun, Feb 3, 2013 at 8:31 AM, Marco IZ3GME iz3gme.marco@gmail.com wrote:

Hi Jim in attach some patches to refine your code.

73 de IZ3GME Marco

Maybe I'm missing something. If the user has to enter the frequency as a floating point number, how does storing it as an integer help? When the user's input is changed to and saved as in integer, wouldn't the same error occur? Jim

On Mon, Jan 28, 2013 at 11:24 AM, Andrew Errington erringtona@gmail.comwrote:

On Mon, 28 Jan 2013 19:33:44 Jim Unroe wrote:

...

I'm don't believe I understand what "try with integers" means.

Here's the portion of code that I think the problem is in. More specifically the 'def convert_freq_to_bytes(real_freq) part.

•    def convert_bytes_to_freq(bytes):
  

•       real_freq = 0
  

•       for byte in bytes:
  

•           real_freq = (real_freq * 10) + byte
  

•       return real_freq / 100000.0
  

•    def convert_freq_to_bytes(real_freq):
  

•        bytes = [ 0 for x in range(0,8) ]   # init list with 8
  

times 0

...

•        real_freq = int(freq * 100000)      # it has to be integer
  

                           ^^^^

Don't you mean "real_freq" here, not "freq"?

73,

Andrew _______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers