search

juribeparada / MMDVM_HS

MMDVM HotSpot: firmware for ZUMspot or MMDVM_HS based boards (D-Star, DMR, YSF, P25, NXDN and POCSAG)
GNU General Public License v2.0
348 stars 140 forks source link

leading sync frame missing and oversized packets #84

Closed n7tae closed 5 years ago

n7tae commented 5 years ago

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):

  1. The size of of a header frame is always 46 bytes according to the second byte of the header packet, not 44. The extra two bytes at the end 0x00 0x2F.
  2. The leading D-Star sync frame (right after the header) is not transmitted. The first data frame received after the header is a non-sync frame. After that, sync frames appear after every 20 non-sync frames as they should.
  3. It seems that all sync frames are always 17 bytes long, not 15. Only non-sync frame are 15 bytes long. The extra bytes are also 0x00 0x2F.

If these are new features and not bugs, it would be wonderful if someone could update "The MMDVM Specification" document.

juribeparada commented 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.

n7tae commented 5 years ago

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.