New ongoing "Development" version has been created
Re: New ongoing "Development" version has been created
"What beep volume are you using ?"
The default -6dB I never change it after factory reset when opload new firmware
"Is there any difference between version 1 and version 2 of the fix ?"
It looks like the beep drop out on version 2 take longer to show up about 30 min+ on version 1 5-10 min.
If DMR audio drops out also I cannot say as DMR reception to me was OK before I noticed the beep drop out, but the repeater I listen to has nottoo much trafic.
But as said beep was OK after forth and back beep vol adjustment and DMR as well.
Trying the V3 fix since 1 1/2 houras still OK I'll let you know if drop out shows up again at least tomorrow morning if everthing went well.
The default -6dB I never change it after factory reset when opload new firmware
"Is there any difference between version 1 and version 2 of the fix ?"
It looks like the beep drop out on version 2 take longer to show up about 30 min+ on version 1 5-10 min.
If DMR audio drops out also I cannot say as DMR reception to me was OK before I noticed the beep drop out, but the repeater I listen to has nottoo much trafic.
But as said beep was OK after forth and back beep vol adjustment and DMR as well.
Trying the V3 fix since 1 1/2 houras still OK I'll let you know if drop out shows up again at least tomorrow morning if everthing went well.
Re: New ongoing "Development" version has been created
OK.
Actually Version 2 sends less data to the C6000 to attempt to overcome the hardware bug, because it only sends the C6000 bug fix data when the radio is woken from sleeping by receiving a signal
Version 3 is based on version 2 but sends 128 bytes of reset data when the radio receives a signal, instead of 96 bytes.
FYI.
The official firmware sends 128 bytes of reset data only when the radio boots, but because the OpenGD77 firmware now uses the sleep function of the C6000, it appears that this affects the bug in the old C6000 that requires the reset data.
So in Version 3, I tried 128 bytes in case this is better than 96 bytes.
In our tests 76 bytes seems to be enough to clear the buffer, but I don't have a radio which has these problems, so I can't test whether the number of bytes e.g. 128 instead of 96 makes any difference.
Also, the official firmware has many bugs, so I don't assume that the data they send to the C6000 is guaranteed to be 100% correct
Actually Version 2 sends less data to the C6000 to attempt to overcome the hardware bug, because it only sends the C6000 bug fix data when the radio is woken from sleeping by receiving a signal
Version 3 is based on version 2 but sends 128 bytes of reset data when the radio receives a signal, instead of 96 bytes.
FYI.
The official firmware sends 128 bytes of reset data only when the radio boots, but because the OpenGD77 firmware now uses the sleep function of the C6000, it appears that this affects the bug in the old C6000 that requires the reset data.
So in Version 3, I tried 128 bytes in case this is better than 96 bytes.
In our tests 76 bytes seems to be enough to clear the buffer, but I don't have a radio which has these problems, so I can't test whether the number of bytes e.g. 128 instead of 96 makes any difference.
Also, the official firmware has many bugs, so I don't assume that the data they send to the C6000 is guaranteed to be 100% correct
Re: New ongoing "Development" version has been created
I am extremely impressed with the eco level feature. None of my radios happen to have the bugs associated with the 6000 chip and I run using eco level 4. After an entire day on standby with average use, my battery is usually above 95%. The latency is also incredibly good considering the highest battery saving level.
Thanks
Joe
Thanks
Joe
Re: New ongoing "Development" version has been created
Bonsoir
et merci
et merci
Re: New ongoing "Development" version has been created
Beep and DMR audio with the V3 fix is OK on two GD-77 that I uploaded the FW with.VK3KYY wrote: ↑Tue Mar 09, 2021 10:11 amOK.
Actually Version 2 sends less data to the C6000 to attempt to overcome the hardware bug, because it only sends the C6000 bug fix data when the radio is woken from sleeping by receiving a signal
Version 3 is based on version 2 but sends 128 bytes of reset data when the radio receives a signal, instead of 96 bytes.
FYI.
The official firmware sends 128 bytes of reset data only when the radio boots, but because the OpenGD77 firmware now uses the sleep function of the C6000, it appears that this affects the bug in the old C6000 that requires the reset data.
So in Version 3, I tried 128 bytes in case this is better than 96 bytes.
In our tests 76 bytes seems to be enough to clear the buffer, but I don't have a radio which has these problems, so I can't test whether the number of bytes e.g. 128 instead of 96 makes any difference.
Also, the official firmware has many bugs, so I don't assume that the data they send to the C6000 is guaranteed to be 100% correct
Both running whole day yesterday and one over night.
Both on ECO 4 one scanning the other, the over the night one, on a DMR repeater, frequently receiving DMR and I also frequently pressed a button to test the beep.
The over the night one was the one with the problem.
So all OK so far, thanks
Re: New ongoing "Development" version has been created
OK.
I'm still waiting for EA5SW to finish his testing, but I'm hopeful that the changes will have also fixed the bug for him.
I'm still waiting for EA5SW to finish his testing, but I'm hopeful that the changes will have also fixed the bug for him.
Re: New ongoing "Development" version has been created
V3 with eco level 4 mute some times beep and audio from DMR transmissions in my GD77, V2 work always.
People report me that v3 have more stable BER that v2.
People report me that v3 have more stable BER that v2.
Re: New ongoing "Development" version has been created
Thanks a lot. On my device everything beeps, receives, transmits and talks as expected. D2021.03.06.01, Eco Level 2, Voice Prompts 3.
Re: New ongoing "Development" version has been created
This is a hardware fault on older GD77 and seems to affect about 0.5% of all GD77