USB2AX v3.1

[Xevel]

Hey guys,

I have been pretty quiet in the last few month, but I have been quite busy nonetheless on the USB2AX project.

I identified a lot of problems ranging from futile to critical with the 3.0a and 3.0b, and some of them took months to fix. I now have a new version I am satisfied with and if this one does not reveal any new show-stopper, I'll finally move on to the next stage and have some produced (yeah, I know I've been saying that for more than a year now... but I think the wait was worth it). Browse: Publix Ad Preview and Kroger ad this week on Weekly Circulars.





On the software front:
- Sync_read.
The USB2AX firmware now supports inxfergy's sync_read command, as well as iBot's version. Tests showed that you could read the position of 10 servos (AX or MX) in less than 4ms... Thanks to iBot!

- low latency.
On all the test I made using Virtual Com Ports, it's always at least a little faster than the USB2Dynamixel. Sometimes up to a lot. I'll work on verifiable numbers for the release.

- firmware updates.
The board can now be updated without human intervention. Just run a script and it's programmed. Still based on great work by iBot!!! The windows version should be OK soon, working on ironing out the Linux version.

- There used to be a problem with the CDC class blocking the communication host => servos when the host did not read what the USB2AX sent. This was annoying since failing to read the status packets would make the system incapable of sending new commands... FIXED, and the work I did for that is the basis of a LUFA patch for the VirtualSerial demo in the next LUFA release.

- Speaking of LUFA, v3.1 will be supported by the next LUFA release. (thanks Dean!)



On the hardware front, v3.1 has some cool new features:
- ESD and continuous over-voltage protection on DATA.
At the last Eurobot competition, I met two guys who have had problems with the +12V line touching the DATA line (bad custom board, or damaged cables). One had an USB2AX and the other an USB2Dynamixel. In both cases the interface boards stopped working. The guy with the USB2Dynamixel removed the fried ESD protection chip and plugged it back.. only to have another short, and this time a burned motherboard on his PC. So that's pretty serious stuff: I don't want my product to be neither disposable nor a risk for the computer it's plugged in!

Earlier version only had ESD protection. Whenever there would be a contact between DATA and the +12V line of the dynamixel bus, the ESD protection chip would fry, protecting the ATmega and USB port of its dead body... Fixing the board would then require changing the 1.5x1mm chip with 6 pads underneath, not something enjoyable, even with the right tools.
Now, you can zap the dynamixel bus with sparks or short +12V and DATA as long as you want, and when the short is removed, it resumes as if nothing happened. The battery is also protected, since the failing state limits the current to ~20mA. And on the USB port, you still have the same old ESD protection, this one was OK for this use.

- SPI breakout 0.1".
Breaking out the SPI pins gives you the possibility to hack it a whole lot more. You can reprogram it using ISP, you can interface stuff, sensors, whatever. That's something I've been asked a few times, now it's possible

- Two Leds (Red and Green).
You now have a second status LED to play with. By default, the red led is affected to "USB not ready" or "USB enumerating" and the green one to "USB Ready", but you can hack it away to debug stuff, to show traffic, whatever you need.

- Cute, and still 0.5mm shorter than v3.0!

You can still unsolder the Dynamixel connector and cut a jumper to have a full duplex serial interface, and the RST and HWB pads are still available: you won't ever brick the USB2AX with software mishaps.

I also lowered the part count, cleaned up all the component footprints, rationalized the BOM, worked on a full test suite (software and hardware, still a WIP), ...

The website with doc / tutos is a work in progress. Should be up when the first batch is finished. I'll cleanup the stuff that is currently available online to make it easier for people to get information, right now it's divided, incomplete and often obsolete.


I would like to make a last round of beta before pushing the button on a few hundred units, people willing to provide help with testing can contact me by PM.



There. I'll try to work out a way to help people with prototypes to upgrade to the commercial version at reduced cost. It wouldn't have been possible to do it without you

Edit: About the ESD protection: I've been zapping two test boards with a piezo igniter all morning, and so far, I managed to fry the LEDs on one of them, nothing more. They still happily talk to the servos
And for over-voltage protection: I shorted DATA and +12V with a fully charged 3s1p LiPo for minutes without a problem.

[jwatte]

That looks great!

For the new protection, what are you using? A small polyfuse?

[Xevel]

For the new protection, what are you using? A small polyfuse?

A 5.1V zener diode, a PTC resistor of 100ohm and a 150ohm resistor like that:


This is borrowed and adapted from the Ruggeduino.
The 150R is a 0404 2 resistor array.
The 5.1V zener diode datasheet.
The PTC resistor datasheet.

While it is not really my domain, my understanding of the circuit is this (BEWARE, IT MIGHT BE WRONG):
- on normal operation, the zener diode does not let the current flow at all and the equivalent circuit is just an equivalent resistor or 250ohm between PD3/PD2 and DATA. Not enough to be a problem.
- if there is an ESD on DATA, meaning a short pulse (100ns?) with very high voltage (a few kV), then the zener diode tries to clamp it to 5.1V and the "normal" resistance of RPTC1 tries to limit a little the amount of current... but I guess it's not a big factor since it would limit it to a few A. The diode is rated for >16kV HBM, so as far as I understand it, it means that it will be able to "eat up" this pulse without failing, mostly on its own.
- when 12V DC is applied on DATA, at first the zener diode lets the current flow and sets its reverse voltage to 5.1V. The 100ohm resistance of RPTC1 gets the rest of the voltage (~7V) and limits the current to around the maximum that the zener can withstand. If the problem persists, the PTC heats up and its resistance increases, decreasing the amount of current the diode has to deal with. I measured a steady current of around 20mA, which makes the power dissipated by the diode around 100mW, half of its standard rating at 25°C.
EDIT: In the meantime, the atmega pin only sees 5.1V. R3.2 limits the current that the MCU has to supply if the pin were to be driven low (it would be a short otherwise).

I hope these are not misconceptions :/
One thing I am sure of is that the prototypes currently hold up to the abuse I made them to withstand.

[Gertlex]

Looks great! I see you copied Apple and used rounded corners

Enjoyed the detailed write-up, too. Thanks

[Xevel]

Looks great! I see you copied Apple and used rounded corners

I haven't received the cease and desist letter yet
But the final version won't have rounded corners anyway :/

It seems that the details of the milling process are different when you want arbitrary shapes, and might get less precise.

This caused errors on the PCB:



This is not acceptable, it makes the USB plug nearly impossible to insert without manually filing the board first. And since I don't really want to have sub-par products nor have the guys at the factory file each board individually to correct this, I'm going back to regular pointy corner...

[jwatte]

That looks like the end mill simply didn't cut far enough through the PCB. That might happen for a straight cut as well (unless they do V-groove and break there instead)

Your understanding of the protection agrees with mine -- I'm also a fan of the Ruggeduino :-)

The Zener might not be rated to be fast enough for full ESD protection, but the AVR pins actually have some ESD protection of their own, so I think your design is quite robust enough. I wish everyone who built gear would be that careful!

[Xevel]

Guys guys guys, hey guys!
The first batch is going into production

[jwatte]

Sounds great! I was just going to say that 150 Ohms for the LED outputs looks like they allow more current than necessary.
Small LEDs are fine with 2 mA of current. Assuming you run the AVR at 3.3V and the LED has a voltage of 1.8V, then you need a 750 Ohm resistor to get the necessary current. Running it too hot will waste energy, and may blow it out over time.

[Xevel]

Thanks jwatte
Here is the datasheet of the LED used : http://www.avagotech.com/docs/AV02-0584EN
The model I use is HSMF-C165. The red (High Eficiency Red) is given for a typical [email protected], the green one (GaP green) is [email protected]
The AVR runs with the voltage of the USB bus, so around 5V (often +/- 0.1V or more...).

With 150ohm, I get around their typical rating. Plus I can use the same value of resistor on the communication lines
The LED dissipates around 40mW each, and on normal operation only one is used at the time. With a typical thermal resistance of 325°C/W, that's only a couple degrees of temperature elevation at most, if I'm not mistaken. Plus the two GND pads are on a copper pour, so the actual thermal resistance should be lower.

I tried with 470Ohm and 1kOhm resistors too, the luminosity was not that great... I kind of want these to be visible even when the robot is not in your hands.

[jwatte]

Yeah, on a USB powered device, it's not so bad. But for anything battery powered, you really want the low-current ones. What is your USB power budget, anyway? If it's 50 mA, and you spend 40 mA on indicators, that's a high percentage. Then again, if the indicator is actually an important part of the use case, then it's probably worth it like you say.

Also, the LEDs dissipate 40 mW (2V * 20 mA) and the current limiting resistors dissipate another 60 mW :-) If the current draw matters, that's something you want to control for.

Anyway, I look forward to seeing this complete! I might get one myself!