Project

General

Profile

Actions

Bug #11488

closed

UV-K5 Not recognising firmware OSFW-bd90ca3

Added by Gwyn Sullivan 4 months ago. Updated 3 months ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
08/18/2024
Due date:
% Done:

100%

Estimated time:
Chirp Version:
next
Model affected:
Quansheng UV-K5
Platform:
Windows
Debug Log:
I read the instructions above:
Yes

Description

(Describe what you were doing) Downoad/upload to radio

(Describe what you expected to happen) Read/Write to radio

(Describe what actually happened instead) Failed


Files

config.txt (891 Bytes) config.txt Gwyn Sullivan, 08/18/2024 05:55 AM
Quansheng_UV-K5_PMR_2Meters_70cm_MerthyrPonty_SouthWales.img (9.43 KB) Quansheng_UV-K5_PMR_2Meters_70cm_MerthyrPonty_SouthWales.img Gwyn Sullivan, 08/18/2024 05:55 AM
debug_log.txt (18.6 KB) debug_log.txt Gwyn Sullivan, 08/18/2024 05:55 AM
uvk5.py (69.1 KB) uvk5.py Dan Smith, 08/19/2024 02:46 PM
uvk5.py (68.3 KB) uvk5.py Hack to properly download unsupported firmwares Dan Smith, 08/23/2024 08:48 AM
config.txt (1.39 KB) config.txt Neil Sinclair, 08/23/2024 01:44 PM
Quansheng_UV-K5_20240823.img (8.25 KB) Quansheng_UV-K5_20240823.img Neil Sinclair, 08/23/2024 01:44 PM
debug_log.txt (78.4 KB) debug_log.txt Neil Sinclair, 08/23/2024 01:44 PM
uvk5.py (68.5 KB) uvk5.py Potentially dangerous driver to allow OSFW-bd90ca3 uploads Dan Smith, 08/23/2024 03:07 PM
QuanshengUv5_23Aug24_fw_OSFW-bd90ca3.txt (11 KB) QuanshengUv5_23Aug24_fw_OSFW-bd90ca3.txt Neil Sinclair, 08/23/2024 03:48 PM
Screenshot 2024-08-23 at 19.17.33.png (379 KB) Screenshot 2024-08-23 at 19.17.33.png Dan Smith, 08/23/2024 07:18 PM
config.txt (1.57 KB) config.txt Neil Sinclair, 08/24/2024 03:34 AM
Quansheng_UV-K5_20240824_W3.img (8.24 KB) Quansheng_UV-K5_20240824_W3.img Neil Sinclair, 08/24/2024 03:34 AM
debug_log.txt (82.4 KB) debug_log.txt Neil Sinclair, 08/24/2024 03:34 AM
config.txt (1.57 KB) config.txt Neil Sinclair, 08/24/2024 03:38 AM
Quansheng_UV-K5_20240824_W3.img (8.24 KB) Quansheng_UV-K5_20240824_W3.img Neil Sinclair, 08/24/2024 03:38 AM
debug_log.txt (157 KB) debug_log.txt Neil Sinclair, 08/24/2024 03:38 AM
clipboard-202408241139-l7fxg.png (83.4 KB) clipboard-202408241139-l7fxg.png Neil Sinclair, 08/24/2024 03:39 AM
Quansheng2024-08-24_11-40-10.png (77.7 KB) Quansheng2024-08-24_11-40-10.png Neil Sinclair, 08/24/2024 03:40 AM
debugLog_24Aug24_1148.txt (158 KB) debugLog_24Aug24_1148.txt Neil Sinclair, 08/24/2024 03:49 AM
config.txt (1.55 KB) config.txt Andreas Waschefort, 09/11/2024 02:30 AM
Quansheng_UV-K5_20240911.img (8.23 KB) Quansheng_UV-K5_20240911.img Andreas Waschefort, 09/11/2024 02:30 AM
debug_log.txt (76.2 KB) debug_log.txt Andreas Waschefort, 09/11/2024 02:30 AM
config.txt (1.55 KB) config.txt Andreas Waschefort, 09/11/2024 02:59 AM
Quansheng_UV-K5_99_202409011_1.img (8.23 KB) Quansheng_UV-K5_99_202409011_1.img Andreas Waschefort, 09/11/2024 02:59 AM
debug_log.txt (713 KB) debug_log.txt Andreas Waschefort, 09/11/2024 02:59 AM
Menu_Items_QUANGSHENG_UV-K5(99)_OSFW-bd90ca3.txt (2.38 KB) Menu_Items_QUANGSHENG_UV-K5(99)_OSFW-bd90ca3.txt UVK5(99).OSFW-bd90ca3 Sven Jungmar, 09/11/2024 08:01 AM
uvk5.py (68.6 KB) uvk5.py Dan Smith, 09/11/2024 02:42 PM
Quansheng_UV-K5_99_OSFW-bd90ca3_NO_LOCK.img (8.24 KB) Quansheng_UV-K5_99_OSFW-bd90ca3_NO_LOCK.img Andreas Waschefort, 09/27/2024 12:43 PM
Quansheng_UV-K5_99_OSFW-bd90ca3_LOCK.img (8.24 KB) Quansheng_UV-K5_99_OSFW-bd90ca3_LOCK.img Andreas Waschefort, 09/27/2024 12:43 PM
Quansheng_UV-K5_99_OSFW-bd90ca3_LOCK2.img (8.24 KB) Quansheng_UV-K5_99_OSFW-bd90ca3_LOCK2.img Andreas Waschefort, 09/28/2024 12:53 PM
Quansheng_UV-K5_99_OSFW-bd90ca3_NO_LOCK.img (8.24 KB) Quansheng_UV-K5_99_OSFW-bd90ca3_NO_LOCK.img Andreas Waschefort, 09/28/2024 12:53 PM
PCS Screen.jpg (171 KB) PCS Screen.jpg Andreas Waschefort, 09/28/2024 12:53 PM
Quansheng_UV-K5_99_OSFW-bd90ca3_LOCK2.img (8.24 KB) Quansheng_UV-K5_99_OSFW-bd90ca3_LOCK2.img Andreas Waschefort, 09/29/2024 11:35 AM
Quansheng_UV-K5_99_OSFW-bd90ca3_LOCK2_off.img (8.24 KB) Quansheng_UV-K5_99_OSFW-bd90ca3_LOCK2_off.img Andreas Waschefort, 09/29/2024 11:35 AM
uvk5.py (68.7 KB) uvk5.py Dan Smith, 09/29/2024 11:46 AM
uvk5.py (68.9 KB) uvk5.py Dan Smith, 10/01/2024 03:33 PM

Related issues 4 (0 open4 closed)

Related to Bug #11570: After Upload show LOCKRejected09/26/2024

Actions
Has duplicate New Model #11410: UV-K5(99) "Firmware 'OSFW-bd90ca3' not supported" ErrorRejected06/29/2024

Actions
Has duplicate Bug #11423: Quansheng UV-K59(99) Firmware not supportedRejected07/08/2024

Actions
Has duplicate Bug #11521: Porgramming not possibleRejected09/04/2024

Actions
Actions #2

Updated by Dan Smith 4 months ago

Where did the image come from that you attached here? It doesn't have firmware info in it, so I assume you downloaded it from another radio and with a much older version of chirp?

Actions #3

Updated by Gwyn Sullivan 4 months ago

Image was from fb group but u only used ot to copy details to export to excel so I could edit img downloaded from radio but I can't download from it due to firmware issue.Regards Gwyn Sullivan.
-------- Original message --------From: Dan Smith redmine@chirpmyradio.com Date: 18/08/2024 17:38 (GMT+00:00) To: gwyn_sullivan@talktalk.net Subject: [CHIRP - Bug #11488] Not recognising firmware OSFW-bd90ca3

Actions #4

Updated by Dan Smith 4 months ago

Okay, well, your radio has a non-OEM firmware in it, which may have any amount of differences in it causing problems with the chirp implementation. You can see this comment for how to restore it to OEM firmware:

https://www.chirpmyradio.com/issues/11483#note-6

If you purchased it like this, I'd recommend you complain to your vendor.

Actions #5

Updated by Dan Smith 4 months ago

Please use the attached test driver to capture an image of your radio using the LoadingTestModules instructions. Do not attempt to upload, please just download (assuming it will let you) and update this bug using Help->Report or update a bug to send the image and debug log.

Actions #6

Updated by Neil Sinclair 4 months ago

Received a KV-U6 today, fresh from the factory.

Same issue - latest version of CHIRP (20240821), firmware version OSFW-bd90ca3, no alterations from my end. (Actually, I want to modify - that's why I got the radio - but I've not done anything at all.)

Should I send it back? Seems an odd coincidence that two unconnected users have the same issue of a non-OEM firmware installed. I'd rather send it back than follow @DanSmith's link, partly because I can't download the originals from the radio since it won't connect.

Perfectly happy to send it back - I owe AliExpress nothing - but I'll hang on to it if there's a likely fix coming soon. It's a nice wee radio!

p.s. my Baofeng UK-17 Pro GPS works fine with CHIRP.

Actions #7

Updated by Dan Smith 4 months ago

Same issue - latest version of CHIRP (20240821), firmware version OSFW-bd90ca3, no alterations from my end. (Actually, I want to modify - that's why I got the radio - but I've not done anything at all.)

The current version of chirp contains a change that (attempts to) let it download from any firmware read-only so we can examine images. If you're really using the latest and this didn't work, please capture a debug log of the attempt and submit it here so I can see (use Help->Report or update a bug).

Should I send it back? Seems an odd coincidence that two unconnected users have the same issue of a non-OEM firmware installed. I'd rather send it back than follow @DanSmith's link, partly because I can't download the originals from the radio since it won't connect.

Perfectly happy to send it back - I owe AliExpress nothing - but I'll hang on to it if there's a likely fix coming soon. It's a nice wee radio!

What's going on is there's an AliExpress seller that is sending these radios out without OEM firmware on them. If that's what you want, then cool, but if you wanted an OEM Quansheng then you might want to send it back (and tell them why). Who knows what else they're doing to them.

CHIRP may grow support for the whatever firmware variant this is at some point (likely in a limited way), but it's hard to tell.

Actions #8

Updated by Neil Sinclair 4 months ago

This is the output from my xfce terminal on terminating chirp:

ERROR: Failed to clone: Firmware version is not supported by this driver
Traceback (most recent call last):
  File "/home/neil/.local/pipx/venvs/chirp/lib/python3.11/site-packages/chirp/wxui/clone.py", line 78, in run
    self._fn()
  File "/home/neil/.local/pipx/venvs/chirp/lib/python3.11/site-packages/chirp/drivers/uvk5.py", line 714, in sync_in
    self._mmap = do_download(self)
                 ^^^^^^^^^^^^^^^^^
  File "/home/neil/.local/pipx/venvs/chirp/lib/python3.11/site-packages/chirp/drivers/uvk5.py", line 549, in do_download
    raise errors.RadioError(
chirp.errors.RadioError: Firmware version is not supported by this driver
WARNING: Stopping clone thread
ERROR: Failed to clone: Firmware version is not supported by this driver
Traceback (most recent call last):
  File "/home/neil/.local/pipx/venvs/chirp/lib/python3.11/site-packages/chirp/wxui/clone.py", line 78, in run
    self._fn()
  File "/home/neil/.local/pipx/venvs/chirp/lib/python3.11/site-packages/chirp/drivers/uvk5.py", line 714, in sync_in
    self._mmap = do_download(self)
                 ^^^^^^^^^^^^^^^^^
  File "/home/neil/.local/pipx/venvs/chirp/lib/python3.11/site-packages/chirp/drivers/uvk5.py", line 549, in do_download
    raise errors.RadioError(
chirp.errors.RadioError: Firmware version is not supported by this driver
WARNING: Stopping clone thread

Happy to use command line to investigate further...

Actions #9

Updated by Neil Sinclair 4 months ago

Sorry for the double paste.. :-)

Actions #10

Updated by Dan Smith 4 months ago

Ah, okay I see why that didn't work. Can you try this hack module with LoadingTestModules and see if you can capture an image?

FWIW, I'd prefer if you can use the inbuilt tool to upload the logs and the image. Since you're running from the command line it's not logging like normal, so if you could run with stdin redirected to not-a-tty so it will do the normal thing, I'd appreciate it. Something like this will probably give you the same experience, but with the internal logging:

chirp -vvv < /dev/null 

Updated by Neil Sinclair 4 months ago

[Uploaded from CHIRP next-20240821]

I did a reset on the radio to factory settings.

Then did a 'download from radio' with the module 'uk5.py' activated in CHIRP.

I was then able to download from the radio, as far as I can tell as a normal download.

Hope this helps!

Actions #12

Updated by Neil Sinclair 4 months ago

Not sure if the downloaded settings from the radio were included in the dump - will upload if you need it. All looked well.

I'll not upload anything to the radio until we think the problems are resolved...

Thanks!

Actions #13

Updated by Dan Smith 4 months ago

You won't be able to upload from that hacked driver (intentionally).

The image you captured looks okay to me, in that I don't see any out-of-range (or any other) errors which I would expect from a large deviation. If you're willing to take the (probably pretty small) risk, attached is a driver that blesses that firmware as an OEM version which will allow you to edit and upload. You'll have to download a fresh image first for it to be tagged as un-smelly.

If you are going to try this, please download, make some trivial change, upload to the radio, and update this bug with the integrated tooling like you did earlier so I can look for issues. Then please confirm the radio was happy with it. Any other testing you can do along the edges would be appreciated.

Actions #14

Updated by Neil Sinclair 4 months ago

OK - when I connected the radio to the computer the display on the radio did not come on - to all intents and purposes the radio was dead.

When I removed the cable, the radio display came back on and it seemed to work as normal.

After resetting, the radio display did come on when connected to the computer.

Would a dmesg log help?

Not wanting to risk an upload - seems perilously close to bricking...

Actions #15

Updated by Neil Sinclair 4 months ago

Here's the dmesg file...

I don't think it helps us ...

Actions #16

Updated by Dan Smith 4 months ago

I think what you're seeing is that the radio will go straight into transmit mode if you power it on with the programming cable attached, in certain states of DSR/DTR initialization. It's ridiculous, yes, but remember these are very very low-quality radios.

Unplug it before you power it on, then attach the cable. Sometimes the radio will go straight into transmit mode until something has accessed the cable once, so sometimes trying a download from chirp without the radio attached will reset the cable, then you can attach the radio and proceed.

Either way, you didn't say what you did before you experienced that behavior so I'm not sure what part of the process you're in...

Actions #17

Updated by Dan Smith 4 months ago

There won't be anything in dmesg for something like this. The only thing you'll see there is minor detection information about your USB device. The radio itself is not something the kernel knows anything about. It's just on the other end of the serial pipeline.

Actions #18

Updated by Neil Sinclair 4 months ago

OK - a step-through is called for!

  1. Reset radio
  2. Started CHIRP
  3. Installed your module from this aftnoon (the download only one)
  4. Radio off
  5. Attach cable
  6. Radio on
  7. Download
  8. Radio off
  9. Detach cable 10.Exit CHIRP 11.Radio on - seems fine 12.Radio off 13.Start CHIRP (no module loaded) 14.Start radio 15.Attach cable - display comes on. 16.Radio off. 17.Exit CHIRP

Repeat above - only with cable attached after resetting and before powering up.
Blank screen.

OK, I'm reassured, will try the new module.

Wish me luck!

Actions #19

Updated by Neil Sinclair 4 months ago

OK, followed your procedure at step #13, and all seemed to work smoothly when I attached the cable with the radio powered up.

Thanks!

Actions #20

Updated by Neil Sinclair 4 months ago

I've just uploaded 120 channels to the radio, no error messages.

There's no indication that programming is taking place - nothing on the display, no flashing LED, bu I'll settle for it just working for now!

Curiously, the display changes after the upload completes with a display of battery voltage as 8.6, though when the unit is switched on it shows 7.9V. Probably the cable operating voltage from USB???

Anyway, thanks again.

Actions #21

Updated by Dan Smith 4 months ago

I've just uploaded 120 channels to the radio, no error messages.

You really won't generally see error messages during the upload, assuming it starts. However, again, I'd prefer of you use the tool to upload a full snapshot of the image and debug log after you download..edit..upload so I can be sure.

There's no indication that programming is taking place - nothing on the display, no flashing LED, bu I'll settle for it just working for now!

This is not something CHIRP has control over. Remember, cheap radios :)

Curiously, the display changes after the upload completes with a display of battery voltage as 8.6, though when the unit is switched on it shows 7.9V. Probably the cable operating voltage from USB???

I doubt it, but could be. See above :)

Please do plenty of testing and report back about any weirdness. Definitely want to have some more assurance before I put this into the main build and unleash it on everyone. And please capture the full log for me, as above.

Thanks!

Actions #22

Updated by Neil Sinclair 4 months ago

Oops - spoke too soon.

The radio keeps locking up - by which I mean, it displays 'Lock' when it is switched off then on again.

Thankfully, it will accept an upload from CHIRP, so it's possible to get it back again.

It will reliably start up with only about 18 channels programmed.

However, if I put in a large number of channels, it goes back to locking up.

I guess we've still got some fettling to do...

:-)

Actions #23

Updated by Dan Smith 4 months ago

The image you posted earlier (still haven't seen an updated one with debug log) had "auto key lock" enabled in the settings. I suspect that's your "problem", in that the feature is enabled, so it's auto-locking.

Since the OEMs like to act like these are part-90 type-accepted, sometimes they enable that by default since it's a part-90 requirement that radios not be programmable while in transmit mode and they think the auto key lock is "good enough", which of course, it isn't.

I suspect if you disable that, you'll see that behavior stop.

Updated by Neil Sinclair 4 months ago

[Uploaded from CHIRP next-20240821]

Radio reset
Radio powered on
Uploaded using your revised module
Lock option enabled
Radio still locks up on powering up

Will remore the lock option and re-submit log...

Updated by Neil Sinclair 4 months ago

[Uploaded from CHIRP next-20240821]

Same settings as before, except Keypad lock and Auto keypad lock turned off.

Radio still locked up on power on.

Updated by Neil Sinclair 4 months ago

Updated settings - disabled the lock as suggested.

Unfortunately, the radio still locked up on powering up.

Actions #27

Updated by Neil Sinclair 4 months ago

Latest debug log attached...

Not being sure of your system, I saved the file ending *20240824_W3.img as the attached text file.

Does your system automatically submit the .img file as a log attached to the bug number?

Cheers!

Actions #28

Updated by Dan Smith 4 months ago

  • Subject changed from Not recognising firmware OSFW-bd90ca3 to UV-K5 Not recognising firmware OSFW-bd90ca3

The "report or update" tool uploads the log and the image, so you don't need to upload it after.

Are you 100% positive that it's not locking with 18 memories (or however many) and is with 19+? That also could be some change the vendor has made with this modified firmware, I guess, along the same lines of the part-90 "strategy" I mentioned before. CHIRP has no control over this, it can only flip feature bits (like the key lock, auto lock, etc). It can't control behaviors that are not exposed as feature bits in memory. It would be worth trying whatever software the vendor tells you to use (or just use the keypad to store memories) to see if the radio is keying off of memory count, or the specific memories populated. Some similar radios have silly requirements where memories in certain channel numbers are the only ones allowed to be GMRS frequencies, and are restricted to part-95 requirements (again, an ill-fated attempt to act like they're actually part-95 accepted).

Anyway, as I mentioned at the outset, it's really hard to say what's going on here since you've got a radio that isn't as the OEM intended, so any number of things could be happening. I guess I'll shelve this for now and maybe someone that is more familiar with these can confirm/deny any of this behaviors.

Actions #29

Updated by Neil Sinclair 4 months ago

I did a factory reset, then I programmed in 6 more channels, and the UV6 hasn't locked up.

Total of 23 channels, 18 from factory, 5 from myself.

Reception is really poor on this unit. Stations which come in with minimal background noise on my
Baofeng UV-5R are completely covered in static, even with a 771 on top.

That's a hardware issue, not a firmware one I guess.

So, back to AliExpress it goes.

I'll keep an eye on the forum for updates, and get another UV-6 (or UV-5(8) - how confusing is that!) when it looks like it'll work reliably.

Thanks for all your help - above and beyond in my humble opinion!

Blue Skies.

Neil S

Actions #30

Updated by Andreas Waschefort 4 months ago

Hello , i can not programm frequencies lower then 50 Mhz. ( 10 + 11m)
Chirp shows " not support by radio.
Manual i can programm and use these Bands without problems.

If i manual store an frequenz on device, i can donload it without any
problems to chirp and upload back to device
But no changes in chirp are possible

Actions #31

Updated by Dan Smith 4 months ago

If you're loading the module properly you should be able to download-modify-upload. If you can't please attach a debug log and the image you are getting from the radio using Help->Report or update a bug so I can see.

The <50MHz is a separate issue from the firmware and identification one, so let's discuss that after we confirm that the firmware you have is usable.

Actions #32

Updated by Sven Jungmar 3 months ago

I could download settings from radio with OSFW-bd90ca3. I could also edit and upload back settings and memory channels. However not all settings are correct or availabale in CHIRP. Can I be of help and in that case how?

/Sven

Actions #33

Updated by Dan Smith 3 months ago

Okay that makes sense and is why I'm hesitant to just bless this firmware fork outright. We'll need a slightly different approach then.

Can you do a survey and make a list of all the settings that are wrong (and how)? If we can get the wrong settings identified and fixed then we can merge that into mainline and then potentially work on missing settings (if they are important).

Thanks!

Updated by Andreas Waschefort 3 months ago

[Uploaded from CHIRP next-20240905]

If o load the uk5 module i can download, edit and upload the data
But if i want program any frequency lower then 50 Mhz , the software
show an screen... unsupportet... and i dnt can programm these frequencies

Direct in mobile i can programm all without any problem.

Is it possible to change an existing modul by myself and test it local ?
If yes how i can do ?

Updated by Andreas Waschefort 3 months ago

[Uploaded from CHIRP next-20240905]

I found the issue why i can not programm Frequencies lower then 50 Mhz:

I set in Driver Information > Limits disabled for modified Software

Now it works

Actions #36

Updated by Dan Smith 3 months ago

Right, but that's not the way to solve this. That makes it easier for someone to upload an image with out-of-band-for-OEM frequencies to an unmodified radio. Since your radio does not have standard firmware, we should make chirp treat it differently. CHIRP needs to know this is a modified radio from the start.

Can you confirm that everything seems to work otherwise without issue? If you can help summarize the wrong/missing settings here like I asked @Sven Jungmar that would be helpful. Also, if you can indicate what the actual band limits of the radio are (i.e. what you can enter via the keypad) that would help as well.

Once some of that is defined, I will attach a proper module that treats that firmware as a separate thing with the proper band limits.

Actions #37

Updated by Sven Jungmar 3 months ago

I went through the menu and wrote down all items and it's settings in my radio. The radio is new to me so I'm not sure what all are for but made some comments.
I hope this will be of some help.

/73
SM0LVG, Sven

Actions #38

Updated by Dan Smith 3 months ago

Thanks @Sven Jungmar for that list. I kinda need a little more fine-grained detail (like setting foo has extra option bar). I could go through your map and figure out what the differences are between that and the base driver, but that would be pretty laborious.

Here's an updated driver to try, which treats the OSFW firmware as its own sub-variant with expanded band limits. If we can get a list of things that need to change about the settings it'd be good so we can put those into this sub-variant. If not, just confirmation that this indeed works with the OSFW firmware for at least memory setting would be a good start.

Actions #39

Updated by Andreas Waschefort 3 months ago

Sven Jungmar wrote in #note-37:

I went through the menu and wrote down all items and it's settings in my radio. The radio is new to me so I'm not sure what all are for but made some comments.
I hope this will be of some help.

/73
SM0LVG, Sven

Sven Jungmar wrote in #note-37:

I went through the menu and wrote down all items and it's settings in my radio. The radio is new to me so I'm not sure what all are for but made some comments.
I hope this will be of some help.

/73
SM0LVG, Sven

Hello

@Sven Strümpel Jungmar thanks for Answer.
I check the Frequency i can set : from 10Mhz to 999.999 i can put in direct (only 3 dig in display to programm MHZ in display)
If i higher scan manual , it scan > scan up to 1299.999 but there the device not work good. At 999.999 all work fine
If i manuel scan hig

Actions #40

Updated by Dan Smith 3 months ago

I'm looking for a read on whether or not the module I attached above is working for people. It sounds like there is still some settings work to do, but that should address the band limits. Can someone confirm that this works well, aside from settings stuff so I can include this in a build and we can iterate from here?

Actions #41

Updated by Dan Smith 3 months ago

  • Related to Bug #11570: After Upload show LOCK added
Actions #42

Updated by Dan Smith 3 months ago

@Andreas Waschefort opened new bug #11570 about the module here saying that his keypad appears locked after using this driver. I've closed that to keep the discussion here, but it further concerns me that this driver is still not right.

@Sven Jungmar have you seen this and do you have any information about this behavior?

Actions #43

Updated by Andreas Waschefort 3 months ago

@Daniel Fiechter Smith

After i upload one self made image file to my devide (99) , it restart and only show LOCK in display
can not open the Kock...

If i upload any other file, all will be ok, no Lock.

I dont found the problem, why the device only show LOCK after upload from one special IMG file with chirp and new driver

Yesterday i see another bug ??, but only at one device from my friend
Same version then my devices (99)

If he use the driver from issue 11488 his scrambler work, but we never can understand us.. dont find the right numbers to decode
If he use the driver from issue 10478 his scranbler work fine with all devices.
We will look , what can be the problem. If we find an solution, i will write here.

But i test 11488 scrambler with 4 other (99) devices , all work fine

Actions #44

Updated by Dan Smith 3 months ago

@Andreas Waschefort Can you attach a good and bad (locks the radio) image here? Unfortunately, if there is a lot different there is very little chance I'll be able to find the lock bits, but it's worth a try.

Is the lock controllable from the radio? i.e. if you have an unlocked radio can you lock it yourself?

Updated by Andreas Waschefort 3 months ago

Shure. I attach …

Lock screen and Upload screen
Img file xxxx_LOCK.img = after upload LOCK Screen
Img File xxx_NO_LOCK = File work normal

If Radio Lock, I only can put possible passwort(wich I don’t know) in screen, not more possible.
Only upload another IMG file…

I don’t know how to LOCK the radio manual is possible. Can not test , sorry
Display lock with * work normal without show LOCK

I test it with 4 (99) Radios, all the same.

A little bit confuse thing :
After the first programming from new 2 Radios , first all work fine with LOCK file.
Then I want to retest anything after 7 days, only switch the mobiles on and see only the LOCK screen
From this time I only see LOCK after upload ;-(

Nobody take this radios during this time !

Actions #46

Updated by Andreas Waschefort 3 months ago

Hello Dan

Just i found another bug ?

I load 11488 last driver
download file from mobile

In chirp /Driver information > Limits disable for modified Software , I activate (mark) this setting
save this file to my Notebook. Upload to mobile
Until here is all ok.

Chirp will not close !!!!

but … after load this saved file manual from Notebook to Chirp, this setting is not more mark (deactive) …
Please check, thanks

BTW: to use the normal (99) version frequencies from 26 to 30 MHZ is not realy possible..
The receiver not sensitive enough to get all signals from other Radios. Only short range (300m) is possible.

Actions #47

Updated by Dan Smith 3 months ago

Is there any chance you reversed the two files and the LOCK one is actually unlocked?

Can you try password 3824 to unlock the radio when locked? If that does not work, please try 0000.

Actions #48

Updated by Dan Smith 3 months ago

The "limits disabled" box is not meant to stay checked, so this is not a bug. However, I can make the OSFW version always disabled. However, let's focus on the lock issue first.

Actions #49

Updated by Andreas Waschefort 3 months ago

I just upload the lock file into my radio and the display show LOCK
after upload the no_LOCK the radio is unlock.

Password must have 6 dig, 3824 or 0000 not work

Actions #50

Updated by Andreas Waschefort 3 months ago

No Problem, limits disabled dont must be change.If I know this, is ok.

Actions #51

Updated by Dan Smith 3 months ago

Others to try:

000000
138240
382400

There is a note in the driver code near what appears to be a "password" although it's only four characters and obviously not correct. However, those values do differ between the two images (although the supposedly locked image).

Also, could you try changing the values in the "unlock settings" portion of the settings tab? Note the differences in the values between your two images. Since you have a non-standard firmware, it's possible one of the frequency range boxes for the OEM firmware actually means "killed" for the OSFW one.

Actions #52

Updated by Andreas Waschefort 3 months ago

Hello Dan ,

i just found the LOCK problem in Chirp….

I download the data from unlock radio - There is Backlight auto mode set to 5 (in Chirp Max. setting! Radio can set up to 60 sec !)

Upload file to radio , all work fine . I Look in Radio Menue 16 (ABR) – Show 5 sec , change it in Radio to 20s

Download to chirp . Chirp show at Backlight auto mode now >> OFF <<
In Radio backlight work 20 sec
Now…
I upload this file back to radio

Now the Radio ist LOCK again

Hope this help to solve the Problem. I thing the maximum setting must be up to 60 sec in chirp too.
Then all work fine

Von: Dan Smith redmine@chirpmyradio.com
Gesendet: Freitag, 27. September 2024 23:41
An: a.waschefort@gmx.de
Betreff: [CHIRP - Bug #11488] UV-K5 Not recognising firmware OSFW-bd90ca3

Actions #53

Updated by Andreas Waschefort 3 months ago

Hello Dan

I check your Pincodes… LOCK anyway

I set all settings same then in no lock file, delete all Memorys…Upload… Lock anyway
save this file to …..LOCK2.img

Then… I use the Portable Radio CPS Software version 2023-02-22 07:49:36
Load LOCK file into the software and see that in Common setting > Power on Password is set an PW !!

I delete this PW , upload to Radio and is unlock !!

Then I set Pincode 123456… Lock
Type in Pincode 123456 .unlock !

Then I Delete Code in Software and upload to mobile > Unlock !

Change to chirp 11488
Download with chirp from unlock Mobile >> Mobile unlock

Upload with chirp to Radio > Radio unlock !!!

This setting is the problem. I don’t know why it is only in this one LOCK file.

But after delete the code in CPS software all work fine.

Let me know, when you found the Problem.
Thanks lot

Actions #54

Updated by Andreas Waschefort 3 months ago

Hello Dan ,

i just found the LOCK problem in Chirp….

I download the data from unlock radio - There is Backlight auto mode set to 5 (in Chirp Max. setting! Radio can set up to 60 sec !)

Upload file to radio , all work fine . I Look in Radio Menue 16 (ABR) – Show 5 sec , change it in Radio to 20s

Download to chirp . Chirp show at Backlight auto mode now >> OFF <<
In Radio backlight work 20 sec
Now…
I upload this file back to radio

Now the Radio ist LOCK again

Hope this help to solve the Problem. I thing the maximum setting must be up to 60 sec in chirp too.
Then all work fine

Von: Dan Smith >
Gesendet: Freitag, 27. September 2024 23:41
An: a.waschefort@gmx.de a.waschefort@gmx.de
Betreff: [CHIRP - Bug #11488] UV-K5 Not recognising firmware OSFW-bd90ca3

Actions #55

Updated by Dan Smith 3 months ago

Can you do the following:

  1. Upload an image to the radio that will be locked, and attach that here (or start with your _LOCK image above)
  2. Download with the OEM software, fix the lock/passcode, upload to the radio
  3. Download with chirp and attach the resulting image here

I think the best thing will be if we can find out only what changed between locked and unlocked so I can make sure chirp handles it properly. I will also look at the backlight setting, but unless you change something in a chirp settings tab it should not be affecting the other settings so I'm not quite sure why your procedure matters. However if we can identify what is changing when you unlock with the OEM software, I will see what the relation is to the backlight setting.

Updated by Andreas Waschefort 3 months ago

Shure , Files as attach

Lock2 = locked display

No_Lock = Lock file download from radio to OEM software , delete Passcode, write back (show no lockscreen) ,
download from radio to Chirp and store to xxx

Actions #57

Updated by Dan Smith 3 months ago

Hmm, those files differ by a huge amount, way too much to analyze the difference. The NO_LOCK one has tons of channels set, but the LOCK2 one has almost none, and very many settings are different between them. We really need to capture two images where the only difference is fixing the lock problem so I can see what change causes it to be unlocked.

Updated by Andreas Waschefort 3 months ago

Ok , i do the same check

Lock2 = Radio lock
Lock2_off = same file only delete the pincode

Von: Dan Smith redmine@chirpmyradio.com
Gesendet: Sonntag, 29. September 2024 16:31
An: a.waschefort@gmx.de
Betreff: [CHIRP - Bug #11488] UV-K5 Not recognising firmware OSFW-bd90ca3

Actions #59

Updated by Dan Smith 3 months ago

Okay, there is still a lot changing between the images, I'm not sure why.

However, please test the following module. It will only make changes to the image when you tweak a setting value. So if you try to load an image that is already locked, you need to change some setting (and change it back if you want) in order for it to "clear" the password field. This is just a guess about what is happening, so this may not work, but please try and if it doesn't help I will try a different change.

Actions #60

Updated by Andreas Waschefort 3 months ago

Hello Dan

Just i test the new driver with new chirp version (from today)
Upload an LOCK file to radio (display only show LOCK) , change only language in file and upload the same file again.
Display will unlock and work normal !
Then I change language back to the old setting, upload , and display is unlock anyway.

Thanks for your help.

Von: Dan Smith redmine@chirpmyradio.com
Gesendet: Sonntag, 29. September 2024 20:47
An: a.waschefort@gmx.de
Betreff: [CHIRP - Bug #11488] UV-K5 Not recognising firmware OSFW-bd90ca3

Actions #61

Updated by Dan Smith 3 months ago

Okay, good to hear. What other things need to be fixed before we could get this out in a build? The backlight timer you mentioned is not critical, but easy to fix. Any other major problems?

Actions #62

Updated by Andreas Waschefort 3 months ago

At the moment only know from one confuse thing:

My Friend have problems with the scrambler, If he load the 11488 driver.
We don’t found any settings to phone together with scrambler.
If he use the 10478, his scambler work fine.

It can be his failure < , because I test the scrambler with 4 same radios and 11488 , all work fine.
Will ask him if we can make an test again. Then I contact you if you have interest for this ?? bug ??

What I only know: The language setting (English) will change to Chinese after download from mobile (99)
But it is not urgent, because version 99 don’t support any voice informations from Radio anyway.

My original UV-K5(8) without any driver, support right voice and it will be store right in settings.

Actions #63

Updated by Dan Smith 3 months ago

Okay I don't know what you mean by the "11478 driver".

Either way, perhaps at the moment the best thing would be to just exclude language and scrambler from the settings in the OSFW driver and get it out to other people for more data.

Actions #64

Updated by Andreas Waschefort 3 months ago

Sorry, i meen the newest 11488 driver.

Because the scrambler ... it works fine on all my radios with your driver.
My Friend can do an mistake in his settings... Will give him tomorrow an working img from me to test the scrambler.
I send you the result.

Am 1. Oktober 2024 13:50:26 UTC schrieb Dan Smith redmine@chirpmyradio.com:

Actions #65

Updated by Dan Smith 3 months ago

Here's a hopefully-final module to try. It extends the backlight to 60s, removes the language option for the OSFW variant.

If this looks good, I will queue this for the next build. Please report.

Thanks!

Actions #66

Updated by Dan Smith 3 months ago

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

Also available in: Atom PDF