Project

General

Profile

Actions

Bug #9101

closed

VX-8DR Blank Menu

Added by Jason Hovak over 3 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
06/03/2021
Due date:
% Done:

100%

Estimated time:
Chirp Version:
daily
Model affected:
VX-8DR
Platform:
All
Debug Log:
I read the instructions above:

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

Yaesu_VX-8R_20200509.img (63.9 KB) Yaesu_VX-8R_20200509.img Image Jason Hovak, 06/03/2021 12:38 PM
debug.log (35.7 KB) debug.log Jason Hovak, 06/03/2021 12:38 PM
Yaesu_VX-8DR_20210604.img (63.9 KB) Yaesu_VX-8DR_20210604.img Jason Hovak, 06/04/2021 05:32 AM
debug.log (193 KB) debug.log Jason Hovak, 06/04/2021 05:32 AM
vx8_test.py (60.1 KB) vx8_test.py Jim Unroe, 06/07/2021 12:41 PM
Actions #1

Updated by Jim Unroe over 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

Actions #2

Updated by Jim Unroe over 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

Actions #3

Updated by Jason Hovak over 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

Actions #4

Updated by Jim Unroe over 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...

  1. Open CHIRP

This starts a new debug.log file.

  1. Download from the radio selecting VX-8DR.

This should create a new tab that is labeled "Yaesu VX-8DR: (Untitled)*". Did it?

  1. 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?

  1. Close CHIRP.

  2. Attach the newly saved image file and latest debug.log file to this issue.

Jim KC9HI

Updated by Jason Hovak over 3 years ago

See attached.

Jason
N2SBG

Actions #6

Updated by Jason Hovak over 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

Actions #7

Updated by Jim Unroe over 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

Actions #8

Updated by Jason Hovak over 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

Actions #9

Updated by Jim Unroe over 3 years ago

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

Actions #10

Updated by Jason Hovak over 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

Actions #11

Updated by Jim Unroe over 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

Actions #12

Updated by Jim Unroe over 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

Actions #13

Updated by Jim Unroe over 3 years ago

  • Status changed from Resolved to Closed

Patch accepted. Support will be in the next CHIRP daily build.

Jim KC9HI

Actions

Also available in: Atom PDF