Navigation

    • Register
    • Login
    • OpenHardware.io
    • Categories
    • Recent
    • Tags
    • Popular
    1. Home
    2. TMRh20Projects
    • Profile
    • Following
    • Followers
    • Topics
    • Posts
    • Best
    • Groups

    TMRh20Projects

    @TMRh20Projects

    1
    Reputation
    6
    Posts
    856
    Profile views
    0
    Followers
    0
    Following
    Joined Last Online

    TMRh20Projects Follow

    Best posts made by TMRh20Projects

    • RE: Are we initializing the nRF24L01+ correctly?

      I've been suspicious of the order of operations in the begin() function of the RF24 driver.

      Specifically these lines:

        // Reset current status
        // Notice reset and flush is the last thing we do
        write_register(NRF_STATUS,_BV(RX_DR) | _BV(TX_DS) | _BV(MAX_RT) );
      
        // Set up default configuration.  Callers can always change it later.
        // This channel should be universally safe and not bleed over into adjacent
        // spectrum.
        setChannel(76);
      
        // Flush buffers
        flush_rx();
        flush_tx();
      
        powerUp(); //Power up by default when begin() is called
      
        // Enable PTX, do not write CE high so radio will remain in standby I mode ( 130us max to transition to RX or TX instead of 1500us from powerUp )
        // PTX should use only 22uA of power
        write_register(CONFIG, ( read_register(CONFIG) ) & ~_BV(PRIM_RX) );
      

      Theoretically, I think it may be best to reset the IRQ flags and flush the buffers after powering up and entering standby, but the failures are a bit sporadic, so I haven't been able to verify if this will reduce/prevent issues on resetting. A larger user base or additional testing may be able to prove it one way or the other, so thought it worth mentioning.

      posted in Development
      TMRh20Projects
      TMRh20Projects

    Latest posts made by TMRh20Projects

    • RE: Are we initializing the nRF24L01+ correctly?

      I've been suspicious of the order of operations in the begin() function of the RF24 driver.

      Specifically these lines:

        // Reset current status
        // Notice reset and flush is the last thing we do
        write_register(NRF_STATUS,_BV(RX_DR) | _BV(TX_DS) | _BV(MAX_RT) );
      
        // Set up default configuration.  Callers can always change it later.
        // This channel should be universally safe and not bleed over into adjacent
        // spectrum.
        setChannel(76);
      
        // Flush buffers
        flush_rx();
        flush_tx();
      
        powerUp(); //Power up by default when begin() is called
      
        // Enable PTX, do not write CE high so radio will remain in standby I mode ( 130us max to transition to RX or TX instead of 1500us from powerUp )
        // PTX should use only 22uA of power
        write_register(CONFIG, ( read_register(CONFIG) ) & ~_BV(PRIM_RX) );
      

      Theoretically, I think it may be best to reset the IRQ flags and flush the buffers after powering up and entering standby, but the failures are a bit sporadic, so I haven't been able to verify if this will reduce/prevent issues on resetting. A larger user base or additional testing may be able to prove it one way or the other, so thought it worth mentioning.

      posted in Development
      TMRh20Projects
      TMRh20Projects
    • RE: Raspberry Pi Ethernet Gateway

      @lollotek Yup, ask away.

      posted in Development
      TMRh20Projects
      TMRh20Projects
    • RE: Getting the NRF24L01+ to work on the RPi

      Just a note, if the CE and CS pins are connected wrong, the radio will sometimes have one-way communication, and/or behave oddly as far as acks etc. The RF24 lib has been tested extensively with RPi, and there are no reported bugs or issues with direct RPi -> NRF24l01.

      posted in Controllers
      TMRh20Projects
      TMRh20Projects
    • RE: Raspberry Pi Ethernet Gateway

      Just to toss my $0.02 in, there are some big advantages to running the nrf24l01 modules directly on the RPi.

      The radios themselves have three 32-byte FIFO buffers, and can receive data without any interaction from the RPi. It also has vast amounts of memory and processing power compared to Arduino, so can handle much more complex tasks, and manage data more efficiently.

      IMHO the RPi + RF24 is very stable and robust at this point, and is beginning to support a number of Linux platforms directly via spidev and mraa

      posted in Development
      TMRh20Projects
      TMRh20Projects