Implement "reliable datagram" #24
Conversation
jerryneedell
changed the title
|
This PR will require updating to accommodate #28. I recommend suspending testing or review until I resolve the conflicts. |
|
updated to accommodate #28 |
|
I am set up to test these now so far I've been able to successfully test # Define pins connected to the chip.
CS = digitalio.DigitalInOut(board.RFM69_CS)
RESET = digitalio.DigitalInOut(board.RFM69_RST)After that I was able to send/receive the counting messages between a pair of devices. I think these pins probably depend on what devices and setup you are using? |
adafruit_rfm69.py
Outdated
| """Reliable Datagram mode: | ||
| Send a packet with data and wait for an ACK response. | ||
| The packet header is automatically generated. | ||
| If enabled, the packet tranmsiion will be retried on failure |
There was a problem hiding this comment.
@jerryneedell Small typo in this comment transmission
examples/rfm69_node1_ack.py
Outdated
| import adafruit_rfm69 | ||
|
|
||
| # set the time interval (seconds) for sending packets | ||
| transmit_interval = 5 |
There was a problem hiding this comment.
@jerryneedell with rfm69_node1_ack.py and rfm69_node2_ack.py I thought I was noticing a trend of longer streaks where I was getting several (tens) of successes in a row or several of No Acks in row with the opposites sprinkled in occasional but a pretty solid trend of back and forth being more or less likely to succeed.
I started taking a peek at how it's working inside of adafruit_rfm69.py. I am brand new to this hardware and low level radio like this generally so I'm not sure how much to trust about my understanding and the conclusions I drew from them perhaps they may not be plausible.
I got to wondering if the way the various delays inside of the send/retry/receive processes were shaking out was causing my devices to go through periods of being "out of sync" where node2 was not done with all of its waiting and retrying before node 1 was moving on and sending the next packet. I thought maybe increasing this transmit_interval at the application layer might allow some extra time and possibly alleviate it some if this was actually the case.
I increased this timeout to 10 and let them run for a while. In my case it did seem to help out. I do still get a few No Acks in a row from time to time, but overall it seems like my success rate seems to have increased a good bit and I'm no longer noticing stronger trends of success and failure streaks back and forth.
There was a problem hiding this comment.
It will definitely be better with fewer transmissions. I was trying to strike a balance for testing. I think you are correct that with 5 seconds between transmissions, it can get caught up in the retries. I'm happy to set this to 10 for the demo.
adafruit_rfm69.py
Outdated
| # destination address - default is broadcast | ||
| self.destination = _RH_BROADCAST_ADDRESS | ||
| """The default destination address for packet transmissions. (0-255). | ||
| If 255 (0xff) then any receiing node should accept the packet. |
There was a problem hiding this comment.
One more small typo I think in this comment receiving
yes -- this pins do have to be adjusted for the device being used |
Thank you for testing and for your comments. |
|
@tannewt when you have a chance, let me know if you would like any additional changes and if you think this is OK to merge. |
There was a problem hiding this comment.
Looks good to me! Thank you so much @jerryneedell! Thanks to @FoamyGuy for the test too.
Updating https://github.com/adafruit/Adafruit_CircuitPython_RFM69 to 2.0.0 from 1.5.1: > Merge pull request adafruit/Adafruit_CircuitPython_RFM69#24 from jerryneedell/jerryn_ack
Implemented compatibility with the RadioHead library "Reliable DataGram" mode. see #20.
Received packets ar "ACKed" and Transmitted packets wait for ACK response.
It has been difficult to make this work reliably. Packets will still be missed occasionally but now they will be reported. There are attributes taht can be "tweaked" to help
rfm69.ack_delay -- set a delay before the ACK packet is sent - this is necessary when the receive unit an MCU communication to a Raspberry Pi . The MCU can send it's ACK packet before the Raspberry Pi has resumed "listening". The default setting is "None" but setting it to .1 seconds may be necessary. The Arduino RadioHead library does not allow for this "ack_delay" and it it may be difficult to get this to work, especially with a Raspberry Pi.
rfm69.retries -- set the number of ack retries
All of the existing examples will still execute without change.
There are "breaking changes" fo anyone that had been setting the RadioHead headers directly.
There are now attributes for setting the header parameters and the rx_filter parameter for the receive function has been removed.
There are examples for using this mode in rfm69_node1_ack.py and rfm69_node2_ack.py
other new examples
rfm69_header.py -- receive packets and display the header and packet contents
rfm69_node1.py -- uses adresses without ACK
rfm69_node2.py -- companion to rfm69_node1.py
rfm68_rpi_simpletest.py - no LED and set pins for RaspBerry Pi
rfm69_node1_bonnet.py -- similar to rfm69_node1.py but for use with RPi and bonnet -- uses buttons to sent packets