TOC documentation error?

[hsanjuan]

Hello,

[context is crazyflie python client]

according to http://wiki.bitcraze.se/projects:crazyf ... ent_access a TOC element packet will have in its byte 1 the index of the next element to fetch, and in its byte 2 its ID and in its byte 3 the type.

However a LogElement uses data[0] as ident and data[1] as type (cflib/crazyflie/log.py).

Byte 0 (0x00 to identify the command) is stripped from the response in TOCFetcher (cflib/crazyflie/toc.py), but that's all as far as I can see. So data[0] would be the next element to fetch and not the ident. Actually the "next element index" is something that is not used anywhere so I am guessing it is not coming in the packet? Otherwise this could be a bug where all elements IDs have the ident of the next element instead. Maybe this is happening without breaking anything since but there would be an element with 0xFF ident then...

I hope I have explained myself well.. I'd be grateful if some of the developers could clarify

Thanks.

[arnaud]

Hi,

This is an old and out of date documentation. We use to have id of the next element in the packet but now instead we get the lenght of the toc and just fetch all elements with ID fom 0 to len-1. So you are right this is not comming in the packet anymore, the comm part of the wiki has to be cleaned up a bit.

A more up to date documentation of the TOC protocol can be found there: http://wiki.bitcraze.se/projects:crazyf ... ent_access

The TOC for log and parameters uses the same protocol but with a slightly different element payload (different types encoding).

[hsanjuan]

Thank you!

Perhaps out to date docs could have a mark or a notice referring to the current code/wiki page?

Have a nice day