8 bit or 32 bit board?

ltulley · October 2014

Hi all,

As an ex Emotiv Epoc owner, I'm really excited to see this device as it seems that I can finally get my hands on some useful data.

I'm interested in purchasing one of your 8 channel boards to start with (and a daisy chain board later) but I'm unsure as to the pros and cons of each board. Forgive me if I'm being dense but can you please provide me with an explanation?

Thanks in advance!

Leigh

biomurph · December 2014

Hi Leigh,

The biggest differences between the 8bit and 32bit boards are processing speed, and flash RAM memory size.

The 8bit board uses an ATmega328P with Arduino UNO bootloader. The ATmega is an 8bit microcontroller with 32K bytes of code space, 1K of EEPROM, and ~2K of RAM. We're using ~25K of flash, and we have ~450 bytes of RAM available. It's possible to increase the available flash and RAM space if you remove the SD card code (you won't be able to write to SD then...)

The 32bit board uses a PIC32MX250F128B microcontroller with chipKIT bootloader. the PIC is a 32bit micro with 128K bytes of code space, and 32K bytes of Data memory.

We are using about 47K of flash. Have not checked the RAM usage (figuring it out).

Also, the 8bit board clocks at 16MHz. the 32bit board has external 16MHz clock, and internal PLL that generates a system clocks speed of 40MHz.

So, more processing power on the 32bit board if you want to do on-board DSP or other crazy stuff.

ayushmh · January 2015

Does it make difference in coding of program?? nd If I buy an Open BCI 8 bit kit then the difference b/w 32 bit n 8 bit will be only of processing speed??

wjcroft · January 2015

Ayush, I merged your question / thread into this existing one.

Checkout the previous posts on this thread.

The 32 bit version is 'compatible' with Arduino code, but not exactly the same. So there may be some adjustment needed for example if you are importing an Arduino library to run under Chipkit.

http://chipkit.net/tips-porting-arduino-libraries/

Also there is a 'Search" box at the lower right of the forum pages. For example searching for 'chipkit' would have uncovered this thread.

Regards,

William

chipaudette · January 2015

From my perspective, the choice between the 8-bit board and the 32-bit board matters only if you are ever going to change the software running on the OpenBCI board itself. Alternatively, if you are only ever going to use OpenBCI to stream data to the PC, and you're going to have all of your fun on the, then it doesn't matter whether you have the 8-bit or 32-bit board.

Chip

Aphina · March 2015

What is difference between 8-bit and 32-bit for working with P300, sensorimotor cortex and imaginary data?

wjcroft · March 2015

Aphina, moved your post to this existing thread. See previous posts. As Joel points out, it's code space and processing speed. And that is only relevant if you are building a self contained program running on the board. Also see the P300 Speller thread with OpenViBE, which works fine with either board.

JakeStew · March 2015

I've seen it with several projects before... 8-bit should have been phased out ~5-10 years ago. It really has no place in modern projects trying to do anything sophisticated.

Dev. work on the 32-bit version will quickly start adding features that can't be supported on the 8-bit board. Then you'll be suck listening to everyone talking about their new features that you don't have.

Then again, the processor is essentially doing nothing other than passing SPI data along. But the data rate / sampling rate in the current devices is really low. Something's going to need to change to make it useful for more applications. Whatever that is, if you only have an 8-bit board, you'll have to keep your fingers crossed that an 8 year old processor based on 1980's processor architecture will be able to accomplish it.

chipaudette · March 2015

There's no doubt that 32-bit platforms are more capable. But, the reason for getting an 8-bit board is Arduino compatibility. When it comes to programming the board, the 8-bit OpenBCI board *is* an Arduino Uno, no "ifs" or "buts". Load the Arduino IDE, set it to Arduino Uno, and reprogram the board using any code that works on an Uno. IMO, that security blanket is a super-strong reason for choosing the 8-bit board.

If you're sophisticated enough to want to do EEG processing on the OpenBCI board itself (as opposed to on the PC, where it's easier to develop and debug), you're probably also sophisticated enough and confident enough to not need that "Arduino at Heart" security blanket. If you've got that sophistication and confidence, you should definitely rock the 32-bit board.

Chip

JakeStew · March 2015

> the reason for getting an 8-bit board is Arduino compatibility.

OpenBCI is not Arduino compatible. It uses a different form factor.

Personally, I don't see any advantage to limiting yourself to a specific form factor and specific "names" for your pins. It adds nothing. If this were a project for high school students it might be worth it to save them a couple hours of extra dev time and let them pull settings from a drop down list box rather than having to actually learn anything about the uC.

The ArduPilot (APM) project suffered from the same problems. They picked an aged, underpowered design to start with so they could save a little dev time. It quickly reached it's limits, at v2.5 and they ditched it in favor of the pixhawk STM32 based design. Now you can read about feature after feature being added, but they are only for the STM32 design. APM users still have support, but none of the new features are able to be enabled for them. The result is a mangled, bastardized code base that tries to support legacy hardware, a completely different uC arch., and new features... all thrown in the same sloppy code pile.

It would pay to do a thorough review of if it is even worth continuing development on the 8-bit design. 256 sps is not acceptable for a lot of applications, and it seems like a hardware redesign will probably be required to to better. So now would be a good time for a clean break before the next version.

chipaudette · March 2015

To be clear, the EEG sample rate limit has nothing to do with 8-bit vs 32-bit...the limit on the EEG sample rate is due to the RFDuino wireless unit on the board. The RFDuino wireless unit can only go so fast, so if you want 8 channels of EEG, youre stuck with 250 Hz per channel.

As for the rest of the discussion about the value of being Arduino at Heart, I disagree with your view (which is fine for us to disagree) that there is no value in the hand-holding environment provided by the Arduino approach. I do believe that the naming of the pins, the not worrying about memory maps, the not worrying about how the boot loader works, and the not worrying about paths to libraries...I do believe that all of these features DO have value for people just starting into this field. And this value is not just for high school students. A lot of folks, myself included, have picked up this hobby as adults. The lower barrier to entry that is the Arduino toolchain is why the Arduino works at all for new folks...it's not the hardware, it's the software. By keeping OpenBCI in the line of these people's comfort zone (ie, staying within Arduino IDE) it helps to make the 8-bit board more approachable. I think that this has value.

Your ArduPilot example is excellent example for this discussion. I was not aware of the history that you cited, and it is an excellent argument. However, I find ArduPilot to be an imperfect parallel to OpenBCI. To me, the critical difference is that ArduPilot is an application where you are not connected to a PC...the drone needs to fly on its own, not with a laptop attached. Therefore, all of the processing is occurring on the ArduPillot itself, not on a PC. In my opinion, this is not the case for most uses of OpenBCI. In my opinion, most applications will likely execute all of the EEG processing on the PC. Therefore, it doesn't actually matter whether the OpenBCI board is running 64-bit, 32-bit, 8-bit, or a vacuum tube...as long as the processor is fast enough to push the bits, it's fast enough to do the job.

So, in our delightful debate here, I view the 8-bit board as a security blanket....and an important one...one that keeps new people feeling comfortable enough to participate. In the end, though, it doesn't actually matter what processor is on the OpenBCI board because, for most folks, the processing is actually on the PC, so one is unlikely to ever change the firmware on the board itself...the processor becomes just a nameless grunt that is working to push data from the ADS1299 to the wireless unit.

If we're talking about doing thorough reviews of the design, I would propose that it be the wireless subsystem that get all the attention, since it is the wireless subsystem that is actually limiting the system capability, not the processor. With a faster wireless connection, we could pump up the sample rate and the number of channels, both of which would enable this product compete with more research-oriented systems.

Chip

JakeStew · March 2015

Your points are well made. My intended research application and bent towards tinkering for performance certainly influences my opinion on the matter. I should further point out that I have no practical experience with these boards. My last hardware experience in the field was with modeeg, using an Atmega8.

Having done a bit of embedded programming in the past, I've been through hitting the brick wall of processor limitations a couple times. It's not fun.

Manipulating 24-bit data on an 8-bit processor at high speeds is just not feasible. Compression and oversampling should be the next steps for the firmware, and I think that old 328 just isn't going to be up to the task.

The dual design strategy used so far already shows that we know the 8-bit solution is just a stopgap bridge to a final design.

Programming on STM32 is certainly more difficult than Arduino. But it's NOT more difficult than coding and supporting both 8-bit and PIC32 at the same time. That's why I think the current strategy and design path is incorrect.

The low speed bluetooth is another major potential limiting choice. Direct SPI, I2C, USB, UART, and/or WiFi really need to be implemented to hit the speeds we need. It's easy enough to pin out everything except the wifi. End users can choose whatever direct connection or wireless solution they choose.

The fact is, 99% of end users won't ever even look at a single line of firmware code. So the real issue is how well our dev team is managed and what the skill pool is. If nobody has any experience with modern processors, then we're stuck with Arduino and should get to whatever level can be achieved, then ditch it when the dev team has grown/matured enough to move on. If the talent is already here then we should pursue a 32-bit design, hopefully with leading edge products like the STM32 line rather than lagging companies with poor price/performance ratios like Microchip and Atmel.

The one thing that seems like a losing strategy to me is pursuing multiple hardware designs with multiple code bases.

The bottleneck is not just in the bluetooth, it's in the interface between the uC and BLE chip. BT speeds are much faster than we're getting. It's important to work from a set of design goals rather than designing and slapping things together in the fastest/easiest way possible. The design choices made for the current boards severely limit the performance, and I think that would be something important to avoid in the future.

Assuming the bluetooth bottleneck is solved in the next version, that will just make the uC the limiting factor. It might be smart to plan ahead and avoid that becoming the next "Doh!" moment.

chipaudette · March 2015

Continuing the discussion of the wireless link, I think that it is important to remember that any hard-wired link (SPI, I2C, UART, USB) have a safety risk to the user. You do not want to be hardwired to anything that is then plugged into a wall power outlet. Real EEG systems have a medically rated isolated power supply. Including such a power supply in OpenBCI is prohibitively expensive, so not feasible.

Note that the OpenEEG system contains power isolating components, but the first time that a user opens the case to attach another sensor or make some other hack, they risk making an unintended conduction path around the electrical safety devices. I view any hardwired device as a safety risk. To me, OpenBCI must avoid this -- the device must be wireless.

Given the wireless technology options, I think that WiFi is a non-starter given the power draw. It's also more annoying to configure.

The other two main categories of wireless options are bluetooth or a proprietary wireless solution (e.g. Zigbee). RFDuino is kinda in the middle of these two categories...it can run standard bluetooth low-energy (BTLE), or it can run a proprietary communication protocol using the same hardware.

I believe that the original goal with OpenBCI was to use the RFDuino in its BTLE mode so that OpenBCI would connect to any smarthphone or PC with using an add-on dongle. Unfortunately, I think that the OpenBCI guys found that standard BTLE just isn't setup for streaming this much data without hiccups. So, they were forced to use the RFDuino in its proprietary mode. If one is willing to use a reduced number of channels, however, the current OpenBCI radio software can be changed back to standard BTLE and the device can connect directly to a phone...either Android or iOS. I think that flexibility has some value.

Moving forward, though, I'm not sure that this flexibility is worth the overall speed limit that we're all forced to live under with the RFDuino unit. If we do want more data throughput, yet still want the ability to connect to some mobile devices, OpenBCI could be switched away from BTLE and go back to Bluetooth classic (ie, BT 2.1 or whatever it is.). BT Classic has tons more bandwidth. Unfortunately, it is no longer supported by iOS. Given that there is no perfect solution, I think that this is a fair trade.

Of course, I'm not the one who'd have to do the engineering work (design, fab, test, iterate!) to switch the wireless unit...perhaps such a switch (requiring hardware AND software mods to OpenBCI) would have lots of hidden "gotchas" that would make the BT Classic approach not feasible. I do see that here are other systems out there (see FlexVolt) that appear to use BT Classic in this role with success. This gives me hope that, if OpenBCI elect to change the wireless approach, that a BT Classic solution would work.

Chip

JakeStew · March 2015

> remember that any hard-wired link (SPI, I2C, UART, USB) have a safety risk to the user.

There's a couple issues I have with this. The primary argument is that users may choose any sort of wireless link they want. None of those interfaces necessarily means connection to line voltage. Many people use, or could use, their laptops. Smartphones are another demonstrated route.

The other issue, I won't get into as it is unlikely to change anyone's mind or result in productive discussion. But suffice it to say that I don't see any substantial risk being connected to a computer. The noise issue of connecting directly to that hornet's nest of interference should be enough reason to avoid it in any case.

The bluetooth discussion is helpful. I couldn't care less what the wireless solution is. Anything we want to connect to will have both BT and wifi. BT should be plenty fast enough and Wifi can certainly be a big PITA on the software side.

I am kind of surprised that wireless was integrated right off the bat. There's certainly the potential for interference, problems, and as discovered, bottlenecks.

$7 ebay serial bluetooth modules are really cheap and easy to get working. It would be a good idea to see what sort of speeds can be gotten out of them. They support 1M and 1.38M serial speeds supposedly. I'm not going to suggest that they can actually achieve this or if the air rate would hold up to this... but they can certainly go a *lot* faster than the current solution.

I have a few kicking around and IIRC I was able to get 460k out of one before I ran into trouble finding compatible settings with the PIC I was working with. I didn't test throughput either, so it's nothing definitive.

wjcroft · March 2015

> But suffice it to say that I don't see any substantial risk being connected to a computer.

See some of the links on the thread below. If you have a medical rated power supply and isolation on the interface, you're fine. However, many Makers would be inclined to take shortcuts. Which would expose OpenBCI to legal liabilities.

http://openbci.com/forum/index.php?p=/discussion/243/spi-wifi-transfer-eeg-data-to-external-device

biomurph · March 2015

Any direct connection to a computer via USB is going to have tons of noise on the power line that will easily seep into the signal.

You would always inevitably wind up isolating the power supply to avoid that, which is what I did for the V1 and V2 boards.

If you can get a bluetooth solution to work at high data rates, I would love to see it!

Hack away!

JakeStew · March 2015

I've been through a few discussions on isolation before. Avoiding noise is a plenty good reason reason by itself.

I just don't see any legal liability issues. If the product is not used according to instructions you're not liable. There's nothing to stop someone from jamming an electrode or DRL into a 220 socket or something of that sort, yet nobody seems to see that as a liability.

I would worry much more things you actually would be liable for, such as allergic reactions to the recommended/included electrode paste, etc..

The main reason I don't like the excessive worry about connection issues is that I just don't see any evidence of risk.

As far as I can tell, the risk is so small as to be unquantifiable, e.g. it's never happened before. Without a real way to quantify the risk there is no way to determine how much effort is worthwhile to avoid it.

wjcroft · March 2015

Well I guess all these medical power supply companies must be fooling themselves... ;-)

https://www.google.com/search?q=medical+power+supply+leakage

JakeStew · March 2015

The law books are full of regulations against problems that don't exist. I'm not saying that's necessarily the case... but I'm a skeptic, I don't believe in things without a basis in fact.

It would be great to find out what the risk is, or if it is even real. I'm sure someone, somewhere has been electrocuted through their computer in some strange way. I'm not really sure it's fair to blame a 20 ga. wire from the computer to a person for the direct lightning strike that killed them, but lightning strikes are a real risk that CAN be quantified.

One place to start would be to find the failure rate for computer power supplies, and what percentage of those failures are of a mode that fries the computer with dangerous voltage levels. Another way might be to see how many people are shocked through peripherals. There's plenty of ways to establish if there is a risk and get some level of quantification.

When I worked as a test operator I got shocked on an almost daily basis with everything from 110 and 220 line voltage all the way to 1000v hi-pot testing voltage. They actually poo pooed me when I suggested we should have an AED available at the ~600 employee facility where I was getting shocked daily.

So there's certainly a wide range of opinions ranging from "The sky will fall if there is any chance of any minor voltage contacting your body," all the way to "Suck it up and get back to work, it's only 220v from a 10 amp circuit."

chipaudette · March 2015

One of the key differences between the shock hazard during everyday life and the shock hazard during electrophysiologic measurements (EEG, ECG, etc) is that in everyday life you've got a fairly insulating layer (10s to 100s of kOhm) insulating layer that is your skin. With electrophysiologic measurements, you've used conductive gels and pastes to reduce/remove that insulating layer. Therefore, you greatly increase the amount of current that will enter your body.

A second key difference is that, in electrophysiologic measurements, you've purposely made these low-resistance connection across very interesting parts of your body...such as your heart or your brain. Therefore, if an unexpected shock does occur, the current is flowing through an important part of your body, not something peripheral. You know, getting bit by 110V in one hand is one thing...getting hit by 110V when you've grabbed something with both hands (such that the current goes across your chest)...well, that's a completely different thing.

So, having worked with the previously-hardwired versions of OpenBCI, I'm very pleased that we're now wireless. This is a hobby, something that is supposed to be fun. I'm not really interested in anyone, including myself, having any sort of injury. I see wireless as a key protection.

Chip

JakeStew · March 2015

Good points. It certainly makes sense to take precautions against foreseeable potential risk like this. But it's also good to make sure you are honest about the reality of the situation lest it sabotage our credibility.

A bit of googling hasn't turned up any reports of anyone who's ever been electrocuted via EEG. I can't claim it was a particularly thorough search, but it's interesting to note how much hysteria associated with the topic turns up vs. a lack of anything that indicates a factual basis for risk.

Noise, convenience, and coolness are certainly enough to justify the wireless design choice. Following good design practice, engineering standards, and regulatory guidance is also another good reason for the choice.

I think it is more positive to focus on those aspects rather than try to justify it by claiming it reduces a risk that's already so slight as to be un-quantifiable.

nobletime · May 2016

good posts.... Just have a hard time following your posts JakeStew with advice on engineering, design, etc and how Google hasn't showed reports of anyone being shocked via EEG - supposedly Google should have all the answers - not sure what you're intending to prove here but there are good valid points if you pay attention to, and do not require self-validation / guru mindset.

8 bit or 32 bit board?

Comments