This works fine if we only attach the SD Card Deck on the top of the crazyflie. However, if we additionally use the Flow Deck at the bottom, no log files are created on the SD Card. The logging frequency does not seem to matter, this also appears if we only log a few times per second.

We tested using a log config on the SD Card which does not log anything (only the ticks) and that seems to work so far as the log files are written then (but do not contain any useful data).

Does anyone know why this might happen? Are there known incompatibilities between the Flow Deck and the SD Card deck in combination with logging to the SC Card?

Both decks are using the SPI bus, so it is possible that there is some collision happening there. There is a ticket on github tracking a very similar problem (with the loco-deck), I just updated it to add the flow deck in it as well: https://github.com/bitcraze/crazyflie-f ... issues/270

So, it works find if you are logging only timestamps at any rate but not if you are logging data as well? If so, it might fail when writing too long lines.

I made further tests, it looks a lot as if the SD Card Deck and other Decks are intensively competing for resources (task runtime and memory). Depending on the configuration, various errors can occur (Some just occur randomly):
- The Crazyflie seems to be working fine, but logging only is available for a few seconds and then just stops (when using flow deck and adapting other parameters, so it does at least not restart with an error)
- The Crazyflie has problems with memory allocation due to insufficient heap size (when the buffer is 200 for example. 120 seems to be working fine)
- The Crazyflie has a mutex problem (the assert in task.c:3495 fails - this also means it will drop out of the air, if it does not happen right at the start)
- The Crazyflie can not handle a task waiting for less than a millisecond (seems to be occurring sometimes, when frequency is set to 333 hz - error in task.c:832 - Assert fails)

if( pxMutexHolder != NULL )
{
/* A task can only have an inherited priority if it holds the mutex.
If the mutex is held by a task then it cannot be given from an
interrupt, and if a mutex is given by the holding task then it must
be the running state task. */
configASSERT( pxTCB == pxCurrentTCB );

Is this a problem, that is only known in some settings (some SD cards etc) or can you not log either?

We want to log that frequently, because we want to rebuild the results achieved in this paper using the flow deck for (approximate) localisation instead of a vicon camera system:https://arxiv.org/pdf/1610.05863.pdf

Do you guys have a proposition, how we could get the necessary sensor data from the Crazyflie with at least 250 hz? cflib only allows for logging at 100 hz and only if it fits into one log block, it is even slower when using multiple log blocks.