Online reference on BER testing?

I need to write a fairly quick and dirty BER tester to provide a rough evaluation of an ASK Manchester radio system. Can someone recommend a good online reference on the low-level details of this? What I'm most interested in is how to resync after a corrupted bit. I do have a packet engine available to me, but I'm unsure of the best practice to use here. The engine (which is hardware) silently discards corrupted packets based on a CRC check. So... should I use the packet engine with a small packet size and call the whole packet bad if I miss one? I was thinking that a bit-banged approach is probably superior, and will certainly give better accuracy.

Anyway, a good reference or two would be greatly appreciated.

Thanks!

Reply to
larwe
Loading thread data ...

If this is the case, they call it PER (packet error rate) rather then BER.

It depends on how much of computing power is available.

  1. If you are running the continuous stream of data, the properly implemented bit sync PLL should not loose the lock unless there is a major problem like 100 garbled bits in a row.
  2. You can synchronize the transmitter and receiver to a common clock, such as GPS. Then you don't have to worry about the bit sync.
  3. On the transmit side, generate a 31-bit repeating pseudo random pattern by 5-bit LSFR. On the receive side, continiously correllate the incoming signal with the 31 bit sliding window. The highest correlation value per 31 bits gives you the number of errors. Of course, larger patterns could be used if you can afford the computation.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

I have an MSP430F1611 on this board (it's just a board we built to play with the radio, I wasn't involved in the digital design). It would be irksome to attach a faster processor, I'd prefer not to do that if possible. Likewise, it would not be easy to attach GPS, it kinda falls outside my idea of quick and dirty.

It is anticipated that channel contention will cause long runs of missed bits, especially at the extreme of the range test.

I'll have to benchmark it, but this is a good start.

On the physical layer, though (Manchester remember) once I lose sync, how do I resync without introducing a sync pattern into the data stream (at which time I've basically moved from a BER test to a PER test as you mentioned)?

Reply to
larwe

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.