Rugged industrial protocol for low power sensor - Page 1
Forum section: electronics / projects

author: davegravy
author_rank: Regular Contributor
timestamp: June 28, 2024, 07:22:53 pm
content: I have a linux-based SBC which has I2C, SPI, and a CAN controller (all UART interfaces are consumed already).I have a remote sensor which has yet to be developed but will have an MCU (tentatively STM32U5). There will be roughly 2m cabling between the two and they will be in a somewhat noisy environment (outdoor urban construction site).I need to keep power draw to a minimum since I'm reliant on a compact solar panel.The remote sensor will need to wake the SBC at most once every 10 minutes and send a 50kB payload, so the effective datarate is very low, but the SBC is power-expensive so it's not wise to wake it a long time at a very slow datarate (or many retransmissions due to failed error checking).I've seen that it's possible to convert I2C and SPI to differential signaling over shielded twisted pair cabling, and effectively extend their reach + noise immunity. The other option I know about is CAN but it sounds like this is generally used in automotive which is a bit less power constrained.Obviously there's a tradeoff between power consumption and ruggedness, I'm not sure what's a good balance for this. I'd be pretty happy if I could get a solution that's around 10mW average draw (associated with whatever transceivers are needed), does that seem like a reasonable goal?

author: moffy
author_rank: Super Contributor
timestamp: June 28, 2024, 10:05:31 pm
content: I would probably go with the CAN, because it is designed for the environments you are using it in. There are probably low power solutions for CAN e.g.https://www.ti.com/lit/ds/symlink/sn65hvd1040.pdf?ts=1719612139579&ref_url=https%253A%252F%252Fduckduckgo.com%252F

author: thm_w
author_rank: Super Contributor
timestamp: June 28, 2024, 10:25:16 pm
content: RS485, RS422, or CANReceiving doesn't take much power so if you can shut the transmitter off, 10mW average should be easy.The SBC is not running on solar right? Just the sensor.https://www.eevblog.com/forum/projects/wired-sensors-around-the-house/https://www.eevblog.com/forum/projects/what-technology-for-sensors-everywhere-in-the-house/

author: nctnico
author_rank: Super Contributor
timestamp: June 28, 2024, 10:55:41 pm
content: SPI over RS485 is an option; I have used that in various designs. If you add checksums on the data so a bad packet can be detected, there is little which can go wrong.

author: davegravy
author_rank: Regular Contributor
timestamp: June 28, 2024, 11:17:40 pm
content: Quote from: thm_w on June 28, 2024, 10:25:16 pmEverything is off solar, but the SBC can deep sleep almost all the time.

author: David Hess
author_rank: Super Contributor
timestamp: June 28, 2024, 11:45:28 pm
content: For simplicity and lowest power, I would drive a differential pair with two series terminated CMOS gates, and no termination on the end of the cable. A comparator or differential line receiver works as a receiver.Ethernet cable will work, but any shielded differential pair cable would be good.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: June 29, 2024, 12:23:07 am
content: RS422/485 is excellent for noise purposes, yeah.Logic level is acceptable if you can afford good filtering (maybe not at bitrate) or a shielded cable.Really, 2m isn't long at all, and if one end or the other is floating (no ground connection), you'll find immunity is quite good. For detailed reading, see:https://electronics.stackexchange.com/questions/689066/cable-shielding-best-practices/689138#689138UART saves two channels over SPI, and thus all the power consumption of those channels. (Assuming a basic/naive SPI bus of SCK, MISO, MOSI and CS. Maybe CS is implicit so this would only save one channel.)Three channels even, if a single channel can be used with a transfer protocol. For example, you might have the SBC act as client, sensor as server, and SBC requests a transaction, gets sent a buffer load (maybe some hundreds of bytes), checks CRC, acknowledge, sends another load, etc. until the packet is complete. Each pause and ACK is an opportunity to reset line state, or perhaps request a failed segment (if integrity is important, maybe you have an overall CRC or hash for the packet, or overlapping pairs of sub-packets, etc., so can identify which one(s) are in error). Line direction is gated by state and timing; either party can simply wait until timeout to reset state and then the client can re-send a request, for example.Give or take some modulation tricks (can include Manchester encoding, if a bit clock is available from the UART(s)), you might reduce the sensor entirely to two wires, and use coax. AC signal can be duplexed onto the power line with a decoupling network. Or maybe you meant the sensor is self-powered in which case nevermind.Related question: what is the practical minimum wake time for the SBC? If you could transfer the data instantaneously, how fast could you actually make use of it, and go back to sleep? It's entirely possible to use a baud rate high enough to transfer everything in a few ms (5Mbps+?), but maybe it's not worthwhile as the minimum wake time is 10s of ms or something. The tradeoff is, higher baud means less filtering on the line, more RFI susceptibility.Tim

author: Benta
author_rank: Super Contributor
timestamp: June 29, 2024, 12:27:12 am
content: CAN every time. You'll get up to 1 Mbps, it's differential, error tolerant, and designed to operate in the electrically "dirtiest" environment possible, which is Automotive.Good transceivers are Infineon, NXP, and...

author: Doctorandus_P
author_rank: Super Contributor
timestamp: June 29, 2024, 02:53:49 am
content: RS485 and CAN are very comparable concerning signal integrity and cable length, and if you already have a CAN bus it's logical to use it.You can also consider simply removing power from the cable in between measurements. (I assume the cable has both data and power). There are many (but maybe not all) CAN transceivers that are in a high impedance state when they do not have power.

author: SiliconWizard
author_rank: Super Contributor
timestamp: June 29, 2024, 04:28:53 am
content: I second CAN, and CAN FD can get you significantly higher throughput than CAN 2.0, if you need more throughput. Many recent MCUs support CAN FD (at least that's the case with STM32). Not sure your SBC supports CAN FD though. But just a thought.

author: davegravy
author_rank: Regular Contributor
timestamp: June 29, 2024, 10:14:06 pm
content: Quote from: SiliconWizard on June 29, 2024, 04:28:53 amSBC supports it, but don't know I really need it (see below)Quote from: T3sl4co1l on June 29, 2024, 12:23:07 amSBC takes a good ~100ms to wake up and that again to fully return to sleep. That's without any processing and IoT stuff (cellular TxRx), which takes a few seconds. So I think high throughput doesn't buy much.I've ordered a few of these SN65HVD1040 to try.I need to power the remote sensor (MCU and CAN transceiver) via the same cable that would carry CAN. Would the sensible arrangement be to use 2 twisted pairs inside a shield:* tie shield to GND on both ends* CANH+CANL as the 1st twisted pair* power on both the 2nd twisted pair conductors?Or better to twist power+GND on the 2nd pair?

author: nctnico
author_rank: Super Contributor
timestamp: June 30, 2024, 12:49:56 am
content: AFAIK CAN is pretty power hungry. Especially if you are going to use resistive termination at high speeds. And then you'll have extra software overhead by needing to chop data into several CAN packets and get the sequence right at the receiving end.All in all I don't think CAN is a good fit. Especially if you need to send more data than fits in a single CAN message. With SPI it is easier to implement a request / response pattern using longer messages. UART would be an even better fit due to the inherent noise filtering. NXP has SPI to UART converter chips like the SC16IS750 for which a Linux driver exists (assuming the SBC runs Linux).

author: Doctorandus_P
author_rank: Super Contributor
timestamp: June 30, 2024, 08:55:11 am
content: Oops. I overlooked the bursts of 50kB of data to send every 10 minutes.CAN is a nuisance for sending bigger packets. It has a very limited / small frame format.Neither I2C nor SPI are very suitable for driving cables. Especially I2C is hampered by capacitive loading. SPI can work, but if you have a few meters of cable then you need extra bus drivers to make it reliable.RS485 combined with the simple UART is a good choice. Depending on the UART's you have, a baudrate of a few Mbit/s is achievable. This keeps the total communication time short and this reduces the average power consumption. Another similar idea is to use the UART, but use CAN transceivers instead of RS485 transceivers. This mostly has an advantage when you have multiple masters on a two wire bus, because the "passive" state of CAN makes it easier to detect bus conflicts reliably.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: June 30, 2024, 09:30:31 am
content: Quote from: davegravy on June 28, 2024, 07:22:53 pmIt may be worth seeing if one can be swapped around reflecting priorities here. Or multiplexed (exclusive use with one device at a time). But perhaps they're all optimally used, and something else is preferred.Quote from: Doctorandus_P on June 30, 2024, 08:55:11 amCAN I *think* is more of a set-of-registers protocol, with similarities to Modbus and other industrial comms -- I haven't worked with it personally (actually a bit surprising at this point, to be fair), but yeah this sort of thing tends to complicate large packets. You might basically implement a handshaking transfer protocol on top of the transport layer, which is... annoying, but doable. (For example, client sets "receive ready" register, server sets up new data register values; client polls "data ready" register, then reads out and stores a round; client clears then resets "receive ready" to signal the next round; etc.) All the delays of polling and processing, plus comms with other things on the bus (maybe not the case here, but happens in general purpose use), and automatic re-sending or whatever error correction, can add up to a lot of variable latency and really cut into the transfer rate.I recall hearing about some manner of "mailbox" mechanism, which shows up on these sorts of protocols; I forget if CAN has that, or it's one of the expanded types, or, maybe it's literally just doing the above but as a standard network layer rather than ad-hoc.QuoteDon't be so dismissive based on trigger words -- give it a thought first:Quote from: davegravy on June 28, 2024, 07:22:53 pm2m is hardly a burden for these protocols, and if baud can be cranked down low, ample filtering can be applied, reaping immunity instead.As demonstrated in my earlier link, a short pendant connection like this is quite capable in EMI terms, for frequencies below the electrical length of the cable. And filtering is readily added.I wouldn't actually mind at all doing I2C here, with the sub-400kbaud rate being easily filtered for the 10MHz+ EMI that's likely to interact with it. I2C's 50ns glitch removal helps with EFT/ESD (though how much depends on how those transients interact with the bus filtering), and implementing a CRC and block retransmit protocol should address errors.I2C is kind of the worst case for filtering, as its high-impedance pull-up condition guarantees mismatch with the driven-low (~30Ω) condition, neither case can be optimized for signal quality or noise rejection. But again, noise largely starts in the 10MHz+ range, and a lowpass cutoff around a few MHz, for either condition, will handle that regardless.SPI is fine, as the clock can be cranked down nice and low, and logic-level signals used -- filtering is effective as signals are full-wave driven, no open-drain state (except if deasserted between transactions, which really doesn't matter one way or another).Either option saves greatly on continuous current consumption of a terminated RS-422 bus.if the SBC wake time is some seconds, a transfer rate under 50kBps seems satisfactory. That's under 500kbaud UART, 400kHz SPI, ~450kHz I2C (depending on packet length and overhead), etc.Mind, I'm still being careful with comparisons here:A RS-422/485 bus doesn't need to be terminated into exactly Zo.It may be that a faster 422/485 bus (say 10Mbaud) transfers data faster than the current saved by I2C's larger-value pullups; almost trivially so if weak pulls are used instead of termination.422/485 might simply not be applicable due to higher priority UART allocations, forcing CAN/I2C/SPI.Perhaps CAN could be lightly-terminated as well; though, I don't know how well that plays with the bus arbitration mechanism.(Incidentally, CANbus has an I2C equivalent: differential I2C I believe uses the same unipolar-driven-bus scheme, greatly improving immunity. I don't see it being necessary here, but when you must use I2C over enough distance, it's the preferred way to do it. Also, just to make it clear -- CAN signaling is essentially based on RS-485, indeed you can drive it with such a transceiver, with data set always-high and toggling enable instead. So it's no accident that they show up in similar contexts, as far as robustness and immunity.)Tim

author: nctnico
author_rank: Super Contributor
timestamp: June 30, 2024, 09:36:18 am
content: For 2 meters, UART + TTL levels will work just fine with some filtering & TVS and using receivers with a defined hysteresis. Like using a pair of 74HC14 inverters as drivers & receivers combined with a shielded cable.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: June 30, 2024, 10:06:25 am
content: Quote from: T3sl4co1l on June 30, 2024, 09:30:31 amSure, it can work, but lowering data rates translates in longer communication times and thus time your uC is running (unless you wake it for each byte). If you use RS485, then you pretty much crank it up to the highest baudrate your UART's can handle without even having to worry much about signal integrity or reliability (as long as you use a twisted wire pair with correct termination resistors).CAN peripherals inside uC's are among the "advanced" peripherals. You set it up by writing to some registers (including data) then start the peripheral, and the whole packet pops up in the other uC. Because of this you are also limited to how the peripheral works (I believe 8 data bytes per packet).

author: Doctorandus_P
author_rank: Super Contributor
timestamp: June 30, 2024, 10:25:35 am
content: Quote from: nctnico on June 30, 2024, 09:36:18 amYes, bus drivers. But what does that get above an 8-pin RS485 IC with built in TVS diodes?

author: T3sl4co1l
author_rank: Super Contributor
timestamp: June 30, 2024, 12:30:13 pm
content: Quote from: Doctorandus_P on June 30, 2024, 10:06:25 amI literally just--!?Look:Quote from: T3sl4co1l on June 30, 2024, 09:30:31 amQuote from: davegravy on June 29, 2024, 10:14:06 pmI don't know if you stopped reading at the point quoted and shot off a reply, or intentionally misread or (didn't read) my post; or accidentally, by oversight (hey, it happens to me a lot too), but in any case, I want to emphasize that I covered that.(Or, if you meant to disagree, perhaps by going in a different direction, perhaps you have an objection that is orthogonal to my direction of attack, and didn't feel it necessary to explain how my argument fails while yours succeeds; this occurs all-too-often in conversation, where two people argue as though repeating ones' points would ever make a difference -- points already wholly dismissed by their opponent; but in that case I request a deeper explanation that either reaches a common point where such dismissal can be justified, or at least a heuristic argument prioritizing one over the other. But, this is a simple enough thing, I don't think such a rhetorical mechanic applies here, and this is just a note for completeness.)QuoteI have every confidence that the uC consumes approx. 20 times less current than a matched-termination 422/485 link, give or take efforts to optimize power (reduced clock, sleeping, power-down states compatible with peripheral activity). I also have a strong confidence that the SBC consumes 20+ times more current than the uC; the uC is not the villain here, but neither is the SBC particularly avoidable in terms of activity spent here. Fast '485 would indeed to well, but I doubt it doesbetter, especially give or take cost.(The real joke there is, we've spent exponentially more time discussing it than the parts count in production, if I had to guess.)Quote from: nctnico on June 30, 2024, 09:36:18 amWhat is an HC inverter gaining you that the HC-esque pin drivers on the MCU and/or SBC don't already provide? Yes, added clamp diodes, ESD resistor(s), filtering, all assumed standard; but, you don't need any more drive strength (non-bus HC might be weaker anyway..!), inversion doesn't do anything, schmitt triggeriswelcome but most MCU ports provide it -- worth making a note, check the datasheet; and, it's not likely to improve repairability or whatever, I would assume in lieu of specifying otherwise that servicing for the unit/system is module-level replacement, maybe board-level, and that's that, so a buffer between MCU and bus doesn't add value that way either. (Is a good way to go, using sacrificial logic gates, preferably socketed DIP, to protect boards with more important (expensive, bespoke, vintage?) hardware on them, though. Seems unlikely that's the case here, but not excluding the option.)So...Quote from: Doctorandus_P on June 30, 2024, 10:25:35 am...I would gladly reduce the bus interface to a pair of $0.10 clamp diodes instead of $0.60 gates or $0.80 interfacesTim

author: nctnico
author_rank: Super Contributor
timestamp: June 30, 2024, 12:58:06 pm
content: Quote from: T3sl4co1l on June 30, 2024, 12:30:13 pm74HC14 has schmitt-trigger inputs with defined hysteresis. Very nice when dealing with signals coming from a potentially noisy source. In contrast, microcontroller pins can be allover the place.Quote from: Doctorandus_P on June 30, 2024, 10:25:35 amRS485 drivers vary wildly in ruggedness which greatly depends on price. A couple of logic gates + TVS diodes are likely to consume less power which is also the goal of the OP.

author: davegravy
author_rank: Regular Contributor
timestamp: June 30, 2024, 02:01:28 pm
content: Quote from: T3sl4co1l on June 30, 2024, 12:30:13 pmEspecially given that this will be low volume production. I'm happy to spend substantially more on an IC that simplifies development.I do appreciate the discourse and am learning a lot reading this.Also, for reference the SBC draws 500mW awake and 100mW asleep, which I gather is reasonaby lean as Linux based SBCs go.It has 2 UARTs, one is occupied for console TTY (diagnostic use) the other interfaces with a ublox cell module. The cell connection is pretty critical so I don't know that I want to add complexity with multiplexing, although there's no real need to do cell comms in parallel with sensor comms save for shaving a bit of time off total wake duration.

author: nctnico
author_rank: Super Contributor
timestamp: June 30, 2024, 02:31:05 pm
content: 100mW sleep power sounds high to me. From a Li-ion battery that would be around 25 to 30 mA. Also: how about connecting the cell module to USB and free up a UART?

author: davegravy
author_rank: Regular Contributor
timestamp: June 30, 2024, 02:42:44 pm
content: Quote from: nctnico on June 30, 2024, 02:31:05 pmMight be an option. The USB host port is occupied by another sensor (which is the main reason I'm using an SBC instead of uC). I don't have any experience with USB but I think this would mean adding a hub? Any idea if this would be more or less dev work than SPI-to-UART converter (e.g SC16IS750)?

author: nctnico
author_rank: Super Contributor
timestamp: June 30, 2024, 02:49:09 pm
content: Adding a USB hub chip is easier compared to using an SPI to UART bridge. The USB hub chips work plug & play. And while you are at it, you can use USB-to-UART chips as well.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: June 30, 2024, 11:14:24 pm
content: Quote from: davegravy on June 28, 2024, 07:22:53 pmHow does it wake up ? Using a separate wire ?Quote from: davegravy on June 30, 2024, 02:01:28 pmWhat BAUD speed can the diagnostic port manage ?It's not hard to multiplex a TTL-UART, and 2m is not a large distance for any of the links you have.RS485 can be wired to auto-direction handle (typically a pnp transistor ) and TI even have parts with Auto direction inbuilt.RS422 needs no direction handling, but needs more conductors in the cable.You can use CAN transceivers on UARTS too, the main difference from RS485 is an offset threshold and CAN RX usually echoes CAN TX.The offset effect means CAN hardware has no idle power on the BUS.Which peripheral is easiest to talk to from Linux ?

author: exmadscientist
author_rank: Frequent Contributor
timestamp: July 01, 2024, 01:31:38 am
content: CAN is electrically wonderful here but as noted, requires some software work. If you have a software person who gets enthusiastic about this sort of thing, I have seen it work out basically perfectly in godawful-horrible electrical environments. But that person is not me.Please do not use I2C. Just don't. The issue is not whether you can or cannot filter it. The issue is what happens when one single stray pulse makes it through the filtering, and that is that it usually knocks out the whole bus unless you take heroic measures to keep things in check. (The main issue is that a stray pulse on SCL will get the masters and slaves out of sync. There are, of course, others.) It is possible to deal with this, but if you don't have to, don't. Choose something else.422/485 is probably what I would choose. 232, real 232, is probably also fine.If you want to do TTL I would also recommend a cheap Schmitt buffer. (I'd probably start with an LVC17 or similar?) The Schmitt action and ESD immunity provided by a dedicated chip are much better than MCU pins. Seriously, compare the transfer curve of an MCU I/O cell to the dedicated part if you don't believe me. They aren't always that different (MCUs vary a lot!) but they are different. And putting a dedicated chip in there means you're unlikely to be blowing MCU I/O cells, which is always just annoying to deal with. (Did I blow the cell or is it just driving weakly now or is the load high or is... oh, it's only pulling up now, it must be blown.) Better avoided!

author: T3sl4co1l
author_rank: Super Contributor
timestamp: July 01, 2024, 05:49:02 am
content: Well yeah, impulsive noise corrupting clockor datais 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

author: Njk
author_rank: Frequent Contributor
timestamp: July 01, 2024, 10:47:00 am
content: 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.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: July 01, 2024, 12:50:48 pm
content: 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  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

author: davegravy
author_rank: Regular Contributor
timestamp: July 02, 2024, 02:00:42 pm
content: Quote from: T3sl4co1l on July 01, 2024, 12:50:48 pmPardon 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.

author: David Hess
author_rank: Super Contributor
timestamp: July 02, 2024, 02:17:25 pm
content: Quote from: davegravy on July 02, 2024, 02:00:42 pmThat 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.QuoteWhether 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.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: July 02, 2024, 02:22:53 pm
content: 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