Topics

High Loss% with ThumbDV on DMR


Tom Corcoran
 

Have been using DMR/DStar for couple of years now but I recently acquired a ThumbDV for travel and am generally pleased. However, when I check reflector dashboards, I note high Loss % (yet 0% BER) when on DMR. The loss % is quite volatile as well (5 - 50%). Other stations registering 0% Loss and 0% BER. Anyone else have this experience?

Tom VE3NY


 

Which software are you using with the ThumbDV?

The ThumbDV only deals with serial communications over the USB port.  It is extremely unlikely that any bit errors could be introduced at the USB interface between the computer and ThumbDV.

Bit errors tend to happen in the transport layer, eg. over the air on a weak or interference prone signal, in the modem (which would tend to be a radio), or most likely what you are seeing is UDP packet loss -- if you are seeing packet loss -- I think most dashboards are expressing loss in terms of percentage of packet loss rather than BER.

You may want to run ping between your computer with the ThumbDV and the reflector's IP address (You can find them at https://ar-dns.net) and see what the packet loss is when you kill or stop the ping.  For Windows https://datapath.io/resources/blog/how-to-test-for-packet-loss-on-windows/, on Linux or MacOS, just use the command line ping and run it for a while and then hit Control-C and look at the stats.

On Wed, Jan 24, 2018 at 11:07 AM, <tcorcoran@...> wrote:
Have been using DMR/DStar for couple of years now but I recently acquired a ThumbDV for travel and am generally pleased. However, when I check reflector dashboards, I note high Loss % (yet 0% BER) when on DMR. The loss % is quite volatile as well (5 - 50%). Other stations registering 0% Loss and 0% BER. Anyone else have this experience?

Tom VE3NY
_._,_._,_

--


John D. Hays
Edmonds, WA
K7VE

   


Michael E. Jaggers
 

Plugged directly into the PC or into an external hub?

You may not have enough current capacity to effectively power the ThumbDV.

Try it plugged directly to the PC.

Mike, WB4TTZ

From: John D Hays - K7VE
Sent: Jan 24, 2018 1:40 PM
To: ambe@nw-digital-radio.groups.io
Subject: Re: [ambe] High Loss% with ThumbDV on DMR

Which software are you using with the ThumbDV?

The ThumbDV only deals with serial communications over the USB port.  It is extremely unlikely that any bit errors could be introduced at the USB interface between the computer and ThumbDV.

Bit errors tend to happen in the transport layer, eg. over the air on a weak or interference prone signal, in the modem (which would tend to be a radio), or most likely what you are seeing is UDP packet loss -- if you are seeing packet loss -- I think most dashboards are expressing loss in terms of percentage of packet loss rather than BER.

You may want to run ping between your computer with the ThumbDV and the reflector's IP address (You can find them at https://ar-dns.net) and see what the packet loss is when you kill or stop the ping.  For Windows https://datapath.io/resources/blog/how-to-test-for-packet-loss-on-windows/, on Linux or MacOS, just use the command line ping and run it for a while and then hit Control-C and look at the stats.

On Wed, Jan 24, 2018 at 11:07 AM, <tcorcoran@...> wrote:
Have been using DMR/DStar for couple of years now but I recently acquired a ThumbDV for travel and am generally pleased. However, when I check reflector dashboards, I note high Loss % (yet 0% BER) when on DMR. The loss % is quite volatile as well (5 - 50%). Other stations registering 0% Loss and 0% BER. Anyone else have this experience?

Tom VE3NY




Tom Corcoran
 


Thanks for suggestions ....

I will try John's suggestions on sending a ping from my pc to a selected reflector.

Michael, I have tried both plugging into the pc directly as well as using a powered USB port. Same result.

Tom VE3NY 


VE3MIC
 

Sounds a lot like streaming issues when connected to the Internet over a marginal wireless access point or low bandwidth connection. If you're using public WiFi when experiencing this, there's not much you can do.  But if you have unlimited data, try creating a WiFi hotspot with your smartphone.


Tom Corcoran
 

Mike .. good suggestion and tried it ... no luck. still hi loss % 0% BER and Loss figures are all over the map from 0% to 80%. I have tested on DMR/BM and DMR+ with same result. D-Star works fine and "some" TG's are ok. Have also tried other pc's ... same result.

Do either of you or John (or others) have a ThumbDV and, if so, are you experiencing this issue? 

Tom VE3NY


Tom McDermott
 

Hi Tom,

I've written an interface for ThumbDV to gnuradio.   It runs in DSTAR or DMR
AMBE encoding/decoding mode without losses.  Right now I don't have any modules
written to insert or extract DSTAR bits from a raw 4800 BPS stream, nor
to/from DMR.  So testing is just loop-back:   audio-input to AMBE encoded samples,
those samples looped back to the decoder to audio output.

In writing the gnuradio driver, I ran across one case where the losses were high. For
me this occurred when over-running the ThumbDV with packets faster than a 20 milliseconds
per packet rate.  It was not enough to limit the packets-to-ThumbDV to the 460,800 bps
serial rate,  The device would lose synchronization at the packet level, and eventually
recover after throwing away enough corrupted response packets. Then after a few good
packets it would get lost again.

The device latency appears to be about 3 packets, so it is necessary to pipeline the packets.
It ended up being necessary to limit how many packets are inside the ThumbDV.
My driver limits the number of packets inside the device to 5, it seems to run OK with that.


-- Tom, N5EG









On Thu, Jan 25, 2018 at 10:34 AM, <tcorcoran@...> wrote:
Mike .. good suggestion and tried it ... no luck. still hi loss % 0% BER and Loss figures are all over the map from 0% to 80%. I have tested on DMR/BM and DMR+ with same result. D-Star works fine and "some" TG's are ok. Have also tried other pc's ... same result.

Do either of you or John (or others) have a ThumbDV and, if so, are you experiencing this issue? 

Tom VE3NY



Tom Corcoran
 

Tnx Tom,

this is is a thorough diagnosis and resolution of the problem. Is this something that should be fed back to NW? Or is DMR beyond the design spec of the ThumbDV? 

I understand conceptually what you have done but would be unable to build the interface to provide packet limiting on my own. Any "brite force" method of limiting packets? Is this something that the vendor could/should provide? I’m using BlueDV but not implying he should do anything. It’s a NW issue - correct?

Tom VE3NY 


 

Is HW flow control enabled? It is a requirement for the AMBE3000 Chip

Bryan K7UDR


 

The software, in this case BlueDV, controls the packet flow to/from the ThumbDV.   NW Digital Radio is responsible for the manufacture of the ThumbDV and that it performs according to the hardware specs and documentation.  Software is responsible for transport of Audio (PCM) and AMBE to and from the ThumbDV hardware.



On Thu, Jan 25, 2018 at 1:39 PM, <tcorcoran@...> wrote:
Tnx Tom,

this is is a thorough diagnosis and resolution of the problem. Is this something that should be fed back to NW? Or is DMR beyond the design spec of the ThumbDV? 

I understand conceptually what you have done but would be unable to build the interface to provide packet limiting on my own. Any "brite force" method of limiting packets? Is this something that the vendor could/should provide? I’m using BlueDV but not implying he should do anything. It’s a NW issue - correct?

Tom VE3NY 



--


John D. Hays
Director

  


Tom McDermott
 

Hi Tom,

In my opinion this is not a hardware issue.  The general problem is that the Internet has
variable latency and variable packet loss.  The software feeding a vocoder has to deal
with it.  The use of TCP to recover from lost packets causes a delay in the received
AMBE frames. 

What to do?   

Brute force would be to just throttle the packets to the DV.  But then the latency would
grow with time, and become unusable.  Another approach is for the software to try
to figure out when arriving internet packets are too late and throw them away.

Real time media devices sometimes use a special protocol such as RTP / RTCP to
balance the tradeoff between loss rate and latency.

If the internet path from the source to the destination (involving a lot of connections,
routers, etc.) has loss and / or latency problems, that sort of has to be fixed first.

-- Tom, N5EG





On Thu, Jan 25, 2018 at 1:39 PM, <tcorcoran@...> wrote:
Tnx Tom,

this is is a thorough diagnosis and resolution of the problem. Is this something that should be fed back to NW? Or is DMR beyond the design spec of the ThumbDV? 

I understand conceptually what you have done but would be unable to build the interface to provide packet limiting on my own. Any "brite force" method of limiting packets? Is this something that the vendor could/should provide? I’m using BlueDV but not implying he should do anything. It’s a NW issue - correct?

Tom VE3NY 
_._,_._,_



Tom Corcoran
 

Brian,

not sure. Will check. 


Tom Corcoran
 

All,

tnx for very constructive advice. I will pursue with s/w author. 

Tom VE3NY 


 

Tom -- David (PA7LIM), author of BlueDV, participates on this list, so we may hear from him on this topic.

On Thu, Jan 25, 2018 at 2:22 PM, <tcorcoran@...> wrote:
All,

tnx for very constructive advice. I will pursue with s/w author. 

Tom VE3NY 




--


John D. Hays
Edmonds, WA
K7VE

   


 

Hi All,

I will try to explain. 

What happens when you sent to the DMR master/reflector.

Every 20ms I receive a DMR voice frame of 72 bits from the ThumbDV. I wait until I have 3 frames. Then I add some extra spicy saus for DMR data ( 48 bits ) ( EMB etc ).
So when I miss one frame from the AMBE I will wait for the next. This is not a loss what you see on the other end!
The 3*72 bits voice + data 48 bits = 264 bits / 8 = 33 bytes is send to the master/reflector + extra headers ( depends on network ). When this data ( 33 bytes + header) is not received, it is a loss.
When the 72 bits voice is corrupted the BER will be higher. 

It is not normal to use TCP as a transport for voice. When you have loss it will re-transmit. And retransmitting is latency or jitter. Jitter is really bad for voice!
Normally voice is transported by UDP. UDP is like a postcard. You never know if the card is received. In the DMR/DSTAR data we also send a kind of sequence number so we can count the loss and do something with it like filling up with white noise. 

There are several tools on internet to test the latency, loss etc. A good internet connection from end to end is very important for voice!

---

Greets and 73,
    David PA7LIM


On 25-01-2018 23:24, John D Hays - K7VE wrote:

Tom -- David (PA7LIM), author of BlueDV, participates on this list, so we may hear from him on this topic.

On Thu, Jan 25, 2018 at 2:22 PM, <tcorcoran@...> wrote:
All,

tnx for very constructive advice. I will pursue with s/w author. 

Tom VE3NY 






 
--


John D. Hays
Edmonds, WA
K7VE
 
   
 


Tom Corcoran
 

Tnx David and all others. Will assess internet parameters. In meantime, I think I will contain my use of ThumbDV for DStar ... appears that I have no issues on that mode ... Tom VE3NY


Steve N4IRS
 

One thing we ran into on some hosts was the latency timer on the FTDI serial driver. I want to repeat, on SOME hosts. Take a look as root: cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer it may be set at 16. set it to a 1 and re-test.

73, Steve N4IRS


Tom Corcoran
 

All,
to bring closure on this thread ... I saw the hi Loss% on two repeaters which both happened to be running Pi-Star. In MMDVMHost, we increased the jitter from 300 (default) to 700 and Loss % is consistently 0% now. AND great audio reports.

Tnx for everyone's constructive advice. Much appreciated. ThumbDV is a great performer and suits my need for a convenient travel package. I look forward to future product enhancements. Now returning to regular programming .... with repeaters and hotspots!!

Tom VE3NY


 

👍

On Jan 28, 2018 06:00, <tcorcoran@...> wrote:
All,
to bring closure on this thread ... I saw the hi Loss% on two repeaters which both happened to be running Pi-Star. In MMDVMHost, we increased the jitter from 300 (default) to 700 and Loss % is consistently 0% now. AND great audio reports.

Tnx for everyone's constructive advice. Much appreciated. ThumbDV is a great performer and suits my need for a convenient travel package. I look forward to future product enhancements. Now returning to regular programming .... with repeaters and hotspots!!

Tom VE3NY



Patrice Quilici <f1hmr@...>
 

Thumb DV well arrived look work nice
many thank’s for all
P.QUILICI-F1HMR



Le 25 janvier 2018 à 22:45:08, Bryan Hoyer (bhhoyer@...) a écrit:

Is HW flow control enabled? It is a requirement for the AMBE3000 Chip

Bryan K7UDR