[Question] 5ms delay in powerUp()?

[jscrane]

Hi guys, I have a battery-powered sensor whose loop() is:

• read adc (light + battery)
• read a DHT22 sensor
• transmit data

The third step is basically:

• powerUp
• stopListening
• send data
• powerDown

Digging into why the third step takes over 8ms, the main culprit seems to be the unconditional 5ms delay in powerUp(). Is there any value in skipping this in order to do something useful for 5ms? (Coincidentally, this is the time-to-read the DHT22 sensor.)

Thanks, Steve

[2bndy5]

I talked about this specific delay on #621 The thread is worth a read (I posted some pretty specific info pertaining to the datasheet).

Ultimately, we concluded that it should be 5 ms to compensate for some boards' lack of precision in implementing delay() or delayMicroseconds(). Are you using your ATTiny85 for this?

I recently toyed with the delay in my circuitpython library. When I removed any delay less than 100 us, I found that the SPI bus would frequently hang during the examples. Then I forced the SCK to clock out 1 byte after the CSN pin is reset to its inactive HIGH, and I haven't had any hanging problems since. After some research (with the datasheet), I noticed the CSN pin must be inactive for a minimum of 50 ns. I realize my solution is meant for SD cards, but it seemed faster than doing a time-based delay (albeit depending on SPI baudrate).

[jscrane]

(It's an ATTiny84 but yeah...)

I read that thread, it is interesting; but maybe we shouldn't penalize everyone for a few bad boards? Just a thought.

So I made a small change to the signature of powerUp() in my branch. This allows me to start powering-up while reading the sensor at the same time. As a result, the loop time goes down from 14ms to 9ms, which is a big deal!

You could also imagine defaulting the delay to 5ms but allowing to pass it in to find out if 2ms was enough in a particular case?

[2bndy5]

maybe we shouldn't penalize everyone for a few bad boards?

you just struck my biggest nuisance with this library. I'm of the mind that the software shouldn't overcompensate for faulty hardware (clones and counterfeits included).

You could also imagine defaulting the delay to 5ms but allowing to pass it in to find out if 2ms was enough in a particular case?

you mean like radio.powerUp(1500); for trying to delay 1.5 ms instead of default 5 ms? I fear that people might end up using that arg to break things more than speed up things.

[jscrane]

Yes, exactly!

On Sun, 15 Nov 2020 at 14:16, Brendan notifications@github.com wrote:

maybe we shouldn't penalize everyone for a few bad boards?

you just stuck my biggest nusance with this library. I'm of the mind that the software shouldn't overcompensate for faulty hardware (clones and counterfeits included).

You could also imagine defaulting the delay to 5ms but allowing to pass it in to find out if 2ms was enough in a particular case?

you mean like radio.powerUp(1500); for trying to delay 1.5 ms instead of default 5 ms?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nRF24/RF24/issues/683#issuecomment-727576483, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFDGBQBE6F6ZGJDNP4KOHLSP7PDTANCNFSM4TWFKWNQ .

-- Steve

[2bndy5]

If your radio has an oscillator soldiered into it, then you might be able to get away with 1 ms or less (150 us minimum). This might be tricky as some oscillators suck (especially the cheaper ones).

[2bndy5]

I've been giving the powerUp param more thought. I only have 1 objection: internal calls to powerUp(). Currently this is done in stopListening() and in startListening(). It might be better to have a RF24_PWR_UP_DELAY macro in RF24_config.h instead of an optional parameter to powerUp()

IMO the startFastWrite() & startWrite() functions should check the config_reg private member to make sure that TX mode is enabled (& radio is powered up). To compensate for when the radio isn't configured properly by the user, I would:

• add a stopListening() call

or

• make startFastWrite() & startWrite() return false (to prevent altering the TX FIFO)

My CircuitPython library does the former

[jscrane]

There are a few more delays in RF24.cpp which could use this treatment too. Would certainly improve code readability.

[2bndy5]

The delay on startup is required because the datasheet says that a PoR event takes 100 ms to complete. I see a delay(200) for the XMEGA_D3 macro, but I think that's done specifically for certain boards.

The txDelay is there because C++ is so freaking fast (a welcome convenience thing), but the user can add this themselves if they see an ACK payload getting cut short when calling stopListening().

The delay in errNotify() is probably there so it doesn't get triggered more than once per call to write*(). Same goes for the delay after errNotify() is called.

I don't fully understand the delay in getDynamicPayloadSize(), but it would only get triggered by a bad SPI connection. Personally, I don't think errNotify() or this delay should exist as they only overcompensate for faulty SPI connections (which should be indicated by begin() anyway).

All other delays are standard (per datasheet) or used for debouncing (csDelay). It's only the delay in powerUp() that could be detrimental for speedy application.

Although,

    // Must allow the radio time to settle else configuration bits will not necessarily stick.
    // This is actually only required following power up but some settling time also appears to
    // be required after resets too. For full coverage, we'll always assume the worst.
    // Enabling 16b CRC is by far the most obvious case if the wrong timing is used - or skipped.
    // Technically we require 4.5ms + 14us as a worst case. We'll just call it 5ms for good measure.
    // WARNING: Delay is based on P-variant whereby non-P *may* require different timing.
    delay(5);

I'm not really sure what this is about. I don't recall the datasheet saying anything about this. In fact this is what made me think the csDelay was 5ms instead of 5 us (up until a couple weeks ago).

[2bndy5]

Closing this due to merging of #690 .

When re-working the timingSearch3pin.ino for the SpenceKonde ATTinyCore, I noticed that the settling delay times in csn() could also use a macro in utility/ATTiny/RF24_arch_config.h.

Additionally, the RF24_config.h uses macros not defined in the SpenceKonde ATTinyCore to declare the RF24_TINY macro, but this is actually related to #646

EDIT: I've made changes according to this comment. See this commit