Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 10 of 10

Thread: Connecting multiple T3.2 to a remote RPi

  1. #1
    Senior Member
    Join Date
    Jan 2015
    Posts
    153

    Connecting multiple T3.2 to a remote RPi

    Hello,

    I need to connect few T3.2 boards to a RPi3. The Teensy boards (three for now but more to come ) are situated in remote locations (10-20m range).

    I have some RF24 modules available but I do prefer a hard wired connection (as I run some wires for remotely powering the Teensies anyway). BTW, I don't need a high speed connection, as the T3.2 boards will only send some sensor data once per second or so.

    Does anyone have any experience with such a set up? Could I use the 1-Wire protocol or the I2C one? (once again, I'm talking about 10-20m between T3.2 and RPi boards).

    Thank you very much for your time.

  2. #2
    Senior Member
    Join Date
    Dec 2016
    Location
    Canada
    Posts
    729
    you could do rs485 using serial for long distances, if you want to make a custom rpi sketch to control a slave via spi, ill have a solution soon, rpi is not my field, but the commands remain same for the spi stream

  3. #3
    Senior Member
    Join Date
    Jan 2015
    Posts
    153
    Thanks alot for your quick reply. However, after doing a quick research on this subject, I guess I'll give nRF24L01+ a chance. It allows to create an ad-hoc radio network (TCP/IP) with peer-to-peer communication, which is nice to have for further development.

  4. #4
    Moderator MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    2,545

    Cool

    If your range was 5m, the simplest approach would be to connect the Teensys to the pi via USB, and each sends a text stream. I did a goggle search, and saw that you can use active repeater cables to get a longer distance, such as 50 feet (15m).

    IIRC, Rasberry Pi's only have 1 serial port (maybe pi3 has 2, I haven't kept track), but perhaps you can do a serial connection on a Teensy using RS-485, and then plug that into a serial->USB converter for connection to the pi.

    Forget i2c, it is meant for inches/cm, not for long distances.

    Perhaps look at ethernet (wired networking) or various radio devices.

  5. #5
    Senior Member
    Join Date
    Jan 2015
    Posts
    153
    Actually, RPi3 has 4 USB ports (though you could use a hub to extend any USB port). Dunno about the active USB repeaters, as I need a reliable connection hence I don't want any (more) weak links in this communication chain. I even have some USB-to-RS232 adapters to extend the RPi UARTs but, then again, I do prefer a more reliable solution (mostly passive).

    BTW, I'm using nodejs on RPi side and I found some nice modules for nRF24 and/or CANbus communication (currently, I'm using a serialport module to communicate with another T3.2). Looks like I'l have to choose between radio (nRF24) or hard link (CAN or RS485). I've seen that CAN/RS485 transceivers ICs are very cheap, too (so are nRF24 modules).

    Does anyone have any experience with a (reliable) home automation network using the protocols/interfaces above? I also need point-to-multipoint connections (for redundancy) thus no master/slave.

    Does CAN allow for 20m bus length?

  6. #6
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    15,913
    Quote Originally Posted by someteen View Post
    Dunno about the active USB repeaters, as I need a reliable connection hence I don't want any (more) weak links in this communication chain.
    On the scale of reliable communication, I'd rate a lengthy USB cable with repeater above the nRF24L01+ or just about any wireless module.

    But for long distances, RS485 serial is usually the very best way.

  7. #7
    Senior Member
    Join Date
    Jan 2015
    Posts
    153
    Many thanks for your input, Paul. The problem with the USB is the need of dedicated wires for every single T3.2 node. Beside, like I've just mentioned, I need some redundancy as I'm going to use a backup RPi and I want every single sensor (T3.2) to "talk" to both RPi boards. AFAIK, both RS4985/CAN (and nRF24) allow this scenario.

    Btw, just for reference: could I use two nRF24 modules with any single T3.2 board to get a full-duplex communication (sending/receiving at the same time)?

  8. #8
    Senior Member
    Join Date
    Jan 2015
    Posts
    153
    Quote Originally Posted by PaulStoffregen View Post
    On the scale of reliable communication, I'd rate a lengthy USB cable with repeater above the nRF24L01+ or just about any wireless module.
    What do you mean by "reliable"? I don't mind if there are some dropped packets due to radio perturbations & stuff (there is a software routine to check for these kind of errors).

    I just need that radio module to stay up & running 24/7 (like Teeensy does!). Do you have any feedback about these nRF24L01+ boards? I have used two of them for a radio link between two T3.2 boards (my water sprinkler system) for about one year with no problems at all.

  9. #9
    Senior Member
    Join Date
    Dec 2016
    Location
    Canada
    Posts
    729
    if your replaying packets and verifying their crc, you shouldnt ever have problems

  10. #10
    Senior Member
    Join Date
    Jan 2015
    Posts
    153
    I have to mention that I finally choose the radio way (nRF24L01+). Moreover, I'm going to use a "master" Teensy 3.2 on the RPi side so I could have a (USB) serial connection between this "master" node and the RPi itself. That way, I'll keep the nodejs serialport module on the RPi side (the one I have tested for long time) thus all the radio nodes will be [Teensy 3.2 + nRF24L01+] pairs only.

    As far as I have tested it, the radio looks very reliable (I left a pair of nodes running all day long with no packets lost whatsoever - and they are sending one packet per second). I managed to let each node to self assign an address at start up based on its MAC address (and a lookup table, of course).

    These little radio modules are pretty smart (thanks Nordic) and they manage the packet integrity check, retransmission and the acknowledge by themselves. When you have received a message (in software), you might be sure it's a correct one.

    I'll let you know how things work after an extended period of time.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •