Teensy 3.2 and Serial1 baud rate

Status
Not open for further replies.
Hello,

I am currently trying to measure a photodiode voltage signal with Arduino/Teensy and send it to my pc (read the values in Labview) via bluetooth at data rates > 4 kHz. For the bluetooth connection I use the HC-05 bt module. At first I tried the experiment with Arduino Nano and Zero. For the Nano, everything worked fine for low baudrates up to 115200, but this was not enough for me since the transmission needs to be faster to achieve 4 kHz or more. However I could not increase the baudrate, because the Nano only supports high baud rates like 500000 or 1000000, whereas the HC-05 only supports certain values like 921600 (max).
This changed Using the Arduino Zero which supports 921600 baud, so the I could use the HC-05 module with maximum speed and I achieved data rates up to 2,4 kHz, which was limited by the ADC of the Zero and not by the HC-05.

So now I bought a Teensy 3.2 because I have seen that it can go > 10 kHz data acquisition with the ADC. I have the HC-05 connected via Serial1. When I use USB to transfer the data to LabView, everything works fine and I get the desired data rates. But using bluetooth only works for 9600 baud. When I increase the bluetooth baud rate, I do not see any data transmitted at all in LabView (same with the serial monitor). Does anyone know why? As it works fine for 9600 baud, I do not see the point why it should not work with higher baud rates?!?

The code I use is very simple:

uint32_t data=0;
void setup() {
Serial1.begin(921600);
}

void loop() {
data=analogRead(1);
Serial1.print(data);
}
 
What is the speed spec on the Bluetooth unit? Bluetooth is inherently slower for low energy. Has it worked faster? Assuming three wires are common to Bluetooth unit: Tx/Rx/GND and running at 3.3V?
 
As you said, i connected Tx to Rx1 on Teensy, Rx to Tx1, Ground and 3,3 V as Power supply. I already tried to switch Rx and Tx, so thats not the problem. And I tried using 5 V as VCC, still no change. The LED on the bluetooth module is flashing fast, which is correct when the coupling is fine. I know that the bluetooth module can do 921600 baud, because it is already working when I am using Arduino Zero
 
Just by googling quickly around, I found a HC-05 data sheet from Itead and it said that the max baud rate was 460800... Thus I'd go increasing step by step from 9600 to see where the true limit is.
 
It does support up to 921600 baud, I know because it already worked with Arduino Zero. However I tried different baud rates between 9600 and 921600 and only 9600 works with the Teensy.
 
Many people use Teensy at different baud rates. I personally use 115200 all the time.

I have no idea why this isn't working for you, but I can say with good confidence it is not a matter of Teensy only supporting 9600 baud!
 
As I quick sanity check, I ran your code from message #1 on a Teensy 3.2.

Here is the waveform my oscilloscope sees, and properly decodes as 921.6 kbs.

file.png
(click for full size)
 
For comparison, I programmed the exact same code onto an Arduino Zero. Here it is on my workbench:

azero.JPG

This is the waveform Arduino Zero produces, viewed on the same 20 us/div time scale as the Teensy waveform above.

file.png

Here is how it looks if I zoom out by 10X.

file.png

While both Arduino Zero and Teensy 3.2 are sending data at 921600 baud, Teensy is able to read its analog input, convert the number to ASCII text and get them transmitted at the full 921600 rate. Each start bit immediately follows the stop bit of the previous byte. The data rate really is 92160 bytes/sec on Serial1.

Arduino Zero is much, much slower than Teensy. It appears to run the loop only once every 450 us. While the bytes are sending at 921600, Arduino Zero spends almost all the time not sending data. The actual effective rate is approximately 6700 bytes/sec, almost 14X slower than Teensy!

Teensy has dramatically faster CPU speed than Arduino Zero. The Serial1 hardware and software also is much more efficient than Arduino Zero, with a hardware FIFO and highly optimized interrupt-based transmit.

Perhaps your bluetooth module simply can not handle this very high data rate? Maybe it really only works at such a high speed if the data is short bursts with lengthy gaps?

Or maybe it is unable to sync to the start bits? If it initializes after the data stream has begun, there's a chance it could mistake some data bit the start bit, and forever not be able to recover because Teensy is managing to relentlessly send maximum possible speed data with no extra gaps that would allow the receiving UART to recover and find a true start bit again.


Edit: just to be careful, I repeated this test with the SAMD library version 1.6.15 and 1.6.16 (after realizing I had the older version installed the first time). Both show identical speed.
 
Last edited:
Just for comparison, I decided to give this a try on Teensy LC, which has the same Cortex-M0+ CPU running at the same 48 MHz clock speed as Arduino Zero. There's still plenty that isn't apple-to-apples between these two, but they're definitely in the same hardware performance class.

Sadly, LC can't do 921600 baud, so I had to increase the rate slightly to 1 Mbit/sec.

Here is the output, viewed on the same 20 us/div scale.

file.png

Teensy LC can't quite get each run of loop() fast enough for back-to-back output like Teensy 3.2 can, but it's pretty close with about a 1 byte gap between each Serial1.print(). It's not anywhere near Arduino Zero's sluggish net speed.

Part of Teensy LC's performance on this test probably comes from this divmod10 optimization work a couple years ago.
 
Last edited:
Thank you so much for your help. It helped me figure out the problem!

Arduino Zero is much, much slower than Teensy. It appears to run the loop only once every 450 us. While the bytes are sending at 921600, Arduino Zero spends almost all the time not sending data. The actual effective rate is approximately 6700 bytes/sec, almost 14X slower than Teensy!
That was the exact reason why I bought the Teensy and tried to replace the Zero!

Perhaps your bluetooth module simply can not handle this very high data rate? Maybe it really only works at such a high speed if the data is short bursts with lengthy gaps?
This made me think, so added a delay(1) in my loop, just to slow everything down. And afterwards everything worked fine. The problem really is that the HC-05 cant handle that much data. So it generally supports 921600 baud, but only if data is not coming too fast (which was fine for the Zero). As I know the problem know, I will try take the best out of the setup, maybe I use the time for averaging. If its not going to reach the desired data rate, maybe I need to change to Wifi or whatever. Thanks again!

Sadly, LC can't do 921600 baud, so I had to increase the rate slightly to 1 Mbit/sec.
I had the same problem with Arduino Nano. This is not compatible with the HC-05 as it only supports 921600, not 1000000 baud because you can only set the baudrate to certain values.
 
This made me think, so added a delay(1) in my loop, just to slow everything down. And afterwards everything worked fine. The problem really is that the HC-05 cant handle that much data. So it generally supports 921600 baud, but only if data is not coming too fast (which was fine for the Zero). As I know the problem know, I will try take the best out of the setup, maybe I use the time for averaging. If its not going to reach the desired data rate, maybe I need to change to Wifi or whatever. Thanks again!

I am not sure where you are putting the 1ms delay. Is this between packets or between bytes? If something like bytes... Personally I think you are better off lowering the baud rate until the BT works reliably.

I am assuming that the BT adapter has to be even multiples of something like 11500 so does 460800 work?

Does your unit have other pins available, like RTS/CTS? Maybe those can help?
 
The 1 ms delay was not meant as a solution to the problem, I just used it to be sure about what the problem is. After all it does not make sense to increase the baud rate if I do not have any benefit, so I need to find best settings at lower rates. And you are right, it does support multiples of 9600, which I tried early on and had the same problems. There are no other pins available.
To slow down the code, I now average over some measurements and send the average value via bluetooth. Everything works fine and I have a data transfer rate over 4 kHz (although I average more measurements) so that is all I wanted to achieve. Thanks to all!
 
Status
Not open for further replies.
Back
Top