Bug #39
closedError Exporting to .csv from VX-8R
0%
Description
I'm sorry if this is not a 'bug'. That was the best fit for tracking.
I have a new (to me) used VX-8R. I have downloaded the memory contents from the radio using Chirp, and everything looks good in the Chirp display.
I am trying to export the resulting Chirp data to radio.csv. Immediately as the program is "Preparing memory list...", I receive an error, "There was an error during export: Unable to correct rounded frequency 451.724000."
The frequency given in the error message is not one of the memory frequencies that I can see, not even close. From the sorted memory list, the nearest frequencies are 460.200000 and 413.887500.
Do you have any suggestions for a solution or debugging?
My system details for reference:
OS is M$ VISTA 64-bit Home Premium, up to date
CHIRP is v0.1.12
Thanks for your time and consideration.
Steve
Files
Updated by Dan Smith about 13 years ago
Sounds buggy to me :)
Please attach your .img file and your debug.log and I'll have a look.
Thanks!
Updated by Steve Redmond about 13 years ago
- File radio_111212a.img radio_111212a.img added
Thanks for the reply.
Attached is the radio.img file.
Where can I find the debug.log file? (It's not in C:\Program Files (x86)\CHIRP\ , nor in C:\Users...\AppData\Roaming\CHIRP\ with the chirp.config file.) Do I need to set a switch to emit debug.log files?
Steve
Updated by Dan Smith about 13 years ago
Hi Steve,
What is the frequency that is supposed to be in channel number 39?
It looks to be 451.724, which shouldn't be supported by the radio, as I understand it.
Thanks!
Updated by Steve Redmond about 13 years ago
Dan:
Thanks for taking a look at this.
Ahha! I didn't notice until you asked about channel #39, but Chrip doesn't display that row in the tabulated data! That's why I didn't see that frequency occuring.
Anyway, the radio is already programmed in memory, with channel #39 at 451.724 MHz, as I received it used from the previous owner.
The radio does display this frequency! This frequency is within the specified range of coverage of the radio (Rx only). However, when I tune the VFO near it, using the knob or up/down arrow keys, I can only reach 451.720 and 451.725 MHz, i.e., 5 kHz steps, consistent with the minimum channel step specification. Also, I cannot tune the VFO to 451.724 by direct keyboard entry. It balks at the '4' and will only take '0' or '5', consistent with the 5kHz steps. P.S. My tuning step size was set to 5 kHz. When I set steps to 'Auto', the entry 451.72 auto completes as 451.725, and the step size at that frequency is 12.5 kHz (shows 12/13 rounded).
I recently had a brief exchange with the previous owner, and he mentioned that he used a G4HFQ program (FTBVX8 I assume) to manage the memories. Perhaps that program allows this frequency setting. I have't tried it. I'm not sure what frequency the radio actually tunes, despite the display value. I doubt I can check that accurately (i.e., is it capable of 'in between step' tuning, at 451.724 MHz?).
I will try to delete this channel setting in memory, and rerun Chirp without the (alleged) bogus value. I don't need it, afaik. I'll get back to you on how that goes.
With sincere respect for your limited development time and need to prioritize; there appear to be some opportunities to tweak Chirp, to be more informative and robust under the circumstances. E.G., Beginner's help warning this sort of mishap could occur (weak), notification of 'bad' frequency value after cloning download (fair), show the data received but flag it 'bad' and ignore it (better), skip a 'bad' value on export and cloning upload and keep on chugging (good with former flag), maybe force a round-off to the nearest 'good' value (could be troublesome ass-u-me-ing right value), etc.
Thanks again for taking a look at this. I will keep watching Chirp with interest and experiment the best I can on my VX-8R.
Steve
Updated by Dan Smith about 13 years ago
- Status changed from New to Closed
Hi Steve,
Yeah, I don't think 451.724 is valid for the radio at all. Yaesu radios are very un-picky about what you put into their memories, to the point of letting you write things that will lock their CPUs up. Icom (and other brands) do a lot more sanity-checking.
I pushed a change in today (which will be in tomorrow's daily build) that fixes the missing row issue for broken memories. This will allow you to delete such a memory (or correct it) in the future.
I certainly understand the points about robustification, and they're all correct, of course. With respect to the last one, I've found that if the bug doesn't stop the activity, the user will ignore it and never report it, which means it never gets fixed.
CHIRP is open-source, and patches are of course very welcome :)
I'll mark this as complete now that there's a way for the user to delete the bad memory.
Thanks!
Updated by Steve Redmond about 13 years ago
Dan:
OK!.
I changed the 451.724 to 451.725 and everything proceeded AOK; .img->.csv+changes->.img. (I couldn't remove that memory, but I don't know the radio well enough yet!)
Now I will get busy and make a pile of new/replacement memory entries suited to my locale, in Chirp, and upload them to the radio.
Your proposed change seems OK. We'll see the bad data and be better able to make sense of the error message that started me off on this Bug Report. !! Curious that Bug #39 was coincidentally about a bad memory #39 - it would be hard to make it happen on purpose :) I'll pick up the next daily build version.
Thanks for your time and support.
Beyond this, I would like to dabble with Chirp, to the point of being able to manage every button, bell and whistle in the radio that can be touched via the cloning interface. I also have a 'new' used FT-8800R and would do the same for it. I know that is out of your committed scope for Chirp. Perhaps that is ultimately how Chirp or some companion program can harness some extra developer time and evolve, without pulling you too far into the nitty gritty of specific radios. I like open source, have setup Python(x,y), a few extras like PyCairo, wxPython, and I could likely get Pango and your other dependencies going in my environment. I'm limited now to using other peoples' Windows binaries, and don't intend to mount any new M$ developer tools, for $$$ anyway. I do have at least one Linux system but my migration away from the evil empire is slow. I presume that the extra information about radio configuration is in the .img files (or at least in memory when the radio is cloned). If you have mapped that out at all it would be interesting to start exploring the contents. If you're game, perhaps we could start another thread about this.
Thanks again for your time and attention to this bug.
73,
Steve