Go Down

Topic: SoftwareSerial magic numbers (Read 14 times) previous topic - next topic

robtillaart

#10
Jan 02, 2013, 04:54 pm Last Edit: Jan 02, 2013, 06:56 pm by robtillaart Reason: 1
@Marc G

A serial protocol is like a train with wagons and on each wagon there is one bit, 10 bits in total (including start/stop bits). The baud rate represents the speed of the train.

The software serial receiving code is triggered by the edge of the start bit (train). To read a bit properly one wants to read the value of the signal (HIGH/LOW) in the middle of the bit, not at the edges.

rxCenter is the time to the (approx) middle of the first (start) bit,
rxIntra, rxStop are used as timings from the middle of one bit to the middle of the next. The higher the baud rate the lower these numbers.

tx is used for the timing for the transmit.

You can see this in the code of the library - C:\Program Files (x86)\arduino-1.0\libraries\SoftwareSerial - (windows)
and search for this function - void SoftwareSerial::recv() -
Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

robtillaart

#11
Jan 02, 2013, 07:19 pm Last Edit: Jan 02, 2013, 07:21 pm by robtillaart Reason: 1
Did a more extensive test with the SoftwareSerial using the formula approach.
I connected two Arduino's - UNO, 16Mhz (resonator) + 2009, 16Mhz (crystal) +  IDE 1.0 - both using SoftwareSerial, one Master and the other Slave (essentially an echo).

The master sent byte 0x55 at baudrate 100 and waits until the slave echos it back.
If the answer is not 0x55, the test fails and master prints a message.
Otherwise it just increases the baud rate with 100 and starts over.

The results are pretty good as it only gets constantly distorted above 190K baud.
Between 90K and 190K it only failed 10 times.

I took 0x55 as test pattern 0x55 == 01010101 ; it helps to see what happened. (see comments after output

Typical output  (multiple runs had comparable output)
Note: started with baud rate 100 in steps of 100...
Code: [Select]
start...
BAUD BYTE
97600 F5 FAIL  // = 11110101    ??
111200 AA FAIL  // = 10101010   1 bit shifted
114400 D5 FAIL  // = 11010101   1 bit failed (interference with start bit ?
124600 AA FAIL
140600 D5 FAIL
145500 AA FAIL
149000 D5 FAIL
163200 AF FAIL  // = 10101111  ??
190500 FF FAIL  // = 11111111  expect sync lost
190600 FF FAIL
190700 FF FAIL
190800 FF FAIL
190900 FF FAIL
191000 FF FAIL
...


The master and the slave were kept in sync by starting at the same baud rate an wait for each other.

To repeat the test start the master, then start the slave, and press a char in the serial monitor of the master.


Slave program (essentially echo)
Code: [Select]
//
//    FILE: serialSlave (echo)
//  AUTHOR: Rob Tillaart
//    DATE: 2013-01-02
//
// PUPROSE: test SW serial with formulas
//

#include <SoftwareSerial.h>

SoftwareSerial mySerial(2, 3);

void setup()
{
 Serial.begin(9600);
 Serial.println("start slave...");
}

unsigned long baud=0;

void loop()
{
 baud += 100;
 mySerial.begin(baud);
 while (mySerial.available() == 0);
 int b = mySerial.read();
 mySerial.write(b);
 Serial.println(b,DEC);
 delay(10);
}


master program
Code: [Select]
//
//    FILE: serialMaster
//  AUTHOR: Rob Tillaart
//    DATE: 2013-01-02
//
// PUPROSE: test SW serial
//

#include <SoftwareSerial.h>

SoftwareSerial mySerial(2, 3);

void setup()
{
 Serial.begin(9600);
 Serial.println("start...");
}

unsigned long baud=0;

void loop()
{
 if (Serial.available() > 0)
 {
   Serial.flush();

   baud += 100;
   mySerial.begin(baud);
   mySerial.write(0x55);
   while (mySerial.available() == 0);
   int b = mySerial.read();
   if (b != 0x55)
   {
     Serial.print(baud);
     Serial.print("\t");
     Serial.print(b, HEX);
     Serial.print("\t");
     Serial.println(" FAIL");
   }
   delay(20);
 }
}


As always comments/remarks are welcome
Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

robtillaart


same test with stepsize 10 gave some more errors (typical run started with baud rate 10, step 10)
Code: [Select]

start...
BAUD BYTE
70660 D5 FAIL
81950 AD FAIL
88870 AF FAIL
89570 BD FAIL
94410 D5 FAIL
95340 AA FAIL
96590 D5 FAIL
98980 AA FAIL
100750 AB FAIL
103590 BD FAIL
105740 D5 FAIL
110600 AA FAIL
113260 AF FAIL
120200 AA FAIL

...

Up till 70K no failures  ( that are 7000 different baudrates tested !)
between 70K and 115K "only" 13 failures   (13 fail on 4500 baudrates tested ~~ 1/300
above 120K the failures increased, not shown

Conclusion from the tests, SoftwareSerial "by formula" works very good up to 70.000 and reasonable well up to 115.200
Tweaking the formulas further may improve the test results but for now I'm quite satisfied.



This SoftwareSerial "by formula" allows one to build a communication channel in which the baud rate is constantly altered, making it very difficult to eavesdrop - and yes to get in sync :)
Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

mikalhart

@Rob,

I applaud this effort.  Thanks for investigating so thoroughly.  I always thought it might be fun to develop some equations that allow the synthesis of the "table" values on the fly, and now it looks like you are pretty close to doing just that.

It's good that you are getting error-free transmission up to 70K.  Make sure you test not just the single byte round trip, but also lots of bursts.  The values should vary Example:

1. Arduino sends 0x55 as fast as possible to host for one minute.
2. Arduino sends 0xFE as fast as possible to host for one minute.
3. Arduino sends 0x01 as fast as possible to host for one minute.
4. Host sends 0x55 as fast as possible to Arduino for one minute.
5. Host sends 0xFE as fast as possible to Arduino for one minute.
6. Host sends 0x01 as fast as possible to Arduino for one minute.

When constructing the tables, I found several times that I thought the values were good--until I tested the large bursts.

If we want to improve performance at baud rates > 57.6K, I think we're going to have to optimize the timer tick vector.  I studied this for some time with the logic analyzer and discovered that the occasional glitch was due to a timer tick interrupt being processed exactly when a pin change was pending.

Lastly, and you probably already know this, but if your formula is off a bit for the lower baud rates, it shouldn't be a big deal.  They are very tolerant.

Nice!

Mikal

drjiohnsmith

robtillaart

like the idea of a formula,
    but could be slow to change baud rate could it not.

not certain, and for interest,
   did you try two boards connected using the standard software serial code,
      did you try two boards using the standard hardware uart.


Go Up