Neuro spaghetti

I have bought a USB GSM modem from RF online a UK distributor of several RF products.

This interesting GSM modem is manufactured by Hametech, a Shenzen based company.

It is a very interesting module and the software drivers are included in the disk partition.

Most importantly it is supported by the linux kernel until version 2.4.32.

Now guess what?

On my latest Kubuntu 10.04 LTS it doesn’t work, so this is what I did to solve the problem.

This is my configuration:

Linux epokh-quad 2.6.32-27-generic #49-Ubuntu SMP Wed Dec 1 23:52:12 UTC 2010 i686 GNU/Linux
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 10.04.1 LTS
Release:        10.04
Codename:       lucid

Hello guys,

I did an adapter board to interface an xbee digi module which operates with 3.3TTL logic to a polulu 3pi robot which operates with a 5V TTL logic.

I need it because I have to compute some information theoretic measures in real time from the robot while performing the task for my Phd research aim.

The xbee adapter contains a small LDO regulator which step down the voltage from the Vcc of the pololu to the Vcc of the xbee. A simple resistor partition on the RX pin of the Xbee converts 5V ttl from PD1 to 3.3V ttl. There is no partitor between the xbee TX and the RX PD0 port of the pololu.

So in summary the dummy schematic is:

Pololu —————- Xbee

Vcc —– LDO ——– Vcc

PD1 —– resistor —–RX

PD0 —————–TX

In this demo I’m using bidirectional communication as proofed in the pololu serial demo code.

Xbee interface to pololu 3pi test from Robomotic on Vimeo.

I input the commands from terminal window from the PC and the pololu interprets the commands by playing 2 tones and turning on/off the red and green led.

If I press the center button on the pololu it will send an “hello ” string to my terminal window.

Pretty basic but it serves my purpose of logging senory-motor data in real time.
The git repository is available here:

git@github.com:robomotic/Xbee-Pololu-3pi.git

Cheerssss.

I’ve just got a brilliant idea. Modify the S006 Alloy Shark produced by Syma, an indoor RC helicopter which operates in the 27MHz NA range with 3 channels with an ezChronos 430.

The ezChronos 430 provides a 3 axis accelerometer, temperature and pressure sensor. The pressure sensor can be used as an altitude estimator, so what I’m thinking is simply to get the altitude reading and see how high this toy can fly.

Ideally one could you use the sensor reading to control the asset and to limit the height but using an FM PPM radio controller is not the best solution to be interfaced with a controller, so at the moment I just want to stick to a simple “read-only” configuration.

I have some other toys which operates in IR and in that case I will be able to do something from a controller.

This is the video of the helicopter:

To be fair is not the best helicopter in that price range, but it was a gift so I couldn’t really change it.

Anyway, I have noticed that there’s some useful space in the front chassis so I have decided to open it and try to fit an ez430 chronos inside.

This is the helicopter opened:

And then the chronos inside:

Nice:

Now the main problem to get the altitude reading is that I cannot press the button of the ezChronos to start the wireless communication so I have to tweak the open chronos firmware to give me a continuous communication with an interrupt.
The idea is that the ezChronos will wake up every 1 second (with an interrupt) to check if the base station is available to receive data and then eventually start the telemetry function.

In the next article I will talk about the software module.
Stay tuneeeeeeeed!

Heyo guys,

this is my last ultimate hack for the mindflex. I wanted to reproduced the results of the mindflex as indicated by the manufacturer.The simplest test that can be done with an EEG device is to check if the alpha waves go up significantly when closing your eyes.

However doing some test with different subjects (i.e. my guinea pig students/friends) and with or without electrogel I couldn’t find any prove that the neurosky chip is working properly.
I will be happy if somebody can reproduce a high alpha activity with closed eyes.
I could only see some random peaks in the alpha activity during closed eyes which were not stable.
So here the instructions for 2 configurations that can be used to log the data and save it to a CSV file.

So you take out of the shell 3 wires: black is the GND, blue is the Vcc=3.3V and white is the TTL signal at 9600 bauds.
I made 2 possible configurations one which uses a BUB board (based on the FT232 chip) to read the EEG raw data

stream directly to the computer and one which uses a xbee transmitter and an xbee receiver.

As I said before I totally desoldered the original radio modem that was on the main board inside, as in Figure.

What can I do with that? I have no idea! :-p

Serial configuration

The first configuration is the most dangerous one since you are connected to your
computer via the usb without any opto-isolation so DO IT AT YOUR OWN RISK.

Make sure you put the jumper of the BUB board over the 3.3 V level,
the black wires goes to GND, the white wire goes to the RX pin and the blue wire is not required because we don’t need the 3.3 Vdd, so I just put it on an unused pin of the bub board.

XBee configuration

The second configuration is more interesting because uses a pair of xbee modules to send the eeg data over the air, thus avoiding electrocuting yourself for some hardware faults.

The xbee connected to the MindFlex should be configured in this mode:

• ZNET 2.5 ROUTER/END DEVICE AT
• PAN ID 1AAA as the one in the Xbee host receiver
• DH-DL as the SH SL of the Xbee host receiver
• PL power level: 2 MEDIUM
• SERIAL INTERFACING is the most important:
• Set the BAUD Rate to 9600 with NP no parity

• ZNET 2.5 COORDINATOR AT
• PAN ID 1AAA as Xbee sender
• SERIAL INTERFACING is the most important:
• Set the BAUD Rate to 9600 with NP no parity

This is the final integration, I used an Xbee breakout board and drilled a raw of holes to fit the pins.

Now the next thing is to parse the data coming from the serial port,

to do so we use a software coded by EricMika and Spiffomatic.

The code is written for the Processing environment and I have compiled

and put the source codes in the zip file provided.

This is my stable alpha activity during opened eyes which doesn’t differ much from the closed eyes condition!

Wave exporter

The export saves in CSV format.
For the open eye condition: UP arrow start recording, DOWN arrow stop recording
For the closed eye condition: LEFT arrow start recording, RIGHT arrow stop recording
File are saved in the same folder, you can then import them in Matlab and plot.

Conclusion

The opened and closed eye condition does not discriminate in the alpha band.
Elettrogel does not improve the condition.
Even flipping the MindFlex so that the electrode is touching your backhead (close to the visual cortex) does not improve the discrimination.
The problem of all consumer EEGs is the connection between scalp and amplifier. When measuring EEG in the lab there is quite a lot of effort going into making proper contact with each and every electrode each and every time by measuring impedance and carefully preparing each electrode.

The problem with EEG in general is the inherently bad SNR. If you have no properly connected (Ag/AgCl) electrodes, you’re not gonna get reliable signals, period. The voltage is so small, the DC polarization alone you get with mindflex electrodes might be several hundred times the signal and probably contains huge amounts of AC noise, too.

However I expected something more from the Neurosky guys because their marketing in terms of benchmarking is quite aggressive …. There’s is something going on in the toy but is not really really stable!

If you don’t trust me you can do the following, download these 2 CSV files containing the condition with opened eyes and closed eyes and try to determine which number is the open and which one is the closed.

• EEG log 1
• EEG log 2

The best thing I could get off the mindflex was this run where, yes there are spikes of alpha activities but they are not stable considering I had my eyes closed all the time!

I have produced the graph by using a simple matlab script:

% After importing plots the eeg bands

function plotbands(data1,data2)

tstamp=data1(:,1)./1000;

signalquality=data1(:,2);

attention=data1(:,3);

meditation=data1(:,4);

delta=data1(:,5);

theta=data1(:,6);

lowalpha=data1(:,7);

highalpha=data1(:,8);

lowbeta=data1(:,9);

highbeta=data1(:,10);

lowgamma=data1(:,11);

highgamma=data1(:,12);

hold on

plot(lowalpha,’LineWidth’,2,’Color’,'red’);

plot(data2(:,7),’LineWidth’,2,’Color’,'black’);

xlabel(’Sample’);

ylabel(’EEG value’);

legend(’Closed’,'Open’);

title(’Low Alpha wave comparison’);

end

Download the software Procesing Brain Grapher

Some cool pictures during my tests:

I realised the xbee pops out of the enclosure.

So my next attempt will be to drill 3 holes for the wires and put in on the outside of the case.

It’s more complicate than expected! But is good work!

Inspired by the work of Arturo Vidich, Sofy Yuditskaya at EricMika.com,

I decided to interface an XBee Series 2.5 from DigiMark without using an external Arduino or MegaDuino which is bulky and technically unsafe for the missing opto-isolation interface between the electrodes and the main voltage.

Anyway! The interface is very simple: 3 wires.

The T pin on the daughter (neurosky chip) board is the TX (blue wire), the V pin (red wire) is the supply voltage 3.3V regulated from the batteries and the ground pin is either at the negative pole of the edge (black wire under the main board) or also at the right of the V pin.

I would suggest to solder on the - pole under the board because you can easily short circuit the V pin withe the GND pin which are only few millimeters apart.

I checked out with the oscilloscope and the V is a low ripple DC at 3.3 V which can be used to power up the XBee.

So the V pin goes into the pin #1 of the zigbee, the T pin goes to the pin #3 of the xbee (DIN) and the ground pin goes to the pin 10 of the zigbee.

Pictures follows.

The Xbee must be configured in AT mode to rely the incoming serial transmission at 9600 bps into the node coordinator.

Another xbee connected to the pc via the usb explorer simply receives the data in AT mode.

The processing library developed by Eric Mika can be used to decode and show the data.

This video (very poor quality sorry guys) shows a dump of the first successful attempt, I didn’t have time to make a decent video yet.

The next great thing to do is to desolder the RF module on the board and see if the the neurosky chip will still send the raw data even if the RF module does not answer.

I also tried out a LIPO battery of 3.7 V @1100 mAh and it works great, it can also fit inside the battery pack.

I will post the pictures relative to the battery when I have time, I’m slaking off my official work!

I’m doing a feasibility study for tracking objects and persons in terms of range and motion.
The first prototype is based on 2 nodes:
an arduino with an xbee shield and a speaker.
a xbee 2.5 series 2mW antenna + ADXL335 + power supply + signal filters.

The 2 prototypes uses the zigbee API mode to communicate and check if they are moving away from each other. They measure the signal power as well as the motion to estimate the direction.
An xbee explorer works as an internet gateway if connected via usb to an host pc.

The relationship between RSSI and feet in open space can be interpolated using statistic sampling.
Somebody did it already and this is the curve.

RSSI vs Feet

The second prototype is based on 2 nordic keyfobs and 1 usb interface.
The only problem I encountered with the nRF24L01 chips is that the value for the RSSI is binary: 1 bit to detect either an RSSI under -64dBm or an RSSI over -64dBm.

They are provided with 3 tilt sensors for inclination (max 15 degree) to consume less power (4uA average current) and can be connected to the internet as well with the serial usb interface.

Detection Angle:15°
Max Contact Current:0.25A
Contact Resistance:30ohm
External Diameter:4.7mm
External Length / Height:10.2mm

This is an experimental setup to control a prosthetic leg built with the Lego NXT.

The leg is planar and has 2 degree of freedom, one for the knee and one for the ankle.

There are 3 sensors: a gyroscope at the thigh, an ultrasonic sensor at the hip level and contact sensor at the foot tip.

The gyroscope is used to measure the angular speed of the extension/flexion of the thigh and can be integrated to estimate the absolute angle of the thigh with the ground. The contact measures if the foot has touched something. The ultrasonic sensor measures the distance of the hip to the ground when the leg is extended.

The lego NXT has 2 powerful servomotor which can control the knee and ankle orientation.

The human operator position of the knee and ankle is tracked by using 2 accelerometers placed at the proper positions.

The 3-axis accelerometers are wireless connected to the PC (I’m using the ZStar kit) which runs a C# environment. The host program receive the filtered readings from the sensors and then sends the angular positions to the program running on the NXT via bluetooth.

I used the NXT Osek real time environment on the NXT brick for trajectory planning.

The control system receives angular position and speed from the human operator and using a PID control setup the angular position and speed on the artificial leg.

This video shows some preliminary test with PID control on position but not speed.

I’m working also on a prototype with sEMG (surface EMG) using a USB-DUX with a bio-amplifier.

Here is the first test I did for the left leg hyperextension in sitting position.

Duration of 20 seconds and 3 repetition (the last one is discarded) with a wireless Freescale MMA7361L at 30 Hertz sampling rate with 1.5 g scale.

For slow movements where the peak of extension is reached after about 1 second from relax to extension we have an angle of 47 degree which I manage to keep for 2 seconds.

Previous studies such as (3D joint rotation measurement using MEMs inertial sensors: Application to the knee joint) reports an angle a ROM of 51 degrees but they used a 9DOF unit and some advanced compensation/calibration techniques.

For a digital accelerometer I would say is not too bad!

Here are some pictures of the positioning of the sensors. Only the knee one was used in the test.

NemoSport prototype is finally working and doing some good analysis on sport performance!

NemoSport intro!