We built an OpenBCI Cyton / Daisy
dmg
Spain
Hi,
I'm a member of an engineering students association and
recently we had the idea of experimenting with brain computer
interfaces. We found about openBCI, we liked it and as it's an
open-hardware project and our hardware assembly skills surpass our
budget we decided to build an openBCI from scratch, as that would cost
us less than half of the money it costs to buy one. We are building the
whole system, including openBCI 32 bit + daisy module + dongle + full
ultracortex, and so far all the electronics are built and seem to be
working fine. We've checked that all channels respond to stimulus and
that the accelerometer works. In order to save costs we did some minor
modifications:
-We modified the daisy board gerbers and cut about
3 mm from the top of the board. At the same time we corrected the
hardware bug that is documented somewhere and needed to be solved by
desoldering a lead from the ADS and soldering it to the adjacent one.
-Having
made the daisy board 3mm shorter we could then panelize it with the
openBCI board in a panel smaller than 10x10 cm. That way we saved a lot
of money in PCB's as chinese manufacturers offer cheap 4 layer boards of
up to 10x10cm.
-We also modified the dongle board. The on-board
USB connector requires 2.4mm thick PCB material to work reliably, and
that is expensive. So we modified it to use a real USB connector, and
that way we could also shorten it a bit so it was less than 5x5cm in
size and cound be manufactured cheaply.
-We also had to correct several mistakes from the BOM's but fortunately that wasn't very hard.
-And
we're also planning to try and expose a PIC32 UART through the
expansion connectors (should be possible according to PIC's datasheet,
as there are two broken out pins that can be TX and RX of the same uart
by using the peripheral pin select feature). Theoretically that UART
could run as fast as 12 Mbps. Using DMA it should be possible to get a
decent enough throughput to be able to spit out 16 channels at a
reasonable sample rate (1000 Hz or so) to a custom designed radio link
to do away with the rfduino limitations.
On the UltraCortex side
we also checked that the octabolt design can accomodate a metric size
spring. We're going to use 10mm diameter x 20mm long x0,5mm wire
thickness springs, which are about an order of magnitude cheaper than
the proposed model.
Here are the pictures of what we've built so
far. Now it's time to order the EEG electrodes (is there still any
discount available from florida research insititue for OpenBCI?) and to
3D-print the ultracortex!
I'm a member of an engineering students association and
recently we had the idea of experimenting with brain computer
interfaces. We found about openBCI, we liked it and as it's an
open-hardware project and our hardware assembly skills surpass our
budget we decided to build an openBCI from scratch, as that would cost
us less than half of the money it costs to buy one. We are building the
whole system, including openBCI 32 bit + daisy module + dongle + full
ultracortex, and so far all the electronics are built and seem to be
working fine. We've checked that all channels respond to stimulus and
that the accelerometer works. In order to save costs we did some minor
modifications:
-We modified the daisy board gerbers and cut about
3 mm from the top of the board. At the same time we corrected the
hardware bug that is documented somewhere and needed to be solved by
desoldering a lead from the ADS and soldering it to the adjacent one.
-Having
made the daisy board 3mm shorter we could then panelize it with the
openBCI board in a panel smaller than 10x10 cm. That way we saved a lot
of money in PCB's as chinese manufacturers offer cheap 4 layer boards of
up to 10x10cm.
-We also modified the dongle board. The on-board
USB connector requires 2.4mm thick PCB material to work reliably, and
that is expensive. So we modified it to use a real USB connector, and
that way we could also shorten it a bit so it was less than 5x5cm in
size and cound be manufactured cheaply.
-We also had to correct several mistakes from the BOM's but fortunately that wasn't very hard.
-And
we're also planning to try and expose a PIC32 UART through the
expansion connectors (should be possible according to PIC's datasheet,
as there are two broken out pins that can be TX and RX of the same uart
by using the peripheral pin select feature). Theoretically that UART
could run as fast as 12 Mbps. Using DMA it should be possible to get a
decent enough throughput to be able to spit out 16 channels at a
reasonable sample rate (1000 Hz or so) to a custom designed radio link
to do away with the rfduino limitations.
On the UltraCortex side
we also checked that the octabolt design can accomodate a metric size
spring. We're going to use 10mm diameter x 20mm long x0,5mm wire
thickness springs, which are about an order of magnitude cheaper than
the proposed model.
Here are the pictures of what we've built so
far. Now it's time to order the EEG electrodes (is there still any
discount available from florida research insititue for OpenBCI?) and to
3D-print the ultracortex!
Comments
congratulations.
I work in a neuroscience laboratory in Bordeaux, France.
We are really interested by an increased sample rate.
Where are you in Spain?
Currently I use the "SD Only" recently proposed by Biomurph (thanks again).
It works well at 2kHz (and probably more) but during some overruns we loose data up to 400 samples (at 2kHz).
I
am writing a litlle modification of the soft to pool the AD during the
"wait SD not busy" function that causes theses overruns...
Themselfs these overruns are really not a problem (they are so many artefacts and much more, during EEG recording...) but it is difficult to publish scientific results when you know that they exists...
Yannick.
We're in Madrid. We liked the OpenBCI design and the fact that their creators took a time to test and characterize it, but we didn't like two things about it, the radio link's limited speed (this is actually not the fault of the designers as far as I know) and the fact that a single SPI port is shared between the two ADS1299, the accelerometer and the SD card, when the PIC has two SPI ports and one should be reserved for the SD card to avoid overruns and such. Maybe DMA should be used too for this application, looks like a textbook example of something where you would want a DMA channel to move the data for you. We'll try to port the PIC's software to MPLABX and from there design our own radio link, probably we'll first try to use a cheap HC-05 bluetooth 2.1 EDR module which should do 1Mbps+ and if that doesn't work well maybe an ESP8266 or a custom 2.4GHz radio link.
I wonder if this achitecture has been kept in the new card called "Ganglion".
Will you clone it?
Any way even if we have a dedicated spi for the sd card, even if we use interrupts instead polling, (it would be more rational and comfortable), we cannot avoid to buffer the data during sd card interface wait time...
Do you know if these long duration busy states can be avoided? It is beyond my skills, I am a biologist by training...
For what use intend you this card?
16 channels at 2kHz require a 32k buffer to by-pass long overruns... the PIC32 mx 270 f 256 B, pin compatible, offers 64k ram...
Yannick.
on X axis the acquired sample number,
on Y axis the number of samples losted during overruns.
The session duration was 130' and the sample rate 500Hz on 8 channels.
There is a certain regularity of the overruns occurences which depend on the quantity of data written on the SD card...
Yannick.
There are some comments on the thread below, mentioning the possibility of using "double buffering" to achieve maximum SD card writing speed with no lost data. If you post your question on that thread, someone may have found a workaround to the firmware.
http://openbci.com/forum/index.php?p=/discussion/106/sd-card-writing-speed
Such a modification would likely also utilize this,
http://openbci.com/forum/index.php?p=/discussion/418/using-interrupts-vs-polling-of-ads1299
@wjcroft
Thank you William, I missed the first link...
The aim of the second link is not related to the problem raised by the very long "busy state" of the SD interface...
( @hitheshaum : have you tested it recording on a SD card? (Since IT flag is cleared at the entry) I wonder what appends when an interrupt occurs while the previous interrupt call is still wainting that the SD card becomes not busy ... )
In the first link "ADMIN" post a "block raw writing" code which is currently implemented on the V3-32 board used for my stats.
"double buffering" sounds like magic. Waiting states lasts so long time that we need more than 2 block buffers to not to lost data.
I should have said that my stats have been performed with the SD 16Gb card from Transcend ( TS16GUSDHC10 ) Class 10 , 30MB/s, 200x.
May be that other card markers have a better internal managment of the memory and do not impose so long waiting time...
Yannick.
Yeah, I'll put together a post in the community section and will include the modified gerbers and the ready-to-order BOM, and also some details about the building process. I'm not very sure on how to use your forum/comunity system, it took me a while to register in the forum and my account doesn't seem to work for the community section, and apart from that I'm using firefox and I have some web display issues, not sure if it's a general issue or if this is just my problem. Could you please tell me how to register in the communtiy?
This is not a board for newbies to build as it has several gotchas, you gotta be precise and use the right tools or materials mainly because of the leakage sensitivity of the analog front-end, as crap and flux residue can easily ruin your 1 Gohm Zin and the cross-talk between chanels, so you have to solder it right the first time and limit rework and flux usage and then apply proper cleaning techniques.