What do bytes 4-end of the message describe?
I can tell that the "start block" messages have the port, command, block ID, then period. Do the add block messages contain the group/name the ID belongs to?

2. Is the ID of the block the same as the ID of the variable contained within? Can you add multiple variables to one block? In my case, it would be fine to have one block for one variable to avoid confusion.

3. I am trying to retrieve variables such as battery, position (loco positioning system), sensor data (temp, etc), and roll/pitch/yaw/thrust (actual). Are all of these variables within the logging system, or do I need to query the parameters port instead? Sorry, little confused here, as these seem to change with operation so I assume they are not static - whereas the parameters port keeps information which stays the same through operation. So I assume they are all in the log.

4. Upon retrieving the TOC info, the PC client seems to know which log blocks it wants to add/start. How would I know the ID for the relevant variables without retrieiving every item (from 1-log_len) and then using that to determine the ID of the variables I want to log? For example, is "battery" always at the same ID? Can I retrieve this item at the same ID every time without first checking where the items are in the TOC?

5. Is the TOC common to the parameters and log port? Or do they each have separate TOCs? When I retrieve items within the TOC via logging, only 15 seem to respond or "exist". The rest, out of log length, do not send items back to me. Are the rest of those items parameters?

Thanks guys, I keep rereading the wiki but I think I may have misunderstood some things.

This adds a block block_id with a list of variables. The block_id is whatever your client wants it to be, it is an 8bit ID that becomes the identity of this block for later commands. The ID of the variables are found in the LOG TOC. The log subsystem is intended to be used to transmit a list of variables in the same packet, the only limit is the size of the log packet (the limit is 27bytes if I remember well, so you can log 6 floats without problems).

2. No, the ID of the block is an abstract 8bit number you choose when creating the log block.

3. Your assumption about log/param is correct: log is used to read variables that change in the firmware, param is used to have a read/write access to variables that are not changed by the firmware during runtime. You need to have the TOC in order to make sure you have the right ID. The get_info packet returns a hash of the TOC, this way you can store a cache of the TOC and fetch it from the Crazyflie only if you need to. This is that is done by the Python and ROS Crazyflie client, it saves about 4 seconds connection time for both log and param TOC. In the client, if you open the menu "settings/open config folder" you can see the TOC cache files.

4. The ID are in the TOC. The client fetches the TOC for both log and param at startup (possibly from its cache, see 3.) and then different tabs will setup logblock depending of their needs. The Python API used by the client does not expose variable ID, at high level the client is adding log with "group.name", the lib uses the TOC to get the ID for each variable and to make the add_block packet. See the lib examples to see how it looks like at high level: https://github.com/bitcraze/crazyflie-l ... py#L72-L93.

5. There is two different TOC, one for LOG and one for Param, you can see the TOCs in the python client. If you see only 15 variables there is a problem though, using the API V1 I would expect you to get 255 variables. There has been a pull request recently changing the LOG ID length to 16 bits which allows to have up to 64K variables, you should look at implementing that instead. It is event less documented so far though since it has not been added to the wiki. The pull request of the API V2 in the firmware is https://github.com/bitcraze/crazyflie-firmware/pull/337 and the implementation in the client is https://github.com/bitcraze/crazyflie-l ... /issues/89.

Unfortunately reading the wiki is not enough since not everything is in sync with the code. We have been talking about moving the documentation closer to the code (ie. in the same git repos) and to enforce documenting functionality in the same commit they are added, this would help I guess. But in the meantime it is all open source and there is already multiple implementation so the best is to go have a look at the existing implementation to understand the protocols and how they are used.