I followed the advice on the first post on this topic, i.e., reading back the status to look for 0xFFA5. It turns out the original question (delay between a command and its response) still remains, only that this time with the status data instead of the MAC data as in the previous post.
The figures below show the results of interrogating the fuel gauge status register after a command. I highlighted the times (per analyzer software) and data read.
In the first figure, the delay between transactions is around 800us. BQ returns FF. Furter reads return 00, so the 0xFFA5 is missed anyway. Notice that the same happens with the hardware version reading.
Int the second figure, things work as expected, after I added a small delay (a little more than 2ms).
The transactions shown in the figures occurr during startup so adding some delays to the read operations is not a big deal.
My main concerns are:
1- What is the delay for these operations that guarantee BQ will have the time to answer to the commans (2ms works with this one, will it always work?).
2- How long should I wait after other commands, especially one that involves reading the whole MAC Data + MAC + check sum + length.
