I’m interested in the Micro Maestro 6-Channel USB Servo Controller. However, I develop on a Mac, and I only see Windows and Linux listed as supported operating systems. I want to control several servos from software that runs on Windows, Linux, and Mac. Is the Windows/Linux limitation only for the GUI application that comes with the controller, or will the Mac not recognize the device?
Hello nalice,
There are two issues with Mac support - one is that the virtual serial ports created by the Maestro are not supported automatically under Mac OS, since its USB-serial support does not work with composite devices. The second issue is that we do not have any Macs at Pololu for testing.
However, if you have experience compiling software for the Mac, I think you will be able to get the custom USB interface working without much trouble. This will require you to install mono and libusb, then compile our USB Software Development Kit. The libusb package allows user code to control USB devices without any drivers being installed, so you can follow our examples to write your own code in C#, C, or any language that makes it easy to call functions in a shared library. You will still not have virtual serial ports, but the custom USB interface allows access to all of the features of the device except the firmware upgrade.
There is even a simple example GUI included with the SDK, and I expect it to work on the Mac. We will be happy to help you with getting everything working if you decide to give it a try!
-Paul
Thanks for the fast reply. I actually bought the controller and a few servos last night. I’ll let you know how it goes.
Quick question while this thread is alive: any suggestions for a power source for the servos? I want the device to be plugged into the wall, not run off of batteries. I was thinking of finding a 5V power source for some old piece of electronics and attaching a new connector.
- Alex
Hi Alex,
It will be great to find out how it works for you on the Mac. If we learn anything along the way, we can add it to our user’s guide.
Old 5V power supplies are great for servos as long as they are regulated. The older, less efficient, unregulated supplies will have a much higher voltage when there is no load, possibly high enough to damage your servos. I have on my desk a regulated power supply from an old D-Link router that is capable of doing 2A at 5V, probably enough for most applications. To get higher power, old computer supplies might be useful.
-Paul
Paul,
Is there some way I can get a document that describes the different USB interfaces on the device? More specifically, I need to know what is being sent via USB. Even better would be a peek at the source for the windows driver. Communicating with the controller on the Mac shouldn’t be too bad as long as I know how it’s set up.
Alex
Edit: Scratch that, it looks like I might be able to get the code you suggested earlier running. That’d be easier anyway.
Hi guys,
Any update on this? I am also interested in running a Maestro from a Mac. I was able to compile and run the GUI included in the SDK. When I get the board I’ll let you know if I can connect to it.
Here is what I did to get the example program working:
Download libusb at sourceforge.net/projects/libusb/
Open it (will unpack the .tar.bz2)
Open a Terminal window and cd to the directory of files
Run "./configure"
Run "make"
Run "sudo make install"
Download Mono from go-mono.com/mono-downloads/download.html
Open .dmg file (mounts a disk image)
Open the .pkg file (runs the installer)
The Mac OS X installer for Mono does not put the libraries in the expected place for unix. You can fix this by making a symbolic link:
Run "ln -s /Library/Frameworks/Mono.framework/Libraries/mono /usr/lib/mono"
In Terminal, cd to the pololu_usb_sdk directory.
Run "make"
Now you can run the example maestro program by running “mono ./Maestro/MaestroExample/MaestroExample”
Ideally I’d like to be able to control some servos from a Cocoa GUI. Any thoughts on this?
That’s cool that you were able to get it working, and thanks for posting the step-by-step instructions.
My thoughts:
The MaestroExample application you compiled should probably just work when you plug the Maestro in to your Mac. If it doesn’t, you might need to put a file in /etc/udev/rules.d/ folder as described in the Linux section of the Pololu USB SDK’s README.txt.
I searched around a little bit for ways to make C# .NET code interact with Cocoa code, and the best I found was the CocoaSharp project, which hasn’t been updated for two years. So if you want to make a Cocoa program that talks to the Maestro you should probably be to figure out how to call libusb functions from Cocoa, and then use the code in our SDK as a guide to write your own code for talking to the Maestro. Alternatively, Apple provides another library for talking to USB devices called the IO Kit which would probably work.
–David
I got the board today (a Mini Maestro 24) and indeed it worked (I didn’t even have to do the rules fix).
I tried using the Linux version of MaestroControlCenter (from pololu.com/file/download/mae … e_id=0J315 ). It partly worked, but the GUI is very slow and glitchy. I suspect that the Mono implementation for Mac is buggy. I installed Fink so I could use apt-get to update the mono and winform libraries, as is recommended in the Maestro Linux documentation, but it didn’t help.
I see a few options for developing a GUI that I can run on my iMac:
(A) Dual-boot to Linux, and develop using C-sharp and Mono in that environment.
– Is Mono pretty slick under Ubuntu, or is it buggy there also? This option seems less fun to me than writing a native Mac OS app, but I guess it is tried-and-true.
(B) Use Mono under OS X.
– From the look of MaestroControlCenter this may be problematic.
© Develop a mixed Obj-C and C# app.
– I’d do the interface using the Cocoa APIs in Obj-C, and somehow link it to the C# objects in the SDK that talk to the board. Maybe Cocoa-Sharp would help. This sounds tricky.
(D) Re-write the C-sharp objects in Obj-C so the whole thing can be done “the Mac way.”
– So I guess this means porting the code from Usc.cs, UscSettings.cs, and UscProtocols.cs. At the end I’d have something pretty slick, but that sounds like a lot of work.
(E) Write an interface using Cocoa that sends commands via pipes to UscCmd, which controls the board.
– This sounds like the easiest option. Is it practical to control everything using UscCmd? Basically I just want to send some motion sequences to the servos without noticeable delays. Is there more documentation on UscCmd? When I execute it I get a list of options, but only very short descriptions of what they do.
Any advice? Does option (E) sound like the way to go? Is there more documentation of how to use UscCmd to control a bunch of servos?
That’s cool that you were able to connect to the Maestro on your Mac! Also it’s cool that you were able to run the Linux version of the Maestro Control Center on your mac.
Which parts of the GUI are slow?
My experience when making the Maestro Control Center work in Linux was that the Linux GUI implementation differed from the official .NET Windows implementation in many little ways which caused glitches, so I’m not surprised the Linux version has glitches when you try to run it on a Mac.
A: If you want to Dual Boot, Mono GUIs work fine under Ubuntu, you can see a see a screenshot.
B: Using Mono under OS X is probably more feasible than you think; the Maestro Control Center just behaves badly on a Mac because we never tried to make it work. If MaestroExample works well on the Mac, then you’re probably ok. But your final result won’t look as good as a native Mac application.
C: Yeah, sounds tricky.
D: I personally would opt to do everything “the Mac way”. Note that you don’t have to re-write all the code in Usc.cs, UscSettings.cs, and UscProtocol.cs. Those files support ALL of the features of the Maestro, but you probably only need a small number of features to do what you want, so you can get away with writing a lot less code. To perform motion sequences on the Maestro all you need to do is find the USB device (using vendor ID 0x1FFB and product ID 0x008C), connect to it, and then initiate several Set Target control transfers (see the Usc.setTarget method, it’s not complicated). Libusb has good documentation including example code written in C and you can look at our C# code which calls libusb.
E: Controlling it from UscCmd is probably the easiest thing. You can use the “–servo” option to set the target of a servo. You should see whether there is a noticeable delay when you execute 24 of those commands in series. If there is, that’s probably because there is some overhead when starting up the Mono runtime. You could alleviate that by modifying UscCmd to have a single command-line option that sets the targets of all the servos. We don’t have any additional documentation for UscCmd, besides the source code of course. Is there anything confusing about the list of options with short descriptions?
Let us know how it works for you, and when you get it working I’m sure there are other Mac users that would appreciate having the code!
–David
Hello,
I’m trying to work through the suggestions here. I initially tried loading libusb and mono, which of course required downloading macports and xcode. At the end of the process, tried compiling the Maestro examples and got “System.dll Not Found” error in Mono’s application output.
Then tried kmb’s suggestions. Reloaded libusb; ran mono. Received this error message:
Unhandled Exception: System.DllNotFoundException: libusb-1.0
at (wrapper managed-to-native) Pololu.UsbWrapper.UsbDevice:libusbInit (Pololu.UsbWrapper.LibusbContext&)
at Pololu.UsbWrapper.LibUsb.get_context () [0x00000] in :0
at Pololu.UsbWrapper.UsbDevice.getDeviceList (UInt16 vendorId, System.UInt16[] productIdArray) [0x00000] in :0
at Pololu.Usc.Usc.getConnectedDevices () [0x00000] in :0
at Pololu.Usc.MaestroExample.MainWindow.MainWindow_Shown (System.Object sender, System.EventArgs e) [0x00000] in :0
at System.Windows.Forms.Form.OnShown (System.EventArgs e) [0x00000] in :0
at System.Windows.Forms.Form.SetVisibleCore (Boolean value) [0x00000] in :0
at System.Windows.Forms.Control.set_Visible (Boolean value) [0x00000] in :0
at (wrapper remoting-invoke-with-check) System.Windows.Forms.Control:set_Visible (bool)
at System.Windows.Forms.Application.RunLoop (Boolean Modal, System.Windows.Forms.ApplicationContext context) [0x00000] in :0
at System.Windows.Forms.Application.Run (System.Windows.Forms.ApplicationContext context) [0x00000] in :0
at System.Windows.Forms.Application.Run (System.Windows.Forms.Form mainForm) [0x00000] in :0
at Pololu.Usc.MaestroExample.Program.Main () [0x00000] in :0
Suggestions?
Thanks.
Tried reloading usblib. Still not working.
Currently in /usr/local/lib:
libhelium_mac.a libusb-1.0.a libusb-1.0.la
libusb-1.0.0.dylib libusb-1.0.dylib pkgconfig
Tried restarting. No difference.
Same error message as before- Unhandled Exception: System.DllNotFoundException: libusb-1.0
etc.
Suggestions?
pcimarc,
I also have
libusb-1.0.0.dylib
libusb-1.0.a
libusb-1.0.dylib
libusb-1.0.la
in /usr/local/lib
I should have mentioned that I am using Mac OS X 10.5.8. There could be differences on another version of the system.
Just to be clear, you get the error when you run “make” (after cd’ing to the sdk directory)? The “mono” command runs the executable, but you need to recompile it (which is taken care of by make) in order to get the libraries linked properly.
David,
Thanks! If all I need to do is implement Usc.setTarget then I’ll try that first. I think I see what you’re doing there – the actual libusb function call is set up in UsbWrapper_Linux/UsbDevice.cs. And basically there are a bunch of constants, and the only thing that changes is the servo byte (which should have a value between 0x00 and 0x17 since there are 24 servos on my board) and the value (which should be between 3968 [to swing the servo the farthest to one side] and 8000 [to set the servo to the opposite extreme angle]). And to figure out what value maps to what angle I guess I just measure it for whatever servo I’m using. OK, I’ll try to write something – if I get it working I will definitely post the code!
Oh and FYI, the Mono problem on Mac is that the tabs seem to draw and re-draw at unexpected times (and sometimes on top of each other, or the non-selected tab, or mixtures of tabs).
pcimarc, try reading Mono’s documentation for DllNotFoundException. That page explains what’s going on when you get that error, and it suggests this as a solution:
–David
kmb, good luck with your project! Let us know how it goes!
Your description of the Set Target command is correct. But note that 3968 (992 microseconds) to 8000 (2000 microseconds) might not represent the full range of your servo. Depending on what servos you have, you might be able to get some more rotation out of your servos by sending target values below 3968 or above 8000, but to do that you will need to reconfigure the Min and Max parameters for that channel and you should be careful not strain your servo because some servos can destroy themselves if you command them to go to a position outside of their range.
–David
I looked at using IOKit to talk directly to the board but it seemed complicated. I’m trying to use the libusb functions so I can follow what is in the example code, but I’m having some problems.
The way I am using libusb is simply by adding the source code for the Darwin (Mac) implementation to my project and compiling it right in. That seemed easier than figuring out how to load a dynamic library and invoke the functions that way. I can get everything to compile, but when I try to execute the functions it drops to the debugger. Here is what I am running:
libusb_control_transfer(
libusb_open_device_with_vid_pid( //Get a device handle
(struct libusb_context *)NULL, //"context" -- use null
(uint16_t)0x1ffb, //vendor ID
(uint16_t)0x008c), //product ID
(uint8_t)0x40, //RequestType
(uint8_t)0x85, //Request
(uint16_t)4000, //Value
(uint16_t)0, //Index
(unsigned char*)0, //data
(uint16_t)0, //Length
(unsigned int)5000); //timeoutHere is what I see in the debugger:
And here you can see what is included in the project:
kmb,
This is starting to get beyond what we can support, but I have some suggestions:
- Figure out why your device handle is 0 and fix that.
- Figure out why your IDE is jumping in to the debugger. Maybe you just accidentally set a breakpoint? I don’t see any error message so it’s hard to tell what is going wrong.
- Make your program be more like ours by using a non-null libusb context.
- Learn how to call functions in a shared library: the fact that you copied the source code of libusb could be causing problems.
-David
This does not work on my system (64 bit intel mac with OS 10.6.4, OS X devel tools 3.2.3 ). I read that macs don’t have ldconfig either, not just mine.
Building libusb-1.0.8 with the “-m32” compiler option solves the problem
./configure CC="gcc -m32"
./make
./sudo make installThis fixed the errors about the libraries being the wrong architecture.
I would like to control my Micro Maestro using Python on my Mac. I have successfully communicated with other USB devices using the pyserial module. Unfortunately the MM doesn’t show up as a serial device on the Mac so I can’t use pyserial 
It seems that libusb can be used with Mono, but I really do not want to use Mono. Python has a module called pyusb (which was a light weight wrapper around libusb, but is now a 100% python module that can use libusb or openusb).
Has anyone successfully used Python with pyusb to communication with the Micro Maestro ??
Any ideas on how to go about it. I guess I can’t use a serial protocol directly. I assume it is more like generating serial data packets to send and receive using pyusb … but that’s just a guess. I’m not sure what setup or handshaking would be involved.
Also, has anyone actually looked at writing a usb-serial driver for OS X ?? Surely it must be possible, and I presume the linux drivers must be a good reference.
Cheers, Brendan.
Hello,
Instead of trying to write a serial driver, I recommend looking at our USB SDK, which shows the specific low-level USB operations involved in communicating with the Maestro on its native USB interface. The Maestro code in the SDK is written in C#, but you should be able to port it to python without much trouble, since it is basically just a set of wrappers around the low-level libusb/winusb calls.
-Paul
I’ve been liaising with the libusb darwin (OS X) maintainer about issues dectecting the Maestro. We are going back and forth with new code for me to try (because he doesn’t have a Maestro).
the first 8 bytes of the descriptor look ok but then it is all 0’s.
Does this sound familiar to anyone ??
Does anyone know how to fix/workaround this issue ??
Nathan Hjelm hjelmn@me.com is the maintainer of the darwin part of libusb. Please help him to help us so we can get the Maestro supported under OS X.
If there is any chance of sending him a Micro Mestro then that would be great !!!
Many thanks,
Brendan.
Email trail with libusb darwin debug output.
On 20/03/11 4:12 AM, Nathan Hjelm wrote:
Might be a good idea. They might be able to shed some light onto why we are only getting 8 bytes of the device descriptor.
-Nathan
On Mar 19, 2011, at 3:03 AM, Brendan Simon (eTRIX) wrote:
Would it be worth trying to talk to the Pololu guys to get there take on the device and how it works ??
On 19/03/11 8:01 PM, Brendan Simon (eTRIX) wrote:
I don’t really understand the output so can’t comment. All I can say is it that the device seems to work ok on Windows and Linux so I can only presume the device is not buggy, or at least as buggy as other devices such that Windows and Linux drivers cater for it ok.
Is there anything I can run on Linux to get more information on the device to see if it is buggy or not ??
Cheers, Brendan.
On 19/03/11 4:59 PM, Nathan Hjelm wrote:
Weird, the first 8 bytes of the descriptor look ok but then it is all 0’s. Might be a device bug. I will see if I can come up with a acceptable workaround.
-Nathan
On Mar 18, 2011, at 5:40 PM, Brendan Simon (eTRIX) wrote:
Here is the output
$ ./examples/lsusb
libusb:debug [libusb_init]
libusb:info [event_thread_main] creating hotplug event source
libusb:info [event_thread_main] thread ready to receive events
libusb:debug [usbi_add_pollfd] add fd 4 events 1
libusb:debug [libusb_init] created default context
libusb:debug [libusb_get_device_list]
libusb:info [process_new_device] allocating new device for location 0x04000000
libusb:debug [process_new_device] device descriptor:
libusb:debug [process_new_device] bDescriptorType: 0x01
libusb:debug [process_new_device] bcdUSB: 0x0200
libusb:debug [process_new_device] bDeviceClass: 0x09
libusb:debug [process_new_device] bDeviceSubClass: 0x00
libusb:debug [process_new_device] bDeviceProtocol: 0x00
libusb:debug [process_new_device] bMaxPacketSize0: 0x08
libusb:debug [process_new_device] idVendor: 0x05ac
libusb:debug [process_new_device] idProduct: 0x8005
libusb:debug [process_new_device] bcdDevice: 0x0200
libusb:debug [process_new_device] iManufacturer: 0x02
libusb:debug [process_new_device] iProduct: 0x01
libusb:debug [process_new_device] iSerialNumber: 0x00
libusb:debug [process_new_device] bNumConfigurations: 0x01
libusb:info [darwin_check_configuration] active config: 1, first config: 1
libusb:info [process_new_device] found device with address 1 at 001-05ac-8005-09-00
libusb:info [process_new_device] allocating new device for location 0x04600000
libusb:debug [process_new_device] device descriptor:
libusb:debug [process_new_device] bDescriptorType: 0x01
libusb:debug [process_new_device] bcdUSB: 0x0200
libusb:debug [process_new_device] bDeviceClass: 0x00
libusb:debug [process_new_device] bDeviceSubClass: 0x00
libusb:debug [process_new_device] bDeviceProtocol: 0x00
libusb:debug [process_new_device] bMaxPacketSize0: 0x08
libusb:debug [process_new_device] idVendor: 0x05ac
libusb:debug [process_new_device] idProduct: 0x0236
libusb:debug [process_new_device] bcdDevice: 0x0081
libusb:debug [process_new_device] iManufacturer: 0x01
libusb:debug [process_new_device] iProduct: 0x02
libusb:debug [process_new_device] iSerialNumber: 0x00
libusb:debug [process_new_device] bNumConfigurations: 0x01
libusb:info [darwin_check_configuration] active config: 1, first config: 1
libusb:info [process_new_device] found device with address 2 at 002-05ac-0236-00-00
libusb:info [process_new_device] allocating new device for location 0x04500000
libusb:debug [process_new_device] kernel responded with code: 0xe00002ed. sleeping for 30ms before trying again
libusb:debug [process_new_device] device descriptor:
libusb:debug [process_new_device] bDescriptorType: 0x01
libusb:debug [process_new_device] bcdUSB: 0x0200
libusb:debug [process_new_device] bDeviceClass: 0x00
libusb:debug [process_new_device] bDeviceSubClass: 0x00
libusb:debug [process_new_device] bDeviceProtocol: 0x00
libusb:debug [process_new_device] bMaxPacketSize0: 0x08
libusb:debug [process_new_device] idVendor: 0x05ac
libusb:debug [process_new_device] idProduct: 0x8242
libusb:debug [process_new_device] bcdDevice: 0x0016
libusb:debug [process_new_device] iManufacturer: 0x01
libusb:debug [process_new_device] iProduct: 0x02
libusb:debug [process_new_device] iSerialNumber: 0x00
libusb:debug [process_new_device] bNumConfigurations: 0x01
libusb:info [darwin_check_configuration] active config: 1, first config: 1
libusb:info [process_new_device] found device with address 3 at 003-05ac-8242-00-00
libusb:info [process_new_device] allocating new device for location 0x24000000
libusb:debug [process_new_device] device descriptor:
libusb:debug [process_new_device] bDescriptorType: 0x01
libusb:debug [process_new_device] bcdUSB: 0x0200
libusb:debug [process_new_device] bDeviceClass: 0x09
libusb:debug [process_new_device] bDeviceSubClass: 0x00
libusb:debug [process_new_device] bDeviceProtocol: 0x01
libusb:debug [process_new_device] bMaxPacketSize0: 0x40
libusb:debug [process_new_device] idVendor: 0x05ac
libusb:debug [process_new_device] idProduct: 0x8006
libusb:debug [process_new_device] bcdDevice: 0x0200
libusb:debug [process_new_device] iManufacturer: 0x02
libusb:debug [process_new_device] iProduct: 0x01
libusb:debug [process_new_device] iSerialNumber: 0x00
libusb:debug [process_new_device] bNumConfigurations: 0x01
libusb:info [darwin_check_configuration] active config: 1, first config: 1
libusb:info [process_new_device] found device with address 1 at 001-05ac-8006-09-00
libusb:info [process_new_device] allocating new device for location 0x24400000
libusb:debug [process_new_device] kernel responded with code: 0xe00002ed. sleeping for 30ms before trying again
libusb:debug [process_new_device] device descriptor:
libusb:debug [process_new_device] bDescriptorType: 0x01
libusb:debug [process_new_device] bcdUSB: 0x0200
libusb:debug [process_new_device] bDeviceClass: 0xef
libusb:debug [process_new_device] bDeviceSubClass: 0x02
libusb:debug [process_new_device] bDeviceProtocol: 0x01
libusb:debug [process_new_device] bMaxPacketSize0: 0x40
libusb:debug [process_new_device] idVendor: 0x05ac
libusb:debug [process_new_device] idProduct: 0x8507
libusb:debug [process_new_device] bcdDevice: 0x0419
libusb:debug [process_new_device] iManufacturer: 0x01
libusb:debug [process_new_device] iProduct: 0x02
libusb:debug [process_new_device] iSerialNumber: 0x03
libusb:debug [process_new_device] bNumConfigurations: 0x01
libusb:info [darwin_check_configuration] active config: 1, first config: 1
libusb:info [process_new_device] found device with address 2 at 002-05ac-8507-ef-02
libusb:info [process_new_device] allocating new device for location 0x06000000
libusb:debug [process_new_device] device descriptor:
libusb:debug [process_new_device] bDescriptorType: 0x01
libusb:debug [process_new_device] bcdUSB: 0x0200
libusb:debug [process_new_device] bDeviceClass: 0x09
libusb:debug [process_new_device] bDeviceSubClass: 0x00
libusb:debug [process_new_device] bDeviceProtocol: 0x00
libusb:debug [process_new_device] bMaxPacketSize0: 0x08
libusb:debug [process_new_device] idVendor: 0x05ac
libusb:debug [process_new_device] idProduct: 0x8005
libusb:debug [process_new_device] bcdDevice: 0x0200
libusb:debug [process_new_device] iManufacturer: 0x02
libusb:debug [process_new_device] iProduct: 0x01
libusb:debug [process_new_device] iSerialNumber: 0x00
libusb:debug [process_new_device] bNumConfigurations: 0x01
libusb:info [darwin_check_configuration] active config: 1, first config: 1
libusb:info [process_new_device] found device with address 1 at 001-05ac-8005-09-00
libusb:info [process_new_device] allocating new device for location 0x06100000
libusb:debug [process_new_device] kernel responded with code: 0xe00002ed. sleeping for 30ms before trying again
libusb:debug [process_new_device] kernel responded with code: 0xe00002ed. sleeping for 30ms before trying again
libusb:debug [process_new_device] kernel responded with code: 0xe00002ed. sleeping for 30ms before trying again
libusb:debug [process_new_device] kernel responded with code: 0xe00002ed. sleeping for 30ms before trying again
libusb:debug [process_new_device] kernel responded with code: 0xe00002ed. sleeping for 30ms before trying again
libusb:debug [process_new_device] kernel responded with code: 0xe00002ed. sleeping for 30ms before trying again
libusb:debug [process_new_device] could not retrieve device descriptor 0a5c:4500: device not responding. skipping device
libusb:debug [libusb_unref_device] destroy device 5.0
libusb:info [process_new_device] allocating new device for location 0x06110000
libusb:debug [process_new_device] kernel responded with code: 0xe00002ed. sleeping for 30ms before trying again
libusb:debug [process_new_device] kernel responded with code: 0xe00002ed. sleeping for 30ms before trying again
libusb:debug [process_new_device] kernel responded with code: 0xe00002ed. sleeping for 30ms before trying again
libusb:debug [process_new_device] kernel responded with code: 0xe00002ed. sleeping for 30ms before trying again
libusb:debug [process_new_device] kernel responded with code: 0xe00002ed. sleeping for 30ms before trying again
libusb:debug [process_new_device] kernel responded with code: 0xe00002ed. sleeping for 30ms before trying again
libusb:warning [process_new_device] could not retrieve device descriptor 05ac:8213: device not responding. skipping device
libusb:debug [libusb_unref_device] destroy device 0.30
libusb:info [process_new_device] allocating new device for location 0x06200000
libusb:debug [process_new_device] device descriptor:
libusb:debug [process_new_device] bDescriptorType: 0x01
libusb:debug [process_new_device] bcdUSB: 0x0200
libusb:debug [process_new_device] bDeviceClass: 0xef
libusb:debug [process_new_device] bDeviceSubClass: 0x02
libusb:debug [process_new_device] bDeviceProtocol: 0x01
libusb:debug [process_new_device] bMaxPacketSize0: 0x08
libusb:debug [process_new_device] idVendor: 0x0105
libusb:debug [process_new_device] idProduct: 0x0000
libusb:debug [process_new_device] bcdDevice: 0x0000
libusb:debug [process_new_device] iManufacturer: 0x00
libusb:debug [process_new_device] iProduct: 0x00
libusb:debug [process_new_device] iSerialNumber: 0x00
libusb:debug [process_new_device] bNumConfigurations: 0x00
libusb:debug [process_new_device] device idProduct == 0. will retry
libusb:debug [process_new_device] kernel responded with code: 0xe000404f. sleeping for 30ms before trying again
libusb:debug [process_new_device] device descriptor:
libusb:debug [process_new_device] bDescriptorType: 0x01
libusb:debug [process_new_device] bcdUSB: 0x0200
libusb:debug [process_new_device] bDeviceClass: 0xef
libusb:debug [process_new_device] bDeviceSubClass: 0x02
libusb:debug [process_new_device] bDeviceProtocol: 0x01
libusb:debug [process_new_device] bMaxPacketSize0: 0x08
libusb:debug [process_new_device] idVendor: 0x0105
libusb:debug [process_new_device] idProduct: 0x0000
libusb:debug [process_new_device] bcdDevice: 0x0000
libusb:debug [process_new_device] iManufacturer: 0x00
libusb:debug [process_new_device] iProduct: 0x00
libusb:debug [process_new_device] iSerialNumber: 0x00
libusb:debug [process_new_device] bNumConfigurations: 0x00
libusb:debug [process_new_device] device idProduct == 0. will retry
libusb:debug [process_new_device] kernel responded with code: 0xe000404f. sleeping for 30ms before trying again
libusb:debug [process_new_device] device descriptor:
libusb:debug [process_new_device] bDescriptorType: 0x01
libusb:debug [process_new_device] bcdUSB: 0x0200
libusb:debug [process_new_device] bDeviceClass: 0xef
libusb:debug [process_new_device] bDeviceSubClass: 0x02
libusb:debug [process_new_device] bDeviceProtocol: 0x01
libusb:debug [process_new_device] bMaxPacketSize0: 0x08
libusb:debug [process_new_device] idVendor: 0x0105
libusb:debug [process_new_device] idProduct: 0x0000
libusb:debug [process_new_device] bcdDevice: 0x0000
libusb:debug [process_new_device] iManufacturer: 0x00
libusb:debug [process_new_device] iProduct: 0x00
libusb:debug [process_new_device] iSerialNumber: 0x00
libusb:debug [process_new_device] bNumConfigurations: 0x00
libusb:debug [process_new_device] device idProduct == 0. will retry
libusb:debug [process_new_device] kernel responded with code: 0xe000404f. sleeping for 30ms before trying again
libusb:debug [process_new_device] device descriptor:
libusb:debug [process_new_device] bDescriptorType: 0x01
libusb:debug [process_new_device] bcdUSB: 0x0200
libusb:debug [process_new_device] bDeviceClass: 0xef
libusb:debug [process_new_device] bDeviceSubClass: 0x02
libusb:debug [process_new_device] bDeviceProtocol: 0x01
libusb:debug [process_new_device] bMaxPacketSize0: 0x08
libusb:debug [process_new_device] idVendor: 0x0105
libusb:debug [process_new_device] idProduct: 0x0000
libusb:debug [process_new_device] bcdDevice: 0x0000
libusb:debug [process_new_device] iManufacturer: 0x00
libusb:debug [process_new_device] iProduct: 0x00
libusb:debug [process_new_device] iSerialNumber: 0x00
libusb:debug [process_new_device] bNumConfigurations: 0x00
libusb:debug [process_new_device] device idProduct == 0. will retry
libusb:debug [process_new_device] kernel responded with code: 0xe000404f. sleeping for 30ms before trying again
libusb:debug [process_new_device] device descriptor:
libusb:debug [process_new_device] bDescriptorType: 0x01
libusb:debug [process_new_device] bcdUSB: 0x0200
libusb:debug [process_new_device] bDeviceClass: 0xef
libusb:debug [process_new_device] bDeviceSubClass: 0x02
libusb:debug [process_new_device] bDeviceProtocol: 0x01
libusb:debug [process_new_device] bMaxPacketSize0: 0x08
libusb:debug [process_new_device] idVendor: 0x0105
libusb:debug [process_new_device] idProduct: 0x0000
libusb:debug [process_new_device] bcdDevice: 0x0000
libusb:debug [process_new_device] iManufacturer: 0x00
libusb:debug [process_new_device] iProduct: 0x00
libusb:debug [process_new_device] iSerialNumber: 0x00
libusb:debug [process_new_device] bNumConfigurations: 0x00
libusb:debug [process_new_device] device idProduct == 0. will retry
libusb:debug [process_new_device] kernel responded with code: 0xe000404f. sleeping for 30ms before trying again
libusb:debug [process_new_device] device descriptor:
libusb:debug [process_new_device] bDescriptorType: 0x01
libusb:debug [process_new_device] bcdUSB: 0x0200
libusb:debug [process_new_device] bDeviceClass: 0xef
libusb:debug [process_new_device] bDeviceSubClass: 0x02
libusb:debug [process_new_device] bDeviceProtocol: 0x01
libusb:debug [process_new_device] bMaxPacketSize0: 0x08
libusb:debug [process_new_device] idVendor: 0x0105
libusb:debug [process_new_device] idProduct: 0x0000
libusb:debug [process_new_device] bcdDevice: 0x0000
libusb:debug [process_new_device] iManufacturer: 0x00
libusb:debug [process_new_device] iProduct: 0x00
libusb:debug [process_new_device] iSerialNumber: 0x00
libusb:debug [process_new_device] bNumConfigurations: 0x00
libusb:debug [process_new_device] device idProduct == 0. will retry
libusb:debug [process_new_device] kernel responded with code: 0xe000404f. sleeping for 30ms before trying again
libusb:warning [process_new_device] could not retrieve device descriptor 1ffb:0089: pipe is stalled. skipping device
libusb:debug [libusb_unref_device] destroy device 0.30
libusb:info [process_new_device] allocating new device for location 0x26000000
libusb:debug [process_new_device] device descriptor:
libusb:debug [process_new_device] bDescriptorType: 0x01
libusb:debug [process_new_device] bcdUSB: 0x0200
libusb:debug [process_new_device] bDeviceClass: 0x09
libusb:debug [process_new_device] bDeviceSubClass: 0x00
libusb:debug [process_new_device] bDeviceProtocol: 0x01
libusb:debug [process_new_device] bMaxPacketSize0: 0x40
libusb:debug [process_new_device] idVendor: 0x05ac
libusb:debug [process_new_device] idProduct: 0x8006
libusb:debug [process_new_device] bcdDevice: 0x0200
libusb:debug [process_new_device] iManufacturer: 0x02
libusb:debug [process_new_device] iProduct: 0x01
libusb:debug [process_new_device] iSerialNumber: 0x00
libusb:debug [process_new_device] bNumConfigurations: 0x01
libusb:info [darwin_check_configuration] active config: 1, first config: 1
libusb:info [process_new_device] found device with address 1 at 001-05ac-8006-09-00
libusb:info [process_new_device] allocating new device for location 0x26500000
libusb:debug [process_new_device] kernel responded with code: 0xe00002ed. sleeping for 30ms before trying again
libusb:debug [process_new_device] device descriptor:
libusb:debug [process_new_device] bDescriptorType: 0x01
libusb:debug [process_new_device] bcdUSB: 0x0200
libusb:debug [process_new_device] bDeviceClass: 0x00
libusb:debug [process_new_device] bDeviceSubClass: 0x00
libusb:debug [process_new_device] bDeviceProtocol: 0x00
libusb:debug [process_new_device] bMaxPacketSize0: 0x40
libusb:debug [process_new_device] idVendor: 0x05ac
libusb:debug [process_new_device] idProduct: 0x8403
libusb:debug [process_new_device] bcdDevice: 0x9833
libusb:debug [process_new_device] iManufacturer: 0x03
libusb:debug [process_new_device] iProduct: 0x04
libusb:debug [process_new_device] iSerialNumber: 0x02
libusb:debug [process_new_device] bNumConfigurations: 0x01
libusb:info [darwin_check_configuration] active config: 1, first config: 1
libusb:info [process_new_device] found device with address 2 at 002-05ac-8403-00-00
libusb:debug [libusb_get_device_descriptor]
05ac:8005 (bus 4, device 1)
libusb:debug [libusb_get_device_descriptor]
05ac:0236 (bus 4, device 2)
libusb:debug [libusb_get_device_descriptor]
05ac:8242 (bus 4, device 3)
libusb:debug [libusb_get_device_descriptor]
05ac:8006 (bus 36, device 1)
libusb:debug [libusb_get_device_descriptor]
05ac:8507 (bus 36, device 2)
libusb:debug [libusb_get_device_descriptor]
05ac:8005 (bus 6, device 1)
libusb:debug [libusb_get_device_descriptor]
05ac:8006 (bus 38, device 1)
libusb:debug [libusb_get_device_descriptor]
05ac:8403 (bus 38, device 2)
libusb:debug [libusb_unref_device] destroy device 4.1
libusb:debug [libusb_unref_device] destroy device 4.2
libusb:debug [libusb_unref_device] destroy device 4.3
libusb:debug [libusb_unref_device] destroy device 36.1
libusb:debug [libusb_unref_device] destroy device 36.2
libusb:debug [libusb_unref_device] destroy device 6.1
libusb:debug [libusb_unref_device] destroy device 38.1
libusb:debug [libusb_unref_device] destroy device 38.2
libusb:debug [libusb_exit]
libusb:debug [libusb_exit] destroying default context
libusb:debug [usbi_remove_pollfd] remove fd 4
libusb:info [event_thread_main] thread exiting