CPS R2024.03.09.01 Radio Shut Down?

[W3ATN]

I just downloaded the new CPS, R2024.03.09.01 to my TYT MD-UV390. It seems to work fine, but a major change is that it turns off my radio after I write to it (reading does not shut off the radio). The previous version left the radio on after a write. I don't see any mention of this in the PDF that describes this latest version. I checked the changes I made and it seems they were written to the radio.

Is this normal behavior for this latest version or should I return to the previous one?

[VK3KYY]

I just downloaded the new CPS, R2024.03.09.01 to my TYT MD-UV390. It seems to work fine, but a major change is that it turns off my radio after I write to it (reading does not shut off the radio). The previous version left the radio on after a write. I don't see any mention of this in the PDF that describes this latest version. I checked the changes I made and it seems they were written to the radio.

Is this normal behavior for this latest version or should I return to the previous one?

Do you mean after firmware update the radio is turned off?

The radio remembers it's On/Off state from before you put it into DFU mode

[SA0BUX]

I just downloaded the new CPS, R2024.03.09.01 to my TYT MD-UV390. It seems to work fine, but a major change is that it turns off my radio after I write to it (reading does not shut off the radio). The previous version left the radio on after a write. I don't see any mention of this in the PDF that describes this latest version. I checked the changes I made and it seems they were written to the radio.

Is this normal behavior for this latest version or should I return to the previous one?

Do you mean after firmware update the radio is turned off?

The radio remembers it's On/Off state from before you put it into DFU mode

As you need to press some buttons and power on the radio it should be in "on" after restart when doing upgrades?
At least my radios do that, sometimes you need to press enter if the settings registers have changed.
But it's a very flawless and easy update process compared to other radios.

[VK3KYY]

I just checked and I'm pretty sure its because the radio was turned off before entering DFU mode

i.e If you turn off the radio from the green button on the front panel
Then turn off the PSU
Then hold Orange and P1 to enter DFU , and while still holding Orange and P1, turn on the PSU... The radio will power on and enter DFU mode
Then load the firmware
The radio will now reboot, but becuase the previous state prior to turning on the PSU with Orange and P1 held in.... Was OFF

Then the firmware will be in its OFF state


The confusion is proabbly becuase this radio is never actually OFF.

There is no power control circuity in this radio. When the radio appears to be off, its only every actually in Standby. The CPU is still running, albeit in a low current standby mode.

This is the same as the official fimware

You can tell that the radio is never truely off, even with the official firmware, becuase if you measure the current when the radio is "OFF" you'll find its not 0 (zero)
I forget how much current the radio takes when its in standby, its a few milliamps, possibly 10 or 15mA , I can't remember the exact value.

[SA0BUX]

Strange, can you power off a 390 via the green button?
I have always used the volume/on-off switch and press sk1 + PTT when powering on radio in DFU mode.

[VK3KYY]

Strange, can you power off a 390 via the green button?
I have always used the volume/on-off switch and press sk1 + PTT when powering on radio in DFU mode.

Ah.

I was confused, I thought this problem was on the MD9600 but I see now its the 390

The ability to reboot back into the firmware is not supported by the official loader but we found a way to do this with the OpenGD77 firmware loader

Howeever in this case, it sounds like for whatever reason the bootloader in the radio is not supporting reboot after installation.

The only thing which potentially could have caused this would be a Windows update, changing something in the .Net framework or the STM DFU driver

[W3ATN]

I figured out the problem. However, first I need to clarify what the problem was. It wasn't an FW issue. It had to do with the CPS writing the CP to the radio.

There was a coincidence of events that made the shut down occur. I got the latest CPS software and used it AFTER I'd changed a setting on the radio to "Safe Pwr-On". What that does is require you to hold the SK1 button (above PTT) while powering on the radio. This prevents accidental (e.g., in a backpack) turning on of the unit.

If you watch the UV-890 screen when you write a CP to it, the radio flashes off/on at the end of the write process. I turned OFF the "Safe Pwr-On" mode and the new CPS behaves normally - after writing to the radio, the radio flashes off then immediately back on. Turn on the "Safe Pwr-On" and it can't because you're not holding that SK1 key when it tries to turn on.

So, nothing wrong with CPS, just a quirk caused by a radio setting.

[ZL2MGS]

I can confirm that it is the "Safe Pwr-on" option that triggers this behaviour. I noticed this happening a couple of weeks ago, but eventually decided it wasn't an unreasonable side effect of selecting "Safe Pwr-on" (I've only just started using this option), so I didn't bother raising it as a bug.

As stated by W3ATH, the clue is that if you watch carefully you can see a flash of life as the radio begins the reboot, and then it encounters the Safe Pwr-on flag and quits the boot process.

This seems sensible to me as it preserves, and is in compliance with, the settings that were present prior to whatever update has just been made.

[F1RMB]

Hi,

But that's not a bug, at all.
Turning on safe power on option enables that behavior, that's the operator's choice. Period.

Hence when the CPS writes data that need the transceiver to be rebooted, of course that triggers the boot up protection.