[SOLVED] Serial problem @57600

Hi!, i’m having some problems with the serial i/f of my Photon device @57600 bauds. I’m connecting the photon to a device in order to receive some data packets via serial communication @57600 theough Serial1. The expected packets have a 0xaa 0xaa header followed by a byte indicating the packet length and, then the payload plus a final checksum byte. when i connect the device to my PC i check that everything is OK using HTerm. However, when i connect the device to my photon, at first i begin receiving the packets OK, but at some point, apparently, it starts losing bytes and the received info does not corresponds to the packet format, as you can see on the following log from the Photon device (after 2D 51, the received data are wrong):

AA AA 4 80 2 FF E3 9B AA AA 4 80 2 0 6A 13 AA AA 4 80 2 1 A 72 AA AA 4 80 2 1 CB B1 AA AA 4 80 2 1 5C 20 AA AA 4 80 2 0 23 5A AA AA 4 80 2 FF 9E E0 AA AA 4 80 2 FF BF BF AA AA 4 80 2 FF 5E 20 AA AA 4 80 2 FF 2D 51
AA B8 4 10 4 92 4 AA 80 AA 80 AA 80 AA 80 AA 2 AA 2 AA 2 AA 0 AA 0 AA 1 AA CD AA C3 AA A7 AA E5 AA D3 4 49 4 AA 4 AA 80 AA 80 AA 80 AA 2 AA 2 AA 2 AA FF AA FF AA FF AA B4 AA 1C AA 96 AA B AA 2B 4 71 4 29 4 AA 4 AA 80 AA 80 AA 80 AA 2 AA 2 AA 2 AA 0 AA FF AA FF

i would appreciate any help about this problem and its solution. The code i am using on the Photon device is tha following:

#include "application.h"

void setup() {


void loop() {
    if (Serial1.available()) {
        uint8_t latestByte = Serial1.read();
        Serial.print(latestByte, HEX);
        Serial.print(" ");


If you try while(Serial1.available()) instead of just reading one byte per millisecond (default avg. time for loop() in AUTOMATIC Mode) you’ll have less problems.

The way you’re doing it the 64byte (or 32 - not sure) RX buffer is not read quickly enough and will start overflowing.

@fbt, the serial buffers are 64 bytes deep. If you don’t read the data fast enough, you may lose data. Running with an if (Serial1.available()) in loop() is a good idea except that when loop() finishes, the system firmware will do work in the background adding some delay. Because of this, you should use a while (Serial1.available()) instead to read all available bytes on each loop to avoid loss. :wink:


Hi @ScruffR and @peekay123 … once again, thanks a lot for your fast answers … another solution (more “expensive”), or at less a convenient additional modification could be to allocate my own buffer for Serial1 by implementing acquireSerialBuffer function?.. Thanks!

It’s always better to pull all the available data at once, since even a bigger buffer will overflow eventually when not flushed in a timely manner.

Bigger buffers may be a secondary step if your code flow doesn’t allow for regular reading and you have data bursts to deal with.


… but i just realized acquireSerialBuffer function is not available for Serial1, just for Serial and USBSerial1 …

Hi @ScruffR … i finally solved my initial problem and i started receiving the packes OK, but i still have around 5% of packets lost due to some Serial1 buffer overflow … any general clue to improve it?. thanks again …

What’s your current code?
Does your transmitter allow for any flow control?
Are you expecting a continous high bandwith stream of data or are there bursts of data?

As a easy first step you can use SYSTEM_THREAD(ENABLED) to decouple the application thread and the cloud housekeeping.
If you won’t need the Particle cloud permanently, you can also control the Particle.connect()ion (in combo with a fitting SYSTEM_MODE) in code to keep your Serial1 parts undisturbed by that.

Hi @ScruffR … my transmitter does not allow any flow control, data is received at a continuos strem of data, and by now, i don’t need Particle Cloud services. thanks