Ganglion with WiFi shield not streaming data

Comments

• robertoostenveld

  April 2019 edited April 2019

  Let me give an update. I tried it with another WiFi shield, which resulted in the same failure in the OpenBCI GUI. Furthermore, I tried it with the OpenBCI_Python code, which also failed

  
  

  mac011-3> python stream_data_wifi_high_speed.py 
  

  Welcome to OpenBCI Native WiFi Shield Driver - Please contribute code!

  Opened socket on 192.168.1.182:50491

  Try to find WiFi shields on your local wireless network

  Scanning for 3 seconds nearby devices...

  Found WiFi Shield OpenBCI-11F2 with IP Address 192.168.1.134

  Init WiFi connection with IP: 192.168.1.134

  Connected to ganglion with 4 channels

  WiFi Shield to Python TCP Socket Established

  WiFi Shield Instantiated

  Incoming connection from ('192.168.1.134', 28346)

  
  

  The same stream_data_wifi_high_speed.py Python script does work with the WiFi shield attached to a Cyton board.
  

   

  Perhaps also worthwhile to mention is that with the WiFi shield connected to the Cyton board, I can use either the wifi or the dongle to interface with the board.  With the WiFi shield attached to the Ganglion, data transfer also fails with the built-in Bluetooth interface. Without the WiFi shield attached, built-in Bluetooth works fine.

  
  

  So it is as if the presence of the WiFi shield causes the Ganglion to freeze.
• retiutut Louisiana, USA

  April 2019 edited April 2019

  The Ganglion+WiFi works fine for me. Thanks for the screenshots and relevant details. One more thing, please share the console log information.

  
  

  Go through the steps again with the GUI, then click the new "Console Log Window" button in the top right. You can share the console messages as a file or copying text to clipboard.
• robertoostenveld

  April 2019

  Thanks. I am currently traveling and don't have the OpenBCI hardware with me, so cannot test and report on details. I will report back as soon as I am home.
• Alejandro Ireland

  May 2019

  Hi @robertoostenveld and @retiutut

  
  

  I see the same issues but with a Cyton board. I have a very intermittent direct mode functionality, and when it manages to connect, the data stream is empty. No error message is shown but the raw output file only contains the header with no actual data. 

  
  

  I would be very interested on see what comes out of this discussion.

  
  

  Kind regards

  Alejandro
• wjcroft Mount Shasta, CA

  May 2019

  OpenBCI_Python + Wifi in our official repository is broken, until a pull request is completed. Use the pull originator's repo instead, see,

  
  

  https://github.com/OpenBCI/OpenBCI_Python/issues/117
  

  
  

  https://github.com/cmello418/OpenBCI_Python
  

  
  

  https://github.com/cmello418/OpenBCI_Python/blob/master/scripts/stream_data_wifi_high_speed_no_auto_connect.py
  

  
  

  https://github.com/OpenBCI/OpenBCI_Python/pull/118
  
• robertoostenveld

  May 2019 edited May 2019

  Hi @retiutut, 

  
  

  Please find the log file at https://justpaste.it/7fyte (I am not allowed to paste it here, the message body would get too long). 

  
  

  It contains three system initializations, one of a ganglion board without wifi shield, two of (another) ganglion with wifi shield. As far as I can tell, all communication with the Hub is going fine.

  
  

  I also started the OpenBCI Hub from https://github.com/OpenBCI/OpenBCI_Hub on the macOS command-line terminal (npm install; npm start) in the hope it would show more in the terminal. The sequence to start was first the command-line Node.js application, then start the OpenBCI Processing application. The latter tries to start the Hub as well, fails, and in the command line I can see that the one I started is in control. However, there is no useful information in the command window.

  
  

  As I mentioned before: with the cyton with wifi shield attached, I can use either BT serial or wifi. With the ganglion with wifi shield attached, both BLE connection AND wifi shield fail to stream data.  On https://justpaste.it/3w1td you can find another log output of the OpenBCI GUI, with the ganglion board that has the wifi shield attached, now selecting built-in bluetooth to make the connection. The failure to stream data in the GUI appears just the same. As such I wonder whether the wifi shield presence causes the ganglion firmware to fail. Could you check whether you can stream data over BLE with the wifi shield attached?

  
  

  best regards,

  Robert

  
  
• robertoostenveld

  May 2019 edited May 2019

  I have done some further investigations, still no solution. But let me report the details.

  
  

  As reported before, the OpenBCI Hub application does not print extra debugging information when started from the command line. I looked into the WiFi shield; by default in the firmeware DEBUG is not defined, and hence https://github.com/OpenBCI/OpenBCI_WIFI/blob/master/examples/DefaultWifiShield/DefaultWifiShield.ino does not print any information on the serial interface. I connected an FTDI tool to GND, TX and RX, and only got to see some feedback (at 74880 baud) upon starting the ESP8266

  
  

   ets Jan  8 2013,rst cause:2, boot mode:(7,7)

  
  

  waiting for host

  
  

  I also considered hooking up the FTDI to the Simblee processor on the Ganglion, but it was not clear from the schematics how to do that. Furthermore, https://github.com/OpenBCI/OpenBCI_Ganglion_Library suggests that there is no debug information printed on a serial debug interface anyway.
  

  
  

  Subsequently I hooked up an oscilloscope to the SCK of the SPI bus. Without the wifi shield, I see that the SPI bus switches on upon start of acquisition ('b') and switched off upon end of acquisition ('s'). By inspecting MOSI and MISO I came up with the same conclusion. With the wifi shield attached, I see SCK  activity about 8 seconds after powering the ganglion and wifi shield on. The SCK activity does not change upon me switching  on or off the data stream (in the GUI). I suppose this SCK activity is related to the ESP8266 acting as SPISlave to the Simblee, and the SPI bus being shared between the MCP3912 ADC, the Simblee  MCU and the ESP8266. I suppose this is not so useful for further diagnostics.