0
\$\begingroup\$

Designing a device for vibration condition monitoring, using multiple wireless accelerometers. Intending to have an arduino as the main controller and peripheral accelerometers sending the vibration data to this for analysis and storage.

Having difficulty with the wireless part of the design. Digital accelerometers use either a I2C or an SPI protocol, and I can't really find a wireless device that will natively interact with it. I found a BLE module that could, but it lacked the required data rate (https://www.bluegiga.com/en-US/products/ble121lr-bluetooth-smart-long/). Currently looking into using a XBee module, but I am not familiar with the technology. I understand that I will need to convert the accelerometer data to UART, but am not 100% sure how.

I'm not sure if XBee is the best path to look into, or if it is capable of handling multiple accelerometers. Bit of a novice with this sort of stuff, so I would appreciate someone letting me know if i'm heading in the right direction with the wireless side of things, and to also recommend resources for me to look into.

\$\endgroup\$
0
\$\begingroup\$

Some of the Xbees are programmable, so you could in theory program one up to be an I2C or SPI remote. I don't know what the toolchain is like though; that might be a laborious process. Same goes for ESP8266, but that's relatively easy to use now.

Otherwise, you will need to put a little microcontroller between each radio and its local sensors. That micro is responsible for polling the sensors at the appropriate rate and sending measurement data back to the central collection point through the radio.

Since you seem familiar with Arduino, you could perhaps consider using an ATtiny85 and nRF24L01+ (if it has sufficient range) at each location, with another nRF24L01+ at the central arduino; there are free libraries that do everything you need. Or use an Xbee Pro (900MHz band) if you want miles of range, but the bitrate will be ~100x lower.

Your radios do not need to support the raw I2C/SPI bitrate, they need to support only just enough to convey the necessary information from your sensors. If you need samples at 10kHz then that's really difficult, but if you need a number from each site only every hour or so, then that's really easy even with the slowest radios.

|improve this answer|||||
\$\endgroup\$
  • \$\begingroup\$ Thanks for the reply. With the ATtiny85 and the nRF24L01+, how would it be connected and coded? the ATtiny85 has limited pins (given the accelerometer will either be i2c (two wire) or SPI (4-wire)), and i'm not entirely sure how to connect it properly, or how to code it. Is the ATtiny purely polling the sensor, and the RF module handling the data transfer? \$\endgroup\$ – mlawes Jan 23 '16 at 8:54
  • \$\begingroup\$ It doesn't need to be a tiny85, you could use a mega328 (arduino) and it would just be a little bigger. The nRF has an SPI interface which you could share with the accelerometer; they just need separate chip-select pins. There are arduino libraries that support it, I believe. The micro would be responsible for polling the sensor and transmitting observations over radio, maybe also receiving configuration commands over radio. \$\endgroup\$ – William Brodie-Tyrrell Jan 27 '16 at 1:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.