Reliability: Teensy Appropriate for Dedicated Industrial Grade USB Device?

Status
Not open for further replies.
T

TechnoFrolics

Member
Hello Paul,

I have not used your (very nice looking!) board previously, but am considering it for a museum/industrial-grade project where I need to stream multi-channel PWM data 24x7x365 from a C++ program running on Windows via USB.

My questions are:

1) Is the USB connection to a PC reliable enough to allow such industrial/museum use?
(I am not referring to mechanical USB connector - item will be within a protected box - but rather electrical/firmware issues.)

2) Does the answer to 1 (if in the affirmative) include environments where static discharges to nearby surrounding metal surfaces are present?
(E.g., museum visitors touching metal elements of cabinetry etc.)

3) Is there anything else I have omitted asking about that would contraindicate such a usage of your board?

Context for my question, based on over 25 years experience developing museum exhibits:

A) In the first half decade after USB's introduction, static sensitivity was so bad (whether due to USB hardware, USB firmware, or both, and whether originating on the PC side, the device side, or both) that sparking a 1ft x 1ft aluminum plate with Piezo charcoal lighter, *placed 2 feet away from USB keyboard and/or mouse (as well as many commercial I/O digital/analog data acquisition and machine control devices), and entirely unconnected to anything* (i.e., just EM pulse in space - no wired connection of any kind), would more times than not cause keyboard and/or mouse (and other "industrial-grade" USB I/O devices) to disconnect permanently until manual USB connector unplug/replug cycle or PC reboot.
(In consequence, we simply could not use USB - we had to use RS232/RS485 serial. Things are better now.)

B) Even today, over 1-1/2 decades after USB's introduction, we have found zero USB-connected hard drives that stay reliably connected to a Windows machine running 24x7x365.
(SATA virtually always fine - so not just "a Windows thing".)


Thank you,
David
 
I'm an electronics engineer and I have and I am using some dozen T3.2s in industrial applications, some facing the same or even worse problems than the ones you described. E.g. one application I designed was a metmast sticking up 20m (65ft) in the air in an open field, making it very susceptible to lightning EMI (or even lightning strike itself). Most of my other applications are connected to very long wires that can potentially pick up or develop high voltage pulses or EMI. After several years

Teensy is a prototyping or development board. As such it is the task of the designer integrating Teensy into their application to provide sufficient EMI protection. Out of the box, Teensy does not offer anything more than the basic protection integrated into the MKxx chip. If you want to use the Teensy in an EMI prone environment, you have to provide additional protection. E.g. use a USB isolator between the Teensy and the computer, or isolate all Teensy input/outputs from the exhibit through opto-isolators. In any industrial or other EMI prone environment, you must avoid exposing microcontroller pins directly to the environment.

The problems you describe sound a lot like a classic common mode differential issue. The computer is on another potential to ground compared to the exhibit, resulting in unpredictable behaviour or even damage to the different systems. Proper equalisation of the ground potentials is a must! E.g. run wires with sufficient diameter between the different exhibit parts and computers, connecting all electronic grounds and metal casings to ground. If equalisation is not an option or is unwanted, galvanic isolate the different systems (which is my preferred solution).
 
Last edited:
Apologies for digressing, but I would never ever dedicate an important 24x7x365 service to the Windows operating system, especially if it is just a single machine without back-up systems ready to jump in.
Over the last cca 17 years I've had piles of hard-disks to work with, from single SCSI-s to fibrechannel servers to current USB/Thunderbolt whatnots (film/tv editor), connected to various machines from most expensive IBM and HP workstations and Macs to cheaper setups, and whenever we worked on Windows - the operating system has proven to be the biggest trouble maker.
 
windows pcs or servers that don't need several reboots a year? hah... you should look into linux for long lasting reliability
 
Hello,

Thank you all for your comments. I understand and appreciate all of them. To perhaps help clarify my question a little further, based on responses so far:

1) Just as a note: We have scores of windows-based machines (with Windows application code base refined over decades) running reliably in science museums around the globe. I say this not to debate whether Linux is more reliable, but rather, to say Windows meets our needs in this regard.
However, when I said 24x7x365, I was too loose in my language: I was trying to distinguish our use from (say) an office system where if one has to manually close a program through the task manager every few hours of use, that is "OK-ish"...
(Our systems are all configured to reboot daily to allow Windows a fresh restart. And we have built in auto-reboot on error as optional configuration as well.)


2) Regarding opto isolation, proper grounding, surge protection, etc.:

a) I understand and appreciate that industrial applications can require one or more of the above, depending on details etc. (and indeed we employ such).

My question was somewhat prior to that level of things (well, not to grounding, but to optical isolation etc.)

For example, if a touch screen cannot reliably be used because visitors touching its metal shell causes it to disconnect from the computer, while one perhaps *could* fix that by optical isolation, Faraday shielding, differential communication, etc., from my (operational) perspective, that is simply a crappy touch screen (or PC USB port to which screen is connected) and I am going to use another model/type.

b) Similarly, uP/uC chips (with no additional protection outside the chip) have a wide variance as to their static sensitivity.

c) More generally, we have found ENORMOUS quality differences between devices, and now simply test them.
For example, we have located an off the shelf PCIe USB card that our USB data acquisition devices plug into, and which NEVER disconnects, regardless of EMI pulses nearby. And we have other cards and motherboard ports that disconnect constantly and are completely unusable. (We determined which was which simply by purchasing and testing, and now just supply the high quality one with all our exhibits.)

d) And for a low quality device, we have found that it is almost impossible (or impossibly expensive) to compensate. MUCH easier and cheaper just to purchase a higher quality unit at the outset.


3) It was in the above context that I posed my original question. In other words and to be more specific, I was just wondering if anyone had experience with such things as, with the Teensy:

a) Sampling digital or analog inputs, or controlling some output device, running for months on end transmitting data over its USB connection, ideally on a Windows machine (but results from any OS would be of interest), and what their experiences were.

b) If, during the above, they had walked on a rug and touched a metal doorknob nearby, and if so, whether the system was still functioning after :)


If answers I am looking for not known/clear, assuming project goes forward, I will likely buy one and just test. If I do, I will report back results.

Thank you.
 
Did you not read the utterance of Sir Epyon of Engineering?

Immunity/susceptibility (and also emissions) is the sole domain of the end-use implementation and system-level design. There is no reasonable expectation of theses units to meet other than the basic HBM-level ESD stuff per IEC61000-4-2.

FWIW, The T3.2 dies sometime between the third and fifth air discharge, and the 2d and 3d contact discharge - both at level 1. So it is quite obvious what you need to do...
 
In response to BJB:

1) I read Epyon's response carefully, thank you (and thank you Epyon for your extensive reply).

2) Thank you for your info re sparking pins.

3) I am well aware of these ESD standards and:

a) As I mentioned in my original post, in the problem I have described and am concerned with, there is NO "discharge" to device, either via air or contact, HBM or otherwise.
A spark is made to *entirely unconnected* piece of metal far away in the room! :) (And yes I am aware of problems if large "antenna" connected to uC pin, but that is not the situation.)

b) I am NOT concerned with physically damaging the uC device via ESD - THAT I readily know how to prevent using properly employed high speed surge protectors on the circuit board. (We employ such as a matter of course if uC pins at risk of ESD.)
What is much more difficult, and what I was asking about, was ensuring reliable uC *operation*, including in particular USB signal connection integrity to host.

c) Also, please note I was asking about USB connection reliability in general (e.g., related to firmware), not just in connection with ESD.
(The USB drives we have found unusable disconnect for reasons entirely unrelated to static discharges or space-conveyed EMI pulses.)


I regret that my questions and concerns have not been sufficiently clearly expressed...

If I end up employing and testing the device, I will report back.
 
TechnoFrolics said:
2) Regarding opto isolation, proper grounding, surge protection, etc.:

a) I understand and appreciate that industrial applications can require one or more of the above, depending on details etc. (and indeed we employ such).

My question was somewhat prior to that level of things (well, not to grounding, but to optical isolation etc.)

For example, if a touch screen cannot reliably be used because visitors touching its metal shell causes it to disconnect from the computer, while one perhaps *could* fix that by optical isolation, Faraday shielding, differential communication, etc., from my (operational) perspective, that is simply a crappy touch screen (or PC USB port to which screen is connected) and I am going to use another model/type.
Click to expand...
I'm sorry, but that is an inaccurate vision. If a touchscreen disconnects because of EMI, you have to take measures to ensure it doesn't. That means doublechecking your grounding, providing power and digital isolation etc. Electronic applications like touchscreens, but also Teensy, only provide the basic EMI protection, which should be enough for normal operation. If you experience erratic behaviour because of EMI, it means you are in a EMI intensive environment and/or you have not applied a proper design strategy (e.g. neglected proper grounding). You then have three options:
1. Implement proper design tailored to the EMI prone environment
2. Pay someone to implement proper design tailored to the EMI prone environment, e.g. buy an expensive EMI proof touchscreen (which is just the same touchscreen but with isolation implemented)
3. Keep trying touchscreens until you find one which is sufficiently above spec that it doesn't blow up soon

Electronics are not supposed to handle each and every situation, especially not prototyping boards like Teensy. I can only concur with Lord BJB: reliability and EMI immunity are the sole responsibility of the application designer.
 
To Sir Epyon of Engineering and Lord BJB,

1) Thank you both for taking the time to respond and share your perspective. You both sound like serious, knowledgeable, good engineers, and I respect that.

2) I agree with both of you that having final product/installation working properly is entirely my responsibility.

3) I have (perhaps) a somewhat different perspective on the operationally best manner to achieve that. Specifically, if four $20 PCIe USB cards are unusable because of disconnect issues no matter what I attempt (within reason of design time, knowledge/expertise, and cost), and the 5th (also $20) one never disconnects no matter how what I do, as part of my "design responsibility/work", I am going to simply use the latter. (Whether this is because the latter employs a ground plane, better caps, shorter traces, or whatever.)
Similarly, if I have a $20 USB keyboard that disconnects from PC when someone touches a doorknob 10ft away, I could buy a $200 USB industrial optical isolator ... or ... I could by another decently designed keyboard for $20 that never disconnects. Again, I choose this latter path.

4) My initial question about the Teensy (or maybe more accurately, considering your responses, to the chip and software it uses), was simply how well was the chip was designed and whether USB driver/firmware was robust. In other words, I actually was trying to "do my job" as application engineer - trying to get pre-my-usage field-experience of a component I hoped to use.
I was simply trying to get a sense of how robust, in hardware and firmware it was, compared to other *bare chips in similar contexts*, given the VAST variance I have found in such items over the years.

In any case and in summary, thank you both again for your time, and while I think our perspectives are a bit different, perhaps they are not as different as our interchange may at first suggest :)

Sincerely,
David
 
Possibly going back to the original question, a bare Teensy and it's default USB and related code seems to be pretty solid. My data points here seem to happily run for months at a time, including one strapped to a home automation Pi in a plastic case (no EMI thought in that design).

You do of course need to have some handling of millis() rollover in your user code but the internal functions seem to run robustly. And can handle the connected USB host going off line and then needing to re-enumerate on reboot. And if you want to get really through there is a command to reboot the teensy itself, so your PC side code can order a cycle of the connected teensy as part of it's own startup or shutdown process.

The main source of actual hardware death seems to be mishaps with the power side driving more than 3.3V into the micro or people exceeding the internal regulator capacity on the 3.0/3.1 units. GPIO themselves seem to be pretty robust if given half a chance (Have killed them, but none were mysterious in hindsight).
 
My general observation - just having raw Teensy's on my desk for 2 years - they will work very well for days/weeks. A powered hub keeps them alive across PC reboots and they come back running when it reconnects. Even generally safe from touch abuse with proper wire connections that won't jiggle loose when touched. With stable wires and no direct touch - isolated from uppity electrons they seem to work. Everyone I've abused is still with me and running - except one that was DOA and replaced.

They've been used in many installations and Constantin has one running his house humidifier - he has a thread noting he added a watchdog IIRC.
 
GremlinWrangler and Defragster,

Thanks much - this is exactly the kind of information I was hoping to get - most helpful!

Appreciatively,
David
 
My two cents: the new Teensy models have USB data lines broken out on the back of the board through pads. If USB surge protection is needed in order to avoid the device to be disconnected from the host PC if somebody is fiddling with it, you can use an external USB connector with all the static surge protection you might need. I usually use varistors from USB ground to case ground, from VBUS to case ground, and TVS/diode arrays on the USB data lines. There's plenty of literature and components for this.

I have no idea about how long a Teensy could be powered on, because I never used it for applications that needed continuous operation.
 
Actually thinking about it, one common failure mode is the micro USB connector physically parting from the board on the 3.2s, so as user proofing that end would be a good idea, even if all you do is some robust strain relief where the cable comes into the box. Better solution is MichMad's comment about soldering to the pads on the board with a USB type B connector if you are after a stand alone box. Better than having a hole through which the USB cable goes directly into the Teensy. Less of an issue if the PC and the Teensy are enclosed together.

Also
https://www.pjrc.com/teensy/schematic.html
Shows the schematics. The Teensy design includes a fair bit of thought through suppression hardware already within the limits of board space and cost.
 
MickMad and GremlinWrangler,

Thank you both.

MickMad: Thanks for comments and note about pads existence. (We actually have a batch of boards made up with surface mount components such as you suggest, plus series resistor and filter caps for uC I/O pins, that we use to both filter and protect when static discharges from fingers etc. are a possibility, as well as to stabilize/protect VCC/GND. Have not actually used with USB specifically though, and doubt the caps would be a good idea for the high speed at which USB operates, particularly when data-line surge protectors are (appropriately) touting their ultra low capacitance. :)

GremlinWrangler: Thanks for comments/tips re USB connectors and schematic link. Our experience too is that such connectors can often be the weakest link.
 
I can offer only anecdotes, and really only my hazy memory of them. So with that caveat in mind, Teensy LC has been reported more susceptible to nearly ESD than Teensy 3.2. I've always assumed the ground plane in 3.2 was the distinguishing factor, but that's not based on any real testing or even anything more than intuition.

Teensy 3.5 & 3.6 are relatively new, so there's much less feedback. Still, there was a thread a while ago claiming 3.6 was more sensitive to ESD than 3.5.

There are have also been reports of some issues related to power supply startup, especially with those miniature Traco power (which really do need a capacitor at their input, regardless of the wrong info in their datasheet).

Last summer, I helped a friend who'd built a "fire chandler", a large welded steel art piece with 5 strips of NeoPixel LEDs and a huge 100 lb propane tank that caused a roughly 20 foot plume of fire to shoot upward when you stood underneath and pulled the cord handing down from the center. Actually, 5 streams of burning propane, but they quickly merged into a huge jet of fire. (Yes, think Burning Man....) Originally he had a Raspberry Pi sending USB data to a Teensy 3.2, which drove the WS2812 LEDs. Usually the burst of fire would crash the system. I ported his code entirely onto the Teensy (from about midnight to 3am at a private burner party) and I'm happy to report it's run trouble-free since then at several parties and festivals. This is perhaps a bit off-topic, and we never did figure out what the original Pi+Teensy combination always crashed, but I can tell you the fire effect was pretty awesome, throughly enjoyed by many not-so-sober friends. ;)
 
Thanks Paul.

Most helpful from the in-the-trenches example/case-study/info perspective, and entertaining from the wild high-tech art perspective.

I have a feeling of visceral connection, for better and worse, to both ;)

David
 
I'm scared enough of static pushing my shopping trolley around coles.
I'm never stepping foot in a museum.
 
Status
Not open for further replies.
Back
Top