Icom and Kenwood DV "Fast Data"

[timclassic]

First, I'm not sure if this is the right place to ask this question. Feel free to redirect me.

I have a Zumspot and a Kenwood TH-D74A. I'm experimenting with DV Fast Data mode (the 3480bps mode that uses voice frames for data, not DD mode on 1.2 GHz). Is this mode expected to work when traversing hotspots and reflectors? I get results like the following when using both a local echo test on my Zumspot and when using a path like TH-D74A -> Zumspot -> REF030D -> another hotspot -> another TH-D74A:

$ xxd sent.log
00000000: 5468 6973 2069 7320 6120 7465 7374 206f  This is a test o
00000010: 6620 7468 6520 656d 6572 6765 6e63 7920  f the emergency 
00000020: 6272 6f61 6463 6173 7420 7379 7374 656d  broadcast system
00000030: 2e20 2054 6869 7320 6973 206f 6e6c 7920  .  This is only 
00000040: 6120 7465 7374 2e0d 0a                   a test...

$ xxd received.log
00000000: 5468 6973 226b 73a0 6120 7745 7270 207f  This"ks.a wErp .
00000010: 6630 746c 6520 6d6d 75f2 6749 6e63 7920  f0tle mmu.gIncy 
00000020: 6376 7f61 6463 e16b f4e0 7379 7374 6165  cv.adc.k..systae
00000030: 2e20 2054 e869 7350 4973 207b 4e6e 6920  .  T.isPIs {Nni 
00000040: 7120 7475 7374 2e0d 0a                   q tust...

I've attached these two files: sent.log received.log

This test was performed with a terminal program (PuTTY in local-line-editing mode so I could send a whole line at a time). The corruption is the same every time when using the same source text. I've tried both MMDVMHost and DStarRepeater on the Zumspot and got corruption like this with both.

(Aside: I'm also not sure if the Icom and Kenwood implementations of DV Fast Data are the same since I don't have an Icom radio to test with. Boy I hope they are. I've found no documentation about the changes made to implement Fast Data--I just know that it apparently puts data in place of the voice frames.)

I'm currently running local builds of both DStarRepeater and MMDVM_HS so I'm prepared to tweak and patch to try things out. DV Fast Data plus hotspots and the reflector system seems like a powerful combination, and I think it would be really neat if I could get this working.

Thanks for reading!

-TimS, KG4BXH

[timclassic]

I forgot to mention that my hotspot reports a BER of 12-13% when transmitting DV Fast Data from the radio. It consistently reports 0% for normal voice comms. I have a hunch that the issue is related to assumptions about FEC that are different with Fast Data.

[juribeparada]

Honestly I haven't tried DV Fast Data mode yet, then I can't have a correct answer. I'm pretty sure modem firmware should be transparent, then the problem might be inside MMDVMHost. Can you attach your MMDVMHost log file (level 1)?. And also, have you tried another MMDVM device (not personal hotspot, MMDVM_HS), like a MMDVM repeater or simplex MMDVM?

[timclassic]

I'll generate a log file tonight and attach it. By "level 1", do you mean FileLevel=1 in the [Log] section of the MMDVMHost configuration file? Or is there more to it?

I have not tried any other devices yet, as the Zumspot is the only unit I have. What is the relationship between MMDVM_HS and the repo at https://github.com/g4klx/MMDVM (which I'm guessing is the "upstream" version)?

[juribeparada]

Yes, FileLevel=1 and DisplayLevel=1.

It is not the "upstream" version, they are a complete different things. MMDVM_HS is the firmware for personal hotspots, which means devices that uses ADF7021 as RF chip, like ZUMspot and others. I based the MMDVM_HS firmware on the G4KLX's work (MMDVM), then is compatible with MMDVMHost and other G4KLX's gateways. At the other side, MMDVM firmware is for use of analog radios to build a digital repeater or high power hotspot, which is the original purpose of MMDVM project. https://github.com/g4klx/MMDVM is the official and latest firmware for that kind of projects. MMDVM_HS and MMDVM use a totally different hardware modem.

[timclassic]

Ah, good to know, thanks! Your description actually answered a bunch of questions I had.

I've only recently started playing with D-Star and it's difficult to discover how everything relates.

[timclassic]

Here is MMDVM-2018-11-06.log using the logging settings you described.

[timclassic]

It appears the issue is caused by MMDVMHost regenerating the FEC on voice frames. To test, I commented out the three places in DStarControl.cpp that call m_fec.regenerateDStar() and transmissions now come back clean in an echo test.

I haven't been able to test with another ham yet, so I'm not sure if a reflector will preserve the data in this mode. But at least I can get it through a hotspot! Anyway, I'll move the discussion over to the MMDVMHost repo (I'll link it here too).

Thanks for the assistance, @juribeparada!

[timclassic]

I've opened g4klx/MMDVMHost#470.