> Wow, Bob -
>
> I feel I should send you cruise tickets or pay Leonard Cohen to
> write a song about you.
> That train of thoughts ran me off the tracks a couple of time when I
> tried it.
>
> And you know what - your approach actually works.
>
> The method I experimented my way to is to send 4 x 0x22 - it was
> mentioned in an application note. But It only gives me correct sync
> about half of the times.
> I have googled and yahooed a lot the last couple of days and I am
> sure this method is unique.
>
> It is hereafter named
>
> "Ammerman Synchronization"
>
>
> Thanks,
> Kent

Kent,

Thanks for the compliments. Sometimes to attack a problem you have to go
back to the underlying first principles.

You might be amused to know that I never tested this before posting it ;-)

Also, since posting it, I have found no less than 2 applications for it
within projects I have worked on / am working on.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)s

> > <changed to [EE]:>
> >
> > > >I am interfacing a cheap radio module to a processor via a standard
> > > >UART with buffer (actually a 16C654).
> > > >
> > > >Not by choice, though. The hardware was served in this way.
> > > >
> > > >The radio module is bandpass, 2kHz to 10kHz - so I can transmit
> > > >about 3 bits 111 or 000 before the fan belt hops off at 9600 baud.
> >
> > I've thought about this a little.
> >
> > Note: this answer is based on the following constraints and
asssumptions.
> >
> > We can never transmit more than 3 consecutive 0's or 1's.
> >
> > START bits are the same condition on the line as a data bit of 0.
> >
> > STOP bits are the same condition on the line as a data bit of 1.
> >
> > Bit numbers within the data are from 0 (LSbit) to 7 (MSbit)
> >
> > The bits are transmitted starting with the LSBit
> >
> > We assume the receiving UART will detect a framing error and attempt to
> > resynchronize whenever it sees a zero where it is expecting the stop bit
> > (which should be a one).
> >
> > We assume the receiving UART will start searching for a new start bit (0
> > state) immediately after the line returns to a 1 state after
encountering a
> > framing error condition.
> >
> > First, if we want to transmit a continuous alternating sequence of 0's
and
> > 1's we can do so by repeatedly transmitting the byte value 0x55 as a
> > preamble. This works because we send:
> >
> > START BIT (0)
> > bit 0 (1)
> > bit 1 (0)
> > .
> > .
> > .
> > bit 6 (1)
> > bit 7 (0)
> > STOP BIT (1)
> >
> > The receiving UART will nicely sync on this, but of course it could be
> > misaligned byte wise. There are 5 possible conditions:
> >
> > Case A: The receive UART is properly aligned.
> >
> > Case B: The receive UART is shifted 2 bit times
> > (bit 6 is being treated as the stop bit, bit 7 as the start bit)
> >
> > Case C: The receive UART is shifted 4 bit times
> > (bit 4 is being treated as the stop bit, bit 5 as the start bit)
> >
> > Case D: The receive UART is shifted 6 bit times
> > (bit 2 is being treated as the stop bit, bit 3 as the start bit)
> >
> > Case E: The receive UART is shifted 8 bit times
> > (bit 0 is being treated as the stop bit, bit 1 as the start bit)
> >
> > Now we have to come up with a way to convert the unaligned cases to the
> > aligned case by taking advantage of the way the UART detects framing
errors.
> > We do this by transmitting a 0 data bit where the UART expects a stop
bit (a
> > 1).
> >
> > The binary value B'01000100' will cause a framing error only in Cases C
and
> > E above (because bits 4 and 0 are the wrong state for a stop bit). In
Case
> > C, the UART will treat bit 7 as the next start bit, translating us to
case
> > B. In Case E, the UART will then treat bit 3 as the next start bit,
> > translating us to case D.
> >
> > The binary value B'00010001' will cause a framing error only in Cases B
and
> > D above (because bits 6 and 2 are the wrong state for a stop bit). In
Case
> > B, the UART will treat the start bit of the next byte as the next start
bit,
> > translating us to Case A. In Case D, the UART will treat bit 5 as the
next
> > start bit, translating us to Case C.
> >
> > The binary value B'01000101' will cause a framing error only in Case C
above
> > (because bit 4 is the wrong state for a stop bit). In this case the UART
> > will treat bit 7 as the next start bit, translating us to case B.
> >
> > The binary value B'00010101' will cause a framing error only in Case B
above
> > (because bit 6 is the wrong state for a stop bit). In this case the UART
> > will treat the start bit of the next byte as the next start bit,
translating
> > us to Case A.
> >
> > So, the transmitter could send:
> >
> > Preamble of "N" bytes of 0x55
> >
> > (at this point the receiver is in any of the 5 cases)
> >
> > B'01000100'
> >
> > (the receiver is in case A, B or D because we mapped C->B and E->D)
> >
> > B'00010001'
> >
> > (the receiver is in case A or C because we mapped B->A and D->C)
> >
> > B'01000101'
> >
> > (the receiver is in case A or B because we mapped C->B)
> >
> > B'00010101'
> >
> > (the receiver is in case A because we mapped B->A)
> >
> > whew!!
> >
> >
> > Bob Ammerman
> > RAm Systems
> > (contract development of high performance, high function, low-level
> > software)
> >
> > --
> > http://www.piclist.com#nomail Going offline? Don't AutoReply us!
> > email listserv@mitvma.mit.edu with SET PICList DIGEST in the body
> >
> >
> >
>
> --
> http://www.piclist.com hint: To leave the PICList
> mailto:piclist-unsubscribe-request@mitvma.mit.edu
>
>

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu