On 17 October 2011 14:44, Jan-Erik Soderholm
<jan-erik.soderholm@telia.com>wrote:

>
> Do you have any flow-control ?
>
>
None at all.



> What, more specificaly, does the "garbage" look like ?
>
>
I've pasted a bit of debug dump here:- http://pastebin.com/kKwi78E6

To explain:-

TSIP packets structure is 0x10, <packet type>, some data, 0x10, 0x03.
If the data contains a 0x10, you double it up. So, you spot the end of a
packet by finding an odd number of 0x10 followed by a 0x03.

My program on the PC buffers all incoming data to a FIFO, Finds 0x10 0x03
combinations (coping with duplicate 0x10 as above), and pulls that chunk of
data off the front of the FIFO and dumps it.

In the pastebin, each triplet of lines looks like this:-

 10 A0 04 30 9E 59 10 10 10 03
Bad packet count is 0
<-- 0xA0 ImpulsePPSEventReport, Count =3D 1072, Timestamp =3D 1071518 (0x10=
599E)

Line 1 =3D the raw packet data.
Line 2 =3D total # of "bad" packets so far
Line 3 =3D Attempted decode of the packet.

A "bad" packet looks like this:-

Invalid Packet: 2C 2A 31 32 00 10 03
Bad packet count is 1
<-- 2C 2A 31 32 00 10 03

My program calls it a packet because it ended in 0x10, 0x03. It's regarded
as "bad" because it doesn't start with 0x10. Line 3 shows the same dump as
line 1 because I could not decode said packet.

In the pastebin, things start going wrong around line 1142.

Also of note is that in the successful packets the Timestamp field is
milliseconds since the pic started.

And note the packets AFTER things start to go wrong that APPEAR to be ok,
are mostly not correct but contain invalid data. My protocol has no checksu=
m
or parity support yet.

>
>
--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.