Restructuring
Moved firmware docs into the Hardware section
Esse commit está contido em:
biomurph
+48
-43
@@ -1,6 +1,6 @@
|
||||
# OpenBCI Radio Firmware
|
||||
# Cyton Radio Firmware
|
||||
##Overview
|
||||
The OpenBCI V3 boards communicate via RFduino Bluetooth modules made by RFdigital. This doc will cover the needs of the OpenBCI system, and how we met them with the Radio firmware. Our selection of Bluetooth and RFduino was based on the desire to connect with mobile devices, and the need for accessible development environment. RFduino modules come with a bootloader that allows uploading code via avrdude, just 'like' Arduino. There are some differences, but the basic process is very much the same between RFduino and Arduino UNO, for example. We were also able to wrork very closely with the RFduino team, and they helped us greatly over the development cycle.
|
||||
The OpenBCI Cyton boards communicate via RFduino Bluetooth modules made by RFdigital. This doc will cover the needs of the Cyton system, and how we met them with the Radio firmware. Our selection of Bluetooth and RFduino was based on the desire to connect with mobile devices, and the need for accessible development environment. RFduino modules come with a bootloader that allows uploading code via avrdude, just 'like' Arduino. There are some differences, but the basic process is very much the same between RFduino and Arduino UNO, for example. We were also able to wrork very closely with the RFduino team, and they helped us greatly over the development cycle.
|
||||
|
||||
OpenBCI comes with a RFduino module on-board for communication, and an RFduino based USB Dongle for communicating to computer. The method of 'talking' to and through the radio connection is standard Serial UART 8N1. It is necessary to have the paired radio modules because we also have a Arduino UNO bootloaded ATmega on the 8bit Board, and a chipKIT bootloaded PIC32 on the 32bit Board. Both of these uC's can be programmed using avrdude.
|
||||
|
||||
@@ -30,47 +30,6 @@ Avrdude uploads code to ATmega328 with UNO bootloader in 128 byte pages, and the
|
||||
|
||||
The other basic thing we need to do is have a way for the RFduinos to communicate to each other special messages that the PC and ATmega (or PIC32) don't see. These 'radio only' messages are used for sending the reset command to the ATmega, and for keeping the radios on the same page when uploading to the PIC32. Radio only messages are always packets that have only one byte in them. Any other packet will have at least two bytes (Packet Check-Sum + Data Byte)
|
||||
|
||||
###8bit Board
|
||||
|
||||
The Arduino UNO bootloader runs when the ATmega 'wakes up' from reset. Back in the day the reset signal had to be sent manually by pressing the Arduino reset button. Then some smart folks hijacked the DTR pin (legacy RS232 Handshaking pin) from the FTDI USB<>Serial chip to 'automatically' perform the reset function. We wanted to retain this automatic reset feature, so we are using 'special message' function of our code to pass the reset signal to the OpenBCI Board. With the slide switch on our USB Dongle set to GPIO6, the RFduino Host can 'feel' the polarity of the DTR on its pin 6, and then send a special character to the Device. When the Device gets the special character, it resets the ATmega. That makes it possible to upload code from the Arduino IDE and treat the 8bit Board just as if it were an Arduino UNO.
|
||||
|
||||
|
||||
8bit HOST REMOTE RESET CODE
|
||||
|
||||
resetPinValue = digitalRead(resetPin);
|
||||
if(resetPinValue != lastResetPinValue){
|
||||
if(resetPinValue == LOW){
|
||||
RFmessage[0] = '9'; // Device will toggle target MCLR when it gets '9'
|
||||
}else{
|
||||
RFmessage[0] = '('; // Device will toggle target MCLR when it gets '('
|
||||
}
|
||||
sendRFmessage = true;
|
||||
lastResetPinValue = resetPinValue;
|
||||
}
|
||||
|
||||
|
||||
8bit DEVICE REMOTE RESET CODE
|
||||
|
||||
boolean testFirstRadioByte(char z){ // test the first byte of a new radio packet for reset msg
|
||||
boolean r;
|
||||
switch(z){
|
||||
case '9': // HOST sends '9' when its GPIO6 goes LOW
|
||||
digitalWrite(resetPin,LOW); // clear RESET pin
|
||||
r = true;
|
||||
break;
|
||||
case '(': // HOST sends '(' when its GPIO6 goes HIGH
|
||||
digitalWrite(resetPin,HIGH); // set RESET pin
|
||||
r = true;
|
||||
break;
|
||||
default:
|
||||
r = false;
|
||||
break;
|
||||
}
|
||||
return r; // this might be useful
|
||||
}
|
||||
|
||||
|
||||
|
||||
###32bit Board
|
||||
|
||||
|
||||
@@ -144,3 +103,49 @@ OpenBCI uses ASCII commands to control the board. Setting up the SD card, changi
|
||||
The most sensitive state of the OpenBCI system is during streaming data mode. During this mode, the 2D linear buffer on the Device RFduino is turned into a 2D ring buffer, and both the Device and Host RFduinos will expect no more than one packet at a time, and that packet is expected to be complete (31 data bytes, 1 sample counter byte). The Device code also employs some error checking: if a packet is not complete (31 bytes of data) in a reasonable time (1000uS) then the packet is thrown out, and a new one is started.
|
||||
|
||||
|
||||
##8bit Board
|
||||
###~~Depricated
|
||||
|
||||
|
||||
The Arduino UNO bootloader runs when the ATmega 'wakes up' from reset. Back in the day the reset signal had to be sent manually by pressing the Arduino reset button. Then some smart folks hijacked the DTR pin (legacy RS232 Handshaking pin) from the FTDI USB<>Serial chip to 'automatically' perform the reset function. We wanted to retain this automatic reset feature, so we are using 'special message' function of our code to pass the reset signal to the OpenBCI Board. With the slide switch on our USB Dongle set to GPIO6, the RFduino Host can 'feel' the polarity of the DTR on its pin 6, and then send a special character to the Device. When the Device gets the special character, it resets the ATmega. That makes it possible to upload code from the Arduino IDE and treat the 8bit Board just as if it were an Arduino UNO.
|
||||
|
||||
|
||||
8bit HOST REMOTE RESET CODE
|
||||
|
||||
resetPinValue = digitalRead(resetPin);
|
||||
if(resetPinValue != lastResetPinValue){
|
||||
if(resetPinValue == LOW){
|
||||
RFmessage[0] = '9'; // Device will toggle target MCLR when it gets '9'
|
||||
}else{
|
||||
RFmessage[0] = '('; // Device will toggle target MCLR when it gets '('
|
||||
}
|
||||
sendRFmessage = true;
|
||||
lastResetPinValue = resetPinValue;
|
||||
}
|
||||
|
||||
|
||||
8bit DEVICE REMOTE RESET CODE
|
||||
|
||||
boolean testFirstRadioByte(char z){ // test the first byte of a new radio packet for reset msg
|
||||
boolean r;
|
||||
switch(z){
|
||||
case '9': // HOST sends '9' when its GPIO6 goes LOW
|
||||
digitalWrite(resetPin,LOW); // clear RESET pin
|
||||
r = true;
|
||||
break;
|
||||
case '(': // HOST sends '(' when its GPIO6 goes HIGH
|
||||
digitalWrite(resetPin,HIGH); // set RESET pin
|
||||
r = true;
|
||||
break;
|
||||
default:
|
||||
r = false;
|
||||
break;
|
||||
}
|
||||
return r; // this might be useful
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
+17
-15
@@ -1,10 +1,10 @@
|
||||
# OpenBCI V3 Data Format
|
||||
# OpenBCI Cyton Data Format
|
||||
|
||||
This discussion of the OpenBCI data format only applies to OpenBCI V3 `v1` (2014-2016) and `v2.0.0` (Fall 2016). For OpenBCI V3, the OpenBCI board contains either a ATmega or ChipKIT microcontroller that can both be programmed through the Arduino IDE. The OpenBCI board has an on-board RFDuino radio module acting as a "Device". The OpenBCI system includes a USB dongle for the PC, which acts as the RFDuino "Host". The format of the OpenBCI data as seen on the PC is defined by a combination of the Arduino code on the OpenBCI board and of the RFDuino code running on the Host. So, if you don't like the data format defined here, feel free to change it!
|
||||
This discussion of the OpenBCI data format only applies to OpenBCI `v1` (2014-2016) and `v2.0.0` (Fall 2016). For OpenBCI Cyton, the OpenBCI board contains either a ChipKIT or ATmega microcontroller that can both be programmed through the Arduino IDE. The Cyton board has an on-board RFDuino radio module acting as a "Device". The Cyton system includes a USB dongle for the PC, which acts as the RFDuino "Host". The format of the OpenBCI data as seen on the PC is defined by a combination of the Arduino code on the Cyton board and of the RFDuino code running on the Host. So, if you don't like the data format defined here, feel free to change it!
|
||||
|
||||
### Proprietary ("RFDuino") vs Standard Bluetooth
|
||||
|
||||
OpenBCI uses RFDuino modules for its Bluetooth wireless connection. To achieve the highest data rates, OpenBCI supplies a RFDuino USB dongle that connects to the computer. When using this USB dongle, higher data rates can be achieved versus using a standard bluetooth 4.n BLE connection.
|
||||
OpenBCI Cyton uses RFDuino modules for its Bluetooth wireless connection. To achieve the highest data rates, OpenBCI supplies a RFDuino USB dongle that connects to the computer. When using this USB dongle, higher data rates can be achieved versus using a standard bluetooth 4.n BLE connection.
|
||||
|
||||
If you prefer to use a standard bluetooth connection (to a mobile phone, for instance), that software and data format has not yet been defined.
|
||||
|
||||
@@ -13,28 +13,30 @@ If you prefer to use a standard bluetooth connection (to a mobile phone, for ins
|
||||
The RFDuino USB dongle (the RFDuino "Host") is connected to an FTDI USB<>Serial converter configured to appear to the computer as if it is a standard serial port running at a rate of 115200 baud using the typical 8-N-1. It is possible to run at faster baud (FT231XQ-R on dongle tested up to 1Mbaud), but 115200 is required if you want to upload code to the target uC.
|
||||
|
||||
### Startup
|
||||
**8bit Board**
|
||||
|
||||
When the serial port for the dongle is opened by your PC, it will reset an 8bit Board. That's because the DTR signal from FTDI is getting sent over air, and the ATmega is configured as an Arduino UNO. You will see the familiar blink of the pin 13 LED. After a second or so, you will see the OpenBCI board generate a few lines of ASCII text displaying the device IDs of the ADS1299 and Accelerometer ending in $$$. If you are writing client software for the PC, your software must expect an ASCII string on startup, and look for the $$$ to know it is ready to receive commands.
|
||||
|
||||
**32bit Board**
|
||||
**Cyton Board**
|
||||
|
||||
The chipKIT on our 32bit Board does not go through a reset cycle when its serial port is opened. Because of this, it's possible to connect to the 32bit board and not know it's state. In this case, the terminal or application should write a **v** to the serial port, which causes the system to reset its state to default values.
|
||||
|
||||
**8bit Board (deprecated)**
|
||||
|
||||
When the serial port for the dongle is opened by your PC, it will reset an 8bit Board. That's because the DTR signal from FTDI is getting sent over air, and the ATmega is configured as an Arduino UNO. You will see the familiar blink of the pin 13 LED. After a second or so, you will see the OpenBCI board generate a few lines of ASCII text displaying the device IDs of the ADS1299 and Accelerometer ending in $$$. If you are writing client software for the PC, your software must expect an ASCII string on startup, and look for the $$$ to know it is ready to receive commands.
|
||||
|
||||
|
||||
|
||||
### Initiating Binary Transfer
|
||||
|
||||
Once the OpenBCI has initialized itself and sent the $$$, it waits for commands. In other words, it sends no data until it is told to start sending data. To begin data transfer, transmit a single ASCII **b**. Once the **b** is received, continuous transfer of OpenBCI data in binary format will ensue. To turn off the fire hose, send an **s**.
|
||||
Once the OpenBCI has initialized itself and sent the $$$, it waits for commands. In other words, it sends no data until it is told to start sending data. To begin data transfer, transmit a single ASCII **b**. Once the **b** is received, continuous transfer of data in binary format will ensue. To turn off the fire hose, send an **s**.
|
||||
|
||||
#### Firmware Version 1.0.0 (2014 to Fall 2016)
|
||||
|
||||
Both the Host and Device radios take notice of the **b** and **s**, and go into or out of streamingMode accordingly. That's right, the radio modules on both the OpenBCI board and the Dongle have two states:
|
||||
|
||||
* **!**streamingData
|
||||
* **!streamingData**
|
||||
* The radios appear to be a transparent UART betweeen the PC and target uC
|
||||
* [Command characters](https://github.com/OpenBCI/Docs/blob/master/software/01-OpenBCI_SDK.md) need some delay before and after sending to pass from PC to target uC
|
||||
* streamingData
|
||||
* **streamingData**
|
||||
* Device radio expects to get 31 bytes in each data packet from the uC
|
||||
* After 1 second of no transmission, or not getting 31 bytes in time, Device and Host will revert to **!**streamingData mode
|
||||
* After 1 second of no transmission, or not getting 31 bytes in time, Device and Host will revert to **!streamingData** mode
|
||||
* Command characters can be sent from PC following timing protocol above
|
||||
|
||||
#### Firmware Version 2.0.0 (Fall 2016 to Now)
|
||||
@@ -120,7 +122,7 @@ UDF stands for User Defined and for a general driver perspective, should be left
|
||||
|
||||
### 24-Bit Signed Data Values
|
||||
|
||||
For the EEG data values, you will note that we are transferring the data as a 24-bit signed integer, which is a bit unusual. We are using this number format because it is the native format used by the ADS1299 chip that is at the core of the OpenBCI board. To convert this unusual number format into a more standard 32-bit signed integer, you can steal some ideas from the example Processing (aka, Java) code:
|
||||
For the EEG data values, you will note that we are transferring the data as a 24-bit signed integer, which is a bit unusual. We are using this number format because it is the native format used by the ADS1299 chip that is at the core of the Cyton board. To convert this unusual number format into a more standard 32-bit signed integer, you can steal some ideas from the example Processing (aka, Java) code:
|
||||
|
||||
int interpret24bitAsInt32(byte[] byteArray) {
|
||||
int newInt = (
|
||||
@@ -168,12 +170,12 @@ For the scale factor, this is the multiplier that you use to convert the EEG val
|
||||
|
||||
Scale Factor (Volts/count) = 4.5 Volts / gain / (2^23 - 1);
|
||||
|
||||
Note that 2^23 might be an unexpected term in this equation considering that the ADS1299 is a 24-bit device. This equation is from the ADS1299 data sheet, specifically it is from the text surrounding Table 7. This scale factor has also been confirmed experimentally using known calibration signals.
|
||||
Note that 2^23 might be an unexpected term in this equation considering that the ADS1299 is a 24-bit device. That's because the 24bit raw count value is in 2's Compliment format. This equation is from the ADS1299 data sheet, specifically it is from the text surrounding Table 7. This scale factor has also been confirmed experimentally using known calibration signals.
|
||||
|
||||
Accelerometer data must also be scaled before it can be correctly interpreted. The equation used to scale Accelerometer data is as follows (We assume 4Gs, so 2mG per digit):
|
||||
|
||||
|
||||
Accelerometer Scale Factor = 0.002 / 2^4
|
||||
Accelerometer Scale Factor = 0.002 / 2^4;
|
||||
|
||||
### 16 Channel Data
|
||||
Our 16 channel system allows for control of individual settings for all 16 channels, and data is retrieved from both ADS1299 IC at a rate of 250SPS. The current bandwith limitations on our serial radio links limit the number of packets we can send. To solve for this, we are sending data packet at the same rate of 250SPS, and alternating sample packets between the on Board ADS1299 and the on Daisy ADS1299. The method takes an average of the current and most recent channel values before sending to the radio. The first sample sent will be invalid because there is no previous sample to average it with. After this, on **odd** sample numbers, the Board ADS1299 values are sent, and on **even** sample numbers, the Daisy ADS1299 samples are sent. When running the system with 16 channels, it is highly recommended that you use an SD card to store the raw (un-averaged) data for post processing.
|
||||
@@ -0,0 +1,32 @@
|
||||
# OpenBCI Cyton Bluetooth
|
||||
|
||||
This discussion of the OpenBCI Bluetooth specifics applies to OpenBCI V3 (2014). For OpenBCI V3, the OpenBCI board contains either a Atmel or ChipKIT microcontroller that can be programmed through the Arduino IDE and Microchip's MPIDE, respectively. The OpenBCI board also contains an RFDuino. There is not currenty firmware support for BLE connection to tablets or phones with Bluetooth 4.n capability. As that changes this doc will be updated.
|
||||
|
||||
### RFDuino In A Nutshell
|
||||
|
||||
OpenBCI Cyton uses RFDuino modules for its Bluetooth wireless connection. RFduinos are built on the Nordic nRF51822 SoC Radio IC. To achieve the highest data rates, OpenBCI supplies a RFDuino USB dongle that connects to the computer. When using this USB dongle, both radios use the RFduinoGZLL library, which is based on Nordic's proprietary high speed Gazelle stack. This is the default configuration of the RFduino firmware, and allows for general serial communication between the PC and the Cyton board, while also supporting OpenBCI streaming data mode, and over-air programming of the Arduino compatible chipKIT or Atmega.
|
||||
|
||||
If you want to get the Cyton Board to communicate to an Android or iOS phone or tablet with Bluetooth 4.n (LE), the RFduinoBLE library must be used. This can present a problem, in that when using BLE it is not possible to upload new firmware to the target chipKIT or ATmega uC. To facilitate firmware development, we have provided a switch on the OpenBCI board to select between PC (RFduinoGZLL) and BLE (RFduinoBLE). In the BLE position, the switch activates a pull-up on GPIO-4 of the RFduino module. The idea here is that the firmware would take note of GPIO-4 during the setup routine, begin either the BLE or GZLL stack, and run the appropriate code.
|
||||
|
||||
**NOTE: this is not implemeted yet! The current Radio Firmware only uses RFduinoGZLL library**
|
||||
|
||||
### RFduino Firmware Update
|
||||
|
||||
Please see the [Radios](link.here) page for notes on changing the firmware on our RFduino modules.
|
||||
|
||||
### Cyton BLE Data Format
|
||||
|
||||
**Cyton BLE Data Format is undefined**. For those interested in defining it, there are some issues that must be taken into account.
|
||||
|
||||
First, the maximum number of bytes per BLE radio packet is 20. This limits the number of channels of raw data that can be sent without down-sampling or compression.
|
||||
|
||||
Second, the data rate is limited. When using RFduinoGZLL, data rates of 130kB/S are theoretically possible. Our OpenBCI Boards sample biosignals at 250SPS and thier serial connection runs at 115200 baud. When using RFduinoBLE, implemnting serial baud rates higher than 9600 is possible, but may lead to issues. The BLE data rate is also alot slower. (We'll post our findings here when we get adequate benchmark results).
|
||||
|
||||
### Android Example
|
||||
|
||||
So far, we have one example in Android that connects to the Cyton Board and creates a .csv file to hold the incoming data. This has only been tested with dummy data.
|
||||
[Android <> OpenBCI Prototype](https://github.com/yasser304/OpenBCI-AndroidApp)
|
||||
|
||||
### iOS Example
|
||||
|
||||
Undefined
|
||||
@@ -1,9 +1,9 @@
|
||||
# OpenBCI Firmware SDK
|
||||
The OpenBCI boards communicate using a byte string (mostly ASCII) command protocol. This Doc covers command use for the OpenBCI 8bit and 32bit boards. Some of the commands are board specific, where noted. Further this Doc covers the commands needed in order to alter the radio system. There have been several iterations of the firmware, the 8bit board runs `v0`, while the 32bit runs `v1` and as of Fall 2016 runs `v2.0.0`.
|
||||
# OpenBCI Cyton SDK
|
||||
The OpenBCI Cyton boards communicate using a byte string (mostly ASCII) command protocol. This Doc covers command use for the OpenBCI Cyton and 8bit boards. Some of the commands are board specific, where noted. Further this Doc covers the commands needed in order to alter the radio system. There have been several iterations of the firmware, the 8bit board runs `v0`, while the Cyton runs `v1` and Boards shipped as of Fall 2016 run `v2.0.0`.
|
||||
|
||||
## OpenBCI Command Protocol Overview
|
||||
## Cyton Command Protocol Overview
|
||||
|
||||
OpenBCI boards have two powerful microcontrollers on board, and come pre-programmed with the firmware. The RFduino radio link uses the Nordic Gazelle stack and library. The Board mounted RFduino is configured as a DEVICE. The microcontroller (ATmega328P or PIC32MX250F128B) has been programmed with firmware that interfaces between the ADS1299 (Analog Front End), LIS3DH (Accelerometer), micro SD (if installed), and RFduino (Radio module). The user, or application, controls the board by sending commands over wireless serial connection. You should have received a Dongle with the OpenBCI board. The Dongle has an RFduino running the Gazelle library configured as a HOST, and interfaces your computer through a Virtual Com Port (FTDI). (See the Radios portion for more info on the RFduino link).
|
||||
Cyton boards have two powerful microcontrollers on board, and come pre-programmed with the firmware. The RFduino radio link uses the Nordic Gazelle stack and library. The Board mounted RFduino is configured as a DEVICE. The microcontroller (PIC32MX250F128B or ATmega328P) has been programmed with firmware that interfaces between the ADS1299 (Analog Front End), LIS3DH (Accelerometer), micro SD (if installed), and RFduino (Radio module). The user, or application, controls the board by sending commands over wireless serial connection. You should have received a Dongle with the OpenBCI board. The Dongle has an RFduino running the Gazelle library configured as a HOST, and interfaces your computer through a Virtual Com Port (FTDI). (See the [Radios](needsLink) portion for more info on the RFduino link).
|
||||
|
||||
On startup, the OpenBCI 8bit board (`v0`) sends the following text over the radio:
|
||||
|
||||
@@ -13,14 +13,14 @@ On startup, the OpenBCI 8bit board (`v0`) sends the following text over the radi
|
||||
LIS3DH Device ID: 0x33
|
||||
$$$
|
||||
|
||||
the OpenBCI 32bit board with firmware `v1` sends the following text over the radio:
|
||||
the OpenBCI Cyton board with firmware `v1` sends the following text over the radio:
|
||||
|
||||
OpenBCI V3 16 channel
|
||||
ADS1299 Device ID: 0x3E
|
||||
LIS3DH Device ID: 0x33
|
||||
$$$
|
||||
|
||||
the OpenBCI 32bit board with firmware `v2.0.0` sends the following text over the radio:
|
||||
the OpenBCI Cyton board with firmware `v2.0.0` sends the following text over the radio:
|
||||
|
||||
OpenBCI V3 8-16 channel
|
||||
ADS1299 Device ID: 0x3E
|
||||
@@ -28,7 +28,7 @@ the OpenBCI 32bit board with firmware `v2.0.0` sends the following text over the
|
||||
Firmware: v2.0.0
|
||||
$$$
|
||||
|
||||
Device ID info is useful for general board health confirmation. The $$$ is clear indication to the controlling application that the message is complete and the OpenBCI board is ready to receive commands. As of `v2.0.0`, there is an additional printout to indicate the exact firmware version.
|
||||
Device ID info is useful for general board health confirmation. The $$$ is clear indication to the controlling application that the message is complete and the Cyton board is ready to receive commands. As of `v2.0.0`, there is an additional printout to indicate the exact firmware version.
|
||||
|
||||
Pay attention to timing when sending commands when using `v0` and `v1` firmware. There must be some delay before and after sending a command character from the PC (controlling program or user running a terminal). As of `v2.0.0`, this is no longer the case, send as fast as you can!
|
||||
|
||||
@@ -43,7 +43,7 @@ These ASCII characters turn the respective channels [1-8] on. The channel will r
|
||||
|
||||
###Test Signal Control Commands
|
||||
**0 - = p [ ]**
|
||||
Turn **all** available channels on, and connect them to internal test signal. These are useful for self test and calibration. For example, you can measure the internal noise by sending **0** and connecting all inputs to internal GND.
|
||||
Turn **all** available channels on, and connect them to internal test signal. These are useful for self test and calibration. For example, you can measure the internal noise by sending **0** which connects all inputs to an internal GND.
|
||||
|
||||
* **0** Connect to internal GND (VDD - VSS)
|
||||
* **-** Connect to test signal 1xAmplitude, slow pulse
|
||||
@@ -52,7 +52,7 @@ Turn **all** available channels on, and connect them to internal test signal. Th
|
||||
* **[** Connect to test signal 2xAmplitude, slow pulse
|
||||
* **]** Connect to test signal 2xAmplitude, fast pulse
|
||||
|
||||
**Note: Not all of the internal test connections are implemented here **
|
||||
**Note: Not all possibl internal test connections are implemented here **
|
||||
|
||||
###Channel Setting Commands
|
||||
** x (CHANNEL, POWER_DOWN, GAIN_SET, INPUT_TYPE_SET, BIAS_SET, SRB2_SET, SRB1_SET) X **
|
||||
@@ -177,11 +177,12 @@ Read and report all register settings for the ADS1299 and the LIS3DH. Expect to
|
||||
|
||||
**v**
|
||||
|
||||
Soft reset for the Board peripherals. The 8bit board gets a reset signal from the Dongle any time an application opens the serial port, just like a arduino. the 32bit board doesn't have this feature. So, if you want to soft-reset the 32bit board (`v1` or `v2.0.0`), send it a **v**.
|
||||
Soft reset for the Board peripherals
|
||||
The 8bit board gets a reset signal from the Dongle any time an application opens the serial port, just like a arduino. the Cyton board doesn't have this feature. So, if you want to soft-reset the Cyton board (`v1` or `v2.0.0`), send it a **v**.
|
||||
|
||||
|
||||
##16 Channel Commands
|
||||
Currently, the Daisy Module is implemented only on the 32bit board. The Daisy Module adds 8 more input channels for a total of 16. These are the commands specific to controlling the ADS1299 on the Daisy Module.
|
||||
Currently, the Daisy Module is implemented only on the Cyton board. The Daisy Module adds 8 more input channels for a total of 16. These are the commands specific to controlling the ADS1299 on the Daisy Module.
|
||||
|
||||
###Turn Channels OFF
|
||||
**q w e r t y u i**
|
||||
@@ -201,7 +202,7 @@ Use 8 channels only. If the Daisy Module is attached, it will be unattached, and
|
||||
|
||||
Use 16 channels.
|
||||
|
||||
*Note: On reset, the OpenBCI 32bit board will 'sniff' for the Daisy Module, and if it is present, it will default to 16 channel capability.*
|
||||
*Note: On reset, the OpenBCI Cyton board will 'sniff' for the Daisy Module, and if it is present, it will default to 16 channel capability.*
|
||||
|
||||
#Firmware v2.0.0 New Commands
|
||||
|
||||
@@ -217,7 +218,7 @@ Stops time stamping. If the Board is not streaming, then expect a response of `T
|
||||
|
||||
|
||||
## Radio Configuration Commands
|
||||
As of firmware version `v2.0.0`, a set of commands has been implemented to change the radio system and improve over-the-air programming of the main OpenBCI board.
|
||||
As of firmware version `v2.0.0`, a set of commands has been implemented to change the radio system and improve over-the-air programming of the main Cyton board.
|
||||
In order to use the commands you must keep to the form of **key**-**code**-**(payload)** where **key** is`0xF0`, **code** is defined below and **payload** is optional and dependent on the **code**. For example, to get system status send `0xF0` then send `0x07`.
|
||||
|
||||
####Get Channel Number `0x00`
|
||||
@@ -255,7 +256,7 @@ Returns success or failure. On failure it will send a "system is down" message.
|
||||
|
||||
|
||||
##Unused ASCII Characters
|
||||
These are currently unused characters across the OpenBCI platforms:
|
||||
These are currently unused (and user available) characters in the OpenBCI Cyton platform:
|
||||
|
||||
|
||||
**~ ` 9 ( ) _ { } o O f g h k l ; : ' " V n N M , . / (space)**
|
||||
@@ -1,32 +0,0 @@
|
||||
# OpenBCI V3 Bluetooth
|
||||
|
||||
This discussion of the OpenBCI Bluetooth specifics applies to OpenBCI V3 (2014). For OpenBCI V3, the OpenBCI board contains either a Atmel or ChipKIT microcontroller that can be programmed through the Arduino IDE and Microchip's MPIDE, respectively. The OpenBCI board also contains an RFDuino. There is not currenty firmware support for BLE connection to tablets or phones with Bluetooth 4.n capability. As that changes this doc will be updated.
|
||||
|
||||
### RFDuino In A Nutshell
|
||||
|
||||
OpenBCI uses RFDuino modules for its Bluetooth wireless connection. RFduinos are built on the Nordic nRF51822 SoC Radio IC. To achieve the highest data rates, OpenBCI supplies a RFDuino USB dongle that connects to the computer. When using this USB dongle, both radios use the RFduinoGZLL library, which is based on Nordic's proprietary high speed Gazelle stack. This is the default configuration of the RFduino firmware, and allows for general serial communication between the PC and the OpenBCI board, while also supporting OpenBCI streaming data mode, and over-air programming of the Arduino compatible Atmega or chipKIT.
|
||||
|
||||
If you want to get the OpenBCI Board to communicate to an Android or iOS phone or tablet with Bluetooth 4.n (LE), the RFduinoBLE library must be used. This can present a problem, in that when using BLE it is not possible to upload new firmware to the target ATmega or chipKIT uC. To facilitate firmware development, we have provided a switch on the OpenBCI board to select between PC (RFduinoGZLL) and BLE (RFduinoBLE). In the BLE position, the switch activates a pull-up on GPIO-4 of the RFduino module. The idea here is that the firmware would take note of GPIO-4 during the setup routine, begin either the BLE or GZLL stack, and run the appropriate code.
|
||||
|
||||
**NOTE: this is not implemeted yet! The current Radio Firmware only uses RFduinoGZLL library**
|
||||
|
||||
### RFduino Firmware Update
|
||||
|
||||
Please see the [Radios](link.here) page for notes on changing the firmware on our RFduino modules.
|
||||
|
||||
### BLE Data Format
|
||||
|
||||
**OpenBCI BLE Data Format is undefined**. For those interested in defining it, there are some issues that must be taken into account.
|
||||
|
||||
First, the maximum number of bytes per radio packet is 20. This limits the number of channels of raw data that can be sent without down-sampling or compression.
|
||||
|
||||
Second, the data rate is limited. When using RFduinoGZLL, data rates of 130kB/S are theoretically possible. Our OpenBCI Boards sample biosignals at 250SPS and thier serial connection runs at 115200 baud. When using RFduinoBLE, implemnting serial baud rates higher than 9600 is possible, but may lead to issues. The BLE data rate is also alot slower. (We'll post our findings here when we get adequate benchmark results).
|
||||
|
||||
### Android Example
|
||||
|
||||
So far, we have one example in Android that connects to OpenBCI and creates a .csv file to hold the incoming data. This has only been tested with dummy data.
|
||||
[Android <> OpenBCI Prototype](https://github.com/yasser304/OpenBCI-AndroidApp)
|
||||
|
||||
### iOS Example
|
||||
|
||||
Undefined
|
||||
Referência em uma Nova Issue
Bloquear um usuário