Closed n7tae closed 5 years ago
It is not a bug, I think the "The MMDVM Specification" document that you are seeing is outdated. The MMDVM_HS project (personal hotspots based on ADF7021) follows the modem specification from the original MMDVM project (which uses analog radios, see https://github.com/g4klx/MMDVM). This is because MMDVM_HS project must be compatible with MMDVMHost. For most of the modes (DMR, YSF, P25, NXDN), the modem is almost transparent for the RF data, except for D-Star, where some processing is done inside the modem (like D-Star header processing). The modem perform sync detection, EOF detection, etc, but not all exact RF data is transfer through the modem interface. 1) The extra two bytes are for RSSI information. This is optional, can be turned off if you compile a custom firmware, but the default binary firmware for ZUMspot includes RSSI support. This was added in the MMDVM project in 2017 by Jonathan G4KLX. In the case of MMDVM_HS, the value corresponds to dBm: 0x2F = 47, -47 dBm, the maximum RSSI that ADF7021 can measure. 2) There is a frame sync in the D-Star protocol, after the preamble and before the header. This is detected internally in the modem, but is not transmitted, just the decoded header, then data frames. This is the same behavior of MMDVM. 3) Yes, just data frames with sync flag includes RSSI information.
Okay thanks for the info on RSSI.
On #2, I'm not talking about the preamble sync before the encoded header. The first data frame immediately after the header should be a sync frame (last three byte are 0x55 0x2D 0x16). It's what D-Star radios do. After the header, my ZUMspot produces 20 non-sync voice frames before the first sync voice frame on the serial port, even though my ID-51 is transmitting a sync data frame immediately after the header.
It's an easy problem to correct at my end, but If I take the data and send it on without correction, any receiving D-Star radio will complain with a beep after the first super-frame. I only have one other MMDVM-compatible modem to play with, but it does produce a sync data frame immediately after the header.
I'll close this issue now and you can fix it, or not. At least it's documented.
I have been working on supporting MMDVM modems directly in my own ircddb gateway application and have found some "unusual" behavior of my ZUMspot (running version 1.4.14):
If these are new features and not bugs, it would be wonderful if someone could update "The MMDVM Specification" document.