Open evoggy opened 2 years ago
I tested the intermediate fix in https://github.com/bitcraze/aideck-esp-firmware/issues/9 (issue also described in https://forum.bitcraze.io/viewtopic.php?t=5321). While it does improve the performance, we are still seeing large gaps in the communication (sometimes up to 3 seconds). For us, this seems to be happening only when routing to multiple targets, i.e., especially if we route messages STM32->GAP8, while streaming data out over wifi.
Perhaps this is a bit off-topic, but why isn't the direct UART connection AI-deck <-> GAP8 being used for CPX? This would reduce this SPI bottleneck mentioned in this issue.
When I was testing it here I couldn't find any connection between the GAP8<->STM32 communication and these pauses. Even with all the GAP8<->STM32 communication switched off I was still getting these. As to the cause of this I'm not sure, it could also be interoperability issues with our WiFi setup. I'm happy that skipping the GAP8<->STM32 communication seems to work for you.
There's a few reasons for not using the UART between the GAP8 and the STM32:
I'm hoping to get some time in the coming weeks to look at this (when things wind down for the summer).
I dont have very much to add here, but we have been playing around with the wifi-streaming-example and there was a big performance difference between connecting the cf to my desktop via WiFi and connecting to the one of my colleague. My WiFi driver works fine with other networks, so I am not sure why this happens.
Thanks for the feedback. Yeah, I've also seen some differences between my WiFi at home and at the office.
It's been observed that the WiFi suffers from intermittent performance issues. This can be seen in the wifi-img-streaming example where the frame rate sometime goes down and the image stops updating for a short while. This seems to be caused by the WiFi throughput going down, which causes the tx queues in the ESP to fill up and in turn blocks the SPI communication from the GAP8. The same interruptions can be seen client side. The result can be seen below:
After some investigation the trail ends at
send(...)
inwifi.c
which runs smoothly most of the time, but can take seconds to return sometimes, and this will backup the queues all the way to the GAP8.