I looked it over there was like to specs of dust and I clean it off and tested again and nothing, it is still wonky.
I emailed joel and referred him to this thread. Thank you for helping me out. You guys are awesome and I love your product. I really hope we can get this sorted out so my partner and I can finish our research and edit our paper in time for our conference.
Although the input pins are protected from static electricity, all the various contacts and exposed metal on the top and bottom of the board is not. It's possible your board might have taken a static hit and was partly damaged. (Well, dongle was completely damaged.) Seems odd that both mainboard and dongle would go south in succession around the same timeframe. Have you noticed any sparks when you touch grounded metal objects in your home / office?
A precaution you can take with any exposed circuit boards is to discharge yourself if you've been walking around in the winter on a wool carpet for example. A lot of Maker types know about this, but perhaps it should be stated on the OpenBCI docs site.
I have gotten my replacement tech and it is work fantastic thank you so much @biomurph and @wjcroft.
As was discussed previously in the thread one of the pins on the board was really off and most likely damaged there was some damage found on the back of the hardware. The hardware in question was sent to biomurph and he will be investigating what exactly went wrong with it.
@indra wrote me the following Private Message using the forum Message button,
Hi, I have a 32-bit OpenBCI kit, and the USB dongle is not being recognized on my PC. However it was working fine until last week. When I plug in the dongle, the blue led is on but it does not show up on the Device Manger (Windows 10). I haven't modified the firmware anytime. I tried reinstalling the FTDI drivers. Also tried on different machines with Windows 7 and linux. But the dongle is not recognised. Can you please help me resolve the issue? Regards, Indra
Indra, read through the previous posts on this thread for the suggestions there. But it does sound like you have tried all those ideas. If you could reflash the dongle, that might allow it to come back to life. However without a COM port showing up, that's impossible. I'm cc-ing Joel @biomurph here. You may need to get a replacement dongle. Send an email to contact at openbci.com asking how to proceed.
My dongle works fine now. It does seem like a driver issue.
I installed the FTDI driver (2.12.18) from http://www.ftdichip.com/Drivers/VCP.htm on a different system running Windows 7, after which it is now recognized on both Windows 7 and Windows 10 systems. However I had tried the same thing once before but it didn't work then. Still trying to figure out what caused this behaviour.
Thank you Joel @biomurph for helping in diagnosing the issue.
The same issue with the Dongle happened to us now...
We have 2 OpenBCI boards 32bit: one for 8 channels and other for 16.
Everything was working fine in windows 10, mac and Linux (Lubuntu). We were working now mainly with the 16 channels board and dongle
However, yesterday we plugged the dongle in and it turns on (only) the blue light but is not detected in Windows, Mac (10.9 and 10.11) or Linux...
Could you please help us with this?
Meanwhile, is it possible to make the dongle for the 8 channels board work with the 16 channels one? should we just change the channel in the dongle firmware?
I'm also sending this information by e-mail to [email protected] for direct contact.
If you got your boards last August, I think you have the V1 firmware.
Changing the channel on your other dongle should work, but it then no longer works with your 8 channel.
The new V2 firmware makes channel changing easy to do without reflashing the firmware. But it sounds like you have V1 firmware. (Note that upgrading to V2 requires reflashing all microcontrollers (chipKIT and the 2 RFduinos)). So perhaps easiest to stick with V1 for the moment.
Most likely just reflashing the 'dead' dongle will bring it back to life. Be sure you set the channel the same as your mainboard (marked on the anti-static bag.)
Oops, looking at some other posts by @sardet, I see that you are working with V2 firmware already. In this case, you can just use the Radio Configuration utility to change your radio channel on your 8 channel Cyton. This will update both the RFduinos channels (host and device) on that Cyton. The utility can also search for what channels are already set and then change.
In any case, reflashing the 'dead' dongle should bring it back to life. It has for the few other users who have encountered a frozen dongle.
I assume your dongle com port is showing up in your device manager or /dev, etc. This is necessary in order to flash it. If you are not getting any com port at all when inserting, then the dongle might not be recoverable. In that case proceed with your email exchange with contact at openbci.com.
As reported before, we set our other dongle to work with the 16 channels board and it was working perfectly, even today. Baud rate defined in the board and Processing was the default 115200.
However, just now, after an acquisition, while we were working on the Processing code (just changing some array on our data) we left the dongle plugged in and the board turned on for some few minutes. Since we had the PC sound turned on, we noticed the usual sound of a USB device plugging out. It was odd because we were not touching anything and then we noticed that this dongle started a behaviour just like the other one: blue light on but not showing in the device manager. We tested and it is not recognized in Mac and Linux too...
We really can't understand this issue...
Any input will be appreciated. We will copy this message and send for contact e-mail for tracking in the same topic as before.
Mentioning @biomurph and @pushtheworld. How could two dongles fail like this in succession (same week) at the same customer? This is V2 firmware. I assume this is just a freak hardware failure, but is there any way they could try a revival with some kind of forced reflashing? With no COM port, how?
@sardet, hi. Can you ensure that there are no "static discharges" happening near the dongles? In cold dry winter climates sometimes even walking across a carpet can generate huge voltages which discharge when equipment is touched. Especially with exposed circuit boards. If this sounds plausible, touch a grounded object before handling any OpenBCI board.
re-flashing the Dongle firmware would not necessarily solve the problem. There are two systems on the Dongle. One is the FTDI IC, which provides the USB to Serial connection for the RFduino, and the other is the RFduino, which does not have any relationship to the USB, except through the FTDI chip.
Have you replaced your FTDI drivers? That might work. To not be able to see the Dongle on multiple machines makes me think that the FTDI chip is where the problem lies.
Each Dongle goes through multiple tests in our lab prior to shipping, so we know that it did work previously, as you said.
We believe that there were no "static discharges" and that the conditions in which we were working didn't change. We tried to reinstall the FTDI drivers but nothing changed... We are now in contact with Joel by e-mail.
Meanwhile, as alternative and not to stop, we decided to try the wired connection refered in
Forgive me the question, but is it possible to upload the firmware to the board by wire, not using the dongle? The code compiles (so we believe everything is fine) but the target is not found.
When the Cyton is first programmed at the factory / lab, it's done with a wired connection thru a PIC / chipKIT USB attached dongle type device. I believe this step installs the bootloader. And the bootloader expects to upload over the radio link. So the short answer is no, the bootloader that is flashed on the mainboard expects to upload over the air using the two RFduinos.
But it's possible Joel @biomurph may know a way to upload the firmware + bootloader to the mainboard using the PIC USB wired link device. Continue to email with him, I'd be interested to hear what you find out. Easiest path is likely to just be getting you working OpenBCI dongles.
I had a similar problem, i.e. dongle not being recognized. With the help of Joel I was able to resolve it. Let me first describe the problem, then the solution.
The dongle of my 8-channel 32-bit OpenBCI (Cynthon) board stopped working and did not appear in /dev/tty.xxx on three different computers. I have always stored it properly in the silver anti-static bag in which it originally arrived.
On my daily computer (Macbook Pro model 2013, OS X 10.11.6) the dongle blinks blue for 5-10 seconds, not red, and then stops. In the console I see "01/05/17 20:10:24,000 kernel[0]: 002587.519694 HS01@14100000: AppleUSB20XHCIPort::resetAndCreateDevice: failed to create device, disabling port". I have tried reinstalling the drivers (version 2.2.18), to no avail. I went through http://docs.openbci.com/Tutorials/10-Mac_FTDI_Driver_Fix, also no success.
On my older development MacBook Pro (model 2009, also OS X 10.11.6) it also fails. On this one it does not blink at all, no red, no blue. The message in the console is different: 01/05/2017 20:15:48.000 kernel[0]: 000217.184890 PRT1@04100000: AppleUSBHostPort::disconnect: persistent enumeration failures. On my Raspberry Pi (model 2B, Raspbian 8, Jessie) it also fails, no blinking, nothing appears in the console. I had been using it fine on all three computers in the past.
Now towards the solution: Joel asked me to send some photo's of the dongle. Here is the one that revealed the problem:
If you look closely, you can see that part of the SMD component L1 in the upper left corner is displaced. It should look the same as L2 (bottom left).
Joel explained that it is an inductor, used for input voltage regulation, but that it is not so important and that the dongle will function fine without it. So I used a soldering iron to wipe off the broken component, and connected the two pads with some solder.
After this, the dongle worked again and showed the expected LED blinking pattern (including red and green for RX and TX).
Comments
A precaution you can take with any exposed circuit boards is to discharge yourself if you've been walking around in the winter on a wool carpet for example. A lot of Maker types know about this, but perhaps it should be stated on the OpenBCI docs site.
If you got your boards last August, I think you have the V1 firmware.
Changing the channel on your other dongle should work, but it then no longer works with your 8 channel.
The new V2 firmware makes channel changing easy to do without reflashing the firmware. But it sounds like you have V1 firmware. (Note that upgrading to V2 requires reflashing all microcontrollers (chipKIT and the 2 RFduinos)). So perhaps easiest to stick with V1 for the moment.
Most likely just reflashing the 'dead' dongle will bring it back to life. Be sure you set the channel the same as your mainboard (marked on the anti-static bag.)
http://docs.openbci.com/Hardware/06-Cyton_Radios_Programming_Tutorial#cyton-radios-programming-tutorial-uploading-host-firmware-to-the-openbci-dongle
https://www.google.com/search?q=openbci+radio+configuration
In any case, reflashing the 'dead' dongle should bring it back to life. It has for the few other users who have encountered a frozen dongle.
I assume your dongle com port is showing up in your device manager or /dev, etc. This is necessary in order to flash it. If you are not getting any com port at all when inserting, then the dongle might not be recoverable. In that case proceed with your email exchange with contact at openbci.com.
William
http://openbci.com/forum/index.php?p=/discussion/915/using-wired-usb-connection-with-firmware-2-x-x
Forgive me the question, but is it possible to upload the firmware to the board by wire, not using the dongle? The code compiles (so we believe everything is fine) but the target is not found.
On my daily computer (Macbook Pro model 2013, OS X 10.11.6) the dongle blinks blue for 5-10 seconds, not red, and then stops. In the console I see "01/05/17 20:10:24,000 kernel[0]: 002587.519694 HS01@14100000: AppleUSB20XHCIPort::resetAndCreateDevice: failed to create device, disabling port". I have tried reinstalling the drivers (version 2.2.18), to no avail. I went through http://docs.openbci.com/Tutorials/10-Mac_FTDI_Driver_Fix, also no success.
On my older development MacBook Pro (model 2009, also OS X 10.11.6) it also fails. On this one it does not blink at all, no red, no blue. The message in the console is different: 01/05/2017 20:15:48.000 kernel[0]: 000217.184890 PRT1@04100000: AppleUSBHostPort::disconnect: persistent enumeration failures. On my Raspberry Pi (model 2B, Raspbian 8, Jessie) it also fails, no blinking, nothing appears in the console. I had been using it fine on all three computers in the past.