Skip to content
  • MySensors
  • OpenHardware.io
  • Categories
  • Recent
  • Tags
  • Popular
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo
  1. Home
  2. Bug Reports
  3. Possible flaw in RFM95 driver

Possible flaw in RFM95 driver

Scheduled Pinned Locked Moved Bug Reports
3 Posts 2 Posters 38 Views 3 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • E Offline
    E Offline
    eiten
    wrote on last edited by
    #1

    Hi everybody,

    I'm writing a driver for the CubeCell series. Looking at the code for the RFM95, I think there might be a little flaw here in line 599 of RFM95.cpp. Here we are waiting for a Timeout or some data. But in fact, we should wait for a timeout or a ACK, as we sent a frame we want to have an acknowledge for. It's not big of a deal, because when we go into timeout, normaly the ack should still be there. We only waste some 100ms. Worst case, some other node or the controller sent data to us an we overwrote the ack.
    Or am I wrong?
    Regards, Edi

    YveauxY 1 Reply Last reply
    0
    • E eiten

      Hi everybody,

      I'm writing a driver for the CubeCell series. Looking at the code for the RFM95, I think there might be a little flaw here in line 599 of RFM95.cpp. Here we are waiting for a Timeout or some data. But in fact, we should wait for a timeout or a ACK, as we sent a frame we want to have an acknowledge for. It's not big of a deal, because when we go into timeout, normaly the ack should still be there. We only waste some 100ms. Worst case, some other node or the controller sent data to us an we overwrote the ack.
      Or am I wrong?
      Regards, Edi

      YveauxY Offline
      YveauxY Offline
      Yveaux
      Mod
      wrote on last edited by
      #2

      @eiten I'm not familiar with the RFM59 code, but quickly reviewing the indicated loop shows it is in fact testing for ACK as long as the timeout did not occur and data was not received: https://github.com/mysensors/MySensors/blob/d04e7513877598dd2d039b0e544d45a05ee1f3fa/hal/transport/RFM95/driver/RFM95.cpp#L561
      But then again, I too might be wrong ;-)

      http://yveaux.blogspot.nl

      1 Reply Last reply
      2
      • E Offline
        E Offline
        eiten
        wrote on last edited by
        #3

        Oh sorry, my fault. It was a bit late. We have a return true in there, where we exit the loop as soon as we got an ack. You are right!

        1 Reply Last reply
        1
        Reply
        • Reply as topic
        Log in to reply
        • Oldest to Newest
        • Newest to Oldest
        • Most Votes


        18

        Online

        11.7k

        Users

        11.2k

        Topics

        113.1k

        Posts


        Copyright 2025 TBD   |   Forum Guidelines   |   Privacy Policy   |   Terms of Service
        • Login

        • Don't have an account? Register

        • Login or register to search.
        • First post
          Last post
        0
        • MySensors
        • OpenHardware.io
        • Categories
        • Recent
        • Tags
        • Popular