g4klx
commented
5 years ago Hi Tim
Fast data on normal D-Star radios is a relatively new thing and certainly wasn’t around when my software was first written. The only data mode being used then was the relatively high speed DD mode on 23cms.
Although I own two radios that do this mode, an Icom ID-51 and a Kenwood TH-D74, I have not tried it out. So my comments are based on understanding the protocol and code rather than direct experience of the mode.
So to your questions:
- I don’t know. There is a bit in the header that is marked as being to indicate whether the payload is data or voice. This is not checked in my software currently. I hope that they use this bit for this mode also, although they’re not the same structure. The flags are the first three bytes of the D-Star header. I think any dump will need to be at a low level, i.e. the raw serial data from the modem so that any patterns in the data can be observed.
- I don’t know.
- The FEC is recalculated so that the bit errors don’t accumulate. This is something that Icom repeaters don’t do, and almost all repeaters for other modes do. I am certainly not willing to remove it as it can make a big difference to the received audio, and voice mode is the vast majority of the traffic. If we can find a way to reliably detect this data mode, then we can do something about the FEC regeneration.
To create the traces you need to go into the [Modem] section of MMDVM.ini and set either Debug=1 or Trace=1 (or both, I forget, and I’m at work currently) and logging to level 1 for debug messages. You shouldn’t need much data.
There must be a way to distinguish the voice and data modes, so I await your data logging with interest. Jonathan G4KLX
Sent from Yahoo Mail for iPhone
On Wednesday, November 7, 2018, 02:39, Tim Stewart notifications@github.com wrote:
I've been testing D-Star DV "Fast Data" as implemented on the Kenwood TH-D74. I tried sending data via a ZUMspot only to find that it gets corrupted on its way through (juribeparada/MMDVM_HS#71 has an example of the corruption). MMDVMHost also reports a BER of ~12.6%.
I discovered that if I comment out all three calls to m_fec.regenerateDStar() in DStarControl.cpp, the data is able to pass through without corruption. It seems that all 72 bits of each voice frame are used for data and there is no FEC applied, which also probably explains the ~12.6% BER report.
Some things I don't know:
- Is there a way to tell when a voice frame contains "fast data" instead of voice+FEC?
- Do Icom and Kenwood implement the same fast data spec? (I hope so)
- Why is the FEC recalculated and reapplied in MMDVMHost? Is it so that the BER reports are effectively per-hop? Is there something important to the protocol going on?
To answer question 1, I'm planning to look for a difference in the packet that indicates whether voice or data is contained within the voice frames. I think there must be a way to tell the difference, because the demos I've seen of Icom radios doing fast data allow the user seamlessly transmit audio while a data transfer is ongoing and the radio degrades to slow data while sending voice frames. (The Kenwood does not seem to have this slow data capability)
I'm going to email Kenwood and Icom in an effort to answer question 2 (and maybe question 1?) and also ask if they have any specs to share.
I'm hoping that someone reading this can answer question 3 for me.
I'm interested in all this because I think that fast data + hotspots and the reflector system could be a powerful combination.
-TimS, KG4BXH
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
timclassic
juribeparada
phl0
ravny
I've been testing D-Star DV "Fast Data" as implemented on the Kenwood TH-D74. I tried sending data via a ZUMspot only to find that it gets corrupted on its way through (https://github.com/juribeparada/MMDVM_HS/issues/71 has an example of the corruption). MMDVMHost also reports a BER of ~12.6%.
I discovered that if I comment out all three calls to
m_fec.regenerateDStar()in DStarControl.cpp, the data is able to pass through without corruption. It seems that all 72 bits of each voice frame are used for data and there is no FEC applied, which also probably explains the ~12.6% BER report.Some things I don't know:
To answer question 1, I'm planning to look for a difference in the packet that indicates whether voice or data is contained within the voice frames. I think there must be a way to tell the difference, because the demos I've seen of Icom radios doing fast data allow the user seamlessly transmit audio while a data transfer is ongoing and the radio degrades to slow data while sending voice frames. (The Kenwood does not seem to have this slow data capability)
I'm going to email Kenwood and Icom in an effort to answer question 2 (and maybe question 1?) and also ask if they have any specs to share.
I'm hoping that someone reading this can answer question 3 for me.
I'm interested in all this because I think that fast data + hotspots and the reflector system could be a powerful combination.
-TimS, KG4BXH