UV-380 corrupted

[G4EML]

That is unlikely to be a codeplug problem. If it occasionally transmits on the correct frequency then the codeplug must be good. The fact that it works OK on another radio confirms this.

It sounds as if the synthesiser is not always locking on transmit. What frequency are you trying to transmit on? Does it do this on all frequencies? You could try transmitting on frequencies across the whole range to confirm this.

Colin G4EML

[ok1pt]

Hi!
I believe that it's not a codeplug corruption. Ir really looks like a HW problem - incorrect loading of the coefficients to the synthesizer chip, so it isn't locking for lower fequencies. It reacts to the frequency changes, but only marginally, and fully starts tracking the frequency only above some limit, where it is able to properly lock the PLL loop.
Because it works with original firmware, it seems that there is a difference in the synthesizer handling routines (for example, different timing or different sequence of filling the registers etc), and possibly the particular chip in your radio is more sensitive for keeping the "proper" way that it doesn't accept the data fully then it cannot work reliably.
With regards / 73. Pavel OK1PT

[F1RMB]

Hi,

have you "played" with calibration values ?


Cheers.
---
Daniel

[G4EML]

It definitely sounds like a hardware problem with the RF Chip. It seems it is not locking on the lower frequencies. Strange that it works on the original firmware but they may of course be programming it slightly differently. The code used for this chip is well tested on several different radio types so it is strange that your radio seems to fail.

It is unlikely to be a codeplug problem. But to be sure you can clear the radio settings by holding SK2 while turning on the radio. Then just create a new codeplug in the CPS.

Of course it is possible that your radio is using a slightly different chip. We do know that TYT change their designs when chips are not available. However we have not seen any changes on the MDUV380 as far as we know.

Colin.

[DG5YHS]

Hello, I have almost a similar problem with the original firmware, I had written and saved a clean code plug. suddenly the next day, bit by bit, nothing worked anymore. At first he didn't send or receive anything on FM Channel B, then I completely rewrote the entire channel in the code plug and saved it elsewhere, but still exactly the same problem. Next he destroyed my DMR access, despite the correct code plug he sent in direct mode. Then it was enough for me, I played the GD77 firmware on it. Now everything works, but without programming. Problem this time, I don't know my COM port and tried up to comport 10 but couldn't assign one. does anyone have any advice as to what it could be? it's running Windows 10. I'll try when I'm back home with Windows XP. 73DG5YHS

[VK3KYY]

. Now everything works, but without programming. Problem this time, I don't know my COM port and tried up to comport 10 but couldn't assign one. does anyone have any advice as to what it could be? it's running Windows 10. I'll try when I'm back home with Windows XP. 73DG5YHS

Normally there are no problems with the Com port on S10.

Open the Device Manager, and look in the Serial devices. This will give you the com port number if the CPS can't automatically find the com port of the radio

The com driver assigns a name of OpenGD77 to the com port of the radio, but versions of Windows install a Microsoft generic serial port driver to the radio from port, but it does not have a name of OpenGD77 , so the CPS does not know it is the com port for the radio, and you must manually select it