What is the difference between the frequency versions and why would I choose one over another?
If I have complex code to run between sleep cycles should I get the higher frequency to save power and vice-versa?

Hi deanl,

The frequency difference is basically to cover different country regulations. Although I can understand why you're asking this question as a "low-power" question, I haven't noticed any difference when performing practical tests. In terms of data transfer speed, you'll have the same capabilities on the 433MHz and 915MHz modules, so the time you need to wake-up to transmit a few bytes will be the same on any version.

For details related to different country regulations have a look here: https://www.kickstarter.com/projects/34 ... ts/1576731

Cheers,
Mike M.

Thanks, I didn't look at the Kickstarter page.

I read somewhere that the manufacturer uses a special protocol for their sub-GHz modules so they cannot talk to other devices. But for the life of me, I cannot find the post again. So would I need at least two Talk² devices?

Also on a side note, when I'm not logged in I see 6 forms, but when I log in 2 forms disappear (Whisper Node and RPI Talking Hat). This maybe because we cannot post in them, but we should still be able to view.

Hi again deanl,

The RFM69s can only talk with themselves. Most of the subGhz radios use manufacturer proprietary protocols, preventing different brands to talk to each other. The exception just start to happen with the LoRA devices, where multiple silicon manufactures uses the same standards.

In other words, yes, you'll need at least two Whisper Nodes on the same frequency to have communication.

ps.: thanks for the note regarding the topic, I'll verify.

Cheers,
Mike M.

How about the TX power? I guess sending with 20dBm consumes more power than 13dBm?
Or does the same apply to TX power too, because the sending time is usually very short anyway?

Hi lowpo,

The TX power does indeed affect the power consumption. Even the transmission happening very fast, after thousands of packages sent the chosen TX power would start to make a difference.

On the RFM69HW Datasheet (https://bitbucket.org/talk2/whisper-nod ... W-V1.3.pdf), page 12, there's a table showing the following:

• +20dBm: 130mA (on PA_BOOST)
• +17dBm: 95mA (on PA_BOOST)
• +13dBm: 45mA (on RFIO pin)
• +10dBm: 33mA (on RFIO pin)
• +0dBm: 20mA (on RFIO pin)
• -1dBm: 16mA (on RFIO pin)

*Remember, the RFM69W (Standard version) on has a maxium TX power of +13dBm, so if that's yout case just ignore the two first lines from the list above.

I still need to plug an oscilloscope along with a uCurrent (https://www.eevblog.com/projects/ucurrent/) to measure the power consumption myself and post some screen-shots, but normally datasheet details are reliable.

Now a practical example:
Let's suppose you have a total of 20 bytes to be transmitted, which include all headers+payload per message. If your link running at 80Kbits/sec (or 10KBytes/s), that would mean that a 20 bytes message takes 2ms to be transmitted.

Now, if you transmit one message every 10 seconds, your radio will spend 1.75 hours transmitting data during a year. Now if you don't need to transmit at full strength, reducing the TX power from 45mA to 20mA can save you some juice, adding extra life-time for your application.

Calculations:
365 * 24 * 60 * 60 = 31,536,000 seconds per year
31,536,000 / 10 = 3,153,600 message per year
3,153,600 * 0.002 = 6307.2 seconds transmitting (remember 2ms or 0.002 seconds per message)
6307 / 60 / 60 = 1.75 hours transmitting

When designing an application for long running periods, every millisecond and milliamp counts.

Notes:
- I've used 80kbits/s just to make calculations easier... yes if you double the speed you're going to spend less time transmitting, but also need to consider that lower speeds are more reliable.
- The 2ms represents the time the radio is actually transmitting, for precise estimate would be ideal to include time spent send data to the radio buffer... maybe just adding 1ms or 2ms to it should account for that.