PE>> Fortunately I am rarely wrong. 02 00 does indeed mark the
 PE>> beginning of the message. The middle of the message can also
 PE>> have that sequence of bytes, and it's only by doing full
 PE>> sequential processing of the packet that you can tell for sure
 PE>> whether a particular binary combination of 02 00 represents the
 PE>> start of a message or some other binary data (e.g. node
 PE>> number).

 BL>> What identifies the end of the packet? Your ones have 0D 00 00
 BL>> 00 but you'll only tell me it's hex for "Merry Christmas."

 PE>> A single 00 marks the end.

 BL>   Unfortunately, this is one of those rare occasions when you are
 BL> wrong. FTS-0001 dictates a null terminator for each message, but
 BL> the end of the packet adds another two 00's.

Bloody hell, I didn't even make it through the next paragraph
with my reputation for flawlessness intact.  It was a genuine
mistake though.

As for being illogical, the idea of the packet is that you read
it in sequentially.  If you had read the fixed header bit first,
which is 50 bytes (or whatever), then you search for a NUL 4
times (or whatever), that is the proper way to go from message
to message.  The idea is not to hop into the middle and try
to fight your way out.  Read one message at a time, and any you
want to delete, delete.  BFN.  Paul.
@EOT:

--- Mksmsg