Using LSS adaptor board with serial communication software

[scharette]

@Eranda43 oh! I totally forgot to respond to this amazing reply you placed! My bad!

@Eranda43

@scharette Mate, you are an awesome dev! That reply was very comprehensive. And you are right, it did improve the performance very well! Thank you very much!

I’m glad this was helpful! We are certainly very interested in improving all aspect of the LSS products, so feel free to get back to us with any other ideas/comments/etc.! We’ll do our best to either clarify stuff or improve it as much as we can.

@Eranda43

Here are some of my findings. Hope it will be useful for whoever might run into a similar problem in the future.

Thanks for that! I’m sure the rest of the community will appreciate your efforts!

Here are some ideas concerning what you found out about all of this:

@Eranda43

The bottle-neck is the FIFO buffers and the latency that comes with them (i.e. buffer time-out). The latency to empty the read/write buffers takes forever. Depending on how many bytes are in the write buffer at the time, the FIFO driver waits a fixed amount of time before pushing the data to the serial bus that’s connected to the motor.

I’ve only really had the issue (on Windows) with reading from the buffer, not writing to it (and therefore to the LSS bus). That being said, it may be handled differently on various Linux platforms.

@Eranda43

Sending the commands in a single string (instead of calling the write function multiple times) can therefore reduce the time greatly. However, depending on the size of the string, some latency may still get added.

Yes, there can always be some extra latency just from the fact that if you are not running a RTOS then anything can happen, delaying a reply from the hardware/drivers.

And, of course, even if your packet exceeds the size of the buffer, the extra bytes may be delayed until the next buffer timeout (though that was not my experience with PC TX > LSS RX).

@Eranda43

I’ve read somewhere the FIFO buffer is 16 bytes, so I tried padding the string with random characters to match that length and force the buffer to push the data without waiting for the buffer time-out, but this didn’t seem to work. I guess there may have been something else in the buffer that messes up the timing (couldn’t find a way to show this).

Another option (at least for PC TX) might be to simply tell the UART drivers to flush out the data (instead of waiting for exact size/timeout).

As for replies, it may be possible to add a configuration to the LSS firmware to add padding to replies. When running at 500k baud (~20 µs / character) the delay from buffer timeout/drivers/OS HAL is far, far longer (sometimes dozens of ms) compared to adding a few characters to each reply. It would have to be tested, but that may be one way to circumvent the issue. Since whitespace is ignored in the LSS protocol that would be an easy way to add padding (such as at the end before the footer; a carriage return).

With a lot of hardware (and proper drivers) you can reconfigure the buffering to be different. By default, they are usually set to 8-16 bytes to cater to high-data rates instead of low latency (optimally every byte would trigger an interrupt!). So that should be an interesting thing to look into. I know many of the FTDI chips (such as the one used in the LSS Adapter Board) have configurations that can be changed to lower latency.

@Eranda43

However, ubuntu comes with a package called “setserial” which can be used to mess around with the buffer latency.
You can use “$ setserial /dev/ttyUSBx low_latency” to minimise the time it takes to read/write from the buffer. In my work I sent a string to read the position, temperature, voltage and current in one long string message as was suggested by @scharette . I read the whole output from the motors with 5-7 ms on average. I saw that between read values there was about a 0.9 ms delay. This corresponds with the information provided by @scharette where it takes about 827 µs for the motors to process and send the data over the bus.

I assume that package is probably changing the chip’s/drivers settings to improve the latency. Since the data rate for LSS is quite low but we want high latency smaller buffers are definitely a good way to go. And if you don’t have much running simultaneously anyway and multi cores than it is a no-brainer to do so.

I’ll have to look into that package and see what I can find out about it. I personally mostly run Arch or arch-based systems (such as Manjaro).

@Eranda43

There maybe a way to change the read/write latency in windows as well, but I have not investigated this.

Well, other than changing settings in the chip/its drivers, I’m not sure if there is anything else to do. To be investigated too!

@Eranda43

In conclusion it takes about 1-2 ms on average to request and receive a given sensor data (i.e. temperature, voltage, current, etc.) with 115200 baudrate provided the serial read/write buffer latency is minimised.

This seems like it would be quite acceptable for most cases.

We do have some customers using the LSS bus with a RPi4. The big advantage there is that the RPi4 has multiple physical UART buses available (of course, you’ll need a level shifter / voltage translator such as RB-Spa-879 to use them with the LSS). You can change the FIFO size on some of those buses. If I remember correctly, some can be set to 1 byte and then all that’s left is to give it high priority and you’ll be near real-time. Also, since there are multiple buses available, you can set each UART for a group of LSS to keep everything fast.

@cmackenzie has been doing some great work on this recently. You can read some of the details about it here. Be careful, it is a long topic full of very interesting discussions… you may get sucked in so make sure you have a handy snack nearby!

Keep up the good work @Eranda43!

Sincerely,