g4klx
commented
3 years ago That's very interesting. The first four bytes are internal signaling between the host and the modem so will always be correct, they aren't transmitted. The next two bytes are the sync word, 0x32 0x43, which appears to be corrupt on many of the frames. The 0x00 or 0x01 before the sync bytes indicate that the sync was detected by the modem or not, a number of bit errors are allowed as you can see. The same byte on transmit is included for orthogonality but isn't used for anything.
I would say that the issue is because the parameters for the HS version of M17 aren't quite correct. I am fairly happy with the transmit parameters, but the receive side is much more complex and to be honest I didn't understand them! If one side of your system was MMDVM modem based, then I think you'd see data flowing in one direction at least. Andy is looking at my parameters so I hope that it'll be correct soon, and maybe see M17 rolled into the official MMDVM_HS firmware.
nostar
I have 2 hotspots setup where I TX from one and watch for RX on the other. It seems like the data is being corrupted over RF from what I have so far.
Here is a clip of 2 M17 RF packets from HS A:
The key here is that the first 6 bytes are always E0 34 45 00 32 43, as they should be. On RX from HS B, it takes anywhere from 5 seconds to 30 seconds or more to start receiving a TX from HS A, and I find that it is because it takes this long to receive a packet with the first 6 bytes E0 34 45 01 32 43. Also none if this RX data is processed as M17 voice data since the data seems to almost always be corrupted. Here is a small example of a stream of RX after a correct 6 bytes is received: