Project

General

Profile

Actions

Bug #7799

closed

TYT-9800 Plus Quad Band No Settings Options. Only a blank area

Added by Ray Torella over 4 years ago. Updated about 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
04/13/2020
Due date:
% Done:

100%

Estimated time:
Chirp Version:
daily
Model affected:
TYT-9800 Plus Quad Band
Platform:
All
Debug Log:
I read the instructions above:

Description

TYT-9800 All settings & options available with factory software. Programmed and saved. Imported TYT-9800 into CHIRP latest version. All channels, freqs, tones, power etc correct. When I click on settings tab, empty space with no radio options. See attached photos.

Performed full factory reset and imported into CHIRP with same situation, no radio setting options. Again, factory software works 100%. However, without CHIRP options, I have no way to verify CHIRP has not modified options


Files

Annotation 2020-04-13 112953.jpg (12.1 KB) Annotation 2020-04-13 112953.jpg Ray Torella, 04/13/2020 11:35 AM
Annotation 2020-04-13 113050.jpg (144 KB) Annotation 2020-04-13 113050.jpg Ray Torella, 04/13/2020 11:35 AM
Annotation 2020-04-13 113141.jpg (46.7 KB) Annotation 2020-04-13 113141.jpg Ray Torella, 04/13/2020 11:35 AM
TYT_TH-9800_20211008.img (63.9 KB) TYT_TH-9800_20211008.img CHIRP Image File Richard Frye, 10/08/2021 08:03 AM
debug.log (38 KB) debug.log Debug Log Richard Frye, 10/08/2021 08:03 AM
debug.log (449 KB) debug.log debug.log Richard Frye, 10/10/2021 09:59 PM
TYT_TH-9800_20211008 with date.img (63.9 KB) TYT_TH-9800_20211008 with date.img Jim Unroe, 10/11/2021 01:23 PM
debug.log (447 KB) debug.log debug.log Richard Frye, 10/11/2021 02:49 PM
debug.log (447 KB) debug.log debug.log Richard Frye, 10/11/2021 05:23 PM
1_open_image.png (54.2 KB) 1_open_image.png step 1 Richard Frye, 10/11/2021 05:23 PM
2_upload_image.png (9.56 KB) 2_upload_image.png step 2 Richard Frye, 10/11/2021 05:23 PM
3_download_from_radio.png (9.62 KB) 3_download_from_radio.png step 3 Richard Frye, 10/11/2021 05:23 PM
4_settings_tab.png (17.7 KB) 4_settings_tab.png step 4 Richard Frye, 10/11/2021 05:23 PM
th9800_draft_fix_1.py (27.6 KB) th9800_draft_fix_1.py Jim Unroe, 10/11/2021 06:49 PM
driver_draft_download.png (52.2 KB) driver_draft_download.png screen shot Richard Frye, 10/11/2021 08:29 PM
debug.log (37.1 KB) debug.log Debug Log Richard Frye, 10/11/2021 08:29 PM

Related issues 1 (1 open0 closed)

Related to Bug #8209: TYT TH-9800 Plus No Setting Options After Factory Code Entered On Radio For Expanded Trans FreqsNew08/26/2020

Actions
Actions #1

Updated by Bernhard Hailer about 4 years ago

  • Status changed from New to Feedback
  • Assignee deleted (Ray Torella)

An empty settings page is usually caused by an out-of-range parameter in the radio.
Do you remember what you changed last? Try to restore it.

Actions #2

Updated by Ray Torella about 4 years ago

The TYT-9800 now comes with Ham 2m & 70cm locked down. Everything works with CHIRP while locked. They include a password to open freqs with their software. You import radio, click on freq tab and it will ask for password. Once entered, it opens radio to freqs like Mars Murs mod. All options still available with factory software at that point. Import into CHRIP and all settings and options tabs are on right but each tab field only white background. I saved the original radio image before doing password MURS MARS. After reloading ham only image to radio, then import into CHIRP, all option and settings are available to select and save to radio. Problem is the factory software is clunky and I want to have MURS MARS available in an emergency. But without seeing the actual settings in CHIRP when returned to ham bands only creates possibility that CHIRP could change any-all settings in radio.

Actions #3

Updated by Richard Frye about 3 years ago

I managed to debug the download part of the driver for the radio. The issue is that when you unlock the radio, the "Last Program Date" is blank. This causes bugs in chirp. I tried setting it in the official TYT software but it does not update the date. When I tried to update via chirp, it does not update correctly either but everything else appears to be working. Someone with more knowledge about reading the data from the radio will need to figure out how to fix the date setting. Once that works everything will show up in the settings menu.

Actions #4

Updated by Jim Unroe about 3 years ago

Richard Frye wrote:

The issue is that when you unlock the radio, the "Last Program Date" is blank.

This may well be the "out-of-range" parameter. Including the problem CHIRP Radio Images (*.img) file and a debug.log file would be useful.

Jim KC9HI

Updated by Richard Frye about 3 years ago

The image file and debug file are attached. I pulled the source code down on a linux box and was able to figure out the progdate on line 543/544 is trying to create a date from _info.prog_mon, _info.prog_day and _info_prog_yr. Then that variable is sent to RadioSettingValueString(0, 10, progdate). The problem is those values are either bad or empty. Also, I added some code to set those values to todays date which allowed the settings to load. When I uploaded the image, everything was set except the date. It could be the date address has moved? The regular TYT software just shows blank. If you look at the image file for CHIRP, the Browser shows weird info settings. The info element shows the mon, day but they do not show up when you expand the tree.

Let me know if you need more info. I would love to get this resolved. This program is great.

Actions #6

Updated by Jim Unroe about 3 years ago

Your radio has the S/N, Model and Code in the correct location. I would think that the year, month and day data is just missing (or incorrect in the case of the year). When uploading, CHIRP is supposed to write the current Year, Month, Day to the radio. So are you saying that if you upload to the radio and then immediately download from the radio, the Year, Month, Day data does not became populated as it is supposed to? If not, provide a debug.log file that was obtained after and upload was attempted.

Jim KC9HI

Actions #7

Updated by Richard Frye about 3 years ago

The debug.log is from a download, upload and download of the image. The date does not get written to the radio from chirp or from the factory software.

Actions #8

Updated by Jim Unroe about 3 years ago

CHIRP is generating an error dealing with the invalid date and I don't think it is getting a chance to add the current date. I have attached you image with a valid date. Upload that to your radio to see if the current date gets written to it or not. A debug.log file like you provided before would be appreciated.

Jim KC9HI

Actions #9

Updated by Richard Frye about 3 years ago

I have attached the debug log. I uploaded the image. Then downloaded the image and the settings windows is still empty. If I fake the date via code the settings window shows up. Since the unlock of the additional frequencies, could the memory address of the date changed?

Actions #10

Updated by Jim Unroe about 3 years ago

Richard Frye wrote:

I have attached the debug log. I uploaded the image. Then downloaded the image and the settings windows is still empty. If I fake the date via code the settings window shows up. Since the unlock of the additional frequencies, could the memory address of the date changed?

But after you loaded the image I provided, the Settings tabs showed, right? It was after the download from the radio that the Settings stopped showing.

Jim KC9HI

Actions #11

Updated by Jim Unroe about 3 years ago

After you load my file with the fixed date...
1 verify that the Settings tabs show.
2 upload that tab to the radio.
3 download from the radio
4 check to see if the Settings tabs show or not.
5 attach that image to this issue

Thanks,
Jim KC9HI

Actions #13

Updated by Richard Frye about 3 years ago

The steps were taken and the files were uploaded

Actions #14

Updated by Jim Unroe about 3 years ago

OK. I think I have figured why the date isn't being updated. The upload memory range is shorter than the download range so it is finished before it gets to that area of memory.

Jim KC9HI

Actions #15

Updated by Richard Frye about 3 years ago

Is this going to be an easy fix? Thanks for looking into this issue. This is a big deal for a lot of people

Actions #16

Updated by Jim Unroe about 3 years ago

Richard, Do you know how to load and run test Driver Modules?

Actions #17

Updated by Richard Frye about 3 years ago

I have the source code down and can run it. I have not tried to run any tests but I can figure it out.

Actions #18

Updated by Jim Unroe about 3 years ago

OK. I don't think I can fix the problem with the driver not writing the current date to the radio. Not having a radio in my physical possession or serial captures of a download and upload make me nervous about the prospect.

Anyway, the attached draft driver module, checks for a valid date in the Settings tab. If an invalid date is present "Invalid" is shown in the debug.log and in the Settings tab.

To use it, first save the draft driver module to a convenient location. Do not right-click and choose download. You must left-click and then choose "download" on the next page that loads.

Next access Help in the menu bar and enable "Enable Developer Settings". This will add and additional choice in the File menu called "Load Module"

Use File -> Load Module to load the draft driver module into CHIRP. The background will turn red to let you know that CHIRP is running with an external driver module loaded.

At this point, if all goes well, CHIRP should be able to download from your radio, display the Settings tabs and upload back to your radio. I just won't update like it says it does (but it never has).

Note: This draft driver module does not make any permanent changes to your CHIRP installation. Once you close CHIRP, you must load this draft driver module again prior to loading a file or downloading from a radio with an invalid date.

Let me know how it goes.

Jim KC9HI

Actions #20

Updated by Jim Unroe about 3 years ago

  • Status changed from Feedback to In Progress
  • Assignee set to Jim Unroe
  • Platform changed from Windows to All

I finally got some time to work on creating a formal patch to submit.

Jim KC9HI

Actions #21

Updated by Jim Unroe about 3 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100

Patches submitted. Support will be in the next CHIRP daily build following acceptance.

Jim KC9HI

Actions #22

Updated by Richard Frye about 3 years ago

Thank you very much for all your help Jim.

Actions #23

Updated by Anonymous about 3 years ago

  • Status changed from Resolved to Closed

Applied in changeset commit:8733513617f7.

Actions

Also available in: Atom PDF