Has anyone found documentation or tested the performance of the RPC bridge link between the two processors. In terms of throughput, latency, and blocksize?
It appears that the communication is over a 115200 bps serial connection with some RPC protocol overhead. Is that correct?
I would like to transfer around 4000 floats per second, is that possible?
I did ask that question and indeed it's Serial1 being used at 115200 bauds.
see @ptillisch answers in
4000 floats is 16,000 bytes (plus overhead even if MsgPack adds minimal overhead—usually 1 to a few bytes per array or element for the array header) and at 115200 bauds you transfer roughly 11520 bytes per second ➜ so no you won't be able to do that.
Since you can't, the solution is to reduce the number of bytes transferred. Some sort of compression, or deltas but it has to be a fast algorithm.
probably the solution is to really wonder if you need to send those 4000 floats to the other side.
The idea is likely to process them on the CPU and send to the MCU part whatever is the outcome of this processing.
acquire --- process --- define action list ---> bridge ----> execute actions
⎣____________ CPU SIDE _________________⎦ ⎣____ MCU SIDE______⎦
Many thanks for your quick reply.
I see on the schematic there is SPI connection between processors. Maybe this might be considered as an alternative in future?
The transport layer is independent of the library so indeed, they could move to SPI.
i also wonder why they picked only 115200 bauds for intraboard communication. You could imagine that this link is pretty robust and could go to 1 or 2 mbps easily...
Any good reason you really need to send all those bytes on the other side ? what will you do there that you can't do on the CPU first ?
I will look at doing some compression. The data is from a thermal array. While I need to preserve overall data precision to 5 significant digits, the data is from a thermal array, so has low entropy both spacially and temporaly.
The data is destined for cloud storage and cloud processing
Many thanks.
That can be represented quite well by a 16 bit int.
What is the precision of the measurement from an individual pixel in the thermal array?
Can't The CPU side running Linux handle network communication directly ? what do you want to do on the MCU side ??
The MCU is scanning the thermal array. The data is read as a 24 bit integer, but offset and noise mean that the significant data can be represented in 16 bits.
ah OK - it's in that direction. 
It has been confirmed there is an intent to at some point move the bridge to SPI as the link is available.
In the mean time you could use that SPI link to send the data (and possibly the bridge as a low speed communication channel for commands or sync info).
I'm currently doing some performance test with an oscilloscope and it seems you have to keep in mind that Bridge calls do not go directly to the MCU. It goes to a server, then the MCU.
Spamming as fast as possible the notify command crashes the connection. I'll report when I can if someone else don't do it before
Hello.
I made a video explaining how to increase the Bridge communication speed to 460800bps.
Interesting, pretty easy upgrade.
I will try all possibilities.
One small note on this approach: it’s a quick win if you want a speedup but keep in mind that any update you might receive for the arduino-router service will overwrite your changes if done that way.
If you want to retain your changes across version updates you can run “sudo systemctl edit arduino-router” and add your changes there instead. It will still be an override of the defaults, so if the defaults change you will need to update the override as well, but it will be retained.
Hi all,
@hfujimoto thank you so much for your exploration and findings.
Just so you know, flow control may be required at data rates exceeding 115200 bps. It needs to be enabled in the Linux kernel's device tree for the lpuart2 (/dev/ttyHS1) device, and some changes may be required on the device tree for the corresponding UART (Serial1) on the Arduino side in the Zephyr Core.
Our R&D team is testing to enable this feature and integrate it in the next release of the software stack.
Thanks!
What is the state of this now?
It looks like on the Arduino side, that maybe the bridge begin takes an optional
baud rate? Does that work?
Will try the stuff mentioned here.
Also (from the Arduino guys), what is the state of the SPI communication between the processors?
Not sure if this will help but in my post: Evaluated Uno Q Router / Bridge Latency with MAX31855 I proposed a way to evaluate the latency using python. This latency number is a composite of all the processes between the MCU and Python calling the provided method.