Project

General

Profile

Actions

Bug #10455

closed

1st row does not populate when cloning from radio

Added by Wesley Shimizu about 1 year ago. Updated 11 months ago.

Status:
Closed
Priority:
Normal
Category:
-
Target version:
Start date:
03/17/2023
Due date:
% Done:

100%

Estimated time:
Chirp Version:
next
Model affected:
Wouxon UV8D Plus
Platform:
Windows
I read the instructions above:

Description

March 17, 2023

What is the behavior you are seeing?
When cloning the first row is numbered !1 and no data populated in the balance of the fields.

What is the behavior you were expecting?
No. Channel 1 showed no data.

Can you reproduce the problem all the time?
Yes with the Next and Legacy.

What are the steps required to reproduce the problem?
Clone from radio.

Is this specific to a certain radio model (driver) or something that you can reproduce with another radio?
Wouxon UV8D Plus. Only Wouxon I own.

Note: OEM software does not allow me to pick a com port so I cannot use it. Software issue?

It used to work with my Beelink computer.
RT systems software works.

Computer is a Evolve III, Windows 10Pro.
RT systems USB-K4Y and XLT Painless Programming Cable FTDI USB cables used. Both connected to the radio with Chirp.

Wesley Shimizu
KN6RHV@gmail.com


Files

CHIRP Issues Wouxon UV8D Plus.txt (891 Bytes) CHIRP Issues Wouxon UV8D Plus.txt Wesley Shimizu, 03/17/2023 07:20 PM
Wouxun_KG-UV8D Plus_20230317.img (32.2 KB) Wouxun_KG-UV8D Plus_20230317.img IMG file Wesley Shimizu, 04/13/2023 09:37 PM
UV8D Plus RT Systems Row 1.xlsx (9.11 KB) UV8D Plus RT Systems Row 1.xlsx RT system Row 1 Wesley Shimizu, 04/13/2023 09:41 PM
clipboard-202304140858-ulwvs.png (109 KB) clipboard-202304140858-ulwvs.png mems after updating the DCS decoding to be like the UV8H Mel Terechenok, 04/14/2023 05:58 AM
clipboard-202304140859-gha13.png (29 KB) clipboard-202304140859-gha13.png Mel Terechenok, 04/14/2023 05:59 AM
clipboard-202304140900-rwhut.png (33.5 KB) clipboard-202304140900-rwhut.png Mel Terechenok, 04/14/2023 06:00 AM
kguv8dplus.py (41.7 KB) kguv8dplus.py 8D Plus DCS decoding Read/Write + UHF lower Limit Change Mel Terechenok, 06/05/2023 04:40 PM

Related issues

Related to Bug #6763: KG-UV8D Plus does not parse DCS entriesClosed05/01/2019

Actions
Actions #1

Updated by Dan Smith about 1 year ago

Please attach a .img of your radio for examination.

Actions #2

Updated by Mel Terechenok about 1 year ago

Looking at the debug log, I suspect the driver is not detecting DCS codes properly.
For memory 1, a code of 1644.3 would likely be 0x403B in the radio. This is likely supposed to be DCS code D073. This would be consistent with the KG-UV8H and KG-935G encoding. We need the img and the tone the radio shows to determine the correct encoding scheme for DCS and polarity.

Actions #4

Updated by Mel Terechenok about 1 year ago

in the posted img.... Memory 1 opens just fine in both Chirp-Next and Legacy with a DCS of D073N.

However memories 95, 96, 100, 102, 104, 106, 108 show Errors due to tone decoding.
Using the UV-8H/935G DCS decoding algo, all the tones are decoded correctly except Memory 1.

It seems like Memory 1 has different encoding for the tone than all the other memories.

Was memory 1 updated via chirp before the image was saved?
Was the browser feature or some other direct memory edit of the tone used for Mem 1?
With this image written to the radio, does the radio display the correct D073N tone for mem 1?

I can patch the driver to what I think the correct decoding is, but I can't explain the different encoding for Mem 1 vs the remaining mems.

these pics are after patching the DCS decoding to match what I think it is.


mems after updating the DCS decoding to be like the UV8H

Actions #5

Updated by Mel Terechenok about 1 year ago

  • File kguv8dplus.py added

Try this driver --- Change Tones on the radio and download from Radio to confirm Chirp accepts it correctly.

If that works, the same update can be made to enable proper writing of tones from Chirp to the radio.

How to Load test drivers

Actions #6

Updated by Mel Terechenok 12 months ago

  • Assignee set to Mel Terechenok
  • % Done changed from 0 to 50
Actions #7

Updated by Mel Terechenok 12 months ago

  • Target version set to chirp-py3
Actions #8

Updated by Mel Terechenok 12 months ago

Wesley - have you been able to test the updated driver and confirm whether or not it properly reads the TONE values programmed in the radio now?

Feedback is appreciated.

Actions #9

Updated by Wesley Shimizu 12 months ago

I just tried to add a new repeater into the database, same issue. 20230515.
Wes

Actions #10

Updated by Mel Terechenok 12 months ago

Wesley,

What I want to know is when you use the test driver ... if you change the DCS tone in a memory channel directly on the radio and then do a read from Chirp, does Chirp display the correct DCS tone.

I have not implemented the fix yet for changing a tone in Chirp and writing it to the radio.

I want to confirm that I have the correct decoding of tone values before making more changes.

Actions #11

Updated by Mel Terechenok 11 months ago

  • Related to Bug #6763: KG-UV8D Plus does not parse DCS entries added
Actions #12

Updated by Mel Terechenok 11 months ago

Updated Driver to support Read/Write of DCS tones
Updated UHF Lower Limit to support some radios that come with 350MHz as lower limit

How to load test drivers ISSUE #10455

Actions #13

Updated by Mel Terechenok 11 months ago

  • File deleted (kguv8dplus.py)
Actions #14

Updated by Mel Terechenok 11 months ago

  • Status changed from New to Closed
  • % Done changed from 50 to 100
Actions

Also available in: Atom PDF