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)
'''
The message is truncated. Oddly, in my application I expect 23 bytes and it seems to always truncate to 16 bytes.
I've tried changing baud rate, timeout, response timeout, modem control signals, message pacing and nothing has an effect. I've also verified the signal quality which is very good.
What's the IO board, do you have specs of it?
Where do you put the loopback wire on? Uart2 (AMA1) is on pins 27 & 28 of the Pi header.
Did you edit the /boot/config.txt to enable the uart2?
Yes, for the test flow I use a jumper between pins 27/28 of J8 and yes I did enable the uart in the config file.
I running from the on-board memory not a USB stick.
Obviously in my application I'm not doing a loopback. I am polling a separate processor that's just running some embedded code and see the same issue.
Clutching at straws maybe, but could you stop node-red and start it again in a terminal and post the log from startup here please. Including some comms action.
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?
Keep in mind that pin 27&28 is also used by i2c.
Because your Module 4 IO board has an real-time clock it's likely that the i2c bus is used and can interfere with the UART.
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%.
