OK, I've been over TinyOS 2.0.2 code and the above TEPs and am having some trouble with some inconsistencies that maybe someone could help me out with:
TEP 113 implies a serial header as:
typedef nx_struct SerialAMHeader {
 nx_am_addr_t addr;
 nx_uint8_t length;
 nx_am_group_t group;
 nx_am_id_t type;
} SerialAMHeader;
which is 5 bytes;
while the actual source code shows it as:
typedef nx_struct serial_header {
        nx_am_addr_t dest;
        nx_am_addr_t src;
        nx_uint8_t length;
        nx_am_group_t group;
        nx_am_id_t type;
} serial_header_t;
in serial.h, which is 7 bytes.

TEP111 implies that the serial header is 5 bytes (in section "3.1 Headers"), when, in reality, according to my experiments, it's at least 7 bytes, and, most likely, 9 bytes. Let me elaborate... TEP113, section 3.6 implies that the header should have at least two extra bytes, possibly three:
P       = Protocol byte: SerialP
S       = Sequence number byte: SerialP
D       = Packet format dispatch byte: SerialDispatcherC
where the sequence number byte is not implemented, so I'll accept it's just two additional bytes, P and D. I suppose the argument could be made that this is not part of the header (it's part of the frame or protocol), and I would like to understand that argument.
That being said, it seems like the actual serial header is more like:
typedef nx_struct serial_header {
        nx_uint8_t protb;
        nx_uint8_t pktfmtdispatch;
        nx_am_addr_t dest;
        nx_am_addr_t src;
        nx_uint8_t length;
        nx_am_group_t group;            // 8
        nx_am_id_t type;                        //8
} serial_header_t;
In actuality there is also a frame CRC; but this isn't mentioned TEP111. I understand why it might not be mentioned there, since it's frame-related and not really related to message_t.

It might be nice to mention these "framing" issues in TEP111 to avoid confusion, and having to go to multiple TEPs and source code to piece things together.

OK, so now to show some of my code output showing all of this and the CRC.
This is the raw packet from a BlinkToRadio experiment with
#define TOSH_DATA_LENGTH 100  (I actually used the Makefile entry:
CFLAGS += -DTOSH_DATA_LENGTH=100):
Format is byte number-contents:
Raw TOS packet contents:
0-45 1-00 2-ff 3-ff 4-ff 5-ff 6-64 7-00 8-06 9-00 10-02 11-00 12-09 13-00 14-00 15-00 16-00 17-00 18-00 19-00 20-00 21-00 22-00 23-00 24-00 25-00 26-00 27-00 28-00 29-00 30-00 31-00 32-00 33-00 34-00 35-00 36-00 37-00 38-00 39-00 40-00 41-00 42-00 43-00 44-00 45-00 46-00 47-00 48-00 49-00 50-00 51-00 52-00 53-00 54-00 55-00 56-00 57-00 58-00 59-00 60-00 61-00 62-00 63-00 64-00 65-00 66-00 67-00 68-00 69-00 70-00 71-00 72-00 73-00 74-00 75-00 76-00 77-00 78-00 79-00 80-00 81-00 82-00 83-00 84-00 85-00 86-00 87-00 88-00 89-00 90-00 91-00 92-00 93-00 94-00 95-00 96-00 97-00 98-00 99-00 100-00 101-00 102-00 103-00 104-00 105-00 106-00 107-00 108-00 109-eb 110-a2

Notice my data starts at byte 9 (like it should based on the reasoning above). Bytes 109 and 110 seem to be the CRC. The framing 0x7e (and any escaped chars) have been removed automatically by my code.
Does all this sound reasonable?
Regards,
Kurt


_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Reply via email to