Collecting on-board accelerometer data while using external triggering (ie. digital read)?
Hello! I'm a researcher trying to run a standard P300 test while the subject is moving. I was hoping to use the external triggering system to run the P300 test. However, the data from the on-board accelerometer is also necessary, which I can't collect if I'm using the 'Digital Read' function.
Am I able to collect accelerometer data while using the D11, D12 pins? Or, do I need buy an external accelerometer? (this seems like a waste if there is a functional on-board accelerometer).
Comments
Super, hi.
The default Cyton firmware has three 'Aux' channels, each 16 bits. The 8 (or 16) EXG channels are 24 bits each.
https://docs.openbci.com/docs/02Cyton/CytonDataFormat
The Aux data defaults to Accelerometer X, Y. Z. But can be optionally set to either 'Digital' or 'Analog' read mode.
https://docs.openbci.com/docs/02Cyton/CytonSDK#board-mode
So there is currently no support to multiplex between board modes automatically. For example by only returning Accel data 10 times per second or 5 times per second, etc. And at other sample times, returning digital or analog mode data. However you do have the possibility to custom modify the firmware to implement such a strategy. But note, such alternation between Accel and trigger data, will also have the side effect of lowering your resolution of the trigger timing, with a reduction of accuracy.
It might be easiest if you just use another Bluetooth accelerometer device, that runs on an entirely different radio channel. Since Accel data is not changing that often, this seems like an acceptable tradeoff.
William
Thanks for the response wjcroft. I think I understand, but please correct me if I get something wrong.
Is the digital read signal with external triggering accurate enough to detect P300, so long as I don't use the accelerometer?
And, you say I should just use a Bluetooth accelerometer device. How would I connect this device to OpenBCI GUI? (I'd prefer to have everything collected by the GUI, for simplicity). I was thinking I get an external accelerometer and feed the data into one of the Digital Read ports, but then I'd need a accelerometer that outputs digital data, clearly.
The digital and analog Aux modes, return trigger data on EACH sample. So this is the highest accuracy / correlation you can achieve.
The GUI is not designed to sample from multiple devices simultaneously. Your inexpensive Bluetooth accelerometer is setup to stream samples over the Bluetooth link, to a program on the laptop, using Bluetooth library 'read data' functions.
Your best approach would be to write a small Brainflow Python program, that gathers both streams (Cyton and Accel), and outputs the recording in the format you prefer.
https://brainflow.org/
https://brainflow.readthedocs.io/en/stable/Examples.html
Here is one open source project that reads from a Bluetooth Accel,
https://github.com/fundiZX48/pymotiontracker
Others,
https://www.google.com/search?q=python+read+bluetooth+accelerometer
You mentioned: "... I was thinking I get an external accelerometer and feed the data into one of the Digital Read ports..."
No. As previously pointed out, the Aux data in the radio packets consists of 3, 16 bit values. This is NOT enough resolution to store 3 Accel X, Y, Z values, PLUS your trigger data. Besides, the whole point of the Bluetooth Accel, is to avoid having to muck with custom Cyton firmware.
The other search term that can find these Bluetooth position sensors, is 'IMU' Inertial Measurement Unit. They typically have both accel and gyro, sometimes a compass as well. You can tell by the number of axes listed: 3, 6, or 9.
https://www.google.com/search?q=bluetooth+imu
I did have another thought about Cyton firmware mods. But I think this is still the more difficult pathway:
Since your binary on/off state of the trigger pin, needs basically only one bit to report -- you could then possibly stuff that trigger bit into the high order bit position of one of the X, Y, Z accelerometer values. Then take that into account when decoding the accel and trigger values. In other words, for this particular accel axis, use the SECOND highest order bit as the true accel high order bit. And use that to replace the accel high order bit before processing.
Again, I think reading your Bluetooth IMU is going to be easier than figuring out how to mod the Cyton firmware. Also, once you have such a modified firmware, then the GUI is not going to understand the new Aux channel values. So you'd need to mod the GUI also, etc. etc. It just gets messy.