More Wireless (3)

weirdwave1Posted June 5, 2016:

The nRF24 stuff all works on my Pi2 box.  It’s actually a little easier to implement on Linux, because the WiringPi libraries were designed on that platform (hence the “pi” in wiringpi!)  The things mentioned in this series of posts all apply to the Pi, except that fewer changes have to be made.

I was making a post about the nRF24 devices on the RaspberryPi forum, and another member pointed me to:

https://github.com/LowPowerLab/RFM69

LowPowerLab.com makes a hybrid board that puts a Moteino board, HopeRF RF module, and flash chip together, so as to make things simpler and easier for retrieving remote sensor inputs.  It’s a Moteino with various RF and flash module options, for 433, 868, and 915 MHz.  I looked at the plusses:

  • Promiscuous Mode (easy multicasting)
  • Hardware encryption (probably not with multicasting)
  • Power adjustable up through 40 mA (for battery saving)
  • Hardware Auto-Ack for packet acknowledgement.
  • Sleep function for battery savings.
  • variable range (150m was quoted in one place).

Those points are pretty impressive, but seem pretty oriented towards an Arduino/Moteino biased system.  The way it’s described, a Raspberry Pi SoC/SBC (or anything else that has a serial port) can communicate with all of the Moteino nodes through a serially connected Moteino that acts as a gateway.  This is all well and good, except that I’m looking at building an any-to-any and all-to-all sort of network, and not one that runs everything through one gateway.

However; the Moteino+RF+flash board might still do what I might need it to do, because I don’t need to use the gateway approach that is described. I think I could interface a HopeRF module directly to each SoC/SBC board in the network, instead of using a gateway.  The Moteino boards would use their onboard RF modules and everything would play together, but I’m just guessing.  I’d bet the author had different constraints for his system than I do for mine.

The reported RF range for the Moteino is better than what I’ve seen reported (by customers) for the nRF24.  That’s a plus, even though I personally won’t need more than 50 feet for my communications. Some of the modes of the Moteino+RF setup require an amateur radio license.  I happen to have one – so that’s all good.  The nRF24 draws as little as 11 milliamperes while transmitting.  I see the web page for the Moteino+RF module mentions 40 milliamperes for TX power consumption, but it also indicates that the power is variable in 200 steps.  I’m not sure what the lowest possible transmit value is though.  Maybe it’s as low as it is on the nRF24.  For $12 bucks, I can buy one and see for myself 🙂

At the outset of the project, I had ideas for transmitting all sorts of data (not just sensor input data, which is inherently low data rate). I was going to channel live audio over these links.  So far, I don’t think I see that happening short of using full blown WiFi or Bluetooth boards, but the jury’s still out.  My testing thus far has involved polling-style apps, and the interrupt ones should be snappier.  We’ll see …

Added 06/06/2016:

I managed to find a project for streaming audio, in multicast fashion, using the nRF24 devices.  The claimed performance of the setup is for a 20 KHz sample rate, which would be fine for mediocre music and the regular analog signals one might use with programs like FLDigi, but would be too low for an SDR.  Given that the nRF24 runs at 2.4 GHz air frequency, and the RFM69W at only 915 MHz, one can calculate that audio streaming on the latter board would likely be too low to be workable for our purposes (other than a squawk-box intercom).   At first glance, this seems ridiculous, given that perfectly good AM signals on the broadcast band take only 10 KHz of bandwidth.

Unfortunately, that is an apples and oranges comparison.  The digitizing and undigitizing of the signals plays a huge role in knocking the sample rate down.   There are some things about the operation of the nRF24 that knock it down even more.  For instance, the nRF24 needs to turn off the receiver after each gulp, and then turn it back on for the next gulp.  All kinds of registers need updating between these operations, and buffers need flushing, etc.  There is a special version of the nRF24 (I think it’s nRF24z or something like that) – that is especially designed to stream audio.  I don’t have one to test though.

The audio streaming project is at:

git clone https://github.com/TMRh20/RF24Audio.git

Yeah, that’s the same URL we get the base radio library from!

Read More …

Note: the author does not have a recent, applicable background in circuit building, or battery related issues, so this is presented as the work of a hobbyist, and is not meant for duplication by others. Readers should look elsewhere for design advice and info.

Note: This author and site is not affiliated with the Raspberry Pi in any way. For information about that project visit  http://www.raspberrypi.org. “Raspberry Pi” is a trademark of the Raspberry Pi Foundation. Note: The Odroid site is http://www.hardkernel.com and is not affiliated with this site in any way. The nrf24 is a product of http://www.nordicsemi.com, and they are not affiliated with this author or website in any way. Note: The RFM69W module is a product of HopeRF, LTD.  They are at http://www.hoperf.com. The Moteino is a product found at LowPowerLabs.com, and they are not affiliated with this site in any way.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s