What wireless transmission methodology suits gyroscopic sensor data transfer?

Projects General Guidance
1

Hi.

I'm putting together a project to collect real time 6 axis gyro data (this or another similar sensor https://m.miniinthebox.com/p/the-latest-mpu-6050-6000-6-axis-gyro-accelerometer-module_p4348915.html), then use that data for sound/music creation with MaxMSP. In my mind this is a simple project of receive data, transfer data, then play with data. Practically this raises some questions though.

I'd like a wireless solution such that the sensors can be freely interacted with by external participants (so I'm going to shove them in a ball casing and hope). Due to this I need to know what transmission method will be most effective for data retrieval. From what I understand Bluetooth LE could be a good candidate as it is small, requires little power and has constant information transfer. Would regular Bluetooth or RF offer any advantages besides these? I'm currently looking at Beetle BLE - The Smallest Board Based on Arduino Uno with Bluetooth 4.0 - DFRobot

The plan is to have several of these going at once as well. From what I understand the signals shouldn't interfere with each other in BLE?

Finally, I assume I will need a board to collect all the signals and pass the information to the computer (with a receiver for each sensor). Is that accurate, or would a single Bluetooth device be able to receive all of the readings?

Thanks

(Later in the project I may add different sensor types (pressure sensors, accelerometers etc). Would this make a difference to which method would be best?)

2

When posting links to shopping sites - and you need to read the forum instructions about posting links - you will notice a question mark - "?" - in the URL. Remove that and all the garbage following which only indicates your particular shopping session and that you are in Australia. :astonished:

As best I can figure out amongst all that spurious data, you are wanting to know which wireless technology to use - what the sensors are is pretty irrelevant. You might provide a better description of your actual purpose so we know what range, latency and accuracy you require.

3

Paul__B:
When posting links to shopping sites - and you need to read the forum instructions about posting links - you will notice a question mark - "?" - in the URL. Remove that and all the garbage following which only indicates your particular shopping session and that you are in Australia. :astonished:

As best I can figure out amongst all that spurious data, you are wanting to know which wireless technology to use - what the sensors are is pretty irrelevant. You might provide a better description of your actual purpose so we know what range, latency and accuracy you require.

Cheers for the link info, edited accordingly. Sorry if the purpose didn't come across amongst the spurious data, it is as follows: have an object with included sensors be interacted with by the public. Use this data in MaxMSP such that this data can both act as a midi controller, and such that if certain conditions are met (movement stopping suddenly as an example) a predetermined sound will play.

To be specific to what you've offered, range of at least 10 metres would be good. Low latency is critical, and high accuracy/often updated values would be preferred.

Not used to these sorts of projects just yet, thanks for helping clarify what info you needed.

To clarify purpose of question once more in case I have articulated it poorly, what transmission method will give me accurate, low latency data of the sensors? Once I have that information I'm confident with the sound processing side, just new to hardware involvement and choice.

4

I suspect a pair of nRF24L01+ transceivers (one to transmit and the other to receive) would be suitable. The nRF24 can send 32 bytes in a single message which should be sufficient for a set of readings from the sensor. Have a look at this Simple nRF24L01+ Tutorial.

From the little I know of BLE I think regular Bluetooth would be a better choice. Bluetooth is essentially serial-by-wireless so if you want to choose that option have a look at the examples in Serial Input Basics - simple reliable ways to receive data. There is also a parse example to illustrate how to extract numbers from the received text.

The technique in the 3rd example will be the most reliable. It is what I use for Arduino to Arduino and Arduino to PC communication.

You can send data in a compatible format with code like this (or the equivalent in any other programming language)

Serial.print('<'); // start marker
Serial.print(value1);
Serial.print(','); // comma separator
Serial.print(value2);
Serial.println('>'); // end marker

Note that Bluetooth is just a particular type of RF transmission.

...R

5

Robin2:
I suspect a pair of nRF24L01+ transceivers (one to transmit and the other to receive) would be suitable. The nRF24 can send 32 bytes in a single message which should be sufficient for a set of readings from the sensor. Have a look at this Simple nRF24L01+ Tutorial.

I've been looking that over for the past couple of days (and doing research on wifi and BLE). Looks like this may be the way to go. I have a related question though. If I wanted to use multiple objects each with their own sensors, that would involve transmitting from the balls, and receiving on an receiver linked to the computer. Am I correct in thinking I would need a receiver dedicated for each transmitter as the tutorial you linked notes that it cannot receive for that one signal at once?

6

Minrat:
Am I correct in thinking I would need a receiver dedicated for each transmitter as the tutorial you linked notes that it cannot receive for that one signal at once?

How many have you in mind when you say "multiple objects" and how often does each object need to send a message to the base station?

An nRF24 message is transmitted very quickly - maybe 3 millisecs or less. So a single receiver can receive a lot of separate messsages in one second.

Have you studied the example in my Tutorial of 1 master and multiple slaves?

If you have many transmitters all sending messages at the exact same time (even on different channels) to different receivers you may find that there is interference.

And remember a single Arduino can only do one thing at a time. Just use a single master nRF24.

...R

7

Thanks for the clarifying questions Robin. They are helping me get to and understand the practical side of what I want.

I would like to have at least 3 balls, with a preference to be able to have 5 if the project further develops. As I am using the sensor data as live midi controls, I would like data essentially sent continuously (or quickly enough such that changes from the participant end are easily identified in the sound change) Is it possible to have the receiver cycle through which transmission address it will take input from?

Having thought about it more I would like each ball to have attached a gyro/accelerometer, and a pressure sensor. I assume that this data can be grouped for each outgoing transmission of the ball microcontrollers.

I hadn't seen the multiple slave code on the next page previously, but have now. I think I understand what's happening: the master is sending a signal out addressed to a slave telling it to send its data. After receiving the data, the process repeats cycling through each slave.
Is it possible to instead have the master always receiving, but looking at the from address to cycle through? Would this allow for faster response?

Thanks for all your help.

8

Minrat:
I hadn't seen the multiple slave code on the next page previously, but have now. I think I understand what's happening: the master is sending a signal out addressed to a slave telling it to send its data. After receiving the data, the process repeats cycling through each slave.
Is it possible to instead have the master always receiving, but looking at the from address to cycle through? Would this allow for faster response?

You can use the RX code from my first example to receive data from several TX units each of which sends its message to the RX address. The TX unit can include in its message a byte that identifies the sender.

However the risk with that system is that two (or more) TXs will send at the same time and cause interference and loss of all messages. The polling system in my multi-slave example avoids that. I suspect there would not be a lot of difference in the performance assuming that all transmissions require an acknowledgement (which is the normal procedure).

Rather than say " quickly enough" you need to identify the maximum acceptable interval between wireless messages. I know virtually nothing about MIDI so it's entirely possible that an Arduino would not be fast enough. Better to figure that out before you waste a lot of development time. Maybe there is a standard for the time interval between MIDI messages.

...R

9

I could not find a standard for MIDI, my understanding is that it is simply instructions that are interpreted as they are received by software. I have previously used a single ultrasonic range finder as a controller with no latency issues, so there is precedent for Arduino functioning as I hope it to.

It terms of the practical number, I've looked up some standards to do with visual and audio cues and how in sync they need to be for a relationship between to be identified. Most of this is research looking at audio visual synchronisation in television or film. In these cases, the highest suggested delay for audio after visual is 125ms. Other sources are as low as 45ms. So if we call 125ms the ceiling for delay, and keep in mind your prior figure of around 3ms for transmission each way, that's 6ms per sensor per instruction which is well below. If we say there are 3 balls, then maximum allowable time each way we could say is (125/3~=41)/2~=20 ms. For 5 balls this is (125/5=25)/2~=12, so the estimate of 3 each way is really good.

I've been spending time looking into the transceiver bits, is there a reason you only use one pipe? This resource uses all of them for 1 master 5 slaves and seems to work https://howtomechatronics.com/tutorials/arduino/how-to-build-an-arduino-wireless-network-with-multiple-nrf24l01-modules/ . Is either method inherently more efficient?

Again. Thanks for your time and help through my blathering.

10

Minrat:
I've been spending time looking into the transceiver bits, is there a reason you only use one pipe?

Using more than 1 pipe won't improve performance because the nRF24 has only 1 wireless receiver.

The idea of pipes can be a bit confusing. Think of them as 6 shelves onto which the mail for different residents in an apartment block can be placed. All the letters come through the same mail slot (the radio receiver listening on Channel N) and when they fall on the floor someone picks them up, looks at the name of the recipient (the address the message was sent to) and puts them on the correct shelf (the pipe that has been assigned the same address as the message) or shreds them if they are for a recipient who lives in another block (i.e. if they are for an address that is not assigned to any of the pipes on this nRF24)

...R