Hi! I notices that when multiple sensor/actuators are connected to the BrickPI3 then the update rate of for example the color sensor data is reduced. E.g with 2 lego motors, 1 distance sensor and 2 color sensors , the update rate of the color sensor data may be as slow as 5ms. While the spec of the color sensor itself has a specification of a 1ms update rate. Luckily the BrickPI3 is stackable, so adding an extra BrickPI3 board with e.g. only 1 color sensor gives me the expected update rate (not sure it is 1ms, but probably close). But here my question, is there any knowlegde than can be shared on the “load” that each sensor/actuator is introducing on the board, so I can compute how I should distribute the sensor/actuators over the 2 board to get the expected update rates. Maybe 2 boards is not enough for getting maximum update rates of all sensors? Doing this by experiment will be tough 
.
Thanks in advance!
Regards,
Henk
hm, just did some extra logging while reading from the color sensor. Now this problem with slow refreshrate is also ocurring on that second BrickPI3 board as well, with only 1 sensor attached! Now even worse. Up to 10ms I get the same value. Maybe the board is doing just fine and I have some poblem in my software! But I cannnot explain why the same code was working 2 days ago and is now failling on me. To be investigated. Of course if there is any chance that this behaviour can be explained from hardware side I’d be happy to hear.
Henk
Some update on the issue. When I do not call reset_all and detect on the second stacked BrickPi3 and also reduce the SPI communication to the first BrickPI3 on the shared SPI bus I can get refresh rates of less than 2ms for the color sensor readings (as expected). When the problem of the slow refresh rates occurs then I get a systematic slow refresh rate between 5ms and 10 ms ( values are repeating for 3 up to 6 times) during that run . Is the amount of SPI communication that dominant on the performance of the chip on the BrickPI3?
Henk
Another update: Calling (using C++ interface)
set_sensor_type(PORT_1 + PORT_2 + PORT_3 + PORT_4, SENSOR_TYPE_NONE)
is causing the issue!
It is part of reset_all in the BrickPi3.cpp library. As soon as you call it the refresh rate of the color sensor data drops to 5-10ms . Also calling it at the end of a run of the software, the next run of any software, without resetting the BrickPi3 board will have the issue. That aspect made it very hard to go to the bottom of this! Never calling these reset functionality for all sensor-port is a workaround for my issue. My BrickPi3 has firmware 1.4.3 .
If there is any explanation for this I’d love to hear it!
Regards,
Henk
Similar issue with the inertial measurement unit required I create a “Software Initialization Only” option on my version of the DI sensor class, that created the software object for interfacing with the hardware, but did not re-initialize the hardware.
Interesting! Happy to see I’m not alone 
. I also just noticed that after a cold boot (removing power) during the first run I have this slow referesh rate as well. Restarting the software (with the workaround of not initialising sensors of course) makes the problem go away.
For the people interested in using stacked BrickPi3 boards. This is not working very reliable. It least not in my case. When powering the stacked BrickPI3 solution sometimes 1 of the boards does not start. It can be easily seen by the led that does not light up. power off/power on solved the problem. Also sometimes there is a problem with the SPI communication. When requesting intensity from the color sensor, at random ( about once every 50 measurements) a zero value is returned (on both stacked boards) . Now that I have a workaround for the slow refresh rate I returned to using the single BrickPi3 where I have never seen these erratic zero values.