I can't be sure if this is a node-red or R-PI issue. It's a low runner so I can work around it but thought someone may want to investigate who knows how to get under the hood.
I've seen this issue on two separate R-PI 4 modules mounted on the R-PI IO boards. The flow below can be used to quickly find the issue. You need to add a wire to loop back the serial port on the IO board.
In my application, I used a o-scope to verify the message size on the wire was correct, this seems to be a receive side issue.
What you'll see is an expected msg length of 32 bytes. The flow will stop when a msg of less than 16 bytes is received.
''' flows(1).json (2.1 KB)
Tested it here on a "normal" Pi4 with a jumper on pin 27 & 28, added dtoverlay=uart2 in /boot/config.txt.
And it works fine here with your flow (removed the delay node).
Array with 26 elements is send and every time there 55 bytes received. This because you send an array and set the receiver as binary buffer output.
I meant up to the point the error occurs. I got the impression that it was a solid failure, but apparently not. In that case are you certain that the full message is sent for the message that fails?
Another question. Does the rest of the message appear as the next message, or possibly on the front of the next message?
You said you had tried various timeout settings, have you tried a very long timeout? One second for example?
Is this the image you wanted?
Since I use a start byte, any left over bytes would be discarded. I'll see if i can modify the test to catch any left over bytes. I will also try a string instead of just bytes.
I did try a very long timeout to see if the erro was due to the timeout expiring.
This is interesting.
If I set the serial port to deliver ASCII stings but keep the Split after timeout I see the same issue with some truncated strings.
If I set the split to be on the \n char then it seem to work 100%.