Bug #9101
closedVX-8DR Blank Menu
100%
Description
I'm trying to program a VX-8DR. After downloading the config the setting tab is blank. I can see the memories and banks correctly. I'm running daily-20210520, I've also tried various older dailies. I am able to read and write to the radio via FTBVX8, including the menus. I've included the debug and image files for review.
[2021-06-03 15:36:05,349] chirp.drivers.vx8 - ERROR: Failed to parse settings: Traceback (most recent call last):
File "chirp\drivers\vx8.pyo", line 1322, in get_settings
File "chirp\drivers\vx8.pyo", line 1313, in _get_settings
File "chirp\drivers\vx8.pyo", line 986, in _get_aprs_rx_settings
IndexError: tuple index out of range
Traceback (most recent call last):
File "chirp\ui\settingsedit.pyo", line 219, in _build_ui
Exception: Invalid Radio Settings
Files
Updated by Jim Unroe almost 3 years ago
- Status changed from New to Feedback
Could it be because you downloaded from the radio choosing VX-8R instead of choosing VX-8DR?
Jim KC9HI
Updated by Jim Unroe almost 3 years ago
Yep. If I strip the meta data blob from the end of the image and let CHIRP identify the image as being from a Yaesu VX-8DR, all of the settings tabs show as expected.
Jim KC9HI
Updated by Jason Hovak almost 3 years ago
How do I recover from that? I downloaded a new image and was sure to pick VX-8DR, I have the same issue.
Jason
N2SBG
Updated by Jim Unroe almost 3 years ago
The original debug.log file that you provided indicated that VX-8R was the model that was selected. I don't have a VX-8DR here so I need you to do the following...
- Open CHIRP
This starts a new debug.log file.
- Download from the radio selecting VX-8DR.
This should create a new tab that is labeled "Yaesu VX-8DR: (Untitled)*". Did it?
- Save the new tab to a CHIRP Radio Images (*.img) file.
The suggested file name should be "Yaesu_VX-8DR_yyyymmdd.img" (where "yyyy" is the current year, "mm" is the current month and "dd" is the current day). Is that what it is?
Close CHIRP.
Attach the newly saved image file and latest debug.log file to this issue.
Jim KC9HI
Updated by Jason Hovak almost 3 years ago
- File Yaesu_VX-8DR_20210604.img Yaesu_VX-8DR_20210604.img added
- File debug.log debug.log added
See attached.
Jason
N2SBG
Updated by Jason Hovak almost 3 years ago
Is stripping the meta data blob a possible work around I could use to get me up and running while you review the new debug?
Jason
N2SBG
Updated by Jim Unroe almost 3 years ago
Jason Hovak wrote:
Is stripping the meta data blob a possible work around I could use to get me up and running while you review the new debug?
Jason
N2SBG
No that won't fix it. Your first image has the APRS Transmit -> TX Delay setting set to a value of 500ms which is valid. The last image has the TX Delay set to a value that is out-of-range. Apparently the TX Delay choices between the VX-8R and VX-8DR are not the same.
The current choices that CHIRP accepts are: "100ms", "200ms", "300ms", "400ms", "500ms", "750ms", "1000ms"
The latest image that you attached has a choice that is 2 choices out of range: "100ms", "200ms", "300ms", "400ms", "500ms", "750ms", "1000ms", "out-of-range 1", "out-of-range 2"
So what are the valid choices for APRS Transmit -> TX Delay in the VX-8DR?
And your workaround would be to only set TX Delay setting to any of the first 7 choices until the driver module can be updated to allow the full set of choices.
Jim KC9HI
Updated by Jason Hovak almost 3 years ago
Valid settings are 100ms, 150ms, 200ms, 250ms, 300ms, 400ms, 500ms, 750ms, 1000ms. It looks like 150ms and 250ms are the valuies in question.
Jason
N2SBG
Updated by Jim Unroe almost 3 years ago
- File vx8_test.py vx8_test.py added
Jason Hovak wrote:
Valid settings are 100ms, 150ms, 200ms, 250ms, 300ms, 400ms, 500ms, 750ms, 1000ms. It looks like 150ms and 250ms are the valuies in question.
Jason
N2SBG
Perfect! Just what was needed.
Try the vx8_test.py driver module to see if it works for you. If it works out, I will create and submit a formal patch.
To use this temporary driver module, click Help and then enable the Enable Developer Functions setting. Then click File and use the newly added Load Module option to load the test driver module. The CHIRP background will turn red to indicate that a temporary driver module has been loaded.
Loading a driver module does not permanently change your CHIRP installation in any way. If you close CHIRP, you will have to re-load this temporary driver module again to be able to use the 7th (750ms) and 8th (1000ms) TX Delay choices without causing the Settings tabs to disappear.
Once you are confident that this has fixed the issue, you can just make sure that TX Delay is set to a value of 500ms or less in the radio to avoid needing to load the temporary driver module.
Jim KC9HI
Updated by Jason Hovak almost 3 years ago
That worked. Thanks for the help.
Is it normal for the bulk of the regular settings to not be visible/programable? Most of what is there is for APRS.
Jason
N2SBG
Updated by Jim Unroe almost 3 years ago
Jason Hovak wrote:
That worked. Thanks for the help.
Is it normal for the bulk of the regular settings to not be visible/programable? Most of what is there is for APRS.
Jason
N2SBG
I wouldn't know. I'm not the driver author and I've never owned any Yaesu radios.
A volunteer developer can implement as much or as little of the settings as he/she is willing to spend time reverse engineering.
Jim KC9HI
Updated by Jim Unroe almost 3 years ago
- Status changed from Feedback to Resolved
- Assignee set to Jim Unroe
- Target version set to chirp-legacy
- % Done changed from 0 to 100
- Platform changed from Windows to All
Patch submitted. Support will in the next CHIRP daily build following acceptance.
Jim KC9HI
Updated by Jim Unroe almost 3 years ago
- Status changed from Resolved to Closed
Patch accepted. Support will be in the next CHIRP daily build.
Jim KC9HI