When reading data from UART, fetching data is not correct

[waltr]

I was having the same thoughts. Not all Xbees are the same.

Also, it looks like Missile Works' XBee are basally sending GPS data which is typically once per second and 65 characters per $GPGSV packet. This contains the basic Lat, Long and Height data. It may send some other 'status' info.

This is NOT Streaming large amounts of data from fast sample sensor.

I have a payload package that samples 3 -3-axis plus sensors at 50/second but simply store the data in on-board Flash memory then download after the flight.
Only 'live' info some flight status.

 

[deepfreeze]

Guys i changed my code to API mode instead of AT mode. I am getting the data now without loss. but it's a bit slow. I'll make few adjustments and show you the code.

 

[deepfreeze]

The Xbee should have hardware flow control. Can you use that on the Arduino side? Or poll the CTS bits in an Xbee register?

I am not doing anything on the Xbee side actually. I am trying to control it on the Teensy side with the code. Also i switched it to API mode. It is more reliable i think.

 

[waltr]

Ok, sounds like some progress.

Was also thinking you could be over running the Teensy's UART FIFO.
Does the code library you are using for 'print' ensures the UART can accept more data?

 

[deepfreeze]

Ok, sounds like some progress.

Was also thinking you could be over running the Teensy's UART FIFO.
Does the code library you are using for 'print' ensures the UART can accept more data?

I'm just using Serial3.print. It should be standart right ?

 

[waltr]

I'm just using Serial3.print. It should be standart right ?

I depends on who's library this is from and how it was written.

Hopefully, it will not write data to the UART if UART is not ready for more data.
Is the source code available? If so then dig into it.

Or connect the Serial3 port to the PC (Serial to USB adapter works) to a terminal program and send data as fast as you can.
If all the data shows then library code is ok. If losing data it is not and may be what you saw in first post.

Do you have an LED connected to a Teensy pin? This can be very helpful to troubleshoot.
Toogle the LED each time the loop sends data. The blink rate should be steady if the hardware is keeping up with the code is keeping up.
You can also measure timing if connecting an O'scope to the LED.