Bit Error Rate !!!.!

A project log for Star Trek Communicator Badge

In the true spirit of Star Trek, this communicator badge is completely autonomous, while fitting in the form factor of an original badge

JoeJoe 03/16/2017 at 04:368 Comments

I have started writing the main code for the system. There is a simple state machine (I will probably post the diagram for it later) that manages switching between modes and determining which node is transmitting and when to receive. In short it works like this:

  1. All nodes in standby
  2. When a node wants to transmit audio, it sends a packet (with ECC) to the other node(s).
  3. The other node(s) reply with an ACK
  4. Once an ACK is received the master goes into streaming mode and the slave(s) going into streamingRX mode.

Everything works great up to this point. Here's where things get funky.

How do you end a transmission when the entire data pipe is dedicated to transmit audio?

What I am doing now: when the master wants to end the transmission it sends 1000+ audio bytes of 0xAA. This is a repeating 1010 pattern that allows for good signal integrity. The slave then looks for say, 500 of these packets in a row, to end the transmission.

Problem: I don't know if this is a "real" issue or not (it could be a bread-board signal integrity issue), but I am often seeing bits be skipped by the receiver (maybe 1 in 100,000 samples or so). For example, if a byte sequence is this:

10101010 10101010 10101010

I sometimes get this:

10101010 10101101 01010101

Where a bit is dropped causing the byte sequence to permanently be off by 1 bit. This is not only bad for the end-transmission sequence, but also the audio date can get wacky. 1 in 100,000 samples is sometihng like 1 in a couple seconds or so, so it is pretty frequent.

I fear that the solution may be to double the data rate, or increase it by a couple bits maybe. This would allow for ECC (error correcting codes) or some way to detect a missing bit. Also, maybe Manchester encoding might help.

My initial thoughts:

Does anyone have any experience with correcting for missing bits in a bit-stream for this type of application?


Joe wrote 03/19/2017 at 16:07 point

I have been doing more tests and have found that the RSSI is about -66dB at 1 meter. It is expected to be in. The -90dB range. I think this is the root of my problem. I need to figure out it the issue is on the SMS board or the bread board. If it is a power supply issue or an antenna matching issue

  Are you sure? yes | no

O'Brian wrote 03/17/2017 at 14:40 point

follow me m building a quadcopter wit solar installed propertisde

  Are you sure? yes | no

TheotherMike wrote 03/16/2017 at 17:54 point

Might be a stupid question because I really have not fully understood how it works, so please apologize if it´s too heavy for the µC or just not possible etc.:   Any chance in using some kind of frequency filter? Lets say a Görtzel algorithm or an "moving average array comparison" which monitors one or special frequencies and triggers when reaching a spectral density amplitude threshold while a special end frequency combination was transmitted? 

  Are you sure? yes | no

Joe wrote 03/19/2017 at 16:04 point

every signal in the frequency domain is handled by the radio. If we wanted to do clever frequency domain stuff we would effectively need to have a much higher data rate to allow for this type of detection

  Are you sure? yes | no

TheotherMike wrote 03/19/2017 at 17:31 point

OK, but the device is able to transmit audio up to some kHz, which will be given out on the speaker. It´s really not possible to have the receiving µC looking on those frequencies?

  Are you sure? yes | no

Joe wrote 03/16/2017 at 17:22 point

the trouble with these modules is that there are no packets. it is just a bit stream. UDP generally knows when a packet starts and ends whereas I do not. So once a bit is dropped, the whole packet structure is permanently shifted unless I can detect it.

Reserving bandwidth for ACKs is unfortunately not feasible because the time it takes to reconfigure the radio from TX to RX will destroy the bandwidth. I really needs to be treated as a unidirectional link.

  Are you sure? yes | no

K.C. Lee wrote 03/16/2017 at 18:12 point

Packets can be done in software layers even if all you have is a RAW stream of data.  It is a matter of Encapsulating smaller blocks of data with a header and checksum.

I guess there isn't much you can do for ACK/NACK, so hopefully with enough redundancy - repeating sending same packets with ECC to overcome the BER.  Like I said, you would only need to do that for commands etc and not for the voice stuff.

  Are you sure? yes | no

K.C. Lee wrote 03/16/2017 at 05:27 point

In VoIP or similar applications, the voice packets are transmitted in UDP - i.e. no guarantee in integrity.  So no ECC, no retransmission.  A few voice packets can be dropped here and there without affecting the quality too much.  It is more important to keep the jitter low.

You should consider reserving some bandwidth for inline control packets that have proper error recovery/ ACK/NACK retransmission etc.

  Are you sure? yes | no