Test and verification data

Hi All

Having implemented all of the code in the MMDVM for M17, I am now at the testing stage. Things like the checksum and callsign encoding and decoding have been tested and known to work. However the rest of the code is unknown currently.

I plan on taking known valid M17 network frames, and feed them into my network receiving code, dumping the data at every stage, and feeding the result back into the RF receiving code to ensure that the data is decoded in the opposite way. It would then go out of the network, and I can compare that with the original incoming network data.

The only problem with that is that I will be testing against myself and therefore am only testing for internal consistency. What would be nice would be some example data, as an appending to the specification, that did the same as I am doing for one (or more) RF frame showing what the results should be at each stage. In the absence of hardware, this would allow for independent developments to be sure that they are following the correct route.

Jonathan G4KLX

I agree. We’ve now got, to my knowledge, SP5WWP’s implementation under TR-9, my python implementation, your MMDVM, and N7TAE’s mvoice and mrefd. Having a standardized way to test would be very useful - and this is exactly what I would normally volunteer for, I’m just swamped at the moment from the day job.

Incidentally, I’m the one who volunteered for documenting N7TAE’s connector protocol, on the basis of making my python implementation compatible with it and documenting as I go - I just haven’t been able to yet (sorry!). I’ll get to it, but pull requests accepted in the meantime.

I also need some way to validate frames. I have implemented baseband encoding and would like to validate what I have done so far.

If I post a binary file (one suitable for pushing through https://github.com/mobilinkd/m17-gnuradio) would anyone be able to validate the encoding for me? This would be type 4 bits including preamble packed into bytes containing a few seconds of encoded audio.

Post the binary file, WX9O.

EDIT: better yet, generate two files: one “original”, and one with preamble and syncs removed. We need the latter to find a good syncword.


Here’s the complete file with preamble and syncwords. It should be relatively easy to slice this into 48-byte chunks, remove the first chunk (preamble), then remove the first two bytes of each chunk (sync word).

EDIT: I should mention that the frame CRC still includes the contents of the LICH. I have yet to update the code for this.