PDA

View Full Version : [Discussion] Interest in a powerful, small size USB to Dynamixel ?



Xevel
08-24-2011, 10:03 AM
Hi,

Just a poll: would you be interested in a programmable, very small USB to Dynamixel adapter/controller?

I made the USB2AX (http://paranoidstudio.assembla.com/wiki/show/paranoidstudio/USB2AX) with a friend for my Xachikoma project, and I was thinking maybe other people could be interested in it. As far as I know, there is no product in this niche...



Form factor: a dongle with a Type-A male USB plug and a little longer than an inch (around 3.5cm), with one 3 pin Dynamixel socket.

Different possible firmwares:
- (1) USB2Dynamixel drop-in replacement for AX/MX series (half-duplex TTL serial)
- (2) Simple controller, with possibility of automation of small tasks, like reading values from multiple servos in an efficient way... This one could also expose an HID interface to have low latency communication with the OS.
- (3) custom user firmwares. Imagine for example you made a Dynamixel-based joystick with force feedback: you could easily make a firmware to have it appear as a true plug&play joystick on your computer...
- (4) maybe even a full controller, with gait generator/player...

Two possible version:
- low-end version, max 1Mbaud, limited to simple firmwares [(1), (2) and simple (3)]
- high-end version, with 3Mbaud communication with the new MX series, large processing power and lots of flash/ram for complex programs and lots of eeprom for settings and motion sequences [any type of firmware]

Pricing: Low-end version a lot cheaper than an USB2dynamixel, high-end version priced between USB2Dynamixel and Arbotix.

100% open source/open hardware.

The target would be to use it with a PC, not as a standalone.
It would not take care of providing power to the servos, and would only have one 3pin Dynamixel socket, nothing superfluous.


Any thoughts? Do you think such a product would be of any interest to you or anybody? Ideas on how to make it worthwhile?
Thanks in advance!

EDIT Moved the thread, it was not in the right sub-forum :/

iBot
08-24-2011, 10:57 AM
Certainly an interesting option. Even the A plug is often better replaced with something smaller since the socket doubles the size.

To do a full drop in replacement for the USB2Dynamixel would require that you emulate the FTDI chip. Robotis software that talks to Dynamixels direct seems to demand an FTDI device. Emulating the FTDI gets you into license problems when you use FTDI drivers on the PC. So I would drop the USB2Dynamixel part. Which software did you test it on so far?

HID won't lower your latency, but the fact you can intelligently forward USB packets without a latency timeout puts you ahead of FTDI based device on bulk transfers.

DresnerRobotics
08-24-2011, 11:13 AM
Please email me with pricing details if you are looking for a distributor.

Xevel
08-24-2011, 12:25 PM
Even the A plug is often better replaced with something smaller since the socket doubles the size.

My first idea was that plugging the adapter directly into an USB port was the way to go to make the smallest possible USB to Dynamixel board.
With a smaller plug on the board, you would have to use a USB cable between the computer and the board, and the plugs in such a cable would as big as the controller itself...
My first try was without a real plug:
3418
This proved to be problematic: some USB ports are too loose to hold this kind of 'plug', it's less resistant to vibration than a real plug and it's not very durable. Hence my thoughts of using a big Type-A USB plug, even if it accounts for 50% of the size of the product.

If you have alternatives in mind, I'm all ears!



To do a full drop in replacement for the USB2Dynamixel would require that you emulate the FTDI chip. Robotis software that talks to Dynamixels direct seems to demand an FTDI device. Emulating the FTDI gets you into license problems when you use FTDI drivers on the PC. So I would drop the USB2Dynamixel part. Which software did you test it on so far?

I used the CDC/ACM USB Class, with the same library used in the Arduino Uno (LUFA, by Dean Camera (http://www.fourwalledcubicle.com/LUFA.php)), adapted to account for the "half-duplex" question. This allows for the device to appear as a serial port without the need for external drivers (a .inf descriptor is needed on Windows however, but nothing at all on Linux/MacOS).
I used it with the Dynamixel Wizard of RoboPlus without any problem, as well as on my custom software both on my Win7 64bits PC and various Linux boxes (I use 4 of these on the BeagleBoard of the Xachikoma, 2 as USB to Dynamixel, 2 as standard serial ports).
And alos, I only aim at communicating directly with the AX/MX series, not with the RX/EX series nor with the CM controllers.

Do you know if Robotis software makes use any of FTDI-only functionalities?




HID won't lower your latency, but the fact you can intelligently forward USB packets without a latency timeout puts you ahead of FTDI based device on bulk transfers.

I'm still a little fuzzy on the HID part, I still have to read the corresponding chapters of the USB specs :/


@Andrew: Will do soon, thanks!

iBot
08-24-2011, 03:01 PM
I usually remove the USB connector and wire direct to USB port or hub, so I guess easy enough to leave off the connector on your board and solder wires direct.

The FTDI dependancy seems to depend on whether the software uses Virtual Com Port(VCP) or the more comprehensive FTDI DLL (FT2XX.DLL) under Windows, or the ftdi_sio driver in linux. The old Dynamixel manager seemed to use the FT2XX.DLL, but Dynamixel wizard does not appear to( did not test at 1Mbps though). Some third party software does use these FTDI specific drivers too. I see in your code you set the baud to default of 1Mbps anyway.

It appears your Serial to USB flush timer is already 1ms ((256*64)/16MHz), so HID would not be faster. It would also require a special driver to be written for both Windows and Linux.

I like the optional spilt of the Rx and Tx on the serial. You may consider adding 5V ESD bus protectors to the serial pins. They are very low cost and do often save the controller in case of shorted wires on the serial bus.

Xevel
08-24-2011, 04:45 PM
I usually remove the USB connector and wire direct to USB port or hub, so I guess easy enough to leave off the connector on your board and solder wires direct.

Hardcore :o
Yet I guess it makes sense in some cases.


The FTDI dependancy seems to depend on whether the software uses Virtual Com Port(VCP) or the more comprehensive FTDI DLL (FT2XX.DLL) under Windows, or the ftdi_sio driver in linux. The old Dynamixel manager seemed to use the FT2XX.DLL, but Dynamixel wizard does not appear to( did not test at 1Mbps though). Some third party software does use these FTDI specific drivers too. I see in your code you set the baud to default of 1Mbps anyway.

Ok, I did not know that (my involvement with Dynamixel servos is quite recent, less than a year). I should indeed abandon the "drop-in USB2Dynamixel replacement" claim, as it would not work with software depending on the FTDI library.


It appears your Serial to USB flush timer is already 1ms ((256*64)/16MHz), so HID would not be faster. It would also require a special driver to be written for both Windows and Linux.

Serial to USB Flush frequency is not the only thing that matters in my experience. On Windows 7 I had very small latency when doing a READ on a servo (typically 0.7ms to send the command and get the result back), and on my Beagleboard with Ubuntu it jumped to 7ms. It seems that the kernel simply won't service the serial interruption more frequently than that... I might be wrong on that, but I sure would like to have other options to get rid of this insane latency without needing a RealTime kernel. In this case, I thought a HID solution would provide more reliable low latency on all OS.
And sure it would require custom drivers, yet installing a driver looks less daunting a task than trying to find a Realtime patch for the 2.6.37 linux ARM kernel.
(And it might be of very little importance, but it's 0.5ms ( 0x7F*64 / 16M), the timer is in Clear Timer on Compare Match and the Output Compare Register is 0x7F and the prescaler is /64).



I like the optional spilt of the Rx and Tx on the serial. You may consider adding 5V ESD bus protectors to the serial pins. They are very low cost and do often save the controller in case of shorted wires on the serial bus.

Good idea, we will look into it.

Gertlex
08-25-2011, 12:03 AM
I had meant to ask you about this when I found it via the link you posted in the Xachi thread... but forgot; needless to say, I'm definitely interested in this as a nice tool for debugging/testing.

iBot
08-26-2011, 10:23 AM
I just downloaded your code , rebuilt with latest LUFA and put onto a minimus board and it works good.

Putting a USB analyser on the connection, I see surprising fast polling of endpoint 3 in both Windows and Linux.

With a Windows 7 i7 machine, endpoint 3 is polled about every 10 microseconds by the PC ( USB and PC not very busy). Endpoint 2 is polled every 30 millisec

On a Linux laptop endpoint 3 is polled about every 15 microsec, and not seeing any poling on endpoint 2.

Can you let me have your test programs and I will make measurements on those to see where the delays occur under Linux.

Also interested in your USB2MX project. I did something similar on LPC1343 for Robobuilder and Darwin, so might be able to share code. I used LIS331 and L3G4200D on the SPI bus for tiny and cheap IMU. Also brought out the I2C pins and connected to BlinkM RGB LEDs for eyes. Basically an finger sized CM730. Not really interested in commercialising mine, but could help you. The 32bit cortex can do the bulk reads and intellgently manage the USB protocol to optimally return packets of the correct size.

Xevel
08-26-2011, 12:17 PM
I quite frankly envy you for having an USB analyser :D

Not necessarily relevant to the matter, but more to my understanding of the USB communication protocol:
Are you sure it polls every 10µs ? This would make a polling at 100kHz. I read somewhere USB time frames were 1ms for low/high speed, and 125µs for full speed (source (http://www.beyondlogic.org/usbnutshell/usb5.shtml#EndpointDescriptors)), and polling could be made every X frames, X being between 1 and 255. Or am I completely misinterpreting what you said?
Or maybe you have USB 3.0 ports (aka super speed) and, as we can suppose, polling can be way faster... USB3 is looks 10 times faster compared to USB2.0, it would make sense to have ~12 µs polling...

Anyway,
I chose to measure the time spent in a Dynamixel READ_DATA as a whole, so it consists of the time spent by the OS + time spent for communication + time spent in the USB2AX + time it takes the servo to respond, and the same whn it comes back.
Servo configuration : Return Delay Time is set to 0, baudrate is 1Mbaud

You can replicate the experiment by sending a command to read one byte of data, and see how low it take to wait for the data to be available to your program.
Or you can wait until I rewrite the test, since I can't seem to find the one I used at the time :/


As for the USB2MX, I haven't started software development (and my friend has not started the PCB either), but I thought I should try to make something easily portable. Sharing code with you might be the incentive I need to put myself to work on this ^^. I might take you up on this, but I can't give you any time frame since this project is not my priority (it will be a little expensive).

iBot
08-26-2011, 01:53 PM
I was sort of surprised by this too. In fact 90 polls from host to device within one 1ms frame ! But this done automatically by host and device controllers

The host is a high speed USB 2.0 port through translating hub. No other traffic, USB analyser is on different High Speed USB port.
This implies HID would only be better in high load conditions to reserve at least 1 poll per frame if there are other high load bulk devices on same bus.

I will test some more. We know the AX12 return delay range to be typically around 30 microsec with occasional additional delay of 50 microsec, so be interesting to find if your additional longer delays are driver or OS related.

Xevel
08-30-2011, 07:35 PM
Here are some files to test latency : 3441
You need Python 2.x (I use 2.7) and PySerial.
Modify latency_test.py to set your serial port name and the ID of the servo it will ping. The servo is supposed to be communicating at 1Mbaud, but you can change that too if needed, in the same file.

On my Windows 7 64 bits box I get these results (time in seconds, 10 samples) :


0.00100016593933
0.000999927520752
0.00100016593933
0.000999927520752
0.000999927520752
0.000999927520752
0.000999927520752
0.000999927520752
0.000999927520752
0.000999927520752
servo ID: 17
mean 0.000999975204468
max 0.00100016593933

Sometimes it will show 0.0s for a sample, and that must be why I thought at some point that the latency could be less than 1ms (at the time I only showed the mean time). I have to track this error, but it most likely comes from my python code written during one of many febrile sleepless nights.

Also, unfortunately I don't have my Xachi at hand, and no other Linux board or box in working condition to provide any worthy data for Linux right now. But one thing my experimentation have been consistent about: on a standard Ubuntu, the latency will be much higher than that.

I would be very grateful if you could test it and help me find a solution to decrease said latency without resorting to a real-time kernel.

And by the way, if you may ask: my experience with set_serial is that it does not recognize this virtual serial port as a serial port, and consequently does not allow the use of the low_latency setting.

Xevel
09-02-2011, 04:58 PM
I just tested the same script on Xachi (Beagleboard-xM runnning @800MHz, Ubuntu ARM 10.10 headless, Linux omap 2.6.39.1-x2, Python 2.6.6, Pyserial 2.3-1)... and it does not look like what I remembered at all.

With the code previously posted:


0.00207495689392
0.00192284584045
0.00216698646545
0.0018618106842
0.0019838809967
0.00338697433472
0.0021059513092
0.00204491615295
0.00216698646545
0.00213599205017
servo ID: 23
mean 0.00218513011932
max 0.00338697433472

What has changed between my first tests where I had >7ms latency and now
- upgraded kernel from 2.6.37-x2 to 2.6.39-x2
- updated PySerial, but I don't remember the previous version
- but mostly, my python code was written in an extremely inefficient way I learned. Now it's just intermediately inefficient. With a little modification I got to 1.5ms, and I guess the last 0.5ms could also be shaved off to get to the theoretical minimum of 1ms.



So as I understand it, the minimum round trip delay at application level is 1 USB frame (1ms), non negotiable.

iBot
09-03-2011, 05:46 AM
Here is what I have found so far:

First worked on Windows 7 ( i7 desktop, Windows 7 64 bit). Using Python 2.7.2.

Servo baud is 1000000, servo return delay = 0, servo ID = 1

The USB2AX code is running on a Minimus AVR USB 32. Also using standard USB2Dynamixel(latency = 1) as reference.

When I first started using your python code I got results similar to yours, but was concerned about the zero values. Clearly two sequential calls to time.time() should not return the same value. It does appear that the updating of the value returned by time.time is only about every millisecond, this gives the zero values and the apparent 1ms quantisation. I don't know a fix for this, so I changed the latancy test to loop 1000 times and measured the time for the entire loop. This gave more consistent results though it would still be useful to have individual values to see if any quantisation still exists, and also to know the maximum value.

With the updated python code, I consistently got values of between 700 and 750 microseconds for the python loop of the ping. From the USB analyser I see the time from the start of the OUT transfer to the end of the IN transfer, to be between 500 and 600 microseconds depending on whether the returned data is split over two packets. The IN endpoint is being polled around every 20 microseconds.

I did try two alternative forwarding schemes in the USB2AX to see if any significant improvement was made. The first was to ensure all packets were full and starts a 64 us timer on the first character received and resets timer on each received char, sending when timer expires. This did result in full packets, but did not significantly improve latency. The second was just to send any characters available without waiting. This gave more smaller packets but again did not substancially change latency. I thought smaller packet may be worse for the OS to handle, but they actually may be better since the parse routine then gains some parallel action to the serial reception.

Overall I would say that the 700-750 microsecond performance on the PC is very good. A lower spec. PC and heavier load will obviously make a difference.

The USB2Dynamixel by comparision gave results in the range 1000 to 1500 microseconds, most likely due to the 1ms latency setting.

I also tested with a C# program using the Dynamixel library from Scott Ferguson and got similar results.

Have now moved over to Linux notebook (Pentium 4 1.8GHz) Ubuntu 11.04 Kernel 2.6.38-11. Python 2.7.1

Testing the USB2AX I do get about 3 timeouts per 1000 pings and an average response of 4 milliseconds. With the USB2Dynamixel, no timeouts, but also around 4 milliseconds. USB analyser shows the USB transaction being as fast under Linux as Windows, so all the rest is in linux kernel, drivers, or application. The timeout appears to be caused by linux, the USB2AX responded correctly within 500 us, but the next ping was not until 200 millisec later.

I will investigate further and can test your new Python code if you like.

Xevel
09-03-2011, 05:24 PM
Very interesting, thanks!

On the resolution of time.time(): from http://mail.python.org/pipermail/python-list/2007-January/1121263.html

Under windows time() counts in 1ms steps wheras it usually counts in 1us steps under linux.
This explains that. Thanks for pointing it out.
Even though it has better accuracy, using time.clock() is not really an alternative to time.time() since it does not count the actual time passed between two event, only the processing time. So I guess your fix is as good as it gets on windows.
Also, I don't intend to pursue the use of my python Dynamixel library, so I don't think we need to bother optimizing it now.



On the alternative forwarding schemes: while it does not seem to provide any interesting optimization in this particular case where only a handful of bytes are sent back, maybe the question of having better forwarding schemes will resurface with the improvements I have in mind for the firmware.



The problem I want to solve is as follows: I have 19 dynamixel servos I want to send positions to, and get back their actual position. How fast can this be done without touching the firmware of the servos (so this rules out the alternative firmware made by the guys at Actuatedcharacter (http://actuated.wordpress.com/) and the work of RicardoMarinheiro (http://robosavvy.com/forum/viewtopic.php?t=7021)) and without changing the dynamixel protocol?


Sending many positions at once is not hard: sync_write, or alternatively write all the positions one by one with the return level set to "reply only on read".

But currently, to get data back, the control software running on the PC has to send a command, and wait for the answer before sending anything else. If properly multithreaded, the delay can be put to profit for other calculations by the CPU, but if you look at it from the point of view of the Dynamixel bus, it's very inefficient. Only 1 command passes on the bus every once in a while, when many more could have been sent and answered.

The first improvement that we can imagine (and that I used in my Xachi) is to send a command, wait a little, send another one, wait a little... until you have sent all the commands you wanted, and then only start reading the answers, which have piled up in a receive buffer somewhere in the low layers of the your OS. The "wait a little" part is crucial: it lets time to the servo to answer. Hence, the total delay (time.sleep() + all the delay induced by the various layers of communication) has to be at least as long as the time needed for the Dynamixel device to answer.
This allowed me to make some significant improvements to the overall latency I experienced in the beginning (which I still don't know exactly WHY it disappeared ><), yet it is still not the fastest that can be done, and creates conflicts sometimes when unplanned latency arises at any step of the communication. Overall, a dirty trick.

What I think would be the best thing possible without changing the protocol (meaning I don't allow the computer to send command intended to be interpreted by the controller) would be to implement a form of message queue in the controller.
The USB2AX would receive bytes and parse the messages succinctly, just enough to know two things: the boundaries of each command, and maybe the type of command. it would then be able to make a queue of commands that need sending, and would process them one by one. Knowing the type of command would be used to determine if an answer is awaited.
This poses a few potential problems, to which I propose the following answers:


Servos can be configured to answer every command, only the read and ping, or only the ping (Status Return Level)

We could expect all the servos to be configured the same, in a predefined way possibly tweakable in the firmware source code.
if having all servos configured the same is not a satisfying option, we can imagine the controller keeping a (possibly dynamic) record of the servos it knows are on the line, and the first time it talks to them would ask them their verbose level. In addition, the controller would monitor any write command to the corresponding registry and update the information in its internal database too. But it's a little too complex and maybe could have side effects...


Servos can be configured to wait a little before answering.

Just remove this damned delay already ><


What happens if a servo does not answer?

Standard timeout.



My current feeling is that the overhead would be more than offset by the improvements made by having the controller pass to the next command immediately after the previous one has been answered. Plus their shouldn't be any risk of bus contention.


The next upgrade would be to have the controller be a Dynamixel device too. I only glanced at it, but isn't it how the CM-730 works?
This way, we could simply configure the details of communication.
We could also have a simple means to run the bootloader, allowing easy upgrade of the firmware without the need to press small and scarily costly buttons. I'll try to get back on the problem of flashing the firmware in a post to come, it has physical implications I would like to discuss.

An alternative would be to have a second endoint (another COM port?) for configuration, but having two com ports would be confusing.


So, what do you think would be the features of an adequate firmware for the retail version of the USB2AX?
- simple virtual com port?
- version with queued messages?
- no way to manage the controller itself?
- addressable as a dynamixel device?

I think the version with queued messages and a dynamixel device has the best potential. By default, the queued command system would not be active, and you could configure it by changing a few registries just like any other dynamixel device.

I'm interested in whatever you may think of it!

Xevel
09-06-2011, 06:50 PM
Just an update to the latency test. Please replace this file in the previous archive (for Linux only since it relies on time.time): 3463

iBot
09-14-2011, 06:18 AM
Sorry for the dlay to reply.

I tried the new test, but still have latency around 4 ms under Linux on my aold laptop, compared to less than 1ms under WIndows. I need to try some other Linux devices and kernels.


On the alternative forwarding schemes topic. I still prefer the addition of sync read to the controller. Since the sync read from Mike Ferguson is simple and supported by his ROS Dynamixel software, I propose this.

Although the ATMega32U4 has a high proportion of space spare, it is not really enough to hold poses, so I think it is not possible to add the interpolation from Mike too.

An alternative might be to add an interpolated sync write command. It would add time and steps parameters to make an new sync write command. Interpolation would be from previous sync write. Only slightly tricky part is to mix the controller generated sync writes with other bus transactions coming down the USB.

Xevel
09-14-2011, 10:05 AM
Sorry for the dlay to reply.

Please don't worry about this :)


I tried the new test, but still have latency around 4 ms under Linux on my aold laptop, compared to less than 1ms under WIndows. I need to try some other Linux devices and kernels.

Ok, thanks :)
On my beagleboard, this modification allowed to decrease the latency to around 1.1ms (from 2.1ms).


On the alternative forwarding schemes topic. I still prefer the addition of sync read to the controller. Since the sync read from Mike Ferguson is simple and supported by his ROS Dynamixel software, I propose this.

Although the ATMega32U4 has a high proportion of space spare, it is not really enough to hold poses, so I think it is not possible to add the interpolation from Mike too.

An alternative might be to add an interpolated sync write command. It would add time and steps parameters to make an new sync write command. Interpolation would be from previous sync write. Only slightly tricky part is to mix the controller generated sync writes with other bus transactions coming down the USB.

Ok, I will look into it Mike Ferguson's work. Even though I'm not a fan of custom protocol extensions, it seems like a good idea to be compatible with what is already in use instead of going my own way.

About the way to flash the firmware:
Buttons on the board would have to be extremely small, which would make them expensive and not very easily accessible. That was the route I took for the first prototype and the buttons I found cost roughly 30% of the price of the board and are not easy to press, sometimes it is even impossible when the USB2AX is plugged besides other USB devices.
I'm strongly thinking about adding an auto-update feature, a way to enter bootloader mode by sending a particular string to the USB2AX, without having to physically touch it.
It should have the following properties:
- don't make the code too much more complex
- no risk being triggered by mistake
- no significant slowdown of the communication

First, the detection could be limited to a predefined baudrate, a slow one that people would not normally use to communicate with Dynamixels (9600bauds for example). The overhead would then be low compared to the time it takes to send a byte on the serial port.
At any other baudrate, the code would not even check if the trigger pattern is transmitted.
It would use a trigger pattern that has very low probability of being transmitted, and a timeout for good measure.

However, I still have to find is how to perform a reset after FLIP has programmed the MCU...

More interesting firmwares are definitely something I (and/or probably other persons) will work on, but I won't include them in the final product until they are well-tested.

Xevel
09-17-2011, 01:51 PM
Here is some progress on the hardware.

Thanks to help from iBot, we finally added protection devices: ESD protection on the USB lines and TX/RX lines plus 47ohm resistors on the TX/RX lines, just like in the original USB2Dynamixel :)
The Hardware Boot and Reset pins are now broke out on the side of the board, through a standard 0.1" header.
Decoupling capacitors are applied according to the recommendations of AVR042 and the ATmega32u2 datasheet.

The current length of the USB2AX is slightly above 33mm (including the giganormous USB Type-A male plug), for a board where all the SMD components are soldered on the top side. Depending on the cost of manufacturing, we may change to put SMD components on both sides, and shorten the board a little more.

Schematics:
3484

Eagle files (also available from the git repository (https://www.assembla.com/code/paranoidstudio/git/nodes)): 3485

This is the version I intend to have a few prototypes made, if no critical flaw is found.
(EDIT: the USB footprint needs some fixing )

Feedback very welcome! Thanks!

iBot
09-20-2011, 09:12 AM
I made a version of the USB2AX firmware to include the SYNC READ capability from Mike Ferguson.

Because I am still struggling with latency on my linux laptop, this makes a big difference in performance from using the sync read.

USing Python for a read of 4 bytes (speed, position) from 18 AX12:
Windows 7 READ 20ms
Windows 7 SYNC READ 8.5ms

Linux READ 72ms
Linux SYNC READ 9.4ms

Will try it out with the Vanadium Labs software. Should work with URBI too with id change.

I will send you the source, so you can try it.

Xevel
09-20-2011, 10:32 AM
Awesome! :D

I should be able to finalize the v3.0a board design this week (the silkscreen is still missing, mostly), and have the prototypes boards manufactured directly after that (8 days turnaround). I will assemble between 6 and a dozen boards (I will have access to a manual pick and place and a reflow oven \o/ ) and get them to beta testers immediatly after that.

Stay tuned!

Xevel
09-23-2011, 09:45 AM
Proto PCB ordered!

If I'm lucky, They will arrive around the end of the month. If I'm not... it will be around the 10th of next month, due to holidays in China.

Xevel
09-29-2011, 05:19 AM
All elements (PCB, solder paste stencil, components) are shipped from various parts of the world and should arrive between today and next Monday. Assembled proto should be ready Wednesday.

Xevel
10-06-2011, 10:24 PM
http://www.xevel.fr/blog/public/usb2ax/P1010183.JPG


There! Almost a dozen of functional USB2AX v3.0a :)

All assembled by yours truly, with a nice manual pick and place. I will now send some to the beta-testers to get feedback.

I have parts to make up to 25 of these, so if you desperatly want one and can't wait for the professionally-assembled ones, drop me a PM or a mail.