Stefan Sczekalla-Waldschmidt writes:
>Thats the thing I' like to control. My approach to decode is "look for
>Edges" in the signal
>and messure the distance between. Would have been nice to see how somebody
>else
>has done this.

        This method gives you a time measurement between transitions,
all right, and that is valuable.  It can trip you up so be careful.
When I was trying to decode the Manchester-style output of a HP28
printer port, I did this very thing and it did not work at all.

        The signaling protocol was such that a 0 was represented by a
half-bit period of no carrier followed by a half-bit period of
carrier.  When there is a 0 to one transition, one reads two half-bits
of carrier back to back as ones are represented by a half-bit of
carrier followed by half of a bit of no carrier.  What actually
happened, was that sometimes there would be a tiny glitch back to no
carrier between the two half-bits and other times, there was either no
glitch or the detector ran the two half-bits together effectively
filling them in to make a long 1-bit carrier period.

        I found all that out by measuring the time as is described
above and then discovering that there were hardly ever any carrier
bursts that were two half-bits long, but there were lots of times in
which there was a half-bit on time followed by a return to 0 that was
sometimes as brief as one or two CPU cycles and then another
half-bit.  The thing to do is to reliably detect the start of a frame
and then wait, in this case, a quarter of a bit length before reading
the detector again.  The idea is to read in the middle of a bit and
not on an edge because that's where the signal is most likely to be
unstable.  This is how UARTS do their thing and in the case of the
HP28, this lets the detector glitch between bits all it wants and
nothing bad happens.

Martin McCormick