Closed timclassic closed 5 years ago
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.
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?
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)?
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.
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.
Here is MMDVM-2018-11-06.log using the logging settings you described.
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!
I've opened https://github.com/g4klx/MMDVMHost/issues/470.
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
: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