2

I am implementing a simple visible light communication module with two Arduinos, as a transmitter and a receiver, with a short text message consisting of 120 characters. I have used Manchester encoding with on-off -keying modulation.

Altogether, in my message frame, with Manchester encoding and with preambles and end-of-frame byte, there are 2480 bits. I have set one bit period to be 500 microseconds. On the receiver side, I am sampling this bit four times, at (500/4) 125 microseconds. From my knowledge, since each bit is 500 μs, there are 2000 bits/s that are being transmitted from the transmitter so a baud rate of 9600 bits/s should work. However, 9600 is not working and any baud rate above 38400 up to 115200 is working, and I can properly decode this short message in my receiver.

What is the explanation for this behavior? Why is baud rate of 9600 not working though I am only transmitting 2000 bits per second?

Further information: I have set the prescalar to 128, so the ADC sampling frequency is (16 MHz/128)/13 = 9.6 kHz.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Anne
  • 21
  • 1
  • 2

1 Answers1

1

When you suddenly started talking about "baud rates", it implied that you're using the hardware serial port on the Arduino. If so, then realise that feeding 2,000 bit/s into a device expecting 9,600 bit/s has problems.

The way that an asynchronous UART works is that it waits for a start signal (bit), then decodes the next (typically) 9 signals at the current bit rate. It then checks that the 9th bit is a stop bit; if it isn't, it discards the byte.

Since you're only changing every 9600/2000 = 4.8 bits, then odds on the 9th "stop" bit will be of the wrong sense, and the data will be lost.

Below is an ASCII diagram for the timing that I'm talking about.

  • I'll use the bitstream 00101101 for the signal produced by the circuit, with a . as a 0 ms separator between bits;
  • I'll use a ^ to point out where the UART is sampling the bits;
  • I'll use a * to indicate a "correct" byte (insofar as the byte ends in a correct stop bit);
  • I'll use a ! to indicate an "incorrect" byte (insofar as the byte ends in an incorrect stop bit);

Of course, I'll assume a baud rate of 10,000 bit/s (5 rather than 4.8...)

00000.00000.11111.00000.11111.11111.00000.11111
^^^^^.^^^^!.......^^^^^.^^^^*.......^^^^^.^^^^*

This sequence would result in the UART recording the following 3 bytes:

  1. Error
  2. 0xF0 (LSB first is defined...)
  3. 0xF0 (LSB first is defined...)
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
John Burger
  • 3,662
  • 1
  • 13
  • 23
  • Thank you for your answer. I didn't get what you are saying about changing every 4.8 bits. :( Could you please explain it to me? How does that make it different when using baud rate like 115200 where it changes at every 57.6 bits? – Anne Oct 01 '16 at 12:16
  • And that's what I didn't understand - why changing to a _higher_ baud rate magically worked. I'm going to amplify my answer with a "diagram" - please forgive the crudity. – John Burger Oct 01 '16 at 12:22
  • Thank you very much. To make my question clearer: In the transmitter side, I am connecting an LED to digital pin 2(not in the TX pin). In the receiver side, a photodiode is connected to analog pin 3. A bit period is fixed as 500 us on both transmitter and receiver, and Serial.begin(115200) for both transmitter and receiver. In addition, for each byte that is transmitted, I have added a start and a stop bit to them. And with this addition and Manchester encoding, each transmitted byte = 20 bits. In total I am transmitting 2480 bits. – Anne Oct 01 '16 at 12:27
  • 20 bits? I understand "Manchester encoding" - but that's below the per-bit rate. Each transmitted byte cannot be 20 bits. It's either 10 bits (including start and stop), or you're thinking about the encoding wrong. Yes there may be 20 changes of state per byte - but that's not a "bit" per se. – John Burger Oct 01 '16 at 12:45