Teensy 4.1 lags with the Bolderflight / sbus 7.0.0 LIB, but not with Teensy 3.2

Embring

New member
I have noticed that sbus_rx.Read() lags a lot in below example code with Teensy 4.1 but works great with Teensy 3.2. I am currently using a receiver with already inverted signal Oversky XR602T-A2 running at 3.3V. No problems at all with T3.2 as said. I'm wondering if the T4.1 expects a non-already reversed input? Can I define this Option for T4.1? Or is it the higher clock speed in T4.1?

I have used a "only input" version of the Arduino example in the lib:

#include "sbus.h"

/* SbusRx object on Serial1 */
bfs::SbusRx sbus_rx(&Serial1);

/* Array for storing SBUS data */
std::array<int16_t, bfs::SbusRx::NUM_CH()> sbus_data;

void setup() {
/* Serial to display the received data */
Serial.begin(115200);
while (!Serial) {}
/* Begin the SBUS communication */
sbus_rx.Begin();
}

void loop() {
if (sbus_rx.Read()) {
/* Grab the received data */
sbus_data = sbus_rx.ch();
/* Display the received data 6 channels */

for (int8_t i = 0; i < 6; i++) {
Serial.print(sbus_data);
Serial.print("\t");
}
Serial.println();
}
}
 
Code:
#include "sbus.h"

/* SbusRx object on Serial1 */
bfs::SbusRx sbus_rx(&Serial1);

/* Array for storing SBUS data */
std::array<int16_t, bfs::SbusRx::NUM_CH()> sbus_data;

void setup() {
	/* Serial to display the received data */
	Serial.begin(115200);
	while (!Serial) {}
	/* Begin the SBUS communication */
	sbus_rx.Begin();
}

void loop() {
	if (sbus_rx.Read()) {
		/* Grab the received data */
		sbus_data = sbus_rx.ch();
		/* Display the received data 6 channels */

		for (int8_t i = 0; i < 6; i++) {
			Serial.print(sbus_data[i]);
			Serial.print("\t");
		}
		Serial.println();
	}
}
Could I request that in future you enclose your code between code tags using the # key.
I am sure that you will agree that it makes the code much easier to read and helps others understand your code and are therefore in a better position to be able to help you.

I know that your code is very short, but it makes a good example for everyone else when it is presented properly.
Oh, and by the way, welcome to the Teensy fold.

EDIT: You don't say whose sbus code you are using. This may have an impact.
 
Thank you for your reply. Good point! I will use # key in the future.
I wrote the library name: Bolderflight /sbus and the version 7.0.0 in the Thread header but correct name is Bolder Flight Systems SBUS by Brian Taylor version 7.0.0 its in the Arduino Library Manager
 
No problems! Nice if some knows the difference in the serial hardware ports between T4.1 and T3.2 and if there are some way to get T4.1 work with SBUS without lag. Normal SBUS are inverted (zero = high) but the one I work with are (zero = low). And Teensy3.2 works great with the same code and library. So there are some difference how the boards handle the code.
 
The author has validated the code for Teensy 3.x, Teensy 4.x and Teensy LC so presumably he didn't find any peculiarities for the 4.x.
Hopefully he will see your request and respond. He should be awake soon.
 
What version of Teensy code are you running?

The reason I am asking, is several releases ago, I put in code to speed up some lag stuff in handling Serial ports.

In particular, the hardware is setup to minimize hardware interrupts, so it may queue up several bytes of data in hardware RX queue before it interrupts the processor to transfer the data into the Teensy software RX queue.
And there is sort of a Hardware timeout where it might not interrupt you until either A) there is so many bytes in the queue or B) timeout, which I believe is the time to receive one character. So the HardwareSerial code
was updated for available(), peek and read, to take a peek into the hardware queue and grab from there if needed.

Don't remember which build that went into. But if you are running an old version, you might try updating a more recent release (or beta)
 
I guess I found a work around or error in the sbus.cpp file:

Code:
/* Start the bus /
/ Teensy 3.0 || Teensy 3.1/3.2 /
#if defined(MK20DX128) || defined(MK20DX256)
uart_->begin(BAUD_, SERIAL_8E1_RXINV_TXINV);
/

Teensy 3.5 || Teensy 3.6 ||
Teensy LC || Teensy 4.0/4.1 ||
Teensy 4.0 Beta
*/
#elif defined(MK64FX512) || defined(MK66FX1M0) ||
defined(MKL26Z64) || defined(IMXRT1062) ||
defined(IMXRT1052)
uart_->begin(BAUD_, SERIAL_8E2_RXINV_TXINV);

Code:

I changed the stop bit to 1 as in the /* Teensy 3.0 || Teensy 3.1/3.2 */ for
also * Teensy 3.5 || Teensy 3.6 || * Teensy LC || Teensy 4.0/4.1 | * Teensy 4.0 Beta
Last line:
Code:
uart_->begin(BAUD_, SERIAL_8E1_RXINV_TXINV);
Code:

And now its working!


I also tried the # key but it didn´t work I guess..
 
I also tried the # key but it didn´t work I guess..
Sorry should have said the # button on the reply form (or whatever).
Teensy # key.png
 
What error in the file?

It works for me.

If you look at HardwareSerial.h in cores you should see:
#define SERIAL_8E2_RXINV_TXINV (SERIAL_8E1_RXINV_TXINV | SERIAL_2STOP_BITS)

Edit: Note that was added to the header file 4 years ago.

Also the changes to Peek, Read and Available, looks like were done 3 years ago
 
Last edited:
Just wanted to tag the GitHub issue here:
https://github.com/bolderflight/sbus/issues/59

It's looking like that particular RC receiver isn't implementing the inverted SBUS protocol correctly, but may be implementing a non-inverted version of the signal with the correct number of stop bits. I think a potential improvement to the library would be to make it easier to specify and use a non-inverted serial, especially since a lot more RC receivers are outputting non-inverted SBUS these days.
 
Back
Top