[chirp_devel] VX2r progress
Hi everyone,
I have found the location of the start of the memories (0x17c5) and the size of each record (0x12 bytes). I am picking apart the bits for tones, power level, etc.
There is a bug in the VX7 code that constructs the memory name string.
Around line 161
for i in _mem.name: if i == "\xFF": break mem.name += CHARSET[i] mem.name = mem.name.rstrip()
In the loop, i is a byte. "\xFF" is a character. Looking for a byte value this way doesn't work. It is correct in other code (the VX3 code, for example):
if i == 0xFF:
The VX7 code will appear to work, since a series of 0xFF bytes are mapped to a series of 0x00 bytes by the character lookup. These bytes are then removed by the rstrip() function.
In the VX2 code I still haven't looked for (or found) the checksum. I commented out the check, so all I have right now is the following:
Read data from VX2r My home-made USB->VX2r interface is working with a transistor buffer on the FTDI Tx line.
Save .img file without verifying checksum This is useful as I can view it with a hex editor
Display some channels I can parse the frequency and name, and I think repeater offset is correct too. Some other fields are parsed, but I haven't verified their correctness.
So, progress is slow, but it's taking shape.
I also edited line 518 in mainapp.py as originally the dialog box title was "Discard changes?" but the dialog box contents said "Save changes?". I experienced cognitive dissonance every time it appeared, so I fixed it. Please fix it in the main code (it's not worth a patch...)
73,
Andrew ZL3AME
Hmm. The main code needs a lot more comments.
What is 'required_step' and 'fix_rounded_step' in chirp_common?
In the VX2r we are allowed a step size of 9, which is not accounted for in these routines. I have declared it in STEPS in vx2r.py, but this is not used by chirp_common.py or passed as a parameter. So chirp barfs on 1.458 MHz, which is an AM station in one of my memories.
Whilst I'm at it, the memory name is limited to 6 characters, which is recorded in rf.valid_name_length = 6, but then hard-coded in various other places.
The good thing is I am now reading my VX2r manual very carefully and finding out about the cool things it can do... and then wondering how to implement them in chirp.
73,
A
Hmm. The main code needs a lot more comments.
Hmm. I disagree :)
What is 'required_step' and 'fix_rounded_step' in chirp_common?
If you look at the two, required_step() is clearly returning the step frequency required to hit the supplied frequency. Some radios do not store the entire frequency because the sub-kHz amount can be implied. The fix_rounded_step() attempts to determine that implied value and return the actual frequency.
In the VX2r we are allowed a step size of 9, which is not accounted for in these routines. I have declared it in STEPS in vx2r.py, but this is not used by chirp_common.py or passed as a parameter. So chirp barfs on 1.458 MHz, which is an AM station in one of my memories.
Yep, as it will for any of the radios. It's just never been something I cared about, which is bad and lazy. Feel free to fix :)
Whilst I'm at it, the memory name is limited to 6 characters, which is recorded in rf.valid_name_length = 6, but then hard-coded in various other places.
Where is that? I use all 16 characters on my VX8 without any trouble.
On Tue, March 27, 2012 23:18, Dan Smith wrote:
Hmm. The main code needs a lot more comments.
Hmm. I disagree :)
Well, as long as you don't mind a bunch of dumb questions from me that's fine. :)
What is 'required_step' and 'fix_rounded_step' in chirp_common?
If you look at the two, required_step() is clearly returning the step frequency required to hit the supplied frequency. Some radios do not store the entire frequency because the sub-kHz amount can be implied. The fix_rounded_step() attempts to determine that implied value and return the actual frequency.
In the VX2r we are allowed a step size of 9, which is not accounted for in these routines. I have declared it in STEPS in vx2r.py, but this is not used by chirp_common.py or passed as a parameter. So chirp barfs on 1.458 MHz, which is an AM station in one of my memories.
Yep, as it will for any of the radios. It's just never been something I cared about, which is bad and lazy. Feel free to fix :)
Ok. I'll probably have to. Also, STEPS is not passed back to the GUI, so if you edit a channel you can see the default range of steps, not the actual allowed reange of steps for this radio.
Whilst I'm at it, the memory name is limited to 6 characters, which is recorded in rf.valid_name_length = 6, but then hard-coded in various other places.
Where is that? I use all 16 characters on my VX8 without any trouble.
Sorry, I meant in the radio-specific source. For example, in set_memory, the length of the name is hard-coded, and I had to change it to 6. If it used a constant from elsewhere, such as rf.valid_name_length then it would always be consistent.
Also, I'm not happy with the loop that converts the data to the name in get_memory. It's possible the loop will never terminate, since there is no guarantee there will be an 0xFF byte present. Instead I will make it loop over rf.valid_name_length bytes (and terminate early if 0xFF is found).
My next task is to make a whole bunch of memories on the radio that differ by only one option setting, then dump the data and see what bits have changed. Then I can define them and unpack them properly.
73,
A
Also, I'm not happy with the loop that converts the data to the name in get_memory. It's possible the loop will never terminate, since there is no guarantee there will be an 0xFF byte present. Instead I will make it loop over rf.valid_name_length bytes (and terminate early if 0xFF is found).
No, because mem.name is bounded in length, so it will end before it runs over.
My next task is to make a whole bunch of memories on the radio that differ by only one option setting, then dump the data and see what bits have changed. Then I can define them and unpack them properly.
Yep, welcome to the party :) Be sure to enable the developer features which provide the graphical diffing of two memories, which is handy. Also, note that several of us hang out on #chirp on FreeNode during the US day.
Good luck!
On Wed, March 28, 2012 12:24, Dan Smith wrote:
Also, I'm not happy with the loop that converts the data to the name in get_memory. It's possible the loop will never terminate, since there is no guarantee there will be an 0xFF byte present. Instead I will make it loop over rf.valid_name_length bytes (and terminate early if 0xFF is found).
No, because mem.name is bounded in length, so it will end before it runs over.
...is the right answer. I see that now.
My next task is to make a whole bunch of memories on the radio that differ by only one option setting, then dump the data and see what bits have changed. Then I can define them and unpack them properly.
Yep, welcome to the party :) Be sure to enable the developer features which provide the graphical diffing of two memories, which is handy. Also, note that several of us hang out on #chirp on FreeNode during the US day.
Thanks. I turned on the developer functions in the Help menu, but when I select View|Developer|Show raw memory, nothing happens. No message in the console either. Should I see a new window, or new columns in the main window? Diff raw memories does nothing either.
I am using CHIRP 0.1.12 with GTK 2.12.12 and PyGTK 2.12.1 under Linux 2.6.27and KDE 3.5.
I am in South Korea. During the US day I am either asleep, or at work. I'll try to do what I can alone, and use this email list when I am stuck.
73,
A
Thanks. I turned on the developer functions in the Help menu, but when I select View|Developer|Show raw memory, nothing happens. No message in the console either. Should I see a new window, or new columns in the main window? Diff raw memories does nothing either.
Best to right-click on memories in the editor, but if you select one or two, then run show or diff raw and you'll get a new window showing the output.
On Wed, March 28, 2012 13:35, Dan Smith wrote:
Thanks. I turned on the developer functions in the Help menu, but when I select View|Developer|Show raw memory, nothing happens. No message in the console either. Should I see a new window, or new columns in the main window? Diff raw memories does nothing either.
Best to right-click on memories in the editor, but if you select one or two, then run show or diff raw and you'll get a new window showing the output.
Got it. Thanks.
73!
for i in _mem.name: if i == "\xFF": break mem.name += CHARSET[i] mem.name = mem.name.rstrip()
This is likely holdover from the previous method of implementation.
I also edited line 518 in mainapp.py as originally the dialog box title was "Discard changes?" but the dialog box contents said "Save changes?". I experienced cognitive dissonance every time it appeared, so I fixed it.
I disagree that it's not "worth a patch" but I just fixed/pushed.
On Tue, March 27, 2012 23:13, Dan Smith wrote:
for i in _mem.name: if i == "\xFF": break mem.name += CHARSET[i]
mem.name =
mem.name.rstrip()
This is likely holdover from the previous method of implementation.
Ok, well it's correct in vx3.py but wrong in vx7.py. I don't know which came first.
I also edited line 518 in mainapp.py as originally the dialog box title was "Discard changes?" but the dialog box contents said "Save changes?". I experienced cognitive dissonance every time it appeared, so I fixed it.
I disagree that it's not "worth a patch" but I just fixed/pushed.
Thank you!
73
A
participants (2)
-
Andrew Errington -
Dan Smith