Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Standardizing M17 BER Testing
#1
It would be useful to have interoperable BER testing between conforming implementations, so that a transmitters, receivers, and test equipment from different vendors could be used for M17 equipment testing.  This would be useful for end users -- especially ham operators -- in tuning their equipment.

As a strawman, I propose using the reserved sync word (now BER SYNC WORD) for this purpose, along with a custom frame type which uses the P2 puncture matrix.  The frame would be 197 bits long (24 bytes + 5 bits).  The first two bytes would be a frame number and would seed a LFSR PRNG.  If we want to use more than one LFSR, we could use some of the reserved bits in the frame type word for this.

The LSF would be sent as-is, with the frame type set as STREAM and the stream type set to the reserved type "00".  This would be followed by BER frames using the BER SYNC WORD, containing a 16-bit frame number and 181 bits of pseudo-random data encoded similarly to the stream payload audio data (i.e. using the same puncture matrix).

197 bits gets extended to 201 bits with 4 bits of 0 used to flush the convolutional encoder.  This is encoded into 402 bits.  This is then punctured to 368 bits, which is a full frame.

Frame numbers would start at 1 in order to have at least on bit set in the LFSR.

Seeding the LFSR with a frame number allows for synchronization and recovery of the BER test.

We would use a 16-bit LFSR with the polynomial [img]data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAMQAAAAXCAYAAABUDODqAAAFgUlEQVR4Ae3biZHsNBAG4CYDyAAygAg4EgAi4EiAIwEgAiACeBEAEQARABFABpAB1PdK/arXJc/Y8tjrpaartDosy38fv66pjbjL3QJ3C9wtcLfA3QK3tMCrEfFeZ8CXI+LLiPg6Il7vPD9LE5wfTsDQ6YOIeDMi3o2ITyfPz1b9pAPorWb7s9s/oX908jhJnLO5oPkmIn5vgV87evZLRAg2ZPmxPjxRGWHhlKoIpn9bgp0eZxRE/r7hfKkAZP+fW539/44IbWeV1xpGdn/yIqikKs8iAuMJJc88w8LXI8RTcQ4iIG8lBKJoI4igfGZ9kJoPzoyxmfN61iMEB7wfEV+0rcf1UR6vR48Qb7eVzZbpzNs9VusRoloTOf458SpnBWPv/y0hKIcQtlNEnuXWdKqsR4hsk5u9pivgmRRIQkwx2ebZ7v12YlLD+FUD/tiE6J2DpzZdVBcsqZQXkhCCichz+W5Np8oy+CsojspzQ245zroHT0LULVPVxQrnDHHGlc7WOu38GITge/Fr0hCjczas9rxanhKC4Q2eDkhCZP3qgKXDZwfsK3uEsM2oeOmj31p544DVpUcI5K0Ehv/bteBb/70uRNjXwd+2Wgz9GRHftQl1LVR2Hjmnmsg/n7mYWIvhRf8pITywZ80ASkK8eGFFAWArzp7SI8RfxcBbVgjY6+q5hx49Qpht3f6ljBLC2L/mIDvkxs+0ZYXYamc+YiNYZsVVWAa1TuqYmGKpc+j8oSXlXP6QBNuJfDQothDilYY/MWW9wXqewWyGMjsp56zqu36HIPCPnoG2Oor9ExMs1cbqZlm/k3CmPFc1s2XaPw/VdZznii34I0AE6qiIl8RkDPUpjowjPuCL6fMl395q56uEcJAUBHkoc4WaV2MfN4QU4TBgJOUMPl04AjG2HFZGCQEv7HSwf3bjpU4HKSXxy6XqjMQvHxVj0mGtCCKB6F2rLQzw59Yix9MvbS+vwafufan6Jd9dko8SwvcSv5WKHzJZfaudM47SF/XZEoz6jNo5x2ej2RXCQwGUoqMgskIoc8xRAgvHrhH9636ZYziBmIUE2FGSQbnme1ayOisjAbuzv0Oocg38NWOv7TtKiJ8aXt8TrDCbpCTlkf3+Jewjdq7jXSQEJqekMgiCyYixlzMYf5oAfafTrt+ceKfOiByQBKHblhVr7pvap9jVYYen92xuLLaukwBy5HkgV625d7e293D6fq997luI6zIkJQmN6GJHDFX/ZL+leQ/LiJ3r9y4SonZ0AhdQlNlTGMrhbZrM7IJh2l5n0Eu47Fnhryvepf5bnsE0xQk7Habt6ksnFlu+JPQWfNfeFcQ9nFbUXvvSraQdRRL6GoYlz/ew82JC3FqZJQrXPoDW2bI+W1Lm5CMIPYdl61KONEcRuqeD2Xjp5NN7X9sRhN5q54uEEESWoJ4yZtp609S67ZaNEMKWyF6VIPQfrSxzYFs6s5XXhosjjkIC2wzSI3Q+a112zUYIYTuUt0U9Qu+Bf8TO1XCzhDCwGcleW/Ar60woesulrw17MRshBMy2KfAq1xkOQY4k9Iij4IUbefMX1DQSgkhHyQghMrhMPOKILuxA2J4Pbi0jdq4YEjN9HwgnCCYsBtwZglPcCnDUkcEE2AghkNb/AMDvipg+/l/A7yW5cjxQesfKiKMEEawOn4KfPmZc7W6ZjpQRQphI3eaJGTpI9FF3FtlyoJ7TfcTOxvJLuWRbh7hiXf1BnCBFMtpLSKC+98G6p+wIIRi84nXroU6vo8V36bBWvAc3SX2Onox8e4QQ3oO14qWPtJeM2pmN6ThNjxEri2zjPLD0NmbRgAd3Ytgjzyx7qLfHnv/WONl5r+v0W2O9j3e3wN0CdwvcLfDkLfAfR9ZBM+MA48gAAAAASUVORK5CYII=[/img]

https://en.wikipedia.org/wiki/Linear-fee...imal_LFSRs

The least significant 8 bits would be used, then shifted 8 bits, then the next 8 bits extracted and so on.  On the final byte, only the most-significant 5 bits will be used.
Reply
#2
I like the idea of using the unused sync word for this task, thereby avoiding confusion with normal traffic. Unfortunately that is where I diverge from your ideas. I am all in favour of a way to standardise BER measurements, but I feel that this scheme is too complex. Firstly you don't need to build in any identification, since this will only be used for testing, a voice announcement can be made on frequency before the test if you feel the need. I also don't understand the need to have any form of sequence number on the frames, this makes it very difficult to set up a system when the initial BER is very high, and then to gain synchronisation later. It would be far better to send the BER test frames with an unchanging pseudo random sequence so there is no uncertainty of synchronisation.

Indeed as part of trying to tame the MMDVM, I intend to implement something like this as soon as possible so that some serious testing can take place.
Reply
#3
I am fine with dropping the LSF altogether. That makes sense. And I do agree that it is overly complex.

Is your proposal that every BER frame have the same payload? That is very little entropy. I have found errors in sync handling that only occurred after receiving a large number of frames. It was only triggered by certain bit patterns.

ITU recommends PRBS9 (511 bit sequence) as a minimum for low bitrate systems. I would be fine with that, as long as the sequence wrapped. That will provide enough unique frames. Each frame pulls 197 bits from the PRBS. The first wrap happens 117 bits into the third frame.

An LFSR is self-synchronizing. For PRBS9, synchronization occurs after some number of error-free bits are received. This example uses 2x the PRBS size as the decision point: http://www.pldworld.com/_hdl/5/-thorsten...l/PRBS.pdf
Reply
#4
I still think that it's too complex. A fixed frame content would be adequate I feel based on previous experience, with a few runs of 0s and 1s to test the DC characteristics of the system for good measure. You could theoretically have a number of selectable patterns which you could switch between, but in the case of the MMDVM we already have a wide range of test transmission types that will exercise a system very well indeed.

I'll implement something next week, and of course being open source you're free to copy it if you want. I need it pretty urgently in order to make my systems usable, considering that everything else is in place, even my M17 network gateway will talk to you now!
Reply
#5
(07-31-2021, 09:38 AM)G4KLX Wrote: I still think that it's too complex. A fixed frame content would be adequate I feel based on previous experience, with a few runs of 0s and 1s to test the DC characteristics of the system for good measure. You could theoretically have a number of selectable patterns which you could switch between, but in the case of the MMDVM we already have a wide range of test transmission types that will exercise a system very well indeed.

I'll implement something next week, and of course being open source you're free to copy it if you want. I need it pretty urgently in order to make my systems usable, considering that everything else is in place, even my M17 network gateway will talk to you now!

Here's a working self-synchronizing PRBS9 implementation.

https://github.com/mobilinkd/m17-cxx-dem...til.h#L319 (unit tests are in the repo as well).

PRBS are the de facto standard for BER testing of communications systems.  Standard sequences are defined by ITU.  I don't see why we would want to do something different for M17.

PRBS9 was initially suggested by Wojciech.
Reply
#6
I agree on using the PRBS. They are used everywhere for testing communications systems. We should leverage that.
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)