whosmatt / uvmod

Web-based firmware patcher for various Quansheng radios
https://whosmatt.github.io/uvmod/
268 stars 47 forks source link

[Question] Identify the units that have the problem with the transmit power calibration. #17

Closed reppad closed 1 year ago

reppad commented 1 year ago

As indicated in the readme, some radios have a problem with calibrating the TX power, these units need firmware 2.01.27 to operate correctly.

I have a radio which dates from 07/2023 according to the green sticker under the battery and which has firmware 2.01.27, I don't have a way to test the transmission power so I don't know if this radio has the problem, and so if I can use uvmod...

I saw a radio with a newer sticker 08/2023 and which was delivered with firmware 2.01.26, so we can assume that the problem is "fixed" and that Quansheng no longer uses firmware 2.01.27 (?)

My question is the following: Do we know if all radios delivered with firmware 2.01.27 have the issue of calibrating the TX power? Do some people have radios delivered with 2.01.27 and who do not have the TX power issue with firmware 2.01.26?

whosmatt commented 1 year ago

How do you tell which firmware is preinstalled? As far as i know the version string is nowhere on the radio.

I am currently working on a uvmod configurator tool (to do channels etc on the website without the need for software). Since this tool will have access to the eeprom, it can also easily identify radios that have the txpower bug, and ill display a little info banner. Affected radios have one or more negative calibration values and the bug is that v26 does not properly treat negative values.

So far we dont have a mod to patch the bug in v26 but i am sure someone will do it soon enough.

reppad commented 1 year ago

How do you tell which firmware is preinstalled? As far as i know the version string is nowhere on the radio.

The radio send back the firmware version when you send the right command througt data cable so there are some ways to get the firmware version from the radio, like Python lib libuvk5 , or just by reading configuration with chirp software or with the official tool.

I am currently working on a uvmod configurator tool (to do channels etc on the website without the need for software).

Great news, I'm looking forward to it !

Since this tool will have access to the eeprom, it can also easily identify radios that have the txpower bug, and ill display a little info banner.

We should even be able to find this information in an img file made with chirp if we know where to look because it is an EEPROM dump.

Affected radios have one or more negative calibration values and the bug is that v26 does not properly treat negative values.

So far we dont have a mod to patch the bug in v26 but i am sure someone will do it soon enough.

If I understand correctly, v27 should work in all cases, wouldn't it be simpler to base the mods on this version? (Probably easier said than done if it is not the way that was chosen...)

whosmatt commented 1 year ago

I found the version command and the way it works, the radio has the firmware version hardcoded in the function that replies to the 0x14 command when reading eeprom. I will be able to show the version in configurator. Oddly enough this has nothing to do with the version string found in the encoded firmware, because that never gets stored by the radio.

Right now I am implementing a .uvbk file format which is just the raw full eeprom with a crc16 appended to it. If the chirp format is close enough I can support that as well for import, which would automatically also work with the bug check. I am a little wary to support generic file formats such as .img though, since people could accidentally overwrite sensitive data with garbage by choosing a random file.

UVMOD is on v26 since the uvmod kitchen is, making it easy to transfer new mods. We do have most mods for v27 now so I could move everything to v27, although it seems like more effort than just making a mod that implements signed divide correctly. But after looking at the firmware I can see why nobody did it yet, it is a bit of a mess with multiple sections to be patched and amended.

whosmatt commented 1 year ago

Will be added with the upcoming configurator feature

reppad commented 1 year ago

Thank you, this feature has a lot of value and will make a difference with existing configuration tools.

reppad commented 11 months ago

Right now I am implementing a .uvbk file format which is just the raw full eeprom with a crc16 appended to it. If the chirp format is close enough I can support that as well for import, which would automatically also work with the bug check. I am a little wary to support generic file formats such as .img though, since people could accidentally overwrite sensitive data with garbage by choosing a random file.

I just opened a Chirp image with a hexadecimal editor and it got me thinking about this conversation again, here's what I saw if it's helpful... The Chirp image is also a complete dump of the eeprom with additional data starting from address 0x2000 This data starts with "00 FF 63 68 69 72 70 EE 69 6D 67" i.e. "*chirpimg", which may be a good test to prevent messing around with random img files.