openbci-archive/OpenBCI_NodeJS

ADD Command Line Interface

Opened this issue · 5 comments

Would be nice if this allowed us to use the command line interface

I began this last month at https://github.com/baffo32/OpenBCI_NodeJS/tree/cli but it depends on #82 , so my focus now is finishing #82 .

$ ./openbci --help

  Usage: openbci [options] [command]


  Commands:

    autoFindOpenBCIBoard              Automatically find an OpenBCI board
    softReset                         Attempt to reset the board
    channelOff <channelNumber>        Turn off a specified channel (1-16)
    channelOn <channelNumber>         Turn on a specified channel (1-16)
    channelSet [options] <channel>    Set a channel's settings (1-16)
    channelGet <channelNumber>        Get a channel's settings (1-8)
    listPorts                         List available ports to choose a device
    numberOfChannels                  Convert options to channel count
    printRegisterSettings             Prints all register settings
    radioBaudRateSet <speed>          Set the dongle baud rate (default|fast)
    radioChanGet                      Query the system for its radio channel
    radioChanSet [options] <channel>  Set the system radio channel (1-25)
    radioPollTimeGet                  Query device for its poll time
    radioPollTimeSet <time>           Set the OpenBCI poll time (0-255)
    radioSystemStatusGet              Ask if both radios are up
    sampleRate                        Convert options to sample rate
    sdStart <duration>                Start logging to the SD card
        (14sec|5min|15min|30min|1hour|2hour|4hour|12hour|24hour)
    sdStop                            Stop logging to the SD card
    sntpGetOffset                     Query the current time offset
    streamStart                       Start streaming packets
    streamStop                        Stop streaming packets
    sample [count]                    Output a number of samples (infinity)
    syncClocks                        Start the mid-stream syncing protocol
    testSignal <signal>               Select test signal applied to all channels
        (dc|ground|pulse1xFast|pulse1xSlow|pulse2xFast|pulse2xSlow|none)
    time                              Convert options to unix time in ms
    usingVersionTwoFirmware           Reset & check if firmware is v2 or greater
    write <dataToWrite>               Send commands to the board

  Interacts with OpenBCI biosensor boards.

  Options:

    -h, --help                        output usage information
    -p, --port <port>                 Connect to the specified port
    -r, --baudRate <rate>             Baud Rate [115200]
    -t, --boardType <type>            (default|daisy|ganglion) [default]
    -s, --simulate                    Full functionality, just mock data
    --simulatorBoardFailure           Simulates board communications failure
    --simulatorDaisyModuleAttached    Simulates a daisy module.
    --simulatorFirmwareVersion <v>    Can simulate firmware v2 (v1|v2) [v1]
    --simulatorHasNoAccelerometer     Send packets without accelerometer data
    --simulatorNoInjectAlpha          Do not inject a 10Hz alpha wave
    --simulatorInjectLineNoise <NHz>  Injects line noise (60Hz|50Hz|None) [None]
    --simulatorSampleRate <rate>      The sample rate to use for the simulator
    --simulatorSerialPortFailure      Simulates unable to open a connection
    -y, --sntpTimeSync                Use a time server instead of local time
    --sntpTimeSyncHost <host>         The time server to use [pool.ntp.org]
    --sntpTimeSyncPort <port>         The port to access the time server [123]
    -v, --verbose                     Print out useful debugging events
    -d, --debugSession                Prints out debugging packet information

@baffo32 any progress on this now that we have merged a bunch with master? really really looking forward to this one!

Well it needs #95, which I thought I'd do more robustly the second time around. I couldn't really test that my changes were valid because of #99, which seems critical itself, so I was putting this on hold and trying to make everything robust. I was going to get #92 working next, which helps work towards both I think. I could rush #95 out though and focus on implementing CLI. Thoughts?

Sounds like a good idea, with #92 next which will end up setting you up well to do #95 much easier, totally get that.