Automatic Baudrate Detection with the BASIC Stamp

Phil Pilgrim (PhiPi)

Here's a little trick I discovered for determining a baudrate automatically. Suppose you have a device that's streaming serial data to your BASIC Stamp with an unknown baudrate. It could be unknown because it's coming from a micro that's using an RC clock for its timebase (my case) or for any number of other reasons. What you can do is monitor the input stream for awhile to find the shortest negative-going pulse width (using PULSIN). This will give you the bit time. Then, simply shift this number left by one and subtract 20. It's that easy and will work for all Stamps except the BS2px. (That one's a little trickier, and I haven't taken the time to work out the math for it.)

Here's an example program:

' {$STAMP BS2}
' {$PBASIC 2.5}

sio     PIN 15

baud    VAR Word
pwidth  VAR Word
i       VAR Byte

baud = $ffff

FOR i = 0 TO 255
  PULSIN sio, 0, pwidth
  baud = baud MAX pwidth
NEXT

DEBUG "The minimum pulse width is: ", DEC baud, CR
baud = baud << 1 - 20
DEBUG "The resulting baudrate constant is: ", DEC baud, CR

-Phil

Beau Schwabe

Phil Pilgrim (PhiPi),

Nice!

The px works out to 4X the BS2, so...

baud·=·(baud */ $CD)·<<·2·-·20

... I think will work (I don't have one to test at the moment)

The first part... (baud */ $CD)·translates and holds the·bit time
The <<·2 multiplies the result by 4


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

Post Edited (Beau Schwabe (Parallax)) : 4/22/2009 7:40:06 PM GMT

Zoot

That is so sweet.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

Tracy Allen

Niice. It could happen that 256 bytes do not contain that isolated bit, for example, a string of all ascii zeros "0"=$30=%00110000. You know your data.

I use a similar trick with a PIC with the RC clock, but my case the master (Stamp) stimulates the slave (PIC) to transmit a packet by pulsing the data line low. The return packet starts with the character $80, which gives 8 bit periods low. The formula for baud mode based on PULSIN then is pwidth/4-20

PULSIN picPin, 0, pwidth
SERIN picPin, pwidth/4-20, 100, noData, [noparse][[/noparse]SPSTR 12]

That allows the system to recalculate the baud rate for each packet, and to track extreme temperature changes.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Phil Pilgrim (PhiPi)

Tracey Allen said...
It could happen that 256 bytes do not contain that isolated bit, for example, a string of all ascii zeros "0"=$30=%00110000.

True enough. In that case, since I know the approximate baudrate, I would be able to tell how many bit widths the narrowest pulse encompasses and divide accordingly. This could still be a problem if the device were only sending out NUL characters or $80s, since the difference between 8 and 9 bits is only 12.5% — possibly within the RC oscillator's error range. In this particular case, though, the end user has the ability to insert synchronization bytes into the data stream, which can be anything they want.

The preceding applies to the device's autonomous mode, wherein it's not receiving commands from the Stamp. In command mode, each command is an odd-numbered ASCII character, and the device itself measures the start bit to match the Stamp's baud rate.

-Phil

Tracy Allen

The PIC12F675 RC oscillator spec is +/- 1% at room temperature and 3.5 volts Vdd, however, that degrades to +/-5% over the full power supply and -40 to +85 degC temperature range. How do the AVRs compare? Doing the autobaud increases confidence that it will work over the full range. It is convenient to do the autobaud on the Stamp end. Yet if the slave chip can measure the first bit of the command character of something like that, it does make it more flexible to hook up to a PC or chip that only has fixed baud rates.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Phil Pilgrim (PhiPi)

The AVR ATTiny13 spec is more like ±10% at temp and fixed Vdd with factory calibration but can be recalibrated to ±1%. Beyond that it looks like ±5% over temp and Vdd (graph attached). I've never bothered much with the RC calibration register. In the AVR, the calibration register is loaded on reset from a non-volatile location that doesn't get erased when the chip is reprogrammed. But you can rewrite the register at runtime to modify the frequency.

I'm not sure why the factory calibration spec is so loose, though. My experience has been that the factory-calibrated frequency is closer to what you experience with the PIC.

-Phil