search

g4klx / MMDVMHost

The host program for the MMDVM
GNU General Public License v2.0
373 stars 271 forks source link

Support for D-Star DV Fast Data #470

Open timclassic opened 5 years ago

timclassic commented 5 years ago

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:

  1. Is there a way to tell when a voice frame contains "fast data" instead of voice+FEC?
  2. Do Icom and Kenwood implement the same fast data spec? (I hope so)
  3. 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

timclassic commented 5 years ago

Oh, what a find! And it is recent, too. There is a PDF link in that thread (in Japanese): http://www.jarl.com/d-star/STD5_0b.pdf

g4klx commented 5 years ago

It was a Twitter thread in response to me so it didn't take too much finding. It seems that we're using the wrong method to detect Icom fast data mode, so we need to understand it more and write new rules.

timclassic commented 5 years ago

Oh, great! My hunch is that we get Kenwood for free if we correctly implement the Icom variant, since they seem to be compatible.

ravny commented 5 years ago

Hi @timclassic which patch version did you mean.

timclassic commented 5 years ago

@ravny I'm just referring to the latest version of MMDVMHost that includes the recent Fast Data patches.

ravny commented 5 years ago

If you're sure that you are running the patched version that is capable of the data mode switch, it would be interesting to see a dump of your transmission. Maybe there is an additional sequence of bytes that needs to be added to the code, or something.

I had to set the following to MMDVM.ini:

[Log]
FileLevel=1

[Modem]
Trace=1
Debug=1

I'm not sure that Debug=1 is necessary, but the other two are.

HI @timclassic I have installed latest version of MMDVM. This is what I have in my log file

M: 2018-11-24 06:29:12.016 Debug: Mode set to Idle M: 2018-11-24 06:30:00.499 Debug: DStarRX: found data sync in None, exact D: 2018-11-24 06:30:00.500 RX D-Star Data D: 2018-11-24 06:30:00.500 0000: E0 11 11 9E 8D 32 88 26 1A 3F 61 E8 55 2D 16 00 .....2.&.?a.U-.. D: 2018-11-24 06:30:00.501 0010: 2F / D: 2018-11-24 06:30:00.506 D-Star, raw RSSI: 47, reported RSSI: -47 dBm D: 2018-11-24 06:30:00.517 RX D-Star Data D: 2018-11-24 06:30:00.517 0000: E0 0F 11 AE CC 2A 78 E1 13 3C 67 C0 30 02 F2 .....x..<g.0.. D: 2018-11-24 06:30:00.539 RX D-Star Data D: 2018-11-24 06:30:00.540 0000: E0 0F 11 CE 8E 2E 39 66 12 78 31 B0 04 2A F9 ......9f.x1... D: 2018-11-24 06:30:00.556 RX D-Star Data D: 2018-11-24 06:30:00.557 0000: E0 0F 11 AE CC 2A 78 E1 91 34 67 C0 31 6F C0 .....x..4g.1o. D: 2018-11-24 06:30:00.578 RX D-Star Data D: 2018-11-24 06:30:00.578 0000: E0 0F 11 CA 8E 26 19 26 1E 4C A1 F0 3C 00 C5 .....&.&.L..<.. D: 2018-11-24 06:30:00.600 RX D-Star Data D: 2018-11-24 06:30:00.601 0000: E0 0F 11 AE CC 2A 78 E1 13 3C 67 C0 32 0A DD .....x..<g.2.. D: 2018-11-24 06:30:00.617 RX D-Star Data D: 2018-11-24 06:30:00.617 0000: E0 0F 11 BE 6E 22 48 23 1B 0C 77 80 39 0E B3 ....n"H#..w.9.. D: 2018-11-24 06:30:00.638 RX D-Star Data D: 2018-11-24 06:30:00.639 0000: E0 0F 11 CE 8E 22 09 E4 1E 4C 20 F4 33 6F B3 ....."...L .3o. D: 2018-11-24 06:30:00.660 RX D-Star Data D: 2018-11-24 06:30:00.660 0000: E0 0F 11 AA CC 2A 78 E1 91 3C 67 C0 50 6F B3 .....x..<g.Po. D: 2018-11-24 06:30:00.677 RX D-Star Data D: 2018-11-24 06:30:00.677 0000: E0 0F 11 CE CE AC 31 47 1E 58 E0 F0 16 29 F5 ......1G.X...). D: 2018-11-24 06:30:00.699 RX D-Star Data D: 2018-11-24 06:30:00.699 0000: E0 0F 11 AE 8C 2E 68 22 1F 1C 37 84 16 29 F5 ......h"..7..). D: 2018-11-24 06:30:00.716 RX D-Star Data D: 2018-11-24 06:30:00.716 0000: E0 0F 11 2D 6D AE 00 66 49 2D 0D 6B E4 14 C0 ...-m..fI-.k... D: 2018-11-24 06:30:00.738 RX D-Star Data D: 2018-11-24 06:30:00.738 0000: E0 0F 11 4D 71 A4 88 66 49 2D 38 0A E4 00 D1 ...Mq..fI-8.... D: 2018-11-24 06:30:00.760 RX D-Star Data D: 2018-11-24 06:30:00.760 0000: E0 0F 11 0E 31 ED 61 66 0A 13 4E 55 E4 31 ED ....1.af..NU.1. D: 2018-11-24 06:30:00.776 RX D-Star Data D: 2018-11-24 06:30:00.778 0000: E0 0F 11 0E 31 ED 41 66 75 6C 31 2A E4 31 ED ....1.Aful1.1. D: 2018-11-24 06:30:00.796 RX D-Star Data D: 2018-11-24 06:30:00.797 0000: E0 0F 11 35 00 D1 1D 66 2F 3E 7F 69 E4 4E 92 ...5...f/>.i.N. D: 2018-11-24 06:30:00.820 RX D-Star Data D: 2018-11-24 06:30:00.822 0000: E0 0F 11 2D 6D AE 00 66 49 2D 31 16 E4 4E C8 ...-m..fI-1..N. D: 2018-11-24 06:30:00.839 RX D-Star Data D: 2018-11-24 06:30:00.840 0000: E0 0F 11 4D 0F 97 13 66 41 5B 79 6A E4 0F 4D ...M...fA[yj..M D: 2018-11-24 06:30:00.858 RX D-Star Data D: 2018-11-24 06:30:00.859 0000: E0 0F 11 22 31 ED 03 66 25 2E 61 68 E4 72 EE ..."1..f%.ah.r. D: 2018-11-24 06:30:00.876 RX D-Star Data D: 2018-11-24 06:30:00.877 0000: E0 0F 11 15 3C E7 1B 66 31 22 72 76 FC 1E ED ....<..f1"rv... D: 2018-11-24 06:30:00.900 RX D-Star Data D: 2018-11-24 06:30:00.902 0000: E0 0F 11 70 4F 93 40 66 74 6D 30 2B FC 31 E7 ...pO.@ftm0+.1. D: 2018-11-24 06:30:00.916 RX D-Star Data D: 2018-11-24 06:30:00.917 0000: E0 11 11 CE 8E 2E 39 66 12 78 31 B0 55 2D 16 00 ......9f.x1.U-.. D: 2018-11-24 06:30:00.917 0010: 2F / D: 2018-11-24 06:30:00.917 D-Star, raw RSSI: 47, reported RSSI: -47 dBm D: 2018-11-24 06:30:00.939 RX D-Star Data D: 2018-11-24 06:30:00.939 0000: E0 0F 11 AE EC 2A 78 E1 13 3C 67 C0 16 29 F5 .....x..<g..). D: 2018-11-24 06:30:00.961 RX D-Star Data D: 2018-11-24 06:30:00.961 0000: E0 0F 11 CE CE 2A 29 A5 1E 58 61 F4 55 55 55 .....)..Xa.UUU M: 2018-11-24 06:30:00.963 Debug: DStarRX: Found end sync in Data D: 2018-11-24 06:30:00.969 RX D-Star EOT D: 2018-11-24 06:30:00.969 0000: E0 03 13 ... M: 2018-11-24 06:30:16.533 Debug: DStarRX: found frame sync in None, fuzzy D: 2018-11-24 06:30:16.675 RX D-Star Header D: 2018-11-24 06:30:16.675 0000: E0 2E 10 40 00 00 53 35 36 49 41 52 20 47 53 35 ...@..S56IAR GS5 D: 2018-11-24 06:30:16.676 0010: 36 49 41 52 20 42 43 51 43 51 43 51 20 20 53 35 6IAR BCQCQCQ S5 D: 2018-11-24 06:30:16.676 0020: 36 49 41 52 20 20 49 44 35 31 B6 30 00 2F 6IAR ID51.0./ D: 2018-11-24 06:30:16.677 D-Star, raw RSSI: 47, reported RSSI: -47 dBm M: 2018-11-24 06:30:16.678 D-Star, received RF header from S56IAR /ID51 to CQCQCQ
M: 2018-11-24 06:30:16.686 Debug: Mode set to D-Star D: 2018-11-24 06:30:16.692 RX D-Star Data D: 2018-11-24 06:30:16.693 0000: E0 11 11 B2 4D 22 48 C0 16 28 26 C8 55 2D 16 00 ....M"H..(&.U-.. D: 2018-11-24 06:30:16.694 0010: 2F / D: 2018-11-24 06:30:16.694 D-Star, raw RSSI: 47, reported RSSI: -47 dBm D: 2018-11-24 06:30:16.696 D-Star, audio sequence no. 0, errs: 0/48 (0.0%) D: 2018-11-24 06:30:16.712 RX D-Star Data D: 2018-11-24 06:30:16.713 0000: E0 0F 11 AE CC 2A 78 E1 13 3C 67 C0 30 02 F2 .....x..<g.0.. D: 2018-11-24 06:30:16.714 D-Star, audio sequence no. 1, errs: 0/48 (0.0%) D: 2018-11-24 06:30:16.731 RX D-Star Data D: 2018-11-24 06:30:16.732 0000: E0 0F 11 CE 8E 2E 39 66 12 78 31 B0 04 2A F9 ......9f.x1... D: 2018-11-24 06:30:16.733 D-Star, audio sequence no. 2, errs: 0/48 (0.0%) D: 2018-11-24 06:30:16.750 RX D-Star Data D: 2018-11-24 06:30:16.751 0000: E0 0F 11 AE CC 2A 78 E1 91 34 67 C0 31 6F C0 .....x..4g.1o. D: 2018-11-24 06:30:16.752 D-Star, audio sequence no. 3, errs: 0/48 (0.0%) D: 2018-11-24 06:30:16.769 RX D-Star Data D: 2018-11-24 06:30:16.770 0000: E0 0F 11 CA 8E 26 19 26 1E 4C A1 F0 3C 00 C5 .....&.&.L..<.. D: 2018-11-24 06:30:16.771 D-Star, audio sequence no. 4, errs: 0/48 (0.0%) D: 2018-11-24 06:30:16.792 RX D-Star Data D: 2018-11-24 06:30:16.793 0000: E0 0F 11 AE CC 2A 78 E1 13 3C 67 C0 32 0A DD .....x..<g.2.. D: 2018-11-24 06:30:16.795 D-Star, audio sequence no. 5, errs: 0/48 (0.0%) D: 2018-11-24 06:30:16.812 RX D-Star Data D: 2018-11-24 06:30:16.812 0000: E0 0F 11 BE 6E 22 48 23 1B 0C 77 80 39 0E B3 ....n"H#..w.9.. D: 2018-11-24 06:30:16.813 D-Star, audio sequence no. 6, errs: 0/48 (0.0%) D: 2018-11-24 06:30:16.830 RX D-Star Data D: 2018-11-24 06:30:16.831 0000: E0 0F 11 CE 8E 22 09 E4 1E 4C 20 F4 33 6F B3 ....."...L .3o. D: 2018-11-24 06:30:16.832 D-Star, audio sequence no. 7, errs: 0/48 (0.0%) D: 2018-11-24 06:30:16.850 RX D-Star Data D: 2018-11-24 06:30:16.850 0000: E0 0F 11 AA CC 2A 78 E1 91 3C 67 C0 50 6F B3 .....x..<g.Po. D: 2018-11-24 06:30:16.851 D-Star, audio sequence no. 8, errs: 0/48 (0.0%) D: 2018-11-24 06:30:16.869 RX D-Star Data D: 2018-11-24 06:30:16.870 0000: E0 0F 11 CE CE AC 31 47 1E 58 E0 F0 16 29 F5 ......1G.X...). D: 2018-11-24 06:30:16.876 D-Star, audio sequence no. 9, errs: 0/48 (0.0%) D: 2018-11-24 06:30:16.888 RX D-Star Data D: 2018-11-24 06:30:16.889 0000: E0 0F 11 AE 8C 2E 68 22 1F 1C 37 84 16 29 F5 ......h"..7..). D: 2018-11-24 06:30:16.890 D-Star, audio sequence no. 10, errs: 0/48 (0.0%) D: 2018-11-24 06:30:16.913 RX D-Star Data D: 2018-11-24 06:30:16.914 0000: E0 0F 11 33 0D A2 01 66 37 41 63 1E E4 6B B7 ...3...f7Ac..k. D: 2018-11-24 06:30:16.915 D-Star, audio sequence no. 11, errs: 4/48 (8.3%) D: 2018-11-24 06:30:16.931 RX D-Star Data D: 2018-11-24 06:30:16.932 0000: E0 0F 11 46 06 D2 12 66 59 55 0E 6A E4 0C C1 ...F...fYU.j... D: 2018-11-24 06:30:16.933 D-Star, audio sequence no. 12, errs: 6/48 (12.5%) D: 2018-11-24 06:30:16.951 RX D-Star Data D: 2018-11-24 06:30:16.951 0000: E0 0F 11 5C 0B C0 14 66 35 3F 1A 11 E4 1F DA ......f5?..... D: 2018-11-24 06:30:16.952 D-Star, audio sequence no. 13, errs: 6/48 (12.5%) D: 2018-11-24 06:30:16.970 RX D-Star Data D: 2018-11-24 06:30:16.971 0000: E0 0F 11 5F 7F A5 73 66 44 5C 08 43 E4 7A A2 ..._..sfD.C.z. D: 2018-11-24 06:30:16.972 D-Star, audio sequence no. 14, errs: 7/48 (14.6%) D: 2018-11-24 06:30:16.989 RX D-Star Data D: 2018-11-24 06:30:16.990 0000: E0 0F 11 5E 7A A3 0E 66 5B 5D 01 1F E4 7B A5 ...^z..f[]...{. D: 2018-11-24 06:30:16.991 D-Star, audio sequence no. 15, errs: 7/48 (14.6%) D: 2018-11-24 06:30:17.008 RX D-Star Data D: 2018-11-24 06:30:17.009 0000: E0 0F 11 42 7F BD 74 66 46 28 6B 1B E4 7F A6 ...B..tfF(k.... D: 2018-11-24 06:30:17.010 D-Star, audio sequence no. 16, errs: 8/48 (16.7%) D: 2018-11-24 06:30:17.033 RX D-Star Data D: 2018-11-24 06:30:17.034 0000: E0 0F 11 40 7B BC 0F 66 04 43 10 66 E4 79 A1 ...@{..f.C.f.y. D: 2018-11-24 06:30:17.035 D-Star, audio sequence no. 17, errs: 6/48 (12.5%) D: 2018-11-24 06:30:17.052 RX D-Star Data D: 2018-11-24 06:30:17.053 0000: E0 0F 11 11 3B F6 2A 66 79 36 63 64 E4 60 A3 ....;.fy6cd.`. D: 2018-11-24 06:30:17.053 D-Star, audio sequence no. 18, errs: 8/48 (16.7%) D: 2018-11-24 06:30:17.071 RX D-Star Data D: 2018-11-24 06:30:17.072 0000: E0 0F 11 30 72 D3 7D 66 34 50 0E 1C E4 0D CE ...0r.}f4P..... D: 2018-11-24 06:30:17.072 D-Star, audio sequence no. 19, errs: 5/48 (10.4%) D: 2018-11-24 06:30:17.090 RX D-Star Data D: 2018-11-24 06:30:17.092 0000: E0 0F 11 B8 72 D3 48 66 55 13 4E 55 E4 6D AE ....r.HfU.NU.m. D: 2018-11-24 06:30:17.093 D-Star, audio sequence no. 20, errs: 8/48 (16.7%) D: 2018-11-24 06:30:17.110 RX D-Star Data D: 2018-11-24 06:30:17.111 0000: E0 11 11 2B 0A DC 02 66 29 36 63 64 55 2D 16 00 ...+...f)6cdU-.. D: 2018-11-24 06:30:17.112 0010: 2F / D: 2018-11-24 06:30:17.114 D-Star, raw RSSI: 47, reported RSSI: -47 dBm D: 2018-11-24 06:30:17.115 D-Star, audio sequence no. 0, errs: 6/48 (12.5%) D: 2018-11-24 06:30:17.137 RX D-Star Data D: 2018-11-24 06:30:17.138 0000: E0 0F 11 51 31 ED 3E 66 0A 13 4E 55 EC 31 ED ...Q1.>f..NU.1. D: 2018-11-24 06:30:17.139 D-Star, audio sequence no. 1, errs: 7/48 (14.6%) D: 2018-11-24 06:30:17.150 RX D-Star Data D: 2018-11-24 06:30:17.151 0000: E0 0F 11 71 4E 92 41 66 75 6C 31 2A EC 31 ED ...qN.Aful1.1. D: 2018-11-24 06:30:17.151 D-Star, audio sequence no. 2, errs: 7/48 (14.6%) D: 2018-11-24 06:30:17.172 RX D-Star Data D: 2018-11-24 06:30:17.172 0000: E0 0F 11 30 72 D3 41 66 49 2D 98 9F E4 0D CE ...0r.AfI-..... D: 2018-11-24 06:30:17.172 D-Star, audio sequence no. 3, errs: 7/48 (14.6%) D: 2018-11-24 06:30:17.188 RX D-Star Data D: 2018-11-24 06:30:17.189 0000: E0 0F 11 4D 0F 9C 13 66 41 5B 79 6A E4 6D AE ...M...fA[yj.m. D: 2018-11-24 06:30:17.189 D-Star, audio sequence no. 4, errs: 7/48 (14.6%) D: 2018-11-24 06:30:17.210 RX D-Star Data D: 2018-11-24 06:30:17.210 0000: E0 0F 11 21 0C C2 03 66 25 13 4E 4C E4 1D ED ...!...f%.NL... D: 2018-11-24 06:30:17.210 D-Star, audio sequence no. 5, errs: 7/48 (14.6%) D: 2018-11-24 06:30:17.232 RX D-Star Data D: 2018-11-24 06:30:17.232 0000: E0 0F 11 02 29 F4 27 66 11 0A 55 58 E4 31 D0 ....).'f..UX.1. D: 2018-11-24 06:30:17.232 D-Star, audio sequence no. 6, errs: 6/48 (12.5%) D: 2018-11-24 06:30:17.248 RX D-Star Data D: 2018-11-24 06:30:17.249 0000: E0 0F 11 02 28 C8 05 66 3B 2F 6D 2B FB 3D F4 ....(..f;/m+.=. D: 2018-11-24 06:30:17.249 D-Star, audio sequence no. 7, errs: 4/48 (8.3%) D: 2018-11-24 06:30:17.270 RX D-Star Data D: 2018-11-24 06:30:17.270 0000: E0 0F 11 70 4F 93 40 66 74 6D 30 2B FB 2A E0 ...pO.@ftm0+.. D: 2018-11-24 06:30:17.270 D-Star, audio sequence no. 8, errs: 6/48 (12.5%) D: 2018-11-24 06:30:17.288 RX D-Star Data D: 2018-11-24 06:30:17.289 0000: E0 0F 11 CE CE A8 21 85 1E 58 61 F4 16 29 F5 ......!..Xa..). D: 2018-11-24 06:30:17.289 D-Star, audio sequence no. 9, errs: 0/48 (0.0%) D: 2018-11-24 06:30:17.310 RX D-Star Data D: 2018-11-24 06:30:17.310 0000: E0 0F 11 AE EC 2A 78 E1 13 3C 67 C0 16 29 F5 .....x..<g..). D: 2018-11-24 06:30:17.310 D-Star, audio sequence no. 10, errs: 0/48 (0.0%) D: 2018-11-24 06:30:17.332 RX D-Star Data D: 2018-11-24 06:30:17.332 0000: E0 0F 11 CE 8E 26 19 26 1E 4C A1 F0 55 55 55 .....&.&.L..UUU D: 2018-11-24 06:30:17.332 D-Star, audio sequence no. 11, errs: 0/48 (0.0%) M: 2018-11-24 06:30:17.337 Debug: DStarRX: Found end sync in Data D: 2018-11-24 06:30:17.337 RX D-Star EOT D: 2018-11-24 06:30:17.338 0000: E0 03 13 ... M: 2018-11-24 06:30:17.343 D-Star, received RF end of transmission, 0.7 seconds, BER: 7.7%, RSSI: -47/-47/-47 dBm D: 2018-11-24 06:30:18.088 TX D-Star Header D: 2018-11-24 06:30:18.089 0000: E0 2C 10 01 00 00 53 35 36 49 41 52 20 42 53 35 .,....S56IAR BS5 D: 2018-11-24 06:30:18.089 0010: 36 49 41 52 20 47 53 35 36 49 41 52 20 20 53 35 6IAR GS56IAR S5 D: 2018-11-24 06:30:18.090 0020: 36 49 41 52 20 42 20 20 20 20 CC B2 6IAR B .. D: 2018-11-24 06:30:18.101 TX D-Star Data D: 2018-11-24 06:30:18.101 0000: E0 0F 11 9E 8D 32 88 26 1A 3F 61 E8 55 2D 16 .....2.&.?a.U-. D: 2018-11-24 06:30:18.113 TX D-Star Data D: 2018-11-24 06:30:18.114 0000: E0 0F 11 9E 8D 32 88 26 1A 3F 61 E8 30 1D D6 .....2.&.?a.0.. D: 2018-11-24 06:30:18.125 TX D-Star Data D: 2018-11-24 06:30:18.126 0000: E0 0F 11 9E 8D 32 88 26 1A 3F 61 E8 36 7F A0 .....2.&.?a.6.. D: 2018-11-24 06:30:18.140 TX D-Star Data D: 2018-11-24 06:30:18.140 0000: E0 0F 11 9E 8D 32 88 26 1A 3F 61 E8 31 7F B3 .....2.&.?a.1.. D: 2018-11-24 06:30:18.151 TX D-Star Data D: 2018-11-24 06:30:18.151 0000: E0 0F 11 9E 8D 32 88 26 1A 3F 61 E8 34 6F B3 .....2.&.?a.4o. D: 2018-11-24 06:30:18.162 TX D-Star Data D: 2018-11-24 06:30:18.162 0000: E0 0F 11 9E 8D 32 88 26 1A 3F 61 E8 32 0D D6 .....2.&.?a.2.. D: 2018-11-24 06:30:18.172 TX D-Star Data D: 2018-11-24 06:30:18.173 0000: E0 0F 11 9E 8D 32 88 26 1A 3F 61 E8 22 75 B3 .....2.&.?a."u. D: 2018-11-24 06:30:18.183 TX D-Star Data D: 2018-11-24 06:30:18.183 0000: E0 0F 11 9E 8D 32 88 26 1A 3F 61 E8 33 78 BD .....2.&.?a.3x. D: 2018-11-24 06:30:18.194 TX D-Star Data D: 2018-11-24 06:30:18.194 0000: E0 0F 11 9E 8D 32 88 26 1A 3F 61 E8 47 6A B3 .....2.&.?a.Gj. D: 2018-11-24 06:30:18.205 TX D-Star Data D: 2018-11-24 06:30:18.205 0000: E0 0F 11 9E 8D 32 88 26 1A 3F 61 E8 16 29 F5 .....2.&.?a..). D: 2018-11-24 06:30:18.217 TX D-Star Data D: 2018-11-24 06:30:18.217 0000: E0 0F 11 9E 8D 32 88 26 1A 3F 61 E8 16 29 F5 .....2.&.?a..). D: 2018-11-24 06:30:18.229 TX D-Star Data D: 2018-11-24 06:30:18.230 0000: E0 0F 11 9E 8D 32 88 26 1A 3F 61 E8 16 29 F5 .....2.&.?a..). D: 2018-11-24 06:30:18.241 TX D-Star Data D: 2018-11-24 06:30:18.242 0000: E0 0F 11 9E 8D 32 88 26 1A 3F 61 E8 16 29 F5 .....2.&.?a..). D: 2018-11-24 06:30:18.253 TX D-Star Data D: 2018-11-24 06:30:18.254 0000: E0 0F 11 9E 8D 32 88 26 1A 3F 61 E8 16 29 F5 .....2.&.?a..). D: 2018-11-24 06:30:18.266 TX D-Star Data D: 2018-11-24 06:30:18.267 0000: E0 0F 11 9E 8D 32 88 26 1A 3F 61 E8 16 29 F5 .....2.&.?a..). D: 2018-11-24 06:30:18.278 TX D-Star Data D: 2018-11-24 06:30:18.279 0000: E0 0F 11 9E 8D 32 88 26 1A 3F 61 E8 16 29 F5 .....2.&.?a..). D: 2018-11-24 06:30:18.290 TX D-Star Data D: 2018-11-24 06:30:18.291 0000: E0 0F 11 9E 8D 32 88 26 1A 3F 61 E8 16 29 F5 .....2.&.?a..). D: 2018-11-24 06:30:18.302 TX D-Star Data D: 2018-11-24 06:30:18.303 0000: E0 0F 11 9E 8D 32 88 26 1A 3F 61 E8 16 29 F5 .....2.&.?a..). D: 2018-11-24 06:30:18.314 TX D-Star Data D: 2018-11-24 06:30:18.315 0000: E0 0F 11 9E 8D 32 88 26 1A 3F 61 E8 16 29 F5 .....2.&.?a..). D: 2018-11-24 06:30:18.326 TX D-Star Data D: 2018-11-24 06:30:18.327 0000: E0 0F 11 9E 8D 32 88 26 1A 3F 61 E8 16 29 F5 .....2.&.?a..). D: 2018-11-24 06:30:18.338 TX D-Star EOT D: 2018-11-24 06:30:18.339 0000: E0 03 13 ...* M: 2018-11-24 06:30:23.121 Debug: DStarRX: found frame sync in None, fuzzy M: 2018-11-24 06:30:38.189 Debug: Mode set to Idle M: 2018-11-24 06:31:51.671 Debug: DStarRX: found frame sync in None, fuzzy M: 2018-11-24 06:32:29.600 Debug: DStarRX: found frame sync in None, fuzzy

ravny commented 5 years ago

I have installed this version of D-RATS software

image

timclassic commented 5 years ago

A rudimentary translation of the table in section 6.1.3 of the JARL document, of which rows 8x and 9x seem relevant. A follow-up post will refer to the mini header as the "Pin header."

6.1.3 Assignment of mini header

Mini-header list

Header number x Range (bytes) Use Function, Supplement
0x ------ Reserved ------------
1x ------ Reserved ------------
2x ------ Reserved ------------
3x 1 to 5 Simple data communication Used for character transfer of user's data communication such as PC. Data communication of D-PRS is treated as simple data communication. *The range indicates the number of valid characters per block
4x 0 to 3 (block number) Message function Use it for messages handled by radio unit alone. *Only the message function indicates the data block number
5x 1 to 5 Wireless header retransmission Retransmit the wireless header
6x ------ Reserved ------------ (Excluding x = 6)
66 ------ No data Indicates no data of data frame
7x ------ Reserved ------------
8x 1 to F Fast data Fast data length Indicates from 1 byte to 15 bytes
9x 0 to C Fast data Fast data length Indicates from 16 bytes to 28 bytes
Ax ------ Reserved ------------
Bx ------ Reserved ------------
Cx 2 Code squelch Two-digit code of code squelch
Dx ------ Reserved ------------
Ex ------ Reserved ------------
Fx ------ Reserved ------------

If there is no data in the data frame, embed the part without data 0x66 [not sure about this translation - Ed.]. Reserved: Reserved for special purpose or planned for future use. For "8x" and "9x", see "Chapter 7 Fast Data".

timclassic commented 5 years ago

I've attached an English translation of Sections 7.1 and 7.2: D-Star_Data Drame (Fast Data).pdf

This PDF was sent to me by Kenwood and appears to be derived from http://www.jarl.com/d-star/STD5_0b.pdf. I thanked them, and replied asking if they had more of the document in English that could be shared.

timclassic commented 5 years ago

(side note: Kenwood reaffirmed to me that their fast data mode is compatible with Icom's)

My current theory is that we can look for 8x and 9x in the mini header (Pin header) to determine specifically which voice frames are Fast Data and only avoid FEC recalculation on those particular frames.

Based on the layout described in section 7.2, getting the mini header before FEC recalc may require buffering for the so-called "1st block" since the data frame that contains the mini header is well into the block (as opposed to blocks 2-10, which allow you to get the mini-header for the block in the first Voice+Data frame read per block).

That's all the time I have for tonight--goodnight!

timclassic commented 5 years ago

@ravny Since you have your radio set to Fast Data, and have the latest patches to MMDVMHost, I'm not sure why you don't see it switching to Icom data mode in the logs. Maybe the newfound technical info will make things clear soon.

timclassic commented 5 years ago

I've made some progress decoding the traces that people have pasted here. There are still a few things I need to figure out, but I'll update here in a day or two when I've got my head around things.

g4klx commented 5 years ago

I'll be interested in what you discover. It would appear that the current detection of fast data is incorrect, and so any pointers to the correct implementation would be appreciated. We'll get it right eventually!

juribeparada commented 5 years ago

Nice to see that we have the JARL document now. I will try to see the document soon.

timclassic commented 5 years ago

@juribeparada's message motivated me to update this thread on my status. I'm translating section 7.3 of JARL's PDF right now into English (encoded as LaTeX), which (I believe) will fill in the remaining gaps. I mention this so that nobody tries to duplicate the effort, since I'm nearly done.

I plan to upload a PDF later tonight, or tomorrow at the latest. I believe it will contain everything necessary to detect DV Fast Data, and even generate it if we like.

timclassic commented 5 years ago

Random Things

Here are some things I think I've figured out:

JARL D-Star Standard

I've translated Sections 6.1.3, 7.1, 7.2, 7.3, and part of 7.4 of http://www.jarl.com/d-star/STD5_0b.pdf and put them in this English PDF. The English Word document that Kenwood sent provided some language and the images for sections 7.1 and 7.2.

Detecting DV Fast Data

I'll use @juribeparada's work again to demonstrate how to detect DV Fast Data frames. His test using ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789 is quite appropriate for this.

Here is block E from https://github.com/g4klx/MMDVMHost/issues/470#issuecomment-437725678, corrected to use 0x70 for descrambling instead of 0xE2 as described above:

45 46 47 48 02 49 4A 4B 4C 94 41 42     EFGH.IJKL.AB
4D 4E 4F 50 02 51 52 53 54 94 43 44     MNOP.QRST.CD
59 5A 61 62 02 63 64 65 66 94 55 56     YZab.cdef.UV
67 68 69 6A 02 6B 6C 6D 6E 94 57 58     ghij.klmn.WX
73 74 75 76 02 77 78 79 7A 94 6F 70     stuv.wxyz.op
30 31 32 33 02 34 35 36 37 94 71 72     0123.4567.qr
00 00 00 00 02 00 00 00 00 82 38 39     ..........89
00 00 00 00 02 00 00 00 00 82 00 00     ............

Here is an annotated version of block E using the information from the English PDF, separated into blocks:

                  Noise Reduction       Mini Header/Guard
                  |                     |
     |--Data---|  |   |--Data---|       |   |Data/                 Mini Header Meaning
  Block 6      |  |   |         |       |   |   |                  |
V12: 45 46 47 48  02  49 4A 4B 4C  D12: 94  41 42   EFGH.IJKL.AB   Fast Data, 20 bytes
V13: 4D 4E 4F 50  02  51 52 53 54  D13: 94  43 44   MNOP.QRST.CD   (Guard)
     |         |  |   |         |       |   |   |                  |
  Block 7      |  |   |         |       |   |   |                  |
V14: 59 5A 61 62  02  63 64 65 66  D14: 94  55 56   YZab.cdef.UV   Fast Data, 20 bytes
V15: 67 68 69 6A  02  6B 6C 6D 6E  D15: 94  57 58   ghij.klmn.WX   (Guard)
     |         |  |   |         |       |   |   |                  |
  Block 8      |  |   |         |       |   |   |                  |
V16: 73 74 75 76  02  77 78 79 7A  D16: 94  6F 70   stuv.wxyz.op   Fast Data, 20 bytes
V17: 30 31 32 33  02  34 35 36 37  D17: 94  71 72   0123.4567.qr   (Guard)
     |         |  |   |         |       |   |   |                  |
  Block 9      |  |   |         |       |   |   |                  |
V18: 00 00 00 00  02  00 00 00 00  D18: 82  38 39   ..........89   Fast Data, 2 bytes
V19: 00 00 00 00  02  00 00 00 00  D19: 82  00 00   ............   (Guard)

I don't think we should depend on the Guard values. In the examples above, the Guard byte appears to take on the value from the previous frame, but I suspect this is just an implementation detail in these radios. According to Section 7.3, the important thing is that they don't match the packet loss pattern.

Avoiding FEC Recalculation

I think that detecting voice frames that containing Fast Data is simply a matter of detecting in each block a mini header starting with 0x8n or 0x9n (after descrambling), where n is arbitrary. I've verified this using both Kenwood and Icom data dumps in this issue.

The only potential complication I can see is handling Block 1, where we need to hold off recalculating the FEC on voice frame 1 until we receive data frame 2 and check its mini header to determine whether voice frame 1 contains voice or data.

I happy to put together an annotated example of Block 1 if its layout isn't clear from the document and the description above. Just let me know.

timclassic commented 5 years ago

To give credit where it is due, I should mention that much of the information I just posted is a restatement of the Twitter thread @g4klx linked to at https://twitter.com/isithran/status/1063164783342641152. It was a useful exercise, though, because I didn't really understand the Twitter posts until I went through and decoded our examples myself.

juribeparada commented 5 years ago

Thank you Tim for the work. Now some parts are clearer. I haven't had enough time to return to see this again, but eventually I will do.

timclassic commented 5 years ago

A small update: I haven't had any time to work on this primarily due to the holidays. However, I do now possess an Icom ID-4100, so I will be able to do end-to-end tests of any code changes.

I plan to try creating a patch based on the new information (unless @g4klx beats me to it), but I don't have en ETA as of yet.

g4klx commented 5 years ago

Hi Tim I’ve not had time to look into this issue☹️ If you manage to find a way to detect the mode flip to fast data, that’s all we really need. We can then switch off the AMBE FEC code and pass the fast data through unmolested. If we can detect the flip back to audio then even better. If we fail to detect this second mode flip it only means that the system is a little less than optimum for the rest of the transmission which I think we can live with.

Sent from Yahoo Mail for iPhone

On Sunday, January 13, 2019, 01:10, Tim Stewart notifications@github.com wrote:

A small update: I haven't had any time to work on this primarily due to the holidays. However, I do now possess an Icom ID-4100, so I will be able to do end-to-end tests of any code changes.

I plan to try creating a patch based on the new information (unless @g4klx beats me to it), but I don't have en ETA as of yet.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub, or mute the thread.

g4klx commented 5 years ago

I've done a quick change to the fast data detection code and put it into the fast_data branch (also for ircDDBGateway) which I hope will detect the mini header (called slow data in my code) nibbles that signal the presence of fast data.

g4klx commented 5 years ago

Can someone comment on this change please? I've done some small changes since to clean up the code but otherwise it's pretty close to being correct. It would be nice to have this signed off so I can merge it into master and make it available to all.

phl0 commented 5 years ago

I would be available for another d-rats test :)

g4klx commented 5 years ago

Even just transmitting a small file to CQCQCQ would be useful. This would test to see if the fast data detection was working now, particularly for the Icom.

timclassic commented 5 years ago

@g4klx I will test with my TH-D74A and ID-4100 tomorrow evening. At the moment I have only one operational hotspot, so I'll test with test CQCQCQ and ___E.

@phl0 I plan to work on this between 2019-01-31T01:00Z and 2019-01-31T04:30Z. If you're available, perhaps we can attempt a QSO on REF030D. If that doesn't work, feel free to suggest a different time! (Maybe over the weekend?)

phl0 commented 5 years ago

@timclassic Those are hard times for me. It is 2am to 5.30am at that time over here. I will try to be on air.

timclassic commented 5 years ago

@phl0 I hope you're asleep right now! If not, I hope to be on 30C in about 30 minutes.

phl0 commented 5 years ago

@timclassic Are you still on there? If so I am going to start my machines.

phl0 commented 5 years ago

@timclassic I am on REF030 D now. Seems like I am the only one :) U still there?

phl0 commented 5 years ago

Is this sufficient for a test result?

bildschirmfoto vom 2019-01-31 06-33-50

timclassic commented 5 years ago

I've only tested so far with my TH-D74A. Here are my results with the latest code from master. I did an echo test.

MMDVMHost logs:

D: 2019-01-31 05:35:32.376 D-Star, raw RSSI: 47, reported RSSI: -47 dBm
M: 2019-01-31 05:35:32.376 D-Star, received RF header from KG4BXH  /D74  to        E
D: 2019-01-31 05:35:32.393 D-Star, raw RSSI: 47, reported RSSI: -47 dBm
D: 2019-01-31 05:35:32.394 D-Star, audio sequence no. 0, errs: 0/48 (0.0%)
D: 2019-01-31 05:35:32.411 D-Star, audio sequence no. 1, errs: 0/48 (0.0%)
D: 2019-01-31 05:35:32.433 D-Star, audio sequence no. 2, errs: 0/48 (0.0%)
D: 2019-01-31 05:35:32.455 D-Star, audio sequence no. 3, errs: 0/48 (0.0%)
D: 2019-01-31 05:35:32.472 D-Star, audio sequence no. 4, errs: 0/48 (0.0%)
D: 2019-01-31 05:35:32.494 D-Star, audio sequence no. 5, errs: 0/48 (0.0%)
D: 2019-01-31 05:35:32.512 D-Star, audio sequence no. 6, errs: 0/48 (0.0%)
D: 2019-01-31 05:35:32.531 D-Star, audio sequence no. 7, errs: 0/48 (0.0%)
D: 2019-01-31 05:35:32.551 D-Star, audio sequence no. 8, errs: 0/48 (0.0%)
D: 2019-01-31 05:35:32.574 D-Star, audio sequence no. 9, errs: 0/48 (0.0%)
D: 2019-01-31 05:35:32.594 D-Star, audio sequence no. 10, errs: 0/48 (0.0%)
D: 2019-01-31 05:35:32.612 D-Star, audio sequence no. 11, errs: 0/48 (0.0%)
D: 2019-01-31 05:35:32.631 D-Star, audio sequence no. 12, errs: 0/48 (0.0%)
D: 2019-01-31 05:35:32.655 D-Star, audio sequence no. 13, errs: 0/48 (0.0%)
D: 2019-01-31 05:35:32.672 D-Star, audio sequence no. 14, errs: 0/48 (0.0%)
D: 2019-01-31 05:35:32.692 D-Star, audio sequence no. 15, errs: 0/48 (0.0%)
D: 2019-01-31 05:35:32.715 D-Star, audio sequence no. 16, errs: 0/48 (0.0%)
D: 2019-01-31 05:35:32.733 D-Star, audio sequence no. 17, errs: 0/48 (0.0%)
D: 2019-01-31 05:35:32.751 D-Star, audio sequence no. 18, errs: 0/48 (0.0%)
D: 2019-01-31 05:35:32.771 D-Star, audio sequence no. 19, errs: 0/48 (0.0%)
D: 2019-01-31 05:35:32.791 D-Star, audio sequence no. 20, errs: 0/48 (0.0%)
D: 2019-01-31 05:35:32.814 D-Star, raw RSSI: 47, reported RSSI: -47 dBm
D: 2019-01-31 05:35:32.816 D-Star, audio sequence no. 0, errs: 7/48 (14.6%)
M: 2019-01-31 05:35:32.831 D-Star, switching to fast data mode
D: 2019-01-31 05:35:33.232 D-Star, raw RSSI: 47, reported RSSI: -47 dBm
M: 2019-01-31 05:35:33.337 D-Star, received RF end of transmission, 1.0 seconds, BER: 0.0%, RSSI: -47/-47/-47 dBm
M: 2019-01-31 05:35:35.339 D-Star, received network header from KG4BXH  /ECHO to CQCQCQ  
M: 2019-01-31 05:35:35.801 D-Star, switching to fast data mode
M: 2019-01-31 05:35:36.319 D-Star, received network end of transmission, 1.0 seconds, 0% packet loss, BER: 0.0%

The logs show 21 voice frames corresponding with 10 blocks, which I believe is empty voice data combined with the slow data for the screen message. Then the data starts and you can see "switching to fast data mode." However, just before the switch to fast data, we receive a single voice frame with a BER of 14.6%, when the block sequence is starting again, and I believe this is voice frame 1 in block 1.

vbindiff output of PuTTY logs showing what I sent and what was echoed back to me:

dstar-sent.log                                                                  
0000 0000: 41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  AAAAAAAA AAAAAAAA  
0000 0010: 41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  AAAAAAAA AAAAAAAA  
0000 0020: 41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  AAAAAAAA AAAAAAAA  
0000 0030: 41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  AAAAAAAA AAAAAAAA  
0000 0040: 41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  AAAAAAAA AAAAAAAA  
0000 0050: 41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  AAAAAAAA AAAAAAAA  
0000 0060: 41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  AAAAAAAA AAAAAAAA  
0000 0070: 41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  AAAAAAAA AAAAAAAA  
0000 0080: 41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  AAAAAAAA AAAAAAAA  
0000 0090: 41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  AAAAAAAA AAAAAAAA  
0000 00A0: 41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  AAAAAAAA AAAAAAAA  
0000 00B0: 41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  AAAAAAAA AAAAAAAA  
0000 00C0: 41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  AAAAAAAA AAAAAAAA  
0000 00D0: 41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  AAAAAAAA AAAAAAAA  
0000 00E0: 41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  AAAAAAAA AAAAAAAA  
0000 00F0: 0D 0A                                             ..                 

dstar-received.log                                                              
0000 0000: 41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  AAAAAAAA AAAAAAAA  
0000 0010: 41 41 41 41 40 43 61 41  45 41 C1 45 41 41 41 41  AAAA@CaA EA.EAAAA  
0000 0020: 41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  AAAAAAAA AAAAAAAA  
0000 0030: 41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  AAAAAAAA AAAAAAAA  
0000 0040: 41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  AAAAAAAA AAAAAAAA  
0000 0050: 41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  AAAAAAAA AAAAAAAA  
0000 0060: 41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  AAAAAAAA AAAAAAAA  
0000 0070: 41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  AAAAAAAA AAAAAAAA  
0000 0080: 41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  AAAAAAAA AAAAAAAA  
0000 0090: 41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  AAAAAAAA AAAAAAAA  
0000 00A0: 41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  AAAAAAAA AAAAAAAA  
0000 00B0: 41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  AAAAAAAA AAAAAAAA  
0000 00C0: 41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  AAAAAAAA AAAAAAAA  
0000 00D0: 41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  AAAAAAAA AAAAAAAA  
0000 00E0: 41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  AAAAAAAA AAAAAAAA  
0000 00F0: 0D 0A                                             ..

All looks well with this test except for the corruption at bytes 21-28. These bytes correspond exactly with "1st voice" in block 1 if you look at section 7.3 of the translated PDF.

In https://github.com/g4klx/MMDVMHost/issues/470#issuecomment-444336386 above, I worried:

The only potential complication I can see is handling Block 1, where we need to hold off recalculating the FEC on voice frame 1 until we receive data frame 2 and check its mini header to determine whether voice frame 1 contains voice or data.

I think this is what we are seeing here.

I don't understand the overall control flow well, but from what I've read this particular requirement may not fit well with the current implementation. @g4klx, what do you think? Would it be straightforward to set aside voice frame 1 (always voice+sync) for one round and then handle it once the next voice+data frame is received and the mini header is available?

Regarding @phl0's log, I don't know how to explain the three 14.46% BER voice frames (sequence numbers 0-2). @phl0, is it possible that your RX started late? What kind of radio was it?

Also, I still plan to try with my ID-4100 but I expect I'll see the same issue there. For what it's worth, I think we're very close to the correct solution here.

phl0 commented 5 years ago

@timclassic Are you still online/on air?

phl0 commented 5 years ago

bildschirmfoto vom 2019-01-31 08-13-20

Guess it was a one time issue. Did some DStar Queries to " E".

timclassic commented 5 years ago

(@phl0 I'm sorry we didn't connect--I only saw your post right as I was shutting down for the night. I really hope you didn't trade any sleep to be ignored by me!)

phl0 commented 5 years ago

@timclassic Never mind. Sleep is overvalued :) Want to make a new sked? My equipment is still on the table :)

phl0 commented 5 years ago

I did test again with @timclassic Results:

  1. It works (switching to fast data mode)
  2. We had several errors in single transmissions. Obviously caused by missing error correction on application level
hipmark commented 3 years ago

Mentioned this issue in an article I have written on D-Star Picture Mode, which will appear in the December 2020 issue of RSGB RadCom Magazine. The article talks about transfer of images using DV Fast Data mode, and unfortunately this issue prevents users of low-cost MMDVM hotspots (Pi-Star & others) from transmitting images in Fast Data mode.

Would be nice to see D-Star DV Fast Data mode fully implemented and supported in MMDVMHost; anything I/we (@timclassic @phl0) can do to help progress of this issue towards a fix?

Thanks, Mark, M5BOP

timclassic commented 3 years ago

@hipmark, I'm planning to revisit this issue over the next week or two. It has come up again in my own projects since I'm trying to build a digital radio using a Kenwood TM-V7 and the MMDVM_PCM code + MMDVMHost modifications[1] described at the DUDE-Star Radio Project. As a part of this I would love to get DV Fast Data working.

Conceptually I think I know what needs to be done--I still believe that https://github.com/g4klx/MMDVMHost/issues/470#issuecomment-459227905 captures the final piece of the puzzle (famous last words).

I hope to send @g4klx a PR with a solution in the next week or two. Maybe @phl0 will be up for another test?

[1] I think the MMDVMHost modifications are represented by https://github.com/g4klx/MMDVMHost/pull/647. Maybe there are additional changes? I haven't diffed the two repos to check.

g4klx commented 3 years ago

Hi Mark I originally implemented fast data mode about two years ago based on data dumps from an ID-51 and a TH-D74 and the somewhat obscure description in the D-Star specification. Within the MMDVM and I think ircDDB Gateway was to disable the FEC regeneration and DTMF processing for the duration of the transmission. If fast data is detected then it puts an entry into the log to say so. It should pass through them without difficulty, but I may have missed something. If you do find a bug then I would be most interested. I got my RadCom today so I held off before replying. I think it’s the first time that the MMDVM has been mentioned in the magazine. I keep meaning to do a write up of the project, but never get around to it. Jonathan G4KLX 

Sent from Yahoo Mail for iPhone

On Friday, November 13, 2020, 22:32, hipmark notifications@github.com wrote:

Mentioned this issue in an article I have written on D-Star Picture Mode, which will appear in the December 2020 issue of RSGB RadCom Magazine. The article talks about transfer of images using DV Fast Data mode, and unfortunately this issue prevents users of low-cost MMDVM hotspots (Pi-Star & others) from transmitting images in Fast Data mode.

Would be nice to see D-Star DV Fast Data mode fully implemented and supported in MMDVMHost; anything I/we can do to help progress of this issue towards a fix?

Thanks, Mark, M5BOP

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub, or unsubscribe.

hipmark commented 3 years ago

If you do find a bug then I would be most interested.

Hi Jonathan, thanks for your rapid reply. Please see comments from @timclassic above - he believes that #470 (comment) captures the final piece of the puzzle needed to fully implement DV Fast Data mode (famous last words). Tim is going to take another look at the code based on his findings and send you a PR if he can get to the bottom of this.

I think it’s the first time that the MMDVM has been mentioned in the magazine. I keep meaning to do a write up of the project, but never get around to it.

I believe MMDVM is a fantastic piece of work that has really been under-sung - many people know about Pi-Star, but really don't understand the excellent engineering under the covers that has made low-cost multimode digital hotspots possible. From comments I've read, I'm sure the creators of Pi-Star agree entirely - and for this reason I think you really should write an article about your journey in developing MMDVM. I'd never written for a radio mag before, but with the excellent editing skills of Giles G1MFG at RSGB, I'm really pleased with how my humble efforts turned out!

73 & stay safe! Mark, M5BOP

timclassic commented 3 years ago

@hipmark and @g4klx, just a quick update to say that I’m testing a patch that so far has greatly improved the reliability of sending and receiving Fast Data via MMDVMHost. I have a bit more testing to do, but I plan to submit a PR for review this upcoming weekend.

Stay tuned!

timclassic commented 3 years ago

@phl0 and @hipmark, let me know if either of you would like to do some fast data testing now that #667 has been merged. I'm happy to make a sked, and weekends are generally good for me.

@g4klx, thanks in general for all the work on MMDVM!

phl0 commented 3 years ago

Tnx @timclassic. I'll get my equipment ready. Need to set D-Rats up on my new computer. Which reflector are you on usually?

hipmark commented 3 years ago

Hey Tim @timclassic,

Thanks for all your hard work on Fast Data patches for MMDVM-Host under #667 - sorry for delay in reply until now; have been busy as was our baby’s first Christmas and so wanted to have some focussed family time, but now free to do some testing if that is still helpful / get an update on any testing you’ve done with @phl0

Do I need a special build on my Pi-Star MMDVM hotspot to test; or have Pi-Star now taken the required MMDVM-Host build? I’m currently running Pi-Star 4.1.3 with Linux Kernel 4.19.97+

Thanks @g4klx for another year of sterling support on MMDVM!

Best regards, Mark, M5BOP

On 15 Dec 2020, at 01:44, Tim Stewart notifications@github.com wrote:

@phl0 and @hipmark, let me know if either of you would like to do some fast data testing now that #667 has been merged. I'm happy to make a sked, and weekends are generally good for me.

@g4klx, thanks in general for all the work on MMDVM!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

hipmark commented 3 years ago

Tnx @timclassic. Which reflector are you on usually?

D-Star Picture Net is held weekly on REF072D, so that is where I usually hang out for picture TX/RX. Mark, M5BOP

s-s-s commented 3 years ago

"Conclusion

The ID-51 E3 release somehow switches to Fast Data Mode as soon as it transmits GPS Data. Once it does this it does not send the End of Transmission frame.

This behavior confuses both MMDVM gear and Icom gear. Both will then wait for a timeout and then decide the transmission is gone. Hence the 3s delay on the IC-E92D before end of transmission beep and the garbled R2D2 tail signal on the MMDVM.

The workaround is to switch GPS data off.

Downgrading the ID-51E Anniversary Edition to firmware release pre-November 5th solved the issue."

https://www.f4fxl.org/buggy-icom-id-51-and-id-5100-firmware/

timclassic commented 3 years ago

@hipmark I'll be on the D-Star Picture Net tonight as well. I plan to send images from both my IC-9700 and my TH-D74 (by way of RS-MS1A).

@hipmark and @phl0, I'll look up your contact info on QRZ and we can work out further testing that way, so we don't have to pollute this Issue with scheduling details. I suspect we can close this issue once we do some a bit more testing with images and D-RATS.

g4klx commented 3 years ago

I would like it confirmed that these changes don't affect normal D-Star voice operation. I'm not concerned about the modem/hotspot changes so much, more the changes within the host. On Thursday, 31 December 2020, 01:41:52 GMT, Tim Stewart notifications@github.com wrote:

@hipmark I'll be on the D-Star Picture Net tonight as well. I plan to send images from both my IC-9700 and my TH-D74 (by way of RS-MS1A).

@hipmark and @phl0, I'll look up your contact info on QRZ and we can work out further testing that way, so we don't have to pollute this Issue with scheduling details. I suspect we can close this issue once we do some a bit more testing with images and D-RATS.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub, or unsubscribe.

timclassic commented 3 years ago

@g4klx I've been using the Fast Data changes on both of my hotspots since submitting #667 and voice traffic has been working well.

I also created #675 today so I could watch logs in a more useful way while listening to REF030C for a few hours. All looks well.

Maybe some others (@hipmark and/or @phl0, perhaps?) would be willing to run the latest MMDVMHost for a while and report back with their results, so we could become more confident in the changes?

(Oh, and I did attend the D-Star Picture Net and it went well! The image I sent had good reports from others and the images I received were as good as or better than the quality reported by others on the net. @hipmark sent a nice picture of the moon.)

hipmark commented 3 years ago

Hi Jonathan @g4klx & Tim - is it possible to build a version of MMDVMHost for ARM with Tim’s fixes and inject that into my Pi-Star hotspot - if so I can then use that as my primary hotspot to help validate that changes have no negative impact on D-Star voice. If so, can anyone advise how to do this/provide suitably built components - not familiar with MMDVMHost build process!

@timclassic - what is your callsign? Can then use QRZ to find e-Mail & set up a test sked with you for this weekend.

Cheers Mark @hipmark (glad you liked the Moon pic Tim!)

On 2 Jan 2021, at 00:20, Tim Stewart notifications@github.com wrote:

@g4klx I've been using the Fast Data changes on both of my hotspots since submitting #667 and voice traffic has been working well. I also created #675 today so I could watch logs in a more useful way while listening to REF030C for a few hours. All looks well.

Maybe some others (@hipmark and/or @phl0, perhaps?) would be willing to run the latest MMDVMHost for a while and report back with their results, so we could become more confident in the changes?

(Oh, and I did attend the D-Star Picture Net and it went well! The image I sent had good reports from others and the images I received were as good as or better than the quality reported by others on the net. @hipmark sent a nice picture of the moon.)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.