Finally getting some time to work on Flutter again. Here it goes:
I was basing this on the CC1110, but I think the radio packet format for the CC1200 is the same. Something like this
Where Preamble , Sync , Len  are part of the TI radio packet and perform the functions specified in the CC1200 documentation.
Addr  does not address a specific device as in the CC1110 docs, but specifies the something like a subnet. Addr also defines the FHSS random seed. This way each subnet will hop on its own pattern across the 50 channels instead of all Flutter devices using the same hop pattern.
Ver  allows us to update the format of the packet and hopefully be able to handle various packet formats/be backwards compatible by agreeing on the lowest common packet format for the mesh.
ID  is the address of the sending device.
Peers  is the number of peers that the sending node can hear.
Next Seq  is the next hop in the sequence. Not the channel number, but the sequence number, 1-50.
% Complete  is the % of time through the current sequence the packet was transmitted.
User Data [244 max] Payload data the user wants to send
CRC  CRC as as documented in TI CC1110/1200 user guides.
The Next Seq. and % Complete fields could probably be packed into a single byte or eliminated all together if we stick with a 20ms hop time. I was planning on a 400ms hop time so the complete rotation though the channels would take 20s instead of 1s, so those fields would allow faster/tighter hop synchronization once a device joined a network and reduce the overhead from 6 bytes to 1 or 2. While attempting to join a device could either sit on channel 1 and wait until it hears another node with the same Addr or hop through a smaller set and wait longer than 400ms while listening only. So maybe sequence numbers 10,20,30,40,50 and sit on each one for 1/3 of the cycle time. So 6666ms if using 400ms hops or 333ms if using 20ms hops. Additionally, I was thinking that once a device was connected it would be able to keep track of the approximate time till the next hop (via the % Complete variable) to determine if there is enough time to transmit the queued message(s).
Discovery of peers would happen by listening through the hop sequence and recording the Addr and RSSI. This list of peers could then be used for routing in the mesh. We could also have some control packets where the various nodes exchange information about the nodes that are visible to them. This way each node can build a complete routing table so it can forward packets to the best next node. Another thought on peers and forwarding packets is to have a 1 byte num hops variable that is decremented on each hop so that a packet doesn't roam around the mesh indefinitely. We may also need a packet number byte so that a receiving node can discard duplicate packets (in case multiple nodes retransmit a packet).
Any thoughts on this?