Author Topic: Questions about some code in RFM69  (Read 5916 times)

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6462
  • Country: us
    • LowPowerLab
Re: Questions about some code in RFM69
« Reply #15 on: March 11, 2016, 03:24:12 PM »
@executivul,
I can't remember exactly but I do remember I tried defaulting to hardware per someone's request in the forum, and at that point I abandoned and there was a good reason, i just failed to document it.
@TD22057 you are correct however, the obvious reason hardware filtering was not implemented I think was mainly promiscuous mode.
In addition the address byte is not encrypted with hardware filtering (see page 55 of DS) which could be a potential security issue.
But anyway the suggestion is taken into consideration. Another improvement I think would be defaulting to DC-free algorithms.

TD22057

  • Newbie
  • *
  • Posts: 26
  • Country: us
Re: Questions about some code in RFM69
« Reply #16 on: March 11, 2016, 03:44:19 PM »
Also - if I remember correctly, turning on hardware addressing and encryption means the message length drops to 50 bytes (or something like that) because the address isn't encrypted (which means the last 16 byte block can't be used).  For my applications this wasn't a problem, so I've been using hardware addressing to keep the processing time on the nodes to a minimum.

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6462
  • Country: us
    • LowPowerLab
Re: Questions about some code in RFM69
« Reply #17 on: March 11, 2016, 04:14:00 PM »
@TD22057, good point, i have to dig the datasheet some more. I remember the AES is encrypting in fixed length blocks, i think 16bytes at 1 time. So 4 times that is 64. The header bytes are not encrypted, including address so it might be possible to have 64 total payload bytes (including the RFM69 lib header bytes which would still be considered payload).

executivul

  • Newbie
  • *
  • Posts: 48
  • Country: ro
Re: Questions about some code in RFM69
« Reply #18 on: March 12, 2016, 01:55:12 AM »
Thanks for the answers guys.
Indeed there is a limitation if addressing and variable length is used, I don't heve the datasheet at hand now, will chime in later about it. Anyway, even 50 bytes is more than enough for sensors.
For wireless programming hardware filtering is not needed since running in bootloader implies we have nothing better to do than watch the radio.

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: Questions about some code in RFM69
« Reply #19 on: May 01, 2016, 05:09:00 AM »
Quote
By the way what happens if I do not respond to an interrupt? I mean radio receives a packet and I do not read it from the FIFO. Does the radio remain in RX and receives the next packet and the first one is lost? Then maybe some auto mode trick to go to standby after a valid packet is received with manual rx restart later after processing is more desirable.

I'm currently expanding my radio lib which I use for the bootloader to fully replace rfm69 in my code base. Interestingly I've found that the receiver does not start receiving another packet unless the fifo is emptied. Which means the polling paradigm that rfm69 uses can be implemented without interrupts (and the associated 61 byte buffer) without a risk of packet loss.