Experimental version to help DMR breakup

VK3KYY
Posts: 7478
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: Experimental version to help DMR breakup

Post by VK3KYY » Wed Feb 19, 2020 9:35 pm

EB3AM wrote:
Wed Feb 19, 2020 9:18 pm

youtu.be/yn-_Bifhux4
You can now embed videos by using the video code.

BTW.

It’s difficult to hear the audio from each radio.

G4EML
Posts: 919
Joined: Sat Nov 16, 2019 10:01 am

Re: Experimental version to help DMR breakup

Post by G4EML » Wed Feb 19, 2020 9:39 pm

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.

VK3KYY
Posts: 7478
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: Experimental version to help DMR breakup

Post by VK3KYY » Wed Feb 19, 2020 9:48 pm

G4EML wrote:
Wed Feb 19, 2020 9:39 pm
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

User avatar
EB3AM
Posts: 204
Joined: Fri Jan 24, 2020 1:40 pm
Location: Catalonia, not Spain
Contact:

Re: Experimental version to help DMR breakup

Post by EB3AM » Wed Feb 19, 2020 10:26 pm

Just a question...

This mod also affects hotspot mode?

VK3KYY
Posts: 7478
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: Experimental version to help DMR breakup

Post by VK3KYY » Wed Feb 19, 2020 10:33 pm

EB3AM wrote:
Wed Feb 19, 2020 10:26 pm
Just a question...

This mod also affects hotspot mode?
Yes. I think it will.

User avatar
DU2XXR
Posts: 191
Joined: Thu Nov 28, 2019 5:25 am
Location: Philippines
Contact:

Re: Experimental version to help DMR breakup

Post by DU2XXR » Thu Feb 20, 2020 2:24 am

I've been doing some range tests with my openGD77 hotspot hooked up to aerial, and I can say I've experienced being blocked b BrandMeister several times perhaps due to weak signal (if the network sees you TX around 5-6 times in one second, the master server you are using blocks your hotspot's DMR ID).

Maybe this will prevent that. I've been updating my "portable" radio with the latest versions, but my hotspot radio is still on the February 12 firmware. I'll update the hotspot radio now to see if it reduces the intermittent receive issue at far distances.

VK3KYY
Posts: 7478
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: Experimental version to help DMR breakup

Post by VK3KYY » Thu Feb 20, 2020 2:56 am

I've recompiled the firmware with Colin's suggested value of 13 frames (from the ETSI standard), but I don't notice any difference with the 6 frame timeout

The original 2 frame timeout was giving me loads of dropouts.

Even 13 frames would probably not prevent the BM lockout. The value would need to be much higher, and we would probably need to implement another system to handle the BM lockout problem.
Attachments

[The extension sgl has been deactivated and can no longer be displayed.]


User avatar
DU2XXR
Posts: 191
Joined: Thu Nov 28, 2019 5:25 am
Location: Philippines
Contact:

Re: Experimental version to help DMR breakup

Post by DU2XXR » Thu Feb 20, 2020 6:36 am

Not sure if it's an apples-to-apples comparison, but I was listening to QSO between Roger and Clayton earlier today while in my car for a 1Km trip to fetch my daughter from school. Audio on my Retevis RT8 kept breaking up and "hanging" to something that resembles static. The audio on my openGD77 with this Experimental Version was breaking up a bit but did not hang.

I was using my other GD77 as hotspot hooked up to an aerial antenna pushing 5W.

User avatar
EB3AM
Posts: 204
Joined: Fri Jan 24, 2020 1:40 pm
Location: Catalonia, not Spain
Contact:

Re: Experimental version to help DMR breakup

Post by EB3AM » Thu Feb 20, 2020 7:54 am

After making a route with the reception of several BSs, most of the time with marginal signals, I can say that the 13 frame version works really well.
The audio cuts did occur, but the return was smooth. without stridencies. Last week I went the same route and ended up closing the receiver as it was very difficult to understand anything and the noise was constant.
I think you did a great job, and a huge step forward.

VK3KYY
Posts: 7478
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: Experimental version to help DMR breakup

Post by VK3KYY » Thu Feb 20, 2020 9:01 am

EB3AM wrote:
Thu Feb 20, 2020 7:54 am
After making a route with the reception of several BSs, most of the time with marginal signals, I can say that the 13 frame version works really well.
The audio cuts did occur, but the return was smooth. without stridencies. Last week I went the same route and ended up closing the receiver as it was very difficult to understand anything and the noise was constant.
I think you did a great job, and a huge step forward.
Did you try the version with only 6 frame timeout.

I personally didnt notice any difference between 6 and 8 and 13

Post Reply