github.com / OpenBCI_Python

edited February 2015 in Software
Sorry if there is already a question on this, I didn't see one, thus...

After attempting to run the Python code user.py (which has now been updated and runs a little better, thank you), I get an error about not being able to stream data because there is no SD card installed. Indeed, I was hoping to just stream the data into my computer and process from there without needed an SD card on the board.  Is an SD card required to even stream data to the dongle and out of the serial port of my computer?   

Seems odd to me.

-Cere

Comments

  • edited December 2014
    Hi Cere,

    You should definitely not need an SD card to stream. Which board are you using? Do you get the same error when running test.py? (also in github)

    I'm literally getting on a plane right now but in 24 hours I'll be available again.

    Bests,
    Rodrigo
  • Thanks for the reply Rodrigo.  

    Unfortunately, the test.py code does not seem to working for some reason, it just sort of stalls out.  It would be great to figure out some sort of socat script to allow for "peaking" into the tty.usb stream and being able to send that data directly for debugging.   Maybe I'll work on that in the future...

    Here's the Python output from user.py:
    *****
    Serial established...
    -------------------
    OpenBCI V3 32bit Board
    Setting ADS1299 Channel Values
    ADS1299 OpenBCI V3 32bit Board
    Setting ADS1299 Channel Values
    ADS1299 Device ID: 0x0
    LIS3DH Device ID: 0x0
    $$$
    -------------------

    User serial interface enabled...
    View command map at http://docs.openbci.com.
    Type start to run. Type exit to exit.

    --> start
    updating channel settings to default

    --> start

    --> start

    --> ^[[A

    --> start       
    initialization failed. Things to check:
    * is a card is inserted?
    Could not find FAT16/FAT32 partition. Make sure you've formatted the card
    ****

    Anyhow, I see from grepping this code that these messages only seem to come from .pde (processing) code.  

    OpenBCI_32_Library/SD/examples/CardInfo/CardInfo.pde:    Serial.println("Could not find FAT16/FAT32 partition.\nMake sure you've formatted the card");
    OpenBCI_32bit_SD/SD_stuff.pde:      Serial0.println("Could not find FAT16/FAT32 partition. Make sure you've formatted the card");

    Are we running processing code from the OpenBCI board to stream the data??  Seems nuts to do it that way but that's the only explanation that makes sense to me at the moment for why I would get these errors from using the Python code.   


  • What happens when you send the question mark command? (-->?)

    Also try giving the board more time to initialize. After connecting the board, it should output how much free ram it has. Try hitting enter on the prompt until you get that info and then send some commands. There are some delays in the code ment to give the board time, but perhaps they are not enough.

    You are right, the code should NOT be calling any processing code at all. I'll look into this when I arrive.

    Bests from Lima airport!
    Rodrigo
  • Hey Rodrigo,

    This forum software is very frustrating because it wont allow me to post much of the results from the ?
     command.  Here's the top section of what I can post:

    Serial established...
    -------------------
    OpenBCI V3 32bit Board
    Setting ADS1299 Channel Values
    ADS1299 Device ID: 0x3E
    LIS3DH Device ID: 0x33
    $$$
    -------------------

    User serial interface enabled...
    View command map at http://docs.openbci.com.
    Type start to run. Type exit to exit.

    --> ?
    updating channel settings to default

    --> ?
    ID, 0x00, 0x3E, 0, 0, 1, 1, 1, 1, 1, 0
    CONFIG1, 0x01, 0x96, 1, 0, 0, 1, 0, 1, 1, 0
    CONFIG2, 0x02, 0xC0, 1, 1, 0, 0, 0, 0, 0, 0
    CONFIG3, 0x03, 0xEC, 1, 1, 1, 0, 1, 1, 0, 0
    LOFF, 0x04, 0x02, 0, 0, 0, 0, 0, 0, 1, 0
    CH1SET, 0x05, 0x68, 0, 1, 1, 0, 1, 0, 0, 0
    CH2SET, 0x06, 0x68, 0, 1, 1, 0, 1, 0, 0, 0
    CH3SET, 0x07, 0x68, 0, 1, 1, 0, 1, 0, 0, 0
    CH4SET, 0x08, 0x68, 0, 1, 1, 0, 1, 0, 0, 0
    CH5SET, 0x09, 0x68, 0, 1, 1, 0, 1, 0, 0, 0
    CH6SET, 0x0A, 0x68, 0, 1, 1, 0, 1, 0, 0, 0
    CH7SET, 0x0B, 0x68, 0, 1, 1, 0, 1, 0, 0, 0
    CH8SET, 0x0C, 0x68, 0, 1, 1, 0, 1, 0, 0, 0
    BIAS_SENSP, 0x0D, 0xFF, 1, 1, 1, 1, 1, 1, 1, 1
    BIAS_SENSN, 0x0E, 0xFF, 1, 1, 1, 1, 1, 1, 1, 1
    LOFF_SENSP, 0x0F, 0x00, 0, 0, 0, 0, 0, 0, 0, 0
    LOFF_SENSN, 0x10, 0x00, 0, 0, 0, 0, 0, 0, 0, 0
    LOFF_FLIP, 0x11, 0x00, 0, 0, 0, 0, 0, 0, 0, 0
    LOFF_STATP, 0x12, 0x00, 0, 0, 0, 0, 0, 0, 0, 0
    LOFF_STATN, 0x13, 0x00, 0, 0, 0, 0, 0, 0, 0, 0
    GPIO, 0x14, 0x0F, 0, 0, 0, 0, 1, 1, 1, 1
    MISC1, 0x15, 0x00, 0, 0, 0, 0, 0, 0, 0, 0
    MISC2, 0x16, 0x00, 0, 0, 0, 0, 0, 0, 0, 0
    CONFIG4, 0x17, 0x00, 0, 0, 0, 0, 0, 0, 0, 0
    0x07 0



  • Hey Rodrigo,

    A little more info...

    When I run the test.py program without arguments or further commands, I just see the TXD light blink at varying rates but no data shows up on my screen.  Similarly, with user.py there are some cases where the board does seem to be "working" and perhaps gathering data somehow, as evidence by the fact that I do not get a return prompt, but then I never get a return prompt, can't get out of the program, and eventually my computer crashes...  ;(
  • Your register settings look fine (from the part you could post).

    I think I know what the SD error was. The latest commit for the user.py has a start command (-->/start) not (-->start) . The reason is that I enabled the command line to take multiple characters as arguments so that you could make commands like (-->x3020000X). 
    Where "x" enters Channel Settings mode. Channel 3 is set up to be powered up, with gain of 2, normal input, removed from BIAS generation, removed from SRB2, removed from SRB1. The final ‘X’ latches the settings to the ADS1299 channel settings register." -Docs

    This new way to read inputs meant that when you typed start, it first sent the "s"  command which is used to stop binary streaming. The "S" command is tied to the SD, so that typing Start would have tried to set a SD logging time of 15 minutes and then do other non-sense. (although your code shows you wrote "s" so I'm still a bit confused as to why it produced and SD error.)

    I'm really sorry I didn't catch that from code. I was responding on my phone and it was a mess. 
    The reamme does say you should use /start.

    Something I have found while working with the boards is that the order of connecting and turning them on is sometimes important. Try powering everything off and first connecting the dongle, a blue light (D6) should light up and stay lit on the dongle board. If it isn't, disconnect and re-connect. Then turn on the board. 

    The blinking TXD lights probably means it is transmitting. Are you sure you are using the latest code in the repo? It looks like you might be running a test version that runs csv_collect.py. In that case, a collect.csv file should have been generated with the data coming from the board.

    So to summarize: Make sure you are using the latest version of the code. Try connecting the board in the way I described above. Then run the code using "-->/start".

    Let me know if any of that works.

    And again, sorry about missing the start command prompt error. 
  • An aside about .pde files: Older versions of the Arduino IDE also used this extension, so some of this is code that runs on the device, although it's not Processing.

    (I hear newer versions use the extension .ino.)
  • I seem to be having some trouble with Python on my osx system re: printing stuff out from the serial port, I suspect.  More info when I have some.  

    Also, re: the .ino stuff.  Seems like currently we are still working off of the .pde files since that's the only place where the error msg seems to come from AFAICT.

    Thanks.
  • Heya 

    Just a quick post to say that the Python code user.py and test.py still don't print any data to my screen.  The data is clearly being collected as I can see by the lights blinking on the board, but for some reason the data just doesn't print out.  I focus on the "print out" issue because I tried running this python code from another machine (10.6 OSX via terminal program) and saw that test.py would produce blank return lines but still no visible data output to stdout.  I have my terminal black/white contrast reversed on my terminal so that black is the background and white is the print, but I can't believe that Python code would be affected by something like that... a termcap setting.  Basic print statements from python work fine, just not the stuff that comes from the callback.  Anybody got ideas?
  • Has the code generated a file in your working directory called collect.csv? 
  • I am trying to use the Python code (https://github.com/OpenBCI/OpenBCI_Python). I am following the instructions for user.py, but am unable to stop the stream using the 's' command as explained in the tutorial (http://docs.openbci.com/software/01-OpenBCI_SDK). I must abruptly end the script, but when I try to run it again, it fails because the stream timed out. The only way I've been able to get around this is by turning my board off and on again. Is there another way?  
  • wjcroftwjcroft Mount Shasta, CA
    Afazocar,

    Rceballos98roman3017 are some of the dev's working on that repository.

    keturn is developing,


    I was wondering if any of these developers could give us a "State of the Union" as far as Python goes.  :-)

    William

  • Hello,

    Lately I've been toying with the (very practical) OpenBCI_Python scripts in order to stream data to OpenViBE. I've fixed a couple things on the way, added 16 channels capability, and while I tried to make proper pull request along each functionality in order facilitate a proper repo under OpenBCI patronage, it's getting difficult to backport every change. As a matter I have a "dev" branch, inside there's an OSC streamer, and I don't plan to make a separate patch. Now it'll be easier to just merge my whole branch to master.

    The question is: is there an "official" python maintainer to talk to? I know my python code is not clean, (comments format, architecture, inclusion, etc.), and I'd be willing to follow advice in order to rework it the right way and have a seamless integration --I'm absolutely not a python guru :D

    Ideally we should have one modular and flexible collection of python scripts. I just saw strong relations between  my code and "OpenBCI_Node" repo... which is also a fork. It's getting fragmented already :D There's also some people working on plots. I envision kind of a replica of Processing GUI, but with graphical interface / plot / configuration that could be separately activated + streaming capability so it could serve as an interface between OpenBCI and the outside world (a "software driver"??). I don't know if it makes sense...

    Waiting for your opinion ;)
  • Hi Jeffrey,

    I'm not a python guru myself but so far I've been managing the python scripts for Open_BCI. I'm sorry I haven't managed the pull requests yet. I've been involved in another project but will get back into this tomorrow. 

    You're right to point out the fragmentation problem, this is my first time managing github repos and any advice is definitely welcome!

    Yes, a python driver would definitely be a goal to work towards. 
    As to the organization of such code, well that's the question right hahaha. The way I was thinking this could work is to have a main open_bci.py script that's lightweight and dedicated to managing the serial connection with the board. Because of the callback architecture, people can then create scripts and functions like you have done that can be added to the repo. Eventually, we could make a proper library that collects all these scripts into a coherent block, but I don't know if the code is mature enough to do that right now. 

    Please don't hesitate to contact me regarding any questions or ideas you might have!
  • edited February 2015
    Hello,

    As said in my PM, I understand perfectly that people have other things to deal with, no problem with the delay ;)

    Keeping open_bci.py light seems a good idea to me. I think the major problem would be to have a "user.py" that does not increase with each new "module". It's a good entry point to launch and manage those modules, but although it's simpler than having to re-code a user interface each time, if we have to import new .py and add new flag with each new addition, soon it'll get big and need many dependencies (eg, pyosc).. Something like an auto-discovery system that automatically loads additional modules from a "contrib" folder? Those module would expose a callback function, a descriptive field and ID + options for the CLI. I have yet to learn how to setup a generic interface with python...

    Also I guess it would be nice to launch make separate thread with each module, so we could stream / plot / configure on the fly OpenBCI at the same time.
  • I see what you mean. I wrote user.py to be kind of a tester for new functions, but I see how it would be useful to have it recognize functions automatically and be a platform to start things from. Do you know how to make this contrib automatic folder? I don't think I know how to implement that.

    I'm sure you can you ask python to import all files in a directory with a relative path? But then how would you make the code understand user commands to execute its functions? It would have to generate names for all the function it imported and keep track of what module had which functions, so that one a user types /my_function it correctly sets the callback function to my_function. Then, what if those functions require arguments themselves. How would we pass them down? Have you done anything of the sort?

    It seems like having people use the python interpreter would have almost the same results. People could import their libraries, make an open_bci object and then give it their function to execute with any arguments that it needs.

    I also like your rate function a lot, and was thinking that since it's a really important aspect of the communication, we could incorporate it into the open_bci_v3 main code. There, it would be very easy to time arriving packets and keep an updated transmission rate that could be accessed by outside functions.  What do you think about this?

    I didn't have my daisy module at work with me so give me a few days to get it so I can run the 16 channel code you wrote.
  • I coined what we need: a plugin system! There's different possible solutions, I will toy on my dev branch.

    Integration of sampling rate into open_bci_v3: I'm not sure, it could be the first step toward a bloatware :D It could also be troublesome to combine blocking calls (read serial port) with a parallel thread. I think it'd be better to just combine several callbacks at the same time. It would fit well with plugins.
  • In one word: done

    I made yet another pull request (sorry :D). I think it's a good shot: I used yapsy to implement a plugin system. With that it's very easy to add or remove features, to select those via user.py and... to trigger several plugins at the same time. See code and README (or even logs to see how trivial it is to convert current code to plugins), I think it's self-explanatory.

    I did not translate your code related to UDP and Node yet -- I wasn't sure how you'd use it -- for the moment it's moved to the "scripts" folder.

    There's still some cleanup to do, maybe change some names, and see if it's easier to directly integrate yapsy (deb package available for ubuntu, but windows ??).
  • I just saw you merged everything, thanks :)

    ...I also saw some errors in the README, would it be possible to somehow gain access to the main repo so that I could directly fix such minor things without going through pull request -- it may also save you some management time in the future ;)
  • This is awesome!
    First time I've heard of yapsy, and it looks great. Can't wait to try it out. 
    This is so simple! Awesome work.

    The Node code is a joint project with a couple of webdevs that should soon begin to work on their end of things, but also long as the server works and sends the packets as jsons it shouldn't matter. I'll make it into a plugin as soon as I get a chance.
Sign In or Register to comment.