Cyton Impedance commands not working through Wifi shield API [resolved]

drivasdrivas Montreal CA
edited December 2019 in Wifi Shield

Hi!

There seems to be a strange behavior when using the endpoint command/ and sending a impedance command such as "z101Z" during streaming with the WiFi shield. I receive a confirmation message from the server running on the shield: Success: Lead off set for 1, but in fact, the signal is left unchanged, and it seems the board simply performs a reset (stopping the resuming streaming immediately).

Cyton board: 32bit, firmware 3.1.2
WiFi shield: firmware 2.0.5
Daisy: yes

This happens no matter the connection parameters, (1 or 2ms latency), on 250Hz or 500Hz (1000Hz not attempted), and on TCP (UDP not attempted). Passing other commands have the expected outcome but sometime make the board "crash":

  • "V" works as expected and returns the correct firmware
  • "d" works as expected
  • test signals work as expected
  • sample rate setting works as expected
  • "a" crashes the board
  • "v" crashes the board
  • others not attempted

The cyton and daisy board we have work as expected over Bluetooth (as seen using the openBCI_GUI), including the impedance check, so it does not seem they are at fault. The impedance commands fail to have their intended effect whether sent through our Python code or via Postman.

All of this was tested using a custom Python-backed GUI that we have designed for our needs (based on fixes and modifications on your pyOpenBci), and the impedance commands work through bluetooth with our software too. I am unable to test the impedance commands with WiFi through your GUI since it has never succeeded in connecting, see: https://github.com/OpenBCI/OpenBCI_GUI/issues/590

The fact that the shield explicitly reports a success is the most puzzling part for us. As I understand, this message is generated on the Cyton itself so it cannot be a failure to transmit the message from shield to Cyton. Could there be an issue with the Cyton firmware code around https://github.com/OpenBCI/OpenBCI_Cyton_Library/blob/e601937cead66794231d4a9720672aa9f32e18c2/OpenBCI_32bit_Library.cpp#L1294 ?

We are approaching our data collection phase and impedance measurements are important to ensure data quality, any help would be greatly appreciated

Thanks,
Daniel

Comments

  • wjcroftwjcroft Mount Shasta, CA

    Daniel, thanks for your detailed post here. I've left some comments on the issue page you mentioned above.

    https://github.com/OpenBCI/OpenBCI_GUI/issues/590

    Regards, William

  • wjcroftwjcroft Mount Shasta, CA

    Daniel, one other point to consider is that modern EEG amps have extremely high input impedance. The Cyton ADS1299 is 1 gigaohm. This means that the old 5K ohm skin impedance practice, that originated with amps having input impedance in the low megohms range, is now much less relevant. As this paper shows, skin impedances even up to 40K, show no change in signal quality.

    http://wwe.eeginfo.com/research/ElectrodeImpedance.pdf

    The amp tested in the paper was 200 megohms input impedance. ADS1299 is likely 5 times better than that, at 1 gigaohm.

    Regards, William

  • drivasdrivas Montreal CA

    William,

    Thank for your link to the paper. Despite your latest fixes, I am still unable to run your GUI with the shield on my laptop for testing, and for our real uses in a corporate networking environment, (with different network interfaces assigning our computers different ip addresses), a fix on the Hub (specifying explicitly the local ip address to use) would be necessary which I understand you would be unwilling to do in the short term. For now, we will amend our experimental protocol by using the GUI over bluetooth first to check impedances, then swap on the Shield to get the higher sampling rates. We would have preferred not to but I feel that a thourough investigation of this bug on your part will take too long and we will need to compromise.

    If it's any help, I have also noticed, using the wifi shield + daisy, that the shield will often report only 8 channels (and board==cyton), and that this always happens on the first try (before the first calls to /tcp and /stream/start). Afterwards, the next calls to /board report the correct number of channels (16) but even then sometimes not. Could this be linked to our problem? could this be a glitch on our Cyton?

  • wjcroftwjcroft Mount Shasta, CA

    Daniel, hi.

    I'm mentioning Richard @retiutut, because he said on the Github issue page that he was able to use the GUI to connect to the Cyton + Daisy with Shield, in the latest Git, "Please do git fetch --all and git merge upstream/development". Did you do that Git operation. Are you still seeing the null pointer exception?

    Did you try the other transfer modes (UDPx3), or Wifi Direct? These work independently of your local corporate networking environment.

    Regards, William

  • drivasdrivas Montreal CA

    Thank you for your support!

    All of my tests are using WiFi direct mode (computer connecting to the WiFi network broadcasted by the shield through a USB WiFi adapter). I had assumed any kind of networking would not work on my workstation due to the problem I had myself using the pyOpenBci package earlier.

    Yes, I followed @retiutut 's directives and merged the latest changes and executed the GUI through Processing 3.5.3. I have now discovered that while I still have the NullPointerException on my personal laptop (some kind of high DPI issue maybe? although the UI itself looks fine but other I had issues with some other programs like Windows contextual menus being low res), I managed to get to the widget screens on my work computer using UDP or UDPx3.

    However, There is no visible effect when clicking on the green "start data stream". Furthermore, the Status bar still reports Cyton firmware null. I feel this would warrant a separate issue with full Processing stack trace on GitHub. But you were right, I can see there is some kind of successful connection with the shield using UDP even on our networking environment.

    Notably, it seems it fails when sending 'b' to the wifi shield
    Hub: processCommand: ERROR_COMMAND_NOT_ABLE_TO_BE_SENT -- 226460 Timeout waiting for response

    Should I create the issue?

  • retiututretiutut Louisiana, USA
    edited September 2019

    Yo hold on the Hub has to be changed for Cyton Firmware to show up with wifi. Give us some time to review and push code.

  • wjcroftwjcroft Mount Shasta, CA

    Richard, would he have any better luck with getting impedance readout, by using his Wifi with a router, rather than Direct? It sounds like the null pointer issue is because of some DPI dependency. Why doesn't he get the impedance via UDP, if it is connecting successfully?

  • retiututretiutut Louisiana, USA
    edited September 2019

    I don’t think there is any difference for how we connect to the WiFi other than protocol used. Maybe cyton+wifi+impedance is broken in the Hub. This won’t take long to investigate and it is possible to still do minor updates to the Hub. Out of office right now.

  • retiututretiutut Louisiana, USA

    Is this a problem with the Hub or underlying NodeJS Cyton code?

  • drivasdrivas Montreal CA

    I could not say since I have been unable to ever connect to the shield using the Processing Gui, thus I have never had the chance to try seeing impedance through the Hub. My issue is with the underlying http route /command and the effect on the live signal as seen through our python gui. This is why I am unsure if this can truly be fixed at the hub or nodejs level. However, this would make the Processing GUI more stable with WiFi overall so still a win!

  • drivasdrivas Montreal CA

    Hi @retiutut! I have tried the latest dev versions of the GUI and Hub v2.1.0 via UDPx3 and It's very encouraging that I seem to get some kind of connection, but pressing "Start Stream" invariably results in

    Hub: processCommand: ERROR_COMMAND_NOT_ABLE_TO_BE_SENT -- 80727 Timeout waiting for response

    I can try and look into it myself, but to do this I think I will need to run the Hub from source AND have the GUI connect to my debuggable, running instance of the Hub. Any pointers on how you do this (aka how you usually develop the hub and its communication with the GUI)? will the GUI automatically connect to the default hub url/port?

  • retiututretiutut Louisiana, USA
    edited September 2019

    @drivas Correct. I use Visual Studio Code only now. I have two windows open: one for Hub, one for GUI. Latest GUI version allows up to ~20 seconds to find the Hub. I type npm start in Hub, and CMD+Shift+B on my Mac to run the GUI from VSCode.

    https://github.com/OpenBCI/OpenBCI_GUI/wiki/Developer-Setup#visual-studio-code-set-up

    Keep asking questions and keeping us updated! I have a new WiFi shield coming in soon that I will use with my Cyton+Daisy to help with issues like this.

  • drivasdrivas Montreal CA

    @retiutut thank you for your support! I use VScode as well, so I should be able to get things working fast, although I have much less experience with NodeJS than with my current Python solution. It would be a relief to get the original GUI working with the WiFi shield within our corporate, multiple-interface environment for our data collection. I will definitely keep you posted!

  • drivasdrivas Montreal CA

    Hi @retiutut! I have, after much effort, gotten the hub running under the vscode debugger. This was hard due to the very old versions of electron and other packages causing compilation issues of the serialport npm package. Most of the dependencies of the Hub are also very deprecated. Anyway, I narrowed it down to a problem with getting my computer's local ip address on the shield's network and not on Ethernet.

    I opened an issue on github here https://github.com/OpenBCI/OpenBCI_NodeJS_Wifi/issues/30

  • retiututretiutut Louisiana, USA

    @drivas "Most of the dependencies of the Hub are also very deprecated." --this goes all the way down the stack to the OpenBCI dependancies (ex. NodeJS_Wifi, Cyton, Ganglion). Getting everything to run and build is sometimes a balancing act. Let's continue this conversation on GitHub across the various repos. Make sure to continue to tag me!

  • bmartin427bmartin427 Ashland, MA
    edited December 2019

    I also have the same problem with the impedance measurement not working on wifi, and have filed https://github.com/OpenBCI/OpenBCI_GUI/issues/653 to track this.

Sign In or Register to comment.