Can someone point me to a document that would explain how to get the openbci stream data from the OBCI board to an external device, such as Beaglebone gpio or some such? I am wanting to bypass the rfduino stuff.
The problem with this approach, however, is that you are now attaching electrical items to the OpenBCI board, which is also connected to your head. If you are going to plug anything into the OpenBCI board, be sure that it is either completely unpowered (like a button or switch) or that it is battery powered. Electrically attaching things to the OpenBCI board could pose an extreme electrical hazard to your brain. Think what could happen if there were a power surge or lightning or something and it got into your board and then into your brain...it could shock you dead!
You're right, we are not publishing the V2 (arduino sheild) production files because we don't want anyone to get maimed, or killed. Our schematic files are available, and you could certainly use them, along with the photos of our work, to produce your own board. Before you do, I suggest you look into the standards for electrical isolation. Here's a good place to start learning about it. http://www.601help.com/Requirements/electrical.html OpenBCI disavows and disclaims all liability for the results of your work, or of anybody else's work who may be lurking here. come back when you have more questions. separating the GnD planes is fun and tricky! Joel
----
If indeed your external device is also battery powered, then there are a range of SPI / I2C / serial approaches available.
PS the battery power restriction should be taken seriously. And... There is also a class of Medical rated (60601-1 certified) external supplies and dc-dc converters manufactured. But even with a medical rated supply, that does not excuse the engineer from employing proper isolation / fault protection circuitry in your interfaces.
Thanks for the helpful links about the SPI and I2C stuff. Mkay so it sounds like I could get significantly higher data rates if I sent the data over an SPI connection to my Beaglebone and then sent the data out over wifi, etc then the current Bluetooth limitation. Seems like there's are lots of other solution options available other than the ones that are currently available if the hardware/software architecture is make a more clear. For example, I currently use a rechargeable (Limewire) 5V battery instead of the battery thingy that comes stock with the OBCI system. That same battery could also power the Beaglebone without any more hazard then running off of the battery given. I guess I am confused about how a 5v,1A power supply fails in such a way that it becomes hazardous, but perhaps I am missing something. Probably in fact. Anyhow, regardless, a wall adapter is not how I am powering the system.
> sounds like I could get significantly higher data rates if I sent the data over an SPI connection to my Beaglebone and then sent the data out over wifi
You might be able to avoid the Beaglebone, instead using this tiny Texas Instruments CC3000 board available from Adafruit...
Just wanted to bump this wifi thread up to the top of the recent discussions. Several users were asking about higher sample rates or stacking multiple daisy boards for 24/32 channels. The Texas Instruments CC3000 wifi module may be a way to get faster / larger data transfers over the air.
Bluetooth has the advantage that it is both low power draw, lower EMF, and built into all mobile and desktop devices. Yes, wifi is also present in these same devices.
My impression is that the BLE, Bluetooth Low Energy mode was a deciding factor. Also I'm not sure the particular CC3000 wifi solution was available early in 2014 when Bluetooth options were being weighed.
Lower EMF is an important consideration, particularly if the device is head mounted.
cremona, we used BLE because of cost and EMF, also because of the desire to link to mobile devices. in the last year, there have been more developments and products released that leverage wifi. it's something we're looking at for the next version.
as far a bypassing the RFduino, the 8bit board has the SPI bus pins all broken out nice-like (cause we have to use them to flash the Arduino bootloader) but the 32bit board does not have them handy. If you want to breakout the SPI on our 32bit board, it will take some digging, but it's possible.
Thanks for those details BioMurph. The endevour of ordering a wifi module and hooking it up to the SPI seems a little major for me right now, given that I am not even sure the outcome will get me what I want. Ultimately, I want a low latency connection and often wifi (after all the unecessary layers of crap are added even for a point to point connection) the latency is just rediculously high. Wish the wifi hardware vendors would design the devices so that one could make optional various elements of the ethernet and TCP/IP stack via the API.
agreed, cremorna. I have not messed with wifi too much because of the painful hassle experienced a year ago or so. There's some interesting stuff that spark.io is coming out with something that looks kind of sexy
i have pre-ordered the module. I also have one of their earlier versions here that I will play with and report back. My friend who's messed with one says that it's difficult to move between different routers....
And extraordinary toolbox they provide with it. They are tuned into the Internet of Things vibe, to the max. Look forward to your observations. It does look like the new version has considerably more horsepower, over the CC3000 based design.
Since latency is a concern for your app, and for all neurofeedback applications, I did a quick search on the support that the Spark Core (CC3000 based) has for UDP. Not so good at the moment. See search link below. This is a TI CC3000 failing on the Core design. My impression is that Spark has rewritten their entire IP stack for the Spark Photon.
One of the issues is that most Spark apps are working the IoT / Cloud angle. Whereas for our purposes we would need fast direct point to point IP/UDP. Or possibly TCP if it is fast enough. Photon may be capable of doing this, it will be shipping in April. I didnt look closely there may already be some Photon related UDP posts in that list.
Yeah, I pre-ordered the Photon, then this summer I moved and my order got corrupted.
I'm expecting the photon to arrive this week. One of the guys I share our work space with has one, and we did some preliminary tests with dummy data that seem promising. Lots of issues and testing remain. We are looking into it, for sure.
Comments
The Bluetooth approach was an explicit decision in terms of safety and liability. Read a couple of these posts,
http://openbci.com/forum/index.php?p=/discussion/comment/932/#Comment_932
http://openbci.com/forum/index.php?p=/discussion/comment/489/#Comment_489
http://www.601help.com/Requirements/electrical.html
OpenBCI disavows and disclaims all liability for the results of your work, or of anybody else's work who may be lurking here. come back when you have more questions. separating the GnD planes is fun and tricky!
Joel
----
If indeed your external device is also battery powered, then there are a range of SPI / I2C / serial approaches available.
https://www.google.com/search?q=transfer+between+arduinos
http://electronics.stackexchange.com/questions/42197/making-two-arduinos-talk-over-spi
William
----
PS the battery power restriction should be taken seriously. And... There is also a class of Medical rated (60601-1 certified) external supplies and dc-dc converters manufactured. But even with a medical rated supply, that does not excuse the engineer from employing proper isolation / fault protection circuitry in your interfaces.
http://www.cui.com/medical-external-power-supplies
http://www.cui.com/catalog/resource/iec-60601-1-medical-design-standards.pdf
http://www.digikey.com/product-highlights/us/en/recom-power-high-isolation-dcdc-converters/4204
https://en.wikipedia.org/wiki/Network_isolator
https://www.google.com/search?q=electrically+isolated+usb
> I guess I am confused about how a 5v,1A power supply fails in such a way
that it becomes hazardous, but perhaps I am missing something.
https://www.google.com/search?q=medical+power+supply+leakage
> sounds like I could get significantly higher data rates if I sent the
data over an SPI connection to my Beaglebone and then sent the data out
over wifi
You might be able to avoid the Beaglebone, instead using this tiny Texas Instruments CC3000 board available from Adafruit...
http://www.adafruit.com/products/1469
https://learn.adafruit.com/adafruit-cc3000-wifi
http://www.ti.com/product/cc3000
Regards, William
http://www.adafruit.com/products/1469
https://learn.adafruit.com/adafruit-cc3000-wifi
http://www.ti.com/product/cc3000
William
My impression is that the BLE, Bluetooth Low Energy mode was a deciding factor. Also I'm not sure the particular CC3000 wifi solution was available early in 2014 when Bluetooth options were being weighed.
Lower EMF is an important consideration, particularly if the device is head mounted.
http://www.bioinitiative.org/
The http://spark.io link you posted, amazing!
And extraordinary toolbox they provide with it. They are tuned into the Internet of Things vibe, to the max. Look forward to your observations. It does look like the new version has considerably more horsepower, over the CC3000 based design.
https://store.spark.io/
William
https://www.google.com/search?as_q=udp&as_sitesearch=https://community.spark.io
One of the issues is that most Spark apps are working the IoT / Cloud angle. Whereas for our purposes we would need fast direct point to point IP/UDP. Or possibly TCP if it is fast enough. Photon may be capable of doing this, it will be shipping in April. I didnt look closely there may already be some Photon related UDP posts in that list.
William
Also see these threads,
http://www.openbci.com/forum/index.php?p=/search&Search=ESP8266