Deport USB port to the case

J

jbax

Member
Hi all,

I'm designing a product where I need the teensy to communicate with a software on a PC, via serial connection.
For now in my tests I've used the USB device port on the teensy without any issues
For the final product I'd like the customer to be able to connect to a port on the case.
So I've got several solutions :

Solution 1
Just use the usb device port with a cable like this one : https://www.pjrc.com/store/cable_usb_panel_micro.html
Issue : I fear that the connector will get damage/bend after years of use, also needs to cut the 5V.

Solution 2
Use the usb host port (i don't even know if it's possible software-wise but let's assume it is)
Issue : not possible to solder the USB host pins to the PCB, so once again a mechanical issue .

Solution 3
Use one of the serial ports of the teensy, and have the user use a usb to serial cable
Issue : can't trust the user to always use the correct cable, need to use standard cables and connectors.

Solution 4
Use one of the serial ports of the teensy, and an external usb to uart controller.
Issue : overkill BUT everything can be handled on the PCB

I plan my product to be solid, usable for years, able to be transported, and used in vibration-heavy environment, hence the mechanical issues that some teensy users may not face.

For now I plan to use solution 4 as this is the only one which do not create mechanical issues, but seems way overkill.
I post here in hope that they may be a better solution that I overlooked.
 
Last edited:
With respect to solution #4; wouldn't you need a connector to the outside world for this solution as well? I'm assuming here that the "external usb to uart controller" is inside the box on a kind of carrier PCB.
Solution #1 might not be too bad since that USB type B connector is pretty sturdy [and perhaps relatively easy to replace]. But the biggest advantage of solution #1 is that you still can update the firmware on the teensy.

Paul
 
Thanks for your answer
I realize some info is missing : the teensy will be soldered onto a main PCB board where we plan to put the usb to uart for solution 4.
The user controls on the case, including the usb port, will preferably soldered directly on the main pcb board. That's what I was thinking for solution 4.
The worry about solution 1 is that the teensy micro usb connector may suffer damage/bend the board after years of use, from the weight of the cable.
User update of the firmware is not a requirement for this product, so the USB device port may be inaccessible, that's not an issue.
 
Allright, thanks for the additional clarification.
So, if I understand you correctly: the USB port on the case will only be used for serial I/O. And you would like to avoid a cable for mechanical reasons, being the vibration of the cable that damages the Teensy USB connector.

I still would prefer solution #1 with sufficient mechanical support for the cable. In a previous life as product designer, I have done extension cables in more than one design [not Teensy USB cables but DC jack cables to add-on boards mounted on a carrier board]. With proper mechanical support we never encountered issues in that area.

Another option however is to use low-profile pogo pins or other spring-loaded contacts to connect the Teensy USB signals to the carrierboard. Every Teensy 4.x has the D+ & D- signal exposed on pads on the bottom of the Teensy PCB.
Whether the above mentioned pins or contacts are feasible depends on the height of the soldered Teensy.

User update of the firmware is not a requirement for this product, so the USB device port may be inaccessible, that's not an issue.
Click to expand...
I tend to believe in Murphy's law, so I wouldn't throw away the option to update the board just yet...

Paul
 
Thank so much Paul for your insight. I'll check with the rest of the team, and update the thread with the chosen solution.
About murphy's law, my thinking is that a maintenance technician would still be able to pop the lid off and update the teensy via the micro usb port. Allowing the end user to update the product is out of our scope for various other reasons, but I would agree that not preventing this would be a plus.
 
What about these clamps for holding the cable in place?
1707390887942.png

https://www.icotek.com/en/products/emc-cable-shield-clamps/pcb
Icotek seem to have a lot of useful cable strain relief products.

Paul
 
Hi,

Unless it is for diagnostic and/or configuration, use of USB in industrial environment is not a good idea.
USB is not EMI resistant. A simple ESD on the connectors or case, and you loose the connection. Generaly, on the PC side. At best, you disconnect/reconnect the cable and communication restart. But sometimes, you should reboot the PC.
You can try the best cables, but the weak point is the PC itself. I learned it the hard way.

My suggestion is to use a serial port, with RS-232 levels. And a PC with a native COM port. But you will be limited to less than 1Mbit/s. And such PC are hard to find.
In railway construction machines, I use ethernet with M12 connectors. Reliable against vibrations and EMI, shielded cables, all sort of fluid resistant,..... You can buy cables M12 to RJ45. May be expensive, but easy to replace.

Angelo
 
Thanks Angelo for your input.
I previously did work with M12 connectors on some products in the transportation domain.
For your suggestion, an alternative to A PC with com ports would be a usb/rs232 adaptor.
We're not too concerned about ESD/EMI but rather vibrations, i.e. physical movement.
 
Hi,
If your application is protected against EMI, a simple usb-RS232 will do the job.
Choose one based on FTDI devices. No surprises on the long term with drivers, new windows versions, fake units, .....

Canbus is also an option. It needs a simple transceiver on the hardware, and a USB-CAN converter.
And you can have multiple devices on the same bus.

Angelo
 
The USB Host port on the Teensy 4.1 uses an extra chip to protect against ESD (among other things).
 
Hi,

The ESD prolem doesn't cause a crash or errors on the device, but on the PC. USB controllers on PC doesn't handle problems on signal lines.
I found that you could have 3 levels:

1) Driver returns errors, you can restart transmission by software in your application. You should handle this. you are not sure what appened at application level on the device.

2) Driver returns errors, but you can't do anything in your application to restart communication. You should disconnect the device to completely re-enumerate the device. You should also restart your application.

3) Everything is crashed, freezed, with possible BSOD, and you should cycle the power off-on to restart the PC.

Often, in all 3 cases, your device is patiently waiting on connections from the PC. But you should handle communication loss in you device application.

Angelo
 
You must log in or register to reply here.
Back
Top