RDM Buffer too small - truncated received messages and fails OLA rdm-tests

[Florida-Rob]

I notice that the receive buffer is 60 BYTES ?
// the byte array used while receiving and sending.
byte buffer[60];
RDM allows 231 Bytes, so why set at 60 ?

I noticed this as the OLA rdm-tests fail several tests, like E120_DEVICE_LABEL, > 32char
when set to 60, it truncates the RDM message at exactly 32char (I don't know why a buffer of 60 truncates the RDM Data at 32bytes)?
when i increase the buffer to [231] - we now capture the NACK for > 32 char test

BUT, not that the buffer is [231] it fails 41 instead of 6 !!!
any ideas ?

[peternewman]

I notice that the receive buffer is 60 BYTES ? // the byte array used while receiving and sending. byte buffer[60]; RDM allows 231 Bytes, so why set at 60 ?

Hi @riwalker

This was fixed here:
https://github.com/mathertel/DmxSerial2/blame/98cdfc932de94a096e63033c18560dc69eb9f12c/src/DMXSerial2.cpp#L266-L270

And previously here:
https://github.com/mathertel/DmxSerial2/blame/98cdfc932de94a096e63033c18560dc69eb9f12c/src/DMXSerial2.h#L98

Specifically in e1f293e

You'll need to either use Git or ask @mathertel nicely to release a new version.

I noticed this as the OLA rdm-tests fail several tests, like E120_DEVICE_LABEL, > 32char when set to 60, it truncates the RDM message at exactly 32char (I don't know why a buffer of 60 truncates the RDM Data at 32bytes)? when i increase the buffer to [231] - we now capture the NACK for > 32 char test

The string should always be truncated by RDM at 32 bytes the other test checks for different responses when nacking a message that's too long but fits in the buffer from one that doesn't.

BUT, not that the buffer is [231] it fails 41 instead of 6 !!! any ideas ?

What do you mean by 41 instead of 6? Tests? If so can you list which ones, ideally with debug output. It's probably just more slow EEPROM turnaround time.

[Florida-Rob]

Peter Fixed the issue, by changing to Mega from Leonardo Seems that by changing from 50 to 512, the RAM reduced too much and as soon as it went > 50-80%, even though no compiler issues, I started to get random ‘errors’ I thought it was my code with additional serial and watchdog, but stripping all that out and using the GOT code, and simply adding a bunch of Serial.println to add ‘variables’ into RAM, it started to show the same symptom (no compiler errors, just runtime errors), So its either Leonardo specifically, or just resources getting low (with the [50] to [231] byte increase) Changing to the larger Mega, I see no errors whatsoever. And now passing with just 4 OLA ‘Fails’ and plan to clear them down… p.s still don’t have OLA rdm-tests running on Bullseye – would Really appreciate all the steps to download and build an image, way too many libraries missing and make errors for me to debug Rob From: Peter Newman ***@***.***> Sent: Tuesday, January 31, 2023 8:37 PM To: mathertel/DmxSerial2 ***@***.***> Cc: riwalker ***@***.***>; Mention ***@***.***> Subject: Re: [mathertel/DmxSerial2] RDM Buffer too small - truncated received messages and fails OLA rdm-tests (Issue #46) I notice that the receive buffer is 60 BYTES ? // the byte array used while receiving and sending. byte buffer[60]; RDM allows 231 Bytes, so why set at 60 ? Hi @riwalker <https://github.com/riwalker> This was fixed here: https://github.com/mathertel/DmxSerial2/blame/98cdfc932de94a096e63033c18560dc69eb9f12c/src/DMXSerial2.cpp#L266-L270 And previously here: https://github.com/mathertel/DmxSerial2/blame/98cdfc932de94a096e63033c18560dc69eb9f12c/src/DMXSerial2.h#L98 Specifically in <e1f293e> e1f293e You'll need to either use Git or ask @mathertel <https://github.com/mathertel> nicely to release a new version. I noticed this as the OLA rdm-tests fail several tests, like E120_DEVICE_LABEL, > 32char when set to 60, it truncates the RDM message at exactly 32char (I don't know why a buffer of 60 truncates the RDM Data at 32bytes)? when i increase the buffer to [231] - we now capture the NACK for > 32 char test The string should always be truncated by RDM at 32 bytes the other test checks for different responses when nacking a message that's too long but fits in the buffer from one that doesn't. BUT, not that the buffer is [231] it fails 41 instead of 6 !!! any ideas ? What do you mean by 41 instead of 6? Tests? If so can you list which ones, ideally with debug output. It's probably just more slow EEPROM turnaround time. — Reply to this email directly, view it on GitHub <#46 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABIKT5VU4JTSUIXG7GHLFW3WVG45FANCNFSM6AAAAAAUMW7QUQ> . You are receiving this because you were mentioned. <https://github.com/notifications/beacon/ABIKT5RD5KJPOI6FAFKLBPDWVG45FA5CNFSM6AAAAAAUMW7QUSWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSUD4F5U.gif> Message ID: ***@***.*** ***@***.***> >