From: Jack S. <js...@my...> - 2002-11-28 19:43:11
|
From: "Andreas Robinson" <and...@st...> [...] >Here's the format(s), let me know what you think: > >Each packet is 5, 8 or 11 bytes long. 8 is the >default. Hi Andreas & everyone, I have some initial thoughts about the packet format, and some questions as well. I apologize for the length and incoherence... I have some experience with protocols, but I don't know much about hardware issues. Is it expected that there may be transmission errors on the serial link, which the counter and/or sync bits will be used to detect? Would addition of ECC bits be desirable? Are these sync bits necessary for the sake of hardware, or are they intended as markers to make it easy to decode from the middle of a data stream? What is the intended plan for two-way communication? Could the PC query the unit for version information, and therefore not need it in the packet stream? Would we want to use the two-way ability to improve transmission reliablity by requesting re-xmit of=20 dropped packets? Is it necessary/desirable that the unit be functional in output-only situations where a version query would not be possible (no PC, just a data logger or handheld biofeedback unit e.g.)? My first thought on seeing the existing format (before your proposed changes) is that simple packing of the sample data wo= uld drop it to 7, 9, and 12 bytes per packet (for 2, 4, 6 channels), befo= re doing anything clever. Second thought is that given high transmission reliability, the packet stre= am is easily compressed using simple methods (run length encoding of diff= erences between samples). Not currently needed. >The format is this (looks best with fixed width font): > >1ppppppX <- packet header >0XXXXXXX ... >X =3D one of 8 auxillary data channels, X1 to X8. The=20 >three least significant >bits in the packet counter selects the channel. What would these aux channels be? Is this related to the switches field from the original format? uint8_t=09=09switches;=09// State of PD5 to PD2, in bits 3 to 0. Sorry for length, and I hope this webmail client doesn't post html! --Jack |