Experimental version to help DMR breakup

[VK3KYY]

Hi Roger, I put in the 13 frame version and so far no stuttering audio! I was getting stuttering audio quite often.
And the green led doesn't flash on and off either.

This change is now in the "latest" released version, http://opengd77.com/viewtopic.php?f=13& ... 5e3bb69723
which also has 1 or 2 other fixes.

[EB2EAS]

Buenos días Roger.

No sé si será interesante pero he incluido en el menú de opciones el que se pueda modificar este dato. Las pruebas que he realizado son satisfactorias. Así la gente podrá modificar el valor sin cargar un nuevo firm.

Un saludo de EB2EAS José.

[IZ2EIB]

This change is now in the "latest" released version, http://opengd77.com/viewtopic.php?f=13& ... 5e3bb69723
which also has 1 or 2 other fixes.

Thanks a lot Roger!

73 best regards de Fabio IZ2EIB

[IZ2EIB]

Buenos días Roger.

No sé si será interesante pero he incluido en el menú de opciones el que se pueda modificar este dato. Las pruebas que he realizado son satisfactorias. Así la gente podrá modificar el valor sin cargar un nuevo firm.

Un saludo de EB2EAS José.

Google translator -->

Good morning Roger.

I do not know if it will be interesting but I have included in the options menu the one that can modify this data. The tests I have done are satisfactory. This way people can change the value without loading a new firm.

Greetings from EB2EAS José.

Hi José.
Interesting solution, thank you!

73 best regards de Fabio IZ2EIB

[WP3BM]

Greetings,

So far, so good!

73 de WP3BM

[EB3AM]

Hi, up this post momentarily so it's easier to know what I'm talking about.

I've been playing with GD77 for the area I live in, full of mountains. We now have a major network of DMR repeaters, but the orography means that we do not always have them in reach. As you know, the DMR requires a little more signal level than the FM to start decoding audio.

Well, if I remember correctly, a margin of 390ms (13 frames) was left to lose synchronism.

Can an experimental firmware be made with a switch where this time can be increased?

During the February tests it was seen to be enough, but I think a higher time would help in mountain areas.


How about that?

[VK3KYY]

Hi, up this post momentarily so it's easier to know what I'm talking about.

I've been playing with GD77 for the area I live in, full of mountains. We now have a major network of DMR repeaters, but the orography means that we do not always have them in reach. As you know, the DMR requires a little more signal level than the FM to start decoding audio.

Well, if I remember correctly, a margin of 390ms (13 frames) was left to lose synchronism.

Can an experimental firmware be made with a switch where this time can be increased?

During the February tests it was seen to be enough, but I think a higher time would help in mountain areas.


How about that?

This change happened over 6 months ago. But from what I can remember the change was the number frames which needed to enter the audio buffer before the audio decoding, and hence the audio output would start.

This change does not effect the timeslot part of the firmware, so increasing the value will not stop the radio losing synchronisation.

[G4EML]

The change was to how many lost frames could occur before the signal was considered to have dropped out and the state machine reverted to DMR idle, thus requiring a resync before the signal could return. Increasing the number of allowable lost frames would allow longer fades in the signal. There is a point however where rapid fading will always cause problems.

[g0faj]

I am currently running with a timeout of 13. No issues so far.

It is still only a third of a second. Fading and flutter can easily cause dropouts of that sort of duration.
I would expect some audio artifacts in that situation but it would recover instantly the signal returns. The AMBE Codec is pretty good at handling data errors so the resulting audio would be a lot more usable than having total dropouts.

The problem with low values is that the code drops back to DMR_STATE_IDLE. When the signal returns it has to re-establish the timeslot timing and go through the late entry process, both of which take time.

We probably need to tune this value for Ham radio use.

E.g. for very weak signals, perhaps an even larger value could be better. But there will probably be disadvantages to both large and small values

Hi Chaps. I have found the posts that I was referring to but do not understand how I am able to implement this.. My GD77s use a firmware version Mar 4 2023 efc2c8b D . Have the firmware versions since these posts include the alteration to improve the dmr receive side. Can this timeout be adjusted or what please ? 73 de Les G0FAJ

[VK3KYY]

My GD77s use a firmware version Mar 4 2023 efc2c8b D . Have the firmware versions since these posts include the alteration to improve the dmr receive side. Can this timeout be adjusted or what please ? 73 de Les G0FAJ

This thread releates to a post I made in 2020, so the information in it is totally obsolete.

Last firmware release was December 31 2023, however there were no changes to the GD77S, so updateing to that version will not make any difference to your DMR Rx.