Using CAN transceivers for non-CANBUS differential signaling???......  - Page 1
Forum section: electronics / projects

author: Smokey
author_rank: Super Contributor
timestamp: July 28, 2023, 09:20:16 am
content: I have an application where I need to send a couple of normally single-ended digital data lines over cables through a harsh environment. There is also the potential for a mis-wire and overvoltage on the data pins that I need to deal with.I was looking at RS485, but the transceivers don't have amazing overvoltage protection or aren't the lest expensive things out there (ISL32455EIBZ at $6.49 for example).On the other hand, I can get something like the dual CAN Transceiver TCAN1046 which has 125C rating, 8Mbps, and +/-58V bus fault protection!, all at $2.25 in 1s.https://www.digikey.com/en/products/detail/texas-instruments/TCAN1046DMTRQ1/13532285Do you guys see any problems with using a CAN transceiver like that for non-CANBUS applications where I'm just using one end as a SE->Diff transmitter and the other end as a Diff->SE receiver?Edit to note:I am aware of the "TXD dominant timeout (DTO)", that limits the data rate to a minimum of 9.2kbps. That's lower than what I'm looking to do by a fair bit.

author: AndyC_772
author_rank: Super Contributor
timestamp: July 28, 2023, 09:57:00 am
content: I don't see an issue, other than availability. Be aware that CAN transceivers have had a habit of appearing in stock for a short time then completely disappearing from the supply chain over the last couple of years.I'd advise you to stock up when you can, and try to pick a transceiver that has multiple pin compatible equivalents from different manufacturers, or at least, to make sure your schematic can accommodate some different options.Do also note that CAN requires terminating resistors at each end of the bus, regardless of the data rate, and that driving these can draw a significant current. You wouldn't want to use CAN if your device is powered from a small battery, for example.

author: Berni
author_rank: Super Contributor
timestamp: July 28, 2023, 10:08:19 am
content: The first CAN bus implementations actually used RS485 transceiver chips, it is only after that they actually started making purpose built CAN transceiver chips.Only difference is that you do need termination resistors for CAN to work at all, while RS485 will work without termination just fine on reasonably short wires.Also the real way to make transceivers robust is to add series resistors on the data lines and TVS diodes to clamp it. That way you can choose the resistors and diodes to be as beefy as you need them to be, up to even surviving getting plugged into 220V mains.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 28, 2023, 11:12:08 am
content: Yeah, for that 58V tolerance (sustained for longer than some ESD zap), against accidental application between CANH, CANL, don't forget the power dissipation in termination resistors. 58^2/120 = 28W, not a neat package. You can of course add polyfuse in series with termination resistors, and whatnot.Generally it should work but do a simple test prototype first because these are integrated devices only designed for CAN so might have some weird internal feature easily overlooked, like the TX dominant timeout you already discovered.

author: ataradov
author_rank: Super Contributor
timestamp: July 28, 2023, 05:13:30 pm
content: One thing to keep in mind is that some dedicated CAN transceivers have hard-coded timeout for the dominant state. They will disable the drivers if you request the dominant state for too long.So, your custom protocol should be designed around that.

author: CosteC
author_rank: Regular Contributor
timestamp: July 28, 2023, 05:29:34 pm
content: CAN has bit hard to identify border between physical and protocol layers: for example mentioned timings, dominantce etc. You will need to take it into your protocol design. RS485 is just physical layer.I have been using RS485 with 10 Mbps speed for small distances, within specs.RS485 transceivers are generally cheaper and also can withstand a lot if you take a closer look. I would use RS485 as long as "natural bus collision solving" or real time features existing naturally in CAN would not be needed. But then I would use CAN BUS protocol too. I am lazy

author: Siwastaja
author_rank: Super Contributor
timestamp: July 28, 2023, 05:49:32 pm
content: RS485 is seriously flawed in how it handles bus idle, and from idle to active transition, as no one ever thought about it. As a result, noise margins are colossally poor as slaves will just randomly detect start bits from any noise. This issue is "solved" by adding bus biasing resistors (weirdly called "failsafe biasing", which has nothing to do with failing safely), but with these resistors the noise margins are order of magnitude worse than one would expect from the active-state signal levels / receiver hysteresis specs.There are newer generation RS485 transceivers which improve the idle state problem and increase the noise margin or remove the need for biasing resistors, but then again these reduce your possibilities of second-sourcing because they are quite special snowflakes. And you can't interface with products by others reliably because they probably used just the classic transceiver chips. As a result, RS485 is quite flaky bus and it's no surprise people prefer CAN whenever possible; with CAN you sure depend on 60 ohms of resistive pull-together and 0.5V signal level for decision, but on real RS485 where start bits matter, this is now some 500-600 ohms and just some 100-200mV or so. Order of magnitude worse.Many people just choose to conveniently ignore this total design fuckup and play the "RS485 is industrial and resilient against noise" game. And in good conditions, it works. But RS232 is not much worse.

author: Smokey
author_rank: Super Contributor
timestamp: July 28, 2023, 09:10:12 pm
content: Quote from: Siwastaja on July 28, 2023, 05:49:32 pmThanks. This is the stuff I was hoping I could avoid by repurposing CAN transceivers.I was looking at THVD1420 as a RS485 option:https://www.ti.com/lit/ds/symlink/thvd1420.pdfIt ticks a lot of the boxes for protection: +/-16V max on diff lines, ESD protected, 12Mbps, 125C temp, etc.I'm a little bummed there aren't dual or quad RS485 transceivers that meet that spec. I would prefer not to have to use 4 of these per board, but that's not the end of the world.One funny thing about THVD1420, the banner spec notes "The bus pins are immune to high levels of IEC Contact Discharge ESD events, eliminating the need for additional system level protection components. "... But then in section 8.2.2 they say "In order to protect bus nodes against high-energy transients, the implementation of external transient protection devices is necessary."Thanks TI! just like those true-rail-to-rail* opamps!*not actually rail-to-rail

author: Siwastaja
author_rank: Super Contributor
timestamp: July 29, 2023, 07:28:53 am
content: Quote from: Smokey on July 28, 2023, 09:10:12 pmHere's no actual contradiction, just poor choice of words unless you are really into this stuff. Note they say external protection is necessary againsthigh-energytransients. The ESD events as listed are not high-energy; they are high-voltage, hence high-power, but very short in time so that the internal protection can deal with the limited amount of energy. I would not stress about the protection unless you have some special stuff going on like risk of lightning strike induced transients (say, long wires from building to another).

author: CosteC
author_rank: Regular Contributor
timestamp: July 30, 2023, 10:25:58 am
content: Quote from: Siwastaja on July 28, 2023, 05:49:32 pmCan you provide some paper/source about those?RS485 does not care about bus IDLE/ACTIVE as it is down to protocol - at least that was idea back then.I totally disagree with similar performance of RS232 - not only RS232 is far slower at given cable length, amount of energy required to disrupt terminated RS485 line is just far greater. Of course if things are done per book. Many people think RS485 does not require ground between transceivers - but it is mandatory, same as CAN and USB. I used RS485 under bad conditions with good results, however using proper cables.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 30, 2023, 11:44:16 am
content: Quote from: CosteC on July 30, 2023, 10:25:58 amGoogle "RS485 failsafe biasing" and you'll find as many as you want.QuoteTechnically correct (best kind of correct?), and I mean exactly this by saying the thing was not well thought out. In reality just blame shifting, because 99.9% of RS485 bus products use asynchronous serial communication (i.e., UART) with some kind of "master polls, slaves respond" scheme, if not modbus then something similar-ish. These all depend on slaves detecting start bits correctly, and you can't do that in presence of noise and continuous stream of false start bits. Therefore, noise margin between mark/space is irrelevant; noise margin between idle/active defines if the system works or not.So RS485 is basically unsuitable physical level for nearly every protocol which uses RS485. Go figure. On the other hand, RS422 is just excellent physical layer for unidirectional, always-enabled links.Quote"Far greater" sounds like a wild assumption, something people trusting blindly in RS485 do all the time. Remember that in practical RS485 installations noise margin (expressed in volts) is often actually negative due to failure to use bias-free transceivers or add biasing, and even these systems seemingly "work". Also it's surprisingly common to see RS485 installations without the return wire (GND) which is absolutely required for robust communication. It's also hard to refer the installers to a definite guide because it does not exist; they need to navigate within piles of false information ("ground wire not required"), and find bits and pieces not mentioned in usual install guides (need for biasing resistors). As a result, having to debug flaky RS485 buses is common in the industry.Yes, if the line geometry is properly differential and it's properly terminated at both ends (so low impedance), it's quite resilient against noise: random E and H fields couple/induce only some millivolts to the lines (compare to RS232 where several volts can be easily induced). Still, if you compare to 500mV-ish noise margin of the CAN bus to the practical noise margin of 0-50mV (or even negative) of async-serial-over-RS485, you don't have to wonder why CAN is preferred.But how you would quantitatively evaluate single-ended RS232 with say 3V of noise margin against differential RS485 with 0V of noise margin? On paper RS232 is infinitely better. In reality it's apples vs. oranges as the differential design forgives so much, and maybe you are lucky to have 30mV of noise margin on RS485. Both are flaky, but RS232 without ground loops and pseudo-differential wiring can be quite good, given it has 100x more voltage noise margin. In truly demanding conditions, use something else, e.g. RS422 links, CAN or Ethernet. Or optical fiber in extreme cases.

author: nctnico
author_rank: Super Contributor
timestamp: July 30, 2023, 06:16:14 pm
content: AFAIK CAN transceivers are available in versions that can handle much higher voltages on the CAN lines (like 60V to even 100V). I'm not aware of any RS485 transceiver that likes that. I've also seen CAN just work without having a ground connection. Iffy but be prepared to find this in light electric vehicles where the battery typically switches the negative terminal.OTOH: CAN transceivers can be quite frugal where it comes to pulses on the power supply pins (the ones from Microchip appear to particulary bad).

author: uer166
author_rank: Super Contributor
timestamp: July 30, 2023, 07:31:04 pm
content: Quote from: CosteC on July 30, 2023, 10:25:58 amI've seen first hand how much of a disaster (isolated in my case, and with the reference lines connected) RS485 can be from a very small sample size. I don't think you've used RS485 under bad conditions with good results unless the conditions either weren't truly bad, or it was uni-directional RS422, or you didn't use Modbus or any other popular protocol that actually relies on the UART start bit. CAN is an order of magnitude better at the minimum.

author: uer166
author_rank: Super Contributor
timestamp: July 30, 2023, 07:36:32 pm
content: OP: is your data transfer unidirectional and can be always-on? If so, a lot/most of the RS485 grievances disappear and a RS485 transceiver is suddenly as attractive as CAN.

author: Smokey
author_rank: Super Contributor
timestamp: July 31, 2023, 12:01:19 am
content: Quote from: uer166 on July 30, 2023, 07:36:32 pmIn this use case as I mentioned in the OP, yes it's unidirectional and point to point (one master talking to one slave over a cable). I am not tri-stating the bus data connection between transmissions, so yes, always on.As nctnico pointed out, the CAN high voltage tolerance of the data lines is one of the main attractors in this case. I need at least +/-14V tolerance here. Getting significantly more than that for free without a bunch of additional protection circuitry with CAN is pretty good. The THVD1420 has +/-16V tolerant data lines which in this case is adequate, but nowhere near as good as +/-60V CAN. As I said above, the lack of dual or quad transceivers is also a bummer.Why hasn't the industry made a protocol neutral (no "dominant timeout" stuff) differential transceiver with the physical robustness of CAN? Said another way, why don't they just make RS485+ with +/-60V tolerance and the better noise immunity?Side question: Do you guys know of a standard single ended data buffer that has something around 14V tolerant outputs? I'm adding extra protection around a 74AHC9541 now, but it would be great to make that more robust as well with less interference in the data output.

author: uer166
author_rank: Super Contributor
timestamp: July 31, 2023, 12:40:45 am
content: It might be much easier to have high voltage tolerance for something that is open drain such as CAN vs something that is push-pull such as RS485, but I'm speculating.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 31, 2023, 05:46:24 am
content: Quote from: Smokey on July 31, 2023, 12:01:19 amIn that case, everything I said about RS485 noise immunity is invalid in your case. RS422, 485 and CAN would have roughly the same noise immunity and all it boils down to is finding transceivers with your required overvoltage spec. At that point, adding external protection could be just simpler, being able to use any common IC.

author: Berni
author_rank: Super Contributor
timestamp: July 31, 2023, 07:02:59 am
content: It is better to add external protection to a chip rather than buying the super special resilient chip made by 1 manufacturer in only 1 variant that is often expensive and may disappear from stock at any moment.In the majority of cases chips already have protection diodes inside them on all pins. So in order to make a chip more resilient, all they need is some sort of current limiting circuitry placed between the chip and the scary dangerous outside world. This means the internal ESD diodes in the chip can divert all the fault current into the ground and clamp the voltage on the pin to a safe level. As the fault voltage applied to your device goes up more and more of the electrical power is burned inside the current limiting circuitry and not the chip. Hence it can be designed to handle it, also if it does blow up, it saves the chip from blowing up (as that could take out the rest of the device by shorting out the power supply)Something as simple as a 10 Ohm series resistor makes chips way more resilient. To guard against long time scale faults a PPTC fuse works even better as it will go high resistance during a fault, then return to working afterwards. Multiple stages also works great, first have a resistor + TVS diode to clamp your fault, then just use a series resistor to the chip, it only let a known limited amount of fault current flow into the chips pins. The TVS diode could in theory be made the size of a washing machine in case you want to protect from someone accidentally miswiring your communication bus to a 100kV power transmission line.Protecting outputs is a bit trickier since the series resistors have to be kept low while PPTC fuses have a slow response time due to needing to warm up. For some faster protection you can use a JFET or depletion mode MOSFET wired as a current source. These will stay 'low resistance' when below the set current but then instantly start regulating the current into the pin if you suddenly apply 100V to it. You can get depletion FETs for 800V if you need to protect that high.Most importantly TEST your design. Don't be scared to sacrifice some components. Grab a high voltage capable PSU and send power into those pins and make them suffer. Not only will this tell you that your protection design actually works in practice, but might give you hints on where the weak points are, helping you make it even more robust.

author: CosteC
author_rank: Regular Contributor
timestamp: July 31, 2023, 08:29:46 am
content: Quote from: Siwastaja on July 30, 2023, 11:44:16 amYour lean towards RS422 vs R485 is actually proof issues you expirience are not RS485 related. RS485 and RS422 use the same physiscal layer. If protocol layer has issues with IDLE/ACTIVE transition it is protocol issue. Good noise-resistant implementation is difficult with RS485 - it is true. CAN handles it by default, while often one end of RS485 is outside of control as is third party.With noise margins comparing voltage margins does not make sense. RS485 has low margin, yet works with terminated bus - external E or H fields need to be much larger to disturb it comparing to RS232 which has high impedance (15 k?) far easier to disrupt than 120/60 Ohm bus. Voltage margin does not matter really. Common mode range + EMC margins. Both depends on cabling quality which often is lacking in real implementation, despite good circutry design.Another issue is distance... RS232 over 100 meters? 1000 meters? Never seen it working as it is extreemly far from specs.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 31, 2023, 08:55:20 am
content: Quote from: CosteC on July 31, 2023, 08:29:46 amSo you completely ignored what I wrote about mark/space noise margin being relevant on RS422 but not being relevant on RS485, and also what I wrote about technically correct and blame shifting. When the protocols actually used in real-world RS485 devices suffer from poor noise margin, it doesn't matter the slightest whether it's "rs485's fault" or "protocols's fault". I'm not playing this game any longer, you either get it or you won't.Voltage margin does not matter is a ridiculous claim. Of coursenegative voltage marginmatters, because any operation is by luck. Now for positive margins it's all down to how well the line is truly differential in geometry, how well the drivers are balanced, are there timing skews etc., common to differential mode noise conversion etc. Why CAN would choose 500mV if it doesn't matter, could it be 100mV? 50mV? 1mV? This sort of discussion is exactly what you can find if you did what I suggested in first place, google "RS485 failsafe biasing" to find as many appnotes about this very common problem as you want.And yes, I have ran devices with RS485 through EMC compliance testing. The problems are always with spurious start bits, never in data integrity during correctly detected packet, exactly as predicted by theory. And yes, 115200bps RS485 through CAT5e barely passes only thanks to B criteria, while 100M Ethernet for example using the same CAT5e passes with flying colors on A criteria.

author: asis
author_rank: Frequent Contributor
timestamp: July 31, 2023, 01:35:01 pm
content: Hi,I don’t want to break your smart conversation, but I want to suggest looking at one real technical solution, which, for all its originality, was killed by a thunderstorm, which required reverse engineering due to moral and material interest.The host had MOXA114i installed, which also suffered.

author: uer166
author_rank: Super Contributor
timestamp: July 31, 2023, 05:25:01 pm
content: Quote from: CosteC on July 31, 2023, 08:29:46 amI've seen a terminated (but without failsafe biasing) RS485 bus fail miserably over1 foot. Your comment about RS485 vs RS422 doesn't make any sense, the issue is specifically with the idle state having so little margin that it'll trigger a DOS of start bits in non-ideal conditions, show me a protocol that can deal with that when there's a start event every byte or more. That can be fixed in RS485 but not using it bidirectionally and keeping a transmitter always-on, and of course it doesn't exist in RS422 because it's already like that,

author: AndyC_772
author_rank: Super Contributor
timestamp: August 01, 2023, 11:05:15 am
content: How does Modbus deal with that issue? It's inherently bidirectional and used almost exclusively in noisy industrial environments.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 01, 2023, 11:20:08 am
content: Quote from: AndyC_772 on August 01, 2023, 11:05:15 amIt doesn't deal with it, and no, it's not used almost exclusively in noisy industrial environments, you have fallen into the trap of believing wrong sources.Also that's why industry employs automation experts and maintenance staff. Getting modbus over rs485 work in a real industrial environment consists of either understanding things like grounding and biasing resistors (while shifting the blame as demonstrated in this thread has the disadvantage of not solving the problem; don't trust blame shifters!), or trying random things until it seemingly works, then working around problems when they pop up. Modbus also requires stuff like setting up dummy registers to test endianness. Besides, not all "industrial" is very noisy, why would it? You would be surprised to find out how rare RS485 / modbus RTU is in new industrial installations for past 20 years or so, in favor of ethernet (including Modbus TCP) or optical fiber. After all, galvanic isolation and high bit rates offered by Ethernet are a huge plus, and whenever environments are truly noisy or dangerous voltages are present, think about power distribution or megawatt-class motor drives, optical fiber is used because copper anything is a huge problem.CAN is also surprisingly widely used contender for modbus RTU in industrial applications, it's not limited to vehicles.

author: ejeffrey
author_rank: Super Contributor
timestamp: August 01, 2023, 02:44:32 pm
content: Quote from: Siwastaja on August 01, 2023, 11:20:08 amWe have a fair number of devices which appear to be internally modbus rs485 but have a built in Ethernet bridge. This at least lets you put the burden of getting the rs485 biased properly on the manufacturer without worrying about the rest of the system.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 01, 2023, 03:21:21 pm
content: Quote from: ejeffrey on August 01, 2023, 02:44:32 pmYeah, and simple product evolution: since customers have trouble working with modbus RTU and prefer ethernet and modbus TCP, the manufacturers supply them what they ask for, but don't want to do full PCB redesign but simply an add-on module to the existing design.

author: Berni
author_rank: Super Contributor
timestamp: August 01, 2023, 05:30:52 pm
content: When running your own communication protocol over them there is not that much difference between RS485 and CAN anyway.The signaling levels used by CAN is not inherently more robust by any huge degree. Putting enough noise into it will still make it twitch. The noise resistance to really big noise levels comes from the common mode chokes and filtering before the transceiver chip.What makes CAN so bulletproof is the communication protocol. It is not significantly bothered by a spurious pulse coming into the receiver, while when an uninvited pulse comes in during actual data, that gets quickly detected. If any node on a CAN bus thinks it is seeing garbage it can jam the entire bus on purpose to force a re-transmission, this gets handled by the CAN controller all automatically, so the higher level protocols on top don't even notice it (apart from an error counter getting incremented here or there). Tho the downside is that CAN is limited in length because the protocol requires the round trip time of flight delay between all devices being shorter than 1 bit period, but CAN FD is a bit of a workaround for that.Ethernet is indeed the king of long distance reliability. Being transformer isolated helps a lot. But it is a lot of complexity and power consumption for simple applications. Like where you might just want to send over a few temperature readings once per second. Tho you can simplify Ethernet down a lot for just point to point links. Raw MAC frames can be sent trough it much like a glorified UART, no fancy TCP/IP stacks. There are also single pair ethernet PHYs, so you can run 100Mbit over pretty much the same cables that CAN would run across, and even do it with PoE support. The BOM cost for all that fanciness is going to inflate rapidly tho.

author: Smokey
author_rank: Super Contributor
timestamp: August 01, 2023, 08:42:44 pm
content: Quote from: Berni on August 01, 2023, 05:30:52 pmThat, is interesting....Will single pair ethernet phy work with existing MACs?Answering my own question:https://www.ti.com/lit/ds/symlink/dp83td510e.pdf"It interfaces with MAC layer through MII, Reduced MII (RMII) , RGMII, and RMII low power 5-MHz master mode. It also supports RMII back-to-back mode"

author: ataradov
author_rank: Super Contributor
timestamp: August 01, 2023, 09:04:20 pm
content: There is also 10BASE-T1S, which is indented as a replacement for CAN in automotive environment. Segment length is shorter (25 m), but it supports multi-drop topology.Note that both are 10 Mbps standards. I don't know if there is a 100 Mbps equivalent for a single pair.

author: ejeffrey
author_rank: Super Contributor
timestamp: August 01, 2023, 10:02:44 pm
content: There is even up to gigabit single pair ethernet in 1000base-T1. AFAIK it's also used in automotive applications, I assume for AV streaming purposes.

author: Smokey
author_rank: Super Contributor
timestamp: August 02, 2023, 06:11:21 am
content: What about LVDS? I thought that was used for the really fast stuff like cameras. How does that compare for immunity and robustness? The voltage tolerance sure isn't as good.

author: Berni
author_rank: Super Contributor
timestamp: August 02, 2023, 06:38:31 am
content: Yep single pair ethernet comes in a fair few flavors.Most of them run trough PHYs that have MMI,RMMI, RGMMI...etc interfaces so they do look like your normal bog standard ethernet PHY, so the ethernet controller doesn't even know it is talking over single pair.The whole thing mainly came out as an automotive thing and there is even a new standardized connector for SPE cables (it is not RJxx, it is completely new). While CAN is reliable, it is slow and has a lot of overhead, so as they need more speed the automotive industry turned to ethernet.Since it is just ethernet it means it also integrates with computers very easily. You can give a linux SBC capability for it by just adding a PHY, you can make a USB to SPE network card. There are network switches that have SPE ports instead of RJ45, so you could plug SPE straight into your LAN if you wanted (since these switches usually have at least one normal RJ45 port). Tho at that point implementing a SPE node in a MCU gets significantly more complicated as you need a full TCP/IP stack with ARP and DHCP and all that jazz, otherwise the network switches won't know what to do with your packets.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: August 02, 2023, 07:49:22 am
content: Quote from: Smokey on August 02, 2023, 06:11:21 amyes, that exists called M-LVDShttps://www.analog.com/en/parametricsearch/11050#/Those drivers have high ESD levels, but the common mode range ability is much less than CAN/RS485/422, but they are much faster.one ADI example is -1.8V ~ 4V ABS MAX with test values given at around 3.3V and -1.3V

author: CosteC
author_rank: Regular Contributor
timestamp: August 02, 2023, 08:59:46 am
content: Quote from: Smokey on July 28, 2023, 09:20:16 amGetting back to core of topic:What is distance?What is required speed?Is it point-to-point or multidrop?If it is point-to-point over long range, RS422 will be simple to implement, fast (up to 50 Mbps) and noise resistant.Surge resistance/ESD is almost always relying on external components to transciver - this is cheaper and more scallable. Every sensible supplier will provide application notes how to do it.Anyway: Nothing replaces good cable and good practices. Fibreoptic is close to ideal except fibre is not easy to connect and rather mechanically delicate...Not everybody is so traumatised by RS485 issues, there is no ideal physical layer/protocol either.Actually, MODBUS standard mentions failsafe bias as requirement for RS485 implementation paragraph "3.4.6 Line Polarization" Page 28:https://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdfUnfortunate thing is, this standard is not implemented correctly in many cases.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 03, 2023, 09:26:52 am
content: Quote from: CosteC on August 02, 2023, 08:59:46 amI don't know why, maybe it was published too late (I have not tracked modbus standard revisions), but this particular specification is so widely violated in almost every respect that it's nearly useless; hence, most modbus devices do not discuss the biasing in documentation as required.Modbus standard specifies other useful stuff, too, like thateven parityMUST be implemented and MUST be the default mode, and the optional no parity mode MUST use two stops bits. Yet many modbus devices are 8N1 (illegal mode), by default, and as the only option, which breaks this standardthree timesin one go!The standard is actually pretty sane both in both renaming "failsafe biasing" with more accurate "line polarization", and requiring the devices to deal with it, since RS485 fails to deal with it and pushes the problem to protocol layer where it doesn't belong (in my books, resistor value specifications are physical layer, not logical protocol) but better have it there than not at all. Still, the modbus standard does not discuss the resulting noise margin at all so it's all hand-waving and back to failsafe biasing appnotes and their calculation examples, and this includes knowing what transceiver ICs were used which is usually unspecified.I can see this is also why the modbus standard limits the number of devices per bus as 32, even though even that is a tad optimistic for some values of biasing resistors. Practically even just 20 devices is of course plenty.Attached is how I dealt with RS485/Modbus (usually in master mode) in my latest product design; the most usual cases being, in this order:T+B, end of bus, one of the devicesT, end of bus, the other one0, in the middle of the bus, or special use case with custom external resistors

author: CosteC
author_rank: Regular Contributor
timestamp: August 03, 2023, 01:43:58 pm
content: Quote from: Siwastaja on August 03, 2023, 09:26:52 amThis is from Dec 20, 2006. Not very new.But the problem is most of programmers does not like or neither use standards, and do not know about issues with physical word like noise. "CRC solves everything". Nope. It solves SOME issues. Does not replaces line polarisationNumber of devices is in my expirience to do a lot with nominal loading as well as quality of wiring. Actually wiring quality, especially lack of GND connection was source of issues I was dealing with. There are also horrible devices without GND and isolated RS485 transciver - where noise immunity is in dreamland zone.MODBUS standard is pretty good. Really helps with implementation and debug. But does not help with screwed devices.

author: Smokey
author_rank: Super Contributor
timestamp: April 26, 2025, 06:06:10 am
content: Check me if I'm wrong here, but is it true the SN65HVD230 CAN Transceiver does NOT have the Dominant Timeout (DTO) feature?https://www.ti.com/lit/ds/symlink/sn65hvd230.pdfIf that's true, that might open up some doors for off-label non-canbus differential physical layer stuff.

author: Berni
author_rank: Super Contributor
timestamp: April 26, 2025, 07:06:51 am
content: The early CAN transceiver chips were just RS485 transceivers with the right specs and wired in a different way. Then once CAN got some actual adoption they seen it worth making purpose built CAN transceiver chips.So if you just want to send any arbitrary signal over a long diff pair use a RS485 transceiver. They go to much higher speeds too for the faster chips, >50Mbit. Heck you can even pack a completely different bus into diff pair form using them. Such as SPI over diff pair if you use 4 transceivers and that also fits nicely over CAT5 Ethernet cable (tho synchronous protocols like that do have to worry about the cable delay, so you might have to get a bit creative if you want to run it at high bitrates).

author: dukelec
author_rank: Contributor
timestamp: April 27, 2025, 02:17:52 am
content: THVD2450DR±70-V fault-protected 3.3-V to 5-V RS-485 transceiver with IEC ESDExtended operational common-mode range: ±25 V50Mbps (THVD2410: 500 kbps)SN65HVD1781 with ±70-V fault-protected for lower speed RS485RS485, like CAN FD, can implement arbitration and dual data rates (CDBUS). During the data phase, RS485 supports push-pull output, allowing for much higher speeds (≥50 Mbps) and better noise immunity. In contrast, CAN FD continues to use open-drain output during the data phase, which limits both transmission distance and speed. Additionally, CAN FD requires readback during the data phase; because of the higher transmission speed, the delay can exceed one bit, and with many timing parameters involved, misconfiguration is easy and can lead to errors.UART communication can also use CAN (FD) transceivers instead of RS485, as long as compatibility with other devices is not a concern.

author: JoeyG
author_rank: Regular Contributor
timestamp: April 27, 2025, 03:14:15 am
content: +1 "A faulty CAN node might start transmitting data without a valid reason or even unintentionally, leading to a situation where the bus is continuously occupied, preventing legitimate communication. " So there are timeouts in the CAN transciver