RFM69 Receive buffer

[wvdakker]

Hi,

Perhaps I am mistaken, but why doesnt the RFM69 have a receive buffer? Putting received packages in a ringbuffer doesnt sound to difficult. Is there any reason why not to do so?

Before I am burning my fingers and implement it myself, perhaps there are any good reasons not to do it.

/Willem

[LowPowerLab]

RFM69 has an internal 66 byte buffer. The RFM69 library has a buffer to capture packets as soon as they are received: uint8_t RFM69::DATA[RF69_MAX_DATA_LEN+1];

[wvdakker]

Not quite what I meant.If a package arrives before the package in de RFM69 driver is processedthe old one is overwritten. This can only be solved:- what a certain time before sending next package- make a (ring)buffer to buffer multiple packages. On Mon, 2020-02-17 at 06:46 -0800, Felix Rusu wrote:

RFM69 has an internal 66 byte buffer.

The RFM69 library has a buffer to capture packets as soon as they are received:

uint8_t RFM69::DATA[RF69_MAX_DATA_LEN+1];

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": " https://github.com/LowPowerLab/RFM69/issues/134?email_source=notifications\u0026email_token=AAM7DVKJIUT7YBJJOOO7BSLRDKPM5A5CNFSM4KWD2XRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL6VI6I#issuecomment-587027577 ", "url": " https://github.com/LowPowerLab/RFM69/issues/134?email_source=notifications\u0026email_token=AAM7DVKJIUT7YBJJOOO7BSLRDKPM5A5CNFSM4KWD2XRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL6VI6I#issuecomment-587027577 ", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[LowPowerLab]

Ok. And what happens if a package arrives before the packages in the ring buffer are processed?

[wvdakker]

before it is processed into the buffer, It is lost. But then we have a retransmit (missing ACK).If the packages are comming in and buffer is full the package is dropped (no ack), this is how I would implement it. Dont ack if buffer is full. On Mon, 2020-02-17 at 08:49 -0800, Felix Rusu wrote:

Ok. And what happens if a package arrives before the packages in the ring buffer are processed?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": " https://github.com/LowPowerLab/RFM69/issues/134?email_source=notifications\u0026email_token=AAM7DVJJYCM3N3XRVHNYYCTRDK52RA5CNFSM4KWD2XRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL7CHQI#issuecomment-587080641 ", "url": " https://github.com/LowPowerLab/RFM69/issues/134?email_source=notifications\u0026email_token=AAM7DVJJYCM3N3XRVHNYYCTRDK52RA5CNFSM4KWD2XRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL7CHQI#issuecomment-587080641 ", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[LowPowerLab]

The library is middleware between the radio module and the consumer firmware. It's job is not to hold an unknown number of packets. It will not only increase the library footprint, but can hog memory if not used properly and create a whole set of new problems to deal with. Just think of having to ACK the 17th packet ago, how long was that, will an ACK still be valid? Is the end node still awake?

IMO the consumer can decide to buffer packets if need be. Typically this has worked well and I have applications where a dynamically allocated buffer will actually hold packets that can be afforded to be processed at a later time.

To avoid an ACK delay, the packet is processed in firmware for time critical components such as ACKs before being handed for full processing by upstream application.

The caveat of this library is it needs to be very light and fast, and also the consumer needs to also process the interrupts very quickly to allow freeing up the buffer and servicing ACKs.

[wvdakker]

Let me describe the scenario where I am in. A sensor sends 3 packages (it wakes up, sends P, H and T) and goes to sleep.The packages are processed in the base station.The sensor sends the first package (P) to the base station.The first package is then received, the ack is send and the package forwarded to the serial interfaceThe second package (H) is send right after the ACK is received, no Ack is send because the application is busywith the Serial connection. The sensor retransmits the second package, the base station is then ready and receivesthe second package. And so on for the third package (T). hmmm writing this I think the problem is in de serial connection which is proberbly non interruptable. Otherwisethe ACK would have send. Ok, my bad :) On Mon, 2020-02-17 at 09:08 -0800, Felix Rusu wrote:

The library is middleware between the radio module and the consumer firmware. It's job is not to hold an unknown number of packets. It will not only increase the library footprint, but can hog memory if not used properly and create a whole set of new problems to deal with. Just think of having to ACK the 17th packet ago, how long was that, will an ACK still be valid? Is the end node still awake?

IMO the consumer can decide to buffer packets if need be. Typically this has worked well and I have applications where a dynamically allocated buffer will actually hold packets that can be afforded to be processed at a later time.

To avoid an ACK delay, the packet is processed in firmware for time critical components such as ACKs before being handed for full processing by upstream application.

The caveat of this library is it needs to be very light and fast, and also the consumer needs to also process the interrupts very quickly to allow freeing up the buffer and servicing ACKs.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": " https://github.com/LowPowerLab/RFM69/issues/134?email_source=notifications\u0026email_token=AAM7DVNC7WTXKGTTO4TKIZLRDLAADA5CNFSM4KWD2XRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL7D5UI#issuecomment-587087569 ", "url": " https://github.com/LowPowerLab/RFM69/issues/134?email_source=notifications\u0026email_token=AAM7DVNC7WTXKGTTO4TKIZLRDLAADA5CNFSM4KWD2XRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL7D5UI#issuecomment-587087569 ", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[LowPowerLab]

Sounds like you have some issues in your serial handler. That should be non blocking and asynchronous. If you analyze packets, they take very little time to transmit, only a few ms each. The serial handler code is much faster than that, even on an arduino. Also, why not send all the parameters in 1 packet, just 3 variables should fit in a single packet which takes only a few ms to transmit.

[wvdakker]

I do a lot of sprintf to format the package. It is not optimal I guess.Thanks for the hints. On Mon, 2020-02-17 at 09:26 -0800, Felix Rusu wrote:

Sounds like you have some issues in your serial handler. That should be non blocking and asynchronous. If you analyze packets, they take very little time to transmit, only a few ms each. The serial handler code is much faster than that, even on an arduino.

Also, why not send all the parameters in 1 packet, just 3 variables should fit in a single packet which takes only a few ms to transmit.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": " https://github.com/LowPowerLab/RFM69/issues/134?email_source=notifications\u0026email_token=AAM7DVIIQNLEV2QM44BL63TRDLCCZA5CNFSM4KWD2XRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL7FO7I#issuecomment-587093885 ", "url": " https://github.com/LowPowerLab/RFM69/issues/134?email_source=notifications\u0026email_token=AAM7DVIIQNLEV2QM44BL63TRDLCCZA5CNFSM4KWD2XRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL7FO7I#issuecomment-587093885 ", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[LowPowerLab]

I think the answer is the ring buffer is more appropriate in firmware rather than the lib, sprintf can wait until interrupts are done and ACKs are served.

[wvdakker]

Yes, you're right.

On Mon, 2020-02-17 at 09:42 -0800, Felix Rusu wrote:

I think the answer is the ring buffer is more appropriate in firmware rather than the lib, sprintf can wait until interrupts are done and ACKs are served.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": " https://github.com/LowPowerLab/RFM69/issues/134?email_source=notifications\u0026email_token=AAM7DVNDEVEOAHA3SBY4U7LRDLEBDA5CNFSM4KWD2XRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL7G2XQ#issuecomment-587099486 ", "url": " https://github.com/LowPowerLab/RFM69/issues/134?email_source=notifications\u0026email_token=AAM7DVNDEVEOAHA3SBY4U7LRDLEBDA5CNFSM4KWD2XRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL7G2XQ#issuecomment-587099486 ", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]