IXM Baud Rate Negotiation
Matthew Beale
I'm trying to write a better adapter for Ruby LibIXM that uses
ruby-serialport instead of sfbprog. I'm trying to push through:
src/components/library/SFBSerial.cpp
but I could really use a better spec on negotiation. What's a good
place to start?
I have a lot of the Ruby boilerplate code already written. Thanks,
--
Matthew Beale :: 607 227 0871
Resume & Portfolio @ http://madhatted.com
Dave Ackley
Unfortunately the only doc on the BRN is
pretty severely rotted with respect to
the source. That will have to be fixed
but I'm not sure when it gets to the top
of the stack.
However, if you're looking to cut
sfbprog or the like out of the loop, you
also need to handle the SFB wire
protocol, if you're not doing so
already, before you actually get to the
BRN.
Fortunately, the wire protocol is easy
to implement, and it's documented. It
uses a byte-stuffing procedure, nearly
identical to the KISS and SLIP
protocols, to provide an 8 bit clean
channel.
The SFB wire protocol doc is attached.
- Dave
Dave Ackley
I've pushed together some additional
information on the BRN protocol.
Attached is some text describing the BRN
state machine, and a PDF flow chart that
also includes timing information.
It is a bit nasty, and arbitrary enough
in spots to almost amount to a secret
handshake. It was only really aimed at
'talking to kin' -- who share a common
code base -- rather than trying to be a
proper etiquette guide for 'talking to
strangers'.
That said, it is reimplementable without
the common code base. I made a test
implementation in Perl that seems to be
working, anyway. I'll see if I can get
that cleaned up a bit, for whatever it
might be worth.
- Dave
Matthew Beale
This looks *really* helpful! Chris at Liquidware has also tossed me a
few pointers and starting points. I hope to find some hacking time this
weekend. Cranking the baud rate up for PC communication would be great.
Thanks for the docs,
--
Matthew Beale :: 607 227 0871
Resume & Portfolio @ http://madhatted.com
> plain text document attachment (brn-state-machine-10.txt)
> ||--
> ||BRN Packet Summary
>
> Packet Nickname Purpose(s)
> ------ -------- ----------
> S! I am! Initial synchronization; liveness confirmation
> SR Reset Request remote reset after error
> SBplho Baud Rate Offer (BRO) 'p'referred, 'l'owest, 'h'ighest baud codes, parity
> SSro Selected Confirm 'r'ate is selected (possibly 'o'dd parity)
> SC Complete Confirm BRN completed successfully
> S? You there? Liveness test, requires S! response
>
> ||--
> ||BRN State Machine Summary
>
> State Purpose(s) Next state(s) On transition output
> ----- ---------- ------------- --------------------
> RESET Request remote transition to INIT INIT SR
>
> INIT Set 9600 baud 8N1, clear flags LISTEN
>
> LISTEN Issue/wait for S! LISTEN S!
> Eat SR resets LISTEN
> On S!, make SBplho baud rate offer OFFER SBplho (see details for plho)
>
> OFFER Reset (timeout, error, request) RESET
> Eat S! syncs OFFER
> Allow SC short cut to 9600 baud DONE
> Select baud rate based on SBplho CONFIRM SSro (see details for ro)
>
> CONFIRM Reset (timeout, error) RESET
> On SSr, change baud rate, pause WAIT
>
> WAIT Issue SC's at new baud rate DONE SC
>
> DONE Flag BRN completed successfully SHOWTIME Ph (code flow announcement)
>
> SHOWTIME Reset (error, request) RESET
> Eat SC's and S!'s SHOWTIME
> Respond to liveness tests SHOWTIME S!
> Issue liveness test CHECKIN S?
> Shortcut to re-BRN OFFER SBplho (see details for plho)
>
> CHECKIN Timeout RESET
> Any S packet received (usu. S!) SHOWTIME
>
>
> ||--
> ||Baud Rate Negotiation
>
> Baud Rate Codes:
>
> The BRN protocol, overall, supports ten possible baud rates, each
> referred to by a single digit code in the range '0'..'9':
>
> Baud Rate Code Digit Baud Rate Code Digit
> 300 0 230400 5
> 1200 1 500000 6
> 9600 2 1000000 7
> 57600 3 2000000 8
> 115200 4 3000000 9
>
> However, any particular communicator is not required to support
> all of those rates. The only required rate is code 2, 9600 baud
> 8N1, called the 'rendezvous rate' because that's where the BRN
> starts.
>
> The Baud Rate Offer: SBplho
>
> A communicator expresses its baud rate capabilities and
> preferences via the 'SB' Baud Rate Offer packet, which specifies a
> _range_ of supported baud rate codes, as well as an optional data
> framing code.
>
> The packet contains five or six bytes interpreted as follows:
>
> 'S' This is a reflex level 'S'peed packet
> 'B' This is a Baud Rate Offer packet
> p A digit from 0..9: This is my preferred baud rate code
> l A digit from 0..9: I support no slower baud rate codes
> h A digit from 0..9: I support no faster baud rate codes
> o An optional letter 'o' (or uppercase 'O', which is
> treated as equivalent to lowercase 'o') . If absent,
> data format must be 8N1. If present, sender is
> requesting odd parity, 8O1.
>
> Note that when a communicator makes an offer with a given l and h,
> _all_ baud rate codes from l through h inclusive _must_ be
> supported by that communicator -- there is no protocol support for
> selecting a non-contiguous set of the baud rate codes.
>
> It is a protocol error for the l code to be greater than 2 or the
> h code to be less than 2. (I.e., code 2, the rendezvous speed,
> must be supported).
>
> It is a protocol error for the p code to be less than the l code
> or greater than the h code. (I.e., the preferred speed must be
> supported).
>
> By default, the BRO currently made by the core software on the IXM
> boards is: "SB406o", meaning:
>
> 'p' code 4 (115200 baud preferred) [Can be changed by
> sketch, e.g., 'NorthFace.setPreferredBaudCode(3);'
> would change the North serial preference to
> 57600 baud]
> 'l' code 0 (300 baud minimum)
> 'h' code 6 (500000 baud maximum)
> 'o' odd parity is requested. Odd parity, 8O1, will be used
> if the other side requests it as well, else 8N1.
>
> The Baud Rate Selection Algorithm:
>
> The algorithm for baud rate selection can make no distinction
> between the local and remote abilities and preferences, because,
> by symmetry, the same answer must be reached even though both
> sides consider themselves to be 'local'.
>
> So, given two sets of 'plho's, denoted (p1,l1,h1,o1) and
> (p2,l2,h2,o2), the selected baud rate and framing is determined as
> follows:
>
> (1) DATA FRAMING: If _either_ o1 or o2 is absent, the data
> framing will be 8N1 (8 data bits, no parity bit, one stop
> bit), which all communicators must support.
>
> If o1 == 'o' _and_ o2 == 'o' (both ignoring case),
> indicating support and preference for odd parity, then the
> data framing will be 8O1 (8 data bits, an odd parity bit,
> and one stop bit).
>
> There is no protocol support for expressing any other
> framing options: No even, mark, or stick parity, and nothing
> except for precisely one stop bit.
>
> (2) SELECT BAUD RATE CODE: Of the following rules, the first
> applicable takes precedence:
>
> (2.1) EQUAL PREFERENCES:
> If p1==p2, select code p1
>
> (2.2) FASTER PREFERENCE:
> If max(p1,p2) <= min(h1,h2) and max(p1,p2) >= max(l1,l2)
> select code max(p1,p2)
>
> (2.3) SLOWER PREFERENCE:
> If min(p1,p2) <= min(h1,h2) and min(p1,p2) >= max(l1,l2)
> select code min(p1,p2)
>
> (2,4) RENDEZVOUS SPEED:
> select code 2
>
> Note that according to this algorithm, the selected baud
> rate will always be one of the preferred rates, or the
> rendezvous rate.
>
> The Baud Rate Selection: SSro
>
> The result of the baud rate negotiation is conveyed to the
> counterparty via the 'SS' (speed selected) packet. The SS packet
> contains three or four bytes interpreted as follows:
>
> 'S' This is a reflex level 'S'peed packet
> 'S' This is a speed 'S'elected packet
> r A digit from 0..9: This is our selected baud rate code
> o An optional letter 'o' (or uppercase 'O', which is
> treated as equivalent to lowercase 'o') . If absent,
> the selected data format is 8N1. If present, the
> selected data format is 8O1.
>
> Since both parties must have selected the same baud rate and data
> format, the SS packet provides only confirmation and no new
> information. It is the last packet received before the baud rate
> ia changed to the selected speed.
>
> ||--
> ||BRN Sample Negotiations
>
> They offer: SB406o +---------------------------------+
> [300-500000 baud, with a | Them: Us: Our state: |
> preference for 115200 odd] | INIT |
> | [9600 8N1] |
> We offer: SB506o | ->LISTEN |
> [300-500000 baud, with a | S! LISTEN |
> preference for 230400 odd] | S! LISTEN |
> | SR LISTEN |
> Result: SS5o | S! LISTEN |
> [230400 odd] | SB506o ->OFFER |
> | S! OFFER |
> | SB406o OFFER |
> | SS5o ->CONFIRM |
> | SS5o CONFIRM |
> | [230400 8O1] |
> | ->WAIT |
> | SC WAIT |
> | SC WAIT |
> | SC WAIT |
> | ->DONE |
> | SC DONE |
> +---------------------------------+
>
>
> They offer: SB406o +----------------------------------+
> [300-500000 baud, with a | Them: Us: Our state: |
> preference for 115200 odd] | INIT |
> | [9600 8N1] |
> We offer: SB313 | ->LISTEN |
> [1200-57600 baud, with a | S! LISTEN |
> preference for 57600 none] | S! LISTEN |
> | S! LISTEN |
> Result: SS3 | SB313 ->OFFER |
> [57600 none] | SB406o OFFER |
> | SS3 ->CONFIRM |
> | SS3 CONFIRM |
> | [57600 8N1] |
> | ->WAIT |
> | SC WAIT |
> | SC WAIT |
> | ->DONE |
> | SC DONE |
> +----------------------------------+
>
>
> ||--
> ||BRN Shortcut Negotiation
>
> If 9600 8N1 is sufficient for a communicator's needs, and it
> requires no liveness indications about its counterparty, the
> following drastically simplified state machine can be valid:
>
> (1) Set 9600 8N1. Mark the device 'packet ready'. Go to (2).
> (2) If any "S" packet is received, send "S!" and "SC", and go to (3).
> (3) Ignore any received "S" packets for 0.5 second, then go to (2).
>
> Step (3) defends against a possible packet storm if two such
> simplified communicators end up talking to each other.
>
Dave Ackley
in Perl that does the SFB BRN, using the
Device::SerialPort module to talk to the
IXM (and Term::ReadKey for non-blocking
access to stdin.)
Apparently Device::SerialPort is closely
related to Win32::SerialPort, and
Term::ReadKey is pretty much supposed to
work 'on any architecture', so porting
this script to a non-Linux host might be
pretty doable, if anybody wanted to.
And it's a little cool. Just as a test,
without trying any heavy I/O, I did get
successful echoes from 'Rb' ('Route
back') packets, after negotiating with
an IXM to connect at half a million
baud:
$ ./sfbio.pl -b 6 -v
0.000 Opened /dev/ttyUSB0
0.000 Setting 9600 baud parity none
1.080 Setting 500000 baud parity odd
SFB CONNECT 500000 odd
Rbwow, are we really talking half a megabaud?
wow, are we really talking half a megabaud?
Rbyes!
yes!
quit
$
I expect sketches that did anything at
all involved would start dropping
packets pretty quick, if faced with
sustained input at that rate.. but still.
- Dave