connect multiple arduinos by rf

I Found this:
http://arduino-info.wikispaces.com/nRF24L01-RF24-Examples

"RF24L01"

its seem to be the best solution so far.

somebody heared about it?

"starping.pde Example RF Radio Ping Star Group: This sketch is a more complex example of using the RF24 library for Arduino. Deploy this on up to six nodes."

Soundsl like it has good possibilities

Wow! I was just looking over the data sheet of the nRF24L01. If I understand correctly, this thing has all the RF hardware and a protocol engine built right on it, so all that needs to happen is it gets hooked to an MPU via SPI. And its tiny!

The data sheet isn't - I was going to print it out, but 78 pages!
39 if double sided.
Does look like a nice unit. Was there a price somewhere?

I could not find it at Digikey, but the page where the library is posted listed two vendors, one for $4.75 and the other for $6.50.

I had the same issue with the data sheet, too many pages to print. But, the data sheet even has PCB layouts and a BOM for a board that even has PC antenna. In fact it has a few choices. Too bad the parts are smaller than 0805!

There is also a discussion about how one of these can collect data from up to 6 using virtual channekls. Its not clear to me whether or not the number of clients can by increaded beyond 6 using different software or maybe a combination of virtual and physical channels. If its really limited to 7 total devices in a point-multi point network I'll have to keep looking.

http://arduino-direct.com/sunshop/index.php?l=product_detail&p=188

"126 RF channels"
Is this 126 interconnects, or 126 variations of 2.4GHz frequency selection?

"6 data pipe MultiCeiver™ for 1:6 star networks"

Small transmit buffer, you can only transmit for 4mS at time.
So have a "play nice" arrangment like described earlier, keep everyone in synch.

6.1.5 TX mode
The TX mode is an active mode for transmitting packets. To enter this mode, the nRF24L01+ must have
the PWR_UP bit set high, PRIM_RX bit set low, a payload in the TX FIFO and a high pulse on the CE for
more than 10?s.
The nRF24L01+ stays in TX mode until it finishes transmitting a packet. If CE = 0, nRF24L01+ returns to
standby-I mode. If CE = 1, the status of the TX FIFO determines the next action. If the TX FIFO is not
empty the nRF24L01+ remains in TX mode and transmits the next packet. If the TX FIFO is empty the
nRF24L01+ goes into standby-II mode. The nRF24L01+ transmitter PLL operates in open loop when in TX
mode. It is important never to keep the nRF24L01+ in TX mode for more than 4ms at a time. If the
Enhanced ShockBurst™ features are enabled, nRF24L01+ is never in TX mode longer than 4ms.

Yeah as near as I can tell from reading this, the ShockBurst protocol handles those issues. If you're running it at a higher data rate than you need, like in my case even 256 kb/s payload throughput on a 1 Mb/s back bone, I'll bet those issues go away. Especially if its one unit essentially broadcasting to the others.

But I could be wrong. I need to study it more. Apparently there are a number of products available that are essentially drop in packet radios for < $7 per unit. Just selecting the best one is a project :frowning:

I am glad you have a project goal. I like designing stuff, but I don't really have anything in mind to focus on. Feel like I'm just floundering around at times.

Time to go sit in traffic ...

Oh you'll probably hear from me in the near future with a project goal :wink:

So I should start thinking about a shield with connector for a remote display & RF? :slight_smile:

CrossRoads:
So I should start thinking about a shield with connector for a remote display & RF? :slight_smile:

LOL, I have been thinking about it. I'll send you some notes. What I might do first is a wifi based web server with its own mpu on a shield that can talk to the main board. It occured to me that maybe a jumper would have been in order to let users flash an update to an atmel MPU that's on a shield vs the one on the main board :frowning:

This is the first time you've mentioned having a 2nd processor. Can't think of everything all the time.

CrossRoads:
This is the first time you've mentioned having a 2nd processor. Can't think of everything all the time.

Oh of course its not your fault. It didn't occur to me until just recently.

have you seen the jeenode?
http://jeelabs.net/projects/hardware/wiki/JeeNode
It communicates thru RF.
Not sure if it will be usefull for you.

Best regards Alban

@skyjumper,
I was just saying its hard to think of everything one could possibly do with a card for all future scenarios, not that we forgot to include something. I see folks are talking of a math coprocessor now too, that's certainly a big change in capability I wouldn't have imagined for an 8-bit processor.

@Alban,
We've taken the jeenode and gone way beyond that. ATMega1284 (lots more memory, more IO, 2nd serial ports), added SPI UART for more IO, added RS232 & RS485 drives (converts signal levels), added Real Time Clock with battery backup (bottom of the board), added Secure Data (SD) card. Adding RF will be straight forward, just need to pick from the myriad of transmitters, receivers, or transceivers available. Really crammed a lot of stuff into 60x80mm and 80x100mm footprints. See the cards here Cross Roads Electronics

which battery do you suggest for using?

Arduino nano works with 5v (may be 3v?)
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=220820957973&ssPageName=STRK:MEWNX:IT

and th nRF24 works with 1.9V-3.3V Vcc input
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=280718046569&ssPageName=STRK:MEWNX:IT

I prefer a small rechargeable battery.
can't find the right battery for me.

Thanks again :stuck_out_tongue:

I would go with three AA type batteries to the nano VCC/5V pin and get 50mA of 3.3V from the FTDI chip.
Or, pick off 3V from two of the batteries for the transceiver if 50mA is not enough current.

what do you say about 1/2 AA?
there is a 1.2V each, or 3V each