OS X and virtual com ports (Mavericks / Yosemite note)

edited November 2014 in Software
I'm running the Processing (2.2.1) software on OSX (10.9.4). I've opened the OpenBCI_GUI.pde sketch and run it.

When I try to connect to the LIVE data source, I try selecting /dev/tty.Bluetooth-Incoming-Port and /dev/cu.Bluetooth-Incoming-Port, but neither will ever connect to the board, and I get an error message: Init timeout. Verify your Serial/COM Port. Power UP/DOWN your OpenBCI & USB Dongle. Then retry Initialization.  So I try that, still no connection.

So then I tried the /dev/cu.Bluetooth-Modem port.  That reported: openBCI: openNewLogFile: opened output file: Blah.txt.  However, at that point the interface was stuck in the Data Source preferences.  Clicking around does't close that, or display the signal.  Also, looking at the data file, there is no data in there, just some generic header stuff.

I'm stuck at this point.  Any help appreciated.

Comments

  • wjcroftwjcroft Mount Shasta, CA
    edited November 2014
    Hi (Max) Planck,

    Our dongle uses FTDI's usb virtual com port emulation. I believe it is the case that on some (pre-Mavericks) Macs, things work fine out of the box. (But you are running Mavericks.) 

    In Mavericks and Yosemite, Apple decided to create their own FTDI driver, instead of using the one suppled by FTDI. And that Apple driver: (1) does not listen to our matching usb hardware dongle vendor and device id's.  (2) conflicts with some of the id's supplied by the older FTDI driver.  So the end effect is that the Apple driver messes up not only our own dongle, but various other Arduino and serial devices (using FTDI) as well.

    So the solution most are using, is to follow the directions on this page:


    What this does is to disable the Apple driver, and install the FTDI driver.  You can ignore the section about editing the Info.plist file.  Since the FTDI driver already has our dongle id's in the default Info.plist.  And the paragraph #6 note about disabling signature checking (nvram change) only applies if the Info.plist is edited; and I believe primarily to Yosemite and later.  Yosemite added incresing levels of kernel extension signature checking. Although I think Mavericks had some parts of that as well. Anyway, no need for you to edit the plist.

    Let us know if this works for you.

    William

    PS this is a work in progress, we're going to setup a wiki page with various VCP links and hints.

  • I followed step 1 to disable the native OSX driver, and then step 2 to install the FTDI driver.  I do see the usbserial drivers in the GUI (and in /dev), but I get the same error trying to connect to those devices.

    I then looked in the info.plist file, and there aren't any FT232 devices in there that have the same bcdDevice, idProduct, and idVendor numbers.  So maybe that edit still needs to happen?  Also, that link shows the edit being done on a device called "FT232R USB UART" which isn't in my Info.plist - FT232H is the only device in there starting with "FT232".
  • wjcroftwjcroft Mount Shasta, CA
    edited November 2014
    Planck, hi again.

    It's working here for me with a Mac Mini and Mavericks. For example, I'm using /dev/tty.usbserial-DN009500 here, where the last digits are your dongle serial.  If the dev is showing up, the driver is recognizing the USB ids.

    Did you power cycle your Mac after doing all the changes?  The Apple driver may need to see that it is disabled and shouldnt mess with the FTDI. And if it was loaded previously may still be messing up. Also try cycling the power switch on the OpenBCI board. Ensure your dongle switch is not on Reset.

    On the Processing GUI debug message pane you should see some startup output fly by on initialization, then the data stream. Are you seeing any of that? Or just the Init timeout that you saw before.

    Our entry in the Info.plist is the one labeled "FT X Series".








  • I did (another) reboot.  I checked the dongle settings, and I *did* have the dongle on RESET.  So I changed the switch.  At that point the software was able to connect.  So I am now live and working.

    Thank you very much for helping me trouble-shoot the issue.

    More questions to come.....
  • wjcroftwjcroft Mount Shasta, CA
    See this related post on how to improve the buffering delay performance on Mac OS X. It applies to all versions of OS X.


  • edited December 2014
    If you are working with a brand new Macbook Air OSX 10.10 with Wouxun and a Kenwood Radio handheld TH-F6/F7

    Here are two links I used to get mine working after I fumbled through these instructions, modified plist, etc. etc. 

    Thanks 
    KK6MZC
Sign In or Register to comment.