[Request - Answered] nRF24L01+ library

That looks like a nice write up. I’ll dig in later when I have time.

I ordered my from Amazon. Not sure if its the same buyer or what but Amazon has great customer service if something does happen.

So Bdub can you explain alittle better how the serial link will be used. I understand its a serial bridge but how do we get the most out of it? I’m trying to wrap my head around this. I can see how XBee’s are different as they have a on board processor and do have analog and digital ports you can tie sensors directly to, but on the nRF21 modules you have to add a processor to it. And it looks like that can be done for $12 at the cheapest alternative based on the article linked above.

I pledged for a DSLogic logic analyzer on kickstarter. One of the items I liked was their wireless extension. It is essentially an nRF24 board that acts as the master and up to 6 nodes that can have sensors attached. These nodes are atmega168/nRF24 combos from what I understand (it will be open source once they ship in March). They charged $20 for each node but we all know those most likely cost about $8 to make.

It is much cheaper to have a number of these slaves than an equal number of Sparks. On top of that, they can run VERY low power. So the Spark is the data aggregator and the nodes are the feeders. Think temperature/humidity in several rooms or door sensors or current sensors or whatever. The Spark brings all that data together, processes it and puts it on the cloud for a mobile app to use or for logging in Xlively, etc. :koala:

Thanks @peekay123 for summing that up nicely.

I’m sure if all you want is the cheapest board you can get your hands on to be a low power sensor, there are no less than 3 billion ways to do it with different uC’s than then ATMega328p. I have a couple reels worth of SOIC-28 pin PIC16F886’s that would work nicely. But you can buy uC’s for 50 cents all day long from many sources. Don’t even really need a regulator if you are using a 3V battery source. However, the Arduinos are just so easy for people to write code for, it’s almost worth the extra money to go that route. However however (now I’m arguing with myself), you could just code up something on any uC that sampled several analog inputs, or controlled several digital I/O very easily via the radio and forget about writing code for the sensor uC. Just provide an API to set it up to broadcast certain pins, or be a wireless I/O port-expander.

So these RF boards can be use with sensors that use Serial to communicate right? Is I2C considered Serial?

I have a few sensors that operate via I2C or Serial.

How about a Serial LCD Screen?

The nRL24 just does not have the ADC converter and the digital Hi/Low read /write capabilities right?

Sorry for the correction, but the 6 slaves is not correct and a common misunderstanding. The chip has 6 pipes that can be used at the same time for reception, but that doesn’t limit the number of slaves/leafs you can have. You can put your antenna in low power mode and if one of those six nodes sends a packet to you the chip will recover into full power… So the number 6 limitation is for advanced stuff.

The nRF24L01P from Nordic Semiconductor is a radio transceiver in the 2.4GHz band: if it has an ADC to convert captured electromagnetic analog signals into digital electric ones then it is not exposed for us to use.

There’s a post from @BDub above reporting part of the chip datasheet: that should be our reference document.

I don’t think I2C is Serial in terms of Serial library, but it is serial meaning data is communicated by modulating a train of signals serialized on one line: it is serial as in comparison and opposition to parallel.

Right, it’s SPI and is an SPI Slave to be exact. That means you need to provide an SPI Master with Clock and a couple Select inputs to control it properly, in addition to feeding it data and retrieving data from it. So it’s completely different than just a Serial (UART) TX/RX port. I can see what you are trying to do… maybe create a wireless display. But not without converting the protocol from SPI to one of your choice. It’s possible, and you could do it for less than the cost of a Zigbee radio… but it comes with a price of your time to create it. I’m thinking for a simple wireless Serial port (UART), you could use a pair of Zigbee radios (expensive end). I have briefly explored the lower end of the spectrum but I’m not seeing good robust solutions that can just act as a straight wireless serial bridge.

rlogiacco, you are correct about the pipes. However, since the nRF24L01+ can be used in a mesh configuration, the maximum number of nodes (pipes as you say) per receiver is 6 though, as you mentioned, it is advanced stuff. Thanks for that clarification!

RWB, if you are referring to the DSlogic wireless boards, they are like small arduinos with a radio. My understanding is that they will expose I2C, UART and some analog and digital lines on a connector. They can be reprogrammed with user code like an arduino and I suspect that most arduino libraries will be compatible.

I'm not sure we are saying the same thing here.

The 6 pipes limit applies to the Enhanced ShockBurst mode of the nRF24 chip, which is a communication mode where the nRF24 chip switches autonomously between RX/TX, transmits, receives, sends acks, etc... all without any intervention from the MCU. We can leverage this mode, but this is not a requirement.

What would it mean to not leveraging the ShockBurst mode? It would mean we will have to manage in the MCU the control flow protocol, not something impossible to do. Why should we use the mode? Because it simplifies the application code and keeps it compact (read this as "use cheaper MCUs") and having the control flow protocol hardwired in the chip means the chip can get powered down to a certain level where the control flow can still kick in and power up the chip.

Does the ShockBurst mode have any drawback? Sure, the number of communication pipes is just one, another is the payload size, capped at 32 bytes.

Could we use a ATTiny 85 Trinket as a go between the nRF24 boards and sensors?

rlogiacco, glad you’re on board cause you know one heck of a lot more about the nRF24 than I do! With the cost of a cheap arduino pro mini running less than $9, it’s perfect to do either the “lite” or “full” nRF24 implementations.

RWB, I asked the same thing! I found a mrif library specifically written for the attiny85 and the nRF24L01+. I intend to test it in the next few days. The only catch is that it leaves you with only one I/O pin on the attiy85 but you can do analog or digital with it. Enough for a simple node.

The cost of an Trinket (attiny85) vs an Pro Mini (atmega328) makes it difficult to not justify the latter. More I/O, more resources (timers, SPI, I2C, etc) make it perfect. And there are so many open source eagle PCB layouts that can be used as the foundation for a custom board!

The reason I bought the DSLogic wireless extension is to test the viability of using the nRF24 for remote sensing with a “commercial” product. The rewards are slated to ship in March so I would be glad to share my findings then. :koala:

The Pro Mini does look like the better deal.

I’m quickly learning the difference between nRF24 & XBee + Zigbee & XBee + Digimesh

I’m also interested in all this basically to see whats reliable enough to put to use in some of the products we build and sell. Wireless can be used in alot of cool ways but first it has to be reliable and alot of stuff simply is not, like the Spark Core right now.

RWB, I have been looking at smartthings and what they use. Basically, they use a MeshConnect EM357 transceiver (IEEE 802.15.4) module which has a cortex M3 processor to run a Zigbee protocol stack and application code. Their arduino dev board uses UART communications. I suspect their “hub” also includes a z-wave transceiver to allow z-wave devices in their environment.

There is no question that zigbee is a reliable protocol that is more flexible than BLE for many applications. From what i can see, it is used in a lot of commercial products.

However, buying official zigbee or xbee modules is not so cheap. And thus my quest to investigate the nRF24. :slight_smile:

@peekay123 I believe you are overestimating me, that is just info extracted from the nRF24 datasheet, as I said I have some experience with the nRF24 chip, but it’s just a few months. I’ve much more experience with networks in general though :wink:

Same here, I saw their nice web/iphone app and thought it was nice. I would love to be able to easily create a android iOS app to display data and interact with the Spark Core. But it seems easier to just make a webpage that you can access via Phone & Computer.

Cheaper is better when you want to deploy a decent sized network. I'm looking at putting this into products with a high resale value so $20 extra bucks for a XBee radio is not really that big of a deal. Regardless I do want to see what we can accomplish with the Nordic nRF24 chip with the external antennas and amps built in.

This is all frustrating and fun at the same time. I couldn't get very far without the help of the community.

Just to put the item to bed, I just tested the attiny85/arduino pro mini/nRF24 combo special running the mirf code I had referred to earlier. Works like a charm! Same range but very reliable. However, it is pretty useless on the attiny85 since there is only one I/O pin left. The pro mini was a 3.3V/8MHz version and it was solid.

RWB, it seems that some of the zigbee modules have their own processors and the ones we buy for arduino most likely have a simple serial to zigbee bridge using AT commands. Serious developers likely just use the onboard cortex-M3 for their applications much like the Spark does. One of those EM357 is about $37-$44 CDN at Digikey depending on xmit power. :smile:

Sounds like if the external antenna + amp version of the nRF24 gets good rang then it would be a good alternative to the XBee at around $16-20 bucks. A XBee with the same power output is going to be in the $45-50 range so almost 250% more cost but for sure a more elegant package.

Only thing left to do is range testing on the higher power version of the nRF24 modules and see whats up.

I'm going to probably buy the XBee Pro 900 HP radios with Digimesh any day now for comparison, just need more time to make sure thats the right one to go with. I'm interested in just seeing how far you can get them to work in the real world reliably.

You know there are tons of variables that might enter the game, right?

Even a pipe can make the difference if it’s in the right spot: fill it up with water and you might get disconnected…

Weather and radio noise will impact your long range test for sure.

That’s why I think its best to go with the higher power radios to cut though the noise as much as possible.

I just ordered 2 XBee Pro 900 HP radios with SMA antenna connectors also to compare to the nRF24 radios with amp and SMA antenna. I’ll run the test size by side and see how they compare. 2 completely different radios and frequencies.

With everybody using 2.4Ghz wifi routers I expect any RF radio link using the same frequency to have a lot harder time hearing each other talk though all the other chatter going on.

The XBee Pro 900 HP radios were $35 each at http://www.parallax.com/product/32411 cause they are running a 10% off special. Not bad. Still need to get a antenna on the cheap though.

I have a few project ideas involving devices that I would like to add to my existing home automation network (SmartThings). ST offers an Arduino shield, but I want something with a smaller profile and potential compatibility with the Spark Core. Also, I always like to keep open the option of turning a project into a commercial product.

The are a few Zigbee solutions out there, but most of them are cost prohibitiv for me, due to expensive development kits, programmer hardware, required proprietary debuggers and compilers. This includes the CEL MeshConnect. I would love to find a SoC solution, which I can upload custom firmware to without a massive entry barrier.

So far, the closest I have come is the Telegesis ETRX357, which is also based on the EM357, but comes pre-loaded with a firmware that implements an AT command set, exposing all of the Zigbee PRO stack. In my case, this would mean I still have to implement the Zigbee HA layer on the external MCU on top of the PRO stack that is provided by the ETRX357, but that seems feasible.

In your case, you could simply hook up the ETRX357 to the Spark Core’s serial port, and use the AT command set to join a PAN and send / receive messages.

Anyways, if anyone has ideas regarding how to get custom firmware onto the M3 on the EM357 with the more pervasive gcc toolchain, and a non-proprietary programmer, I’d love to hear about it.