Author Topic: Rugged industrial protocol for low power sensor  (Read 1285 times)

0 Members and 4 Guests are viewing this topic.

Online T3sl4co1l

  • Super Contributor
  • ***
  • Posts: 21982
  • Country: us
  • Expert, Analog Electronics, PCB Layout, EMC
    • Seven Transistor Labs
Re: Rugged industrial protocol for low power sensor
« Reply #25 on: July 01, 2024, 05:49:02 am »
Well yeah, impulsive noise corrupting clock or data is about as likely anywhere. (Less likely during a median-sampled UART bit, perhaps, but what about a random start bit?)  CAN deals with that automatically (or, to the extent that it does), but in general I just wouldn't recommend over-wire communication without some kind of error correction -- either the data itself isn't very precious and errors are tolerable (sensor updates from time to time, just visually smooth over the blips?), or something basic like CRC + retransmit.  Almost certainly error correcting codes wouldn't be necessary (but, some might not be too onerous, if you like).  For I2C, if it gets corrupted, ignore the affected packet(s), reset bus state, wait a moment maybe, and retry; same error and solution as any other, really.

I wouldn't bother with 232 here; it would be worthwhile for a longer cable, or a ground loop scenario, but a floating pendant device doesn't need it.

Tim
Seven Transistor Labs, LLC
Electronic design, from concept to prototype.
Bringing a project to life?  Send me a message!
 

Offline Njk

  • Frequent Contributor
  • **
  • Posts: 253
  • Country: ru
Re: Rugged industrial protocol for low power sensor
« Reply #26 on: July 01, 2024, 10:47:00 am »
I've a suspicion that the real value of the ancient robust protocols like RS485, CAN, various fieldbuses, etc. is overestimated by now. They're still in wide use likely because it's a big industry and a lot of people makes money by promoting and selling that HW. Add to this that the industrial engineering community is traditionally more conservative than the CE one.

Sure the harsh environment conditions are still there but our understanding of the problem evolves, similar to the semiconductor technology. What if the only hard requirement is to avoid electrical damage, while the additional HW provisions for error rate reduction are actually optional.

Remember old analog telephone links. Sometimes, especially on long distance calls, you'd to speak fortissimo just to make sure the other party can hear what's you're speaking despite all the noise and hum in the line. Later, with the digital telephone lines, the problem was solved by adding enough forward error correction to the data packets, retransmissions, and similar protocol features.

Also consider AFDX (https://en.wikipedia.org/wiki/Avionics_Full-Duplex_Switched_Ethernet). The selling point is to use COTS Ethernet hardware and implement all the robustness-related things at the upper layers. The trend can be clearly seen.
 

Online T3sl4co1l

  • Super Contributor
  • ***
  • Posts: 21982
  • Country: us
  • Expert, Analog Electronics, PCB Layout, EMC
    • Seven Transistor Labs
Re: Rugged industrial protocol for low power sensor
« Reply #27 on: July 01, 2024, 12:50:48 pm »
Different strokes.  Industrial sites remain just as noisy as they used to be; the din of mechanical contacts has been oft replaced by poorly- or un-filtered VFDs.  These should be used in shielded conduit, but often the ground quality suffers at HF, and you'll never get a stable trace on the scope, on site, again.  Not to mention various other sorts of process equipment, from material handling (ersatz van de Graaff generator, say?) to specialty processes like EM heating or impulse systems.   In these environments, the ~10V noise margin of RS's 232, 485, etc. remain as beneficial today as they were then; or even more basic, signaling like 4-20mA loop or, going even further back, teletype loop (~100V 60mA?).

These have always been industrial standards; they're a bit overkill for commercial products, but can certainly be used, and the fact that PCs have always been somewhat interoperable with telecoms stuff -- hence RS-232 UART for example -- makes them a welcome combination.  They're also not expensive to implement, 232 for example powered by the obligatory* +/-12V supplies in PCs back then, or 422/485 from 5V and who cares; it's no wonder Apple went with 422 for their serial ports.

*Almost obviated these days, but still provided nonetheless, lol.

PCs certainly didn't need to use them, and logic levels have been in use for a long time -- albeit mainly for internal signals (ribbon cables and such), and either slowish things (keyboard/mouse, unshielded), or any speed with shields (e.g. parallel ports like IEEE-488 or -1284).  At TTL levels, higher speeds, and with potentially joining between grounded equipment, shielded cabling is definitely recommended, and so it was done.

I would suppose that PC serial would've been TTL if there was never a need (or expectation) to connect to grounded equipment; or that attaching an interface module would be expected when signaling compatibility is required.  (But that would be dumb for something as big as a desktop; perhaps the budget at-homes e.g. Speccy, C64, etc. took such a route though?)  Perhaps IBM PCjr is a better representative here -- though it probably can't be called a commercial success, and, I don't really know what all the connections, pinouts and signals are, I'm just assuming they went with bare TTL (or CMOS equivalents).

Today's high-speed interfaces of course are obligatory shielded, as the differential receivers only have 0 to 3.3V compliance range.  USB itself isn't even [fully] differential.

But that said, a fair and direct comparison still exists: a classic serial mouse at 9600,n,8,1 can transfer up to ~1kB/s, or 60kB/min; the requirement in this thread is 50kB/10min so it's a fair order-of-magnitude comparison -- if of course we set aside the bursty requirement.  But if we upgrade to a USB HID standard, that's in the 500kbps range, which will still do the job in some seconds, is a pendant device with no local ground/earth connection just the cable, and is ballpark similar cable length (usually a bit shorter than 2m, but that just scales the upper cutoff for noise immunity).

...Actually if you have a USB low-speed driver in that MCU (can even be bit-bang, though you might not have enough CPU bandwidth otherwise to actually use it this way?), this might be a very promising way to go.

Tim
« Last Edit: July 01, 2024, 12:57:01 pm by T3sl4co1l »
Seven Transistor Labs, LLC
Electronic design, from concept to prototype.
Bringing a project to life?  Send me a message!
 

Offline davegravyTopic starter

  • Regular Contributor
  • *
  • Posts: 196
  • Country: ca
Re: Rugged industrial protocol for low power sensor
« Reply #28 on: July 02, 2024, 02:00:42 pm »
...Actually if you have a USB low-speed driver in that MCU (can even be bit-bang, though you might not have enough CPU bandwidth otherwise to actually use it this way?), this might be a very promising way to go.

Pardon my ignorance (as mentioned, no USB experience) but don't USB devices typically lose power when the host sleeps? I need the sensor to remain powered/running constantly, is that just a matter of powering the device from something independent of the host's USB VBUS?

Also not sure if there's any possible issues on the host side at OS or application level with a USB device that's constantly appearing, communicating, then dropping off the bus...I haven't seen implementations like this, which of course doesn't mean it can't/shouldn't be done.
 

Offline David Hess

  • Super Contributor
  • ***
  • Posts: 16899
  • Country: us
  • DavidH
Re: Rugged industrial protocol for low power sensor
« Reply #29 on: July 02, 2024, 02:17:25 pm »
Pardon my ignorance (as mentioned, no USB experience) but don't USB devices typically lose power when the host sleeps? I need the sensor to remain powered/running constantly, is that just a matter of powering the device from something independent of the host's USB VBUS?

That depends on the behavior of the host.  Often ports may be configured to remain powered while the host sleeps or is even powered down.

On PCs, USB ports may be powered from the power supply's standby +5 volt output to remain powered while the power supply is shut down.  This commonly allows a USB mouse or keyboard to remain powered and wake up the PC.

Quote
Also not sure if there's any possible issues on the host side at OS or application level with a USB device that's constantly appearing, communicating, then dropping off the bus...I haven't seen implementations like this, which of course doesn't mean it can't/shouldn't be done.

Whether there will be problems depends on how well the USB stack was written.  I have seen systems where that was a problem, and other systems where it was not.
 

Online T3sl4co1l

  • Super Contributor
  • ***
  • Posts: 21982
  • Country: us
  • Expert, Analog Electronics, PCB Layout, EMC
    • Seven Transistor Labs
Re: Rugged industrial protocol for low power sensor
« Reply #30 on: July 02, 2024, 02:22:53 pm »
Beats me -- but there are power management options built in, and you're in complete control of the actual power and data, at least from the MCU side.  A keepalive transaction every once in a while might not be much, but it depends on everything else (e.g. maybe the USB interface/hub itself doesn't have a meaningful sleep state, aside from disconnecting completely).  Reconnect can be dealt with by registering the device by ID, or (hard-wired!) route, etc., and whatever calls the OS provides to manage and track that.  Could be varying levels of janky and inconsistent, or just more effort required (and at higher levels i.e. OS and network* APIs) compared to a simpler interface.  Just more options to consider.

*To the extent that USB is a sort of networking interface; informally, I mean.

Tim
Seven Transistor Labs, LLC
Electronic design, from concept to prototype.
Bringing a project to life?  Send me a message!
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf