EEVblog Electronics Community Forum
Electronics => Projects, Designs, and Technical Stuff => Topic started by: 5U4GB on November 05, 2024, 01:06:20 pm
-
I sometimes have to work with modbus (so RS-485) setups that include hubs and repeaters, typically to allow localised star configurations in locations where the standard multidrop setup isn't practical. However of the several hubs I've now worked with, none have built-in termination resistors, which makes them a huge pain to wire up since you can no longer run each wire pair directly into the hub but have to add termination resistors across each one.
Is there some technical reason why you'd build a hub, whose entire job is to constitute one end of an RS485 bus, without the termination resistor that this entails, or is it just a case of not-my-job?
-
They should and they should also included pull up/pull down resistors so the lines don't just flap in the breeze.
The technical reason that you will be told is that there are subtleties to terminations, not all nodes require it, some use AC terminations and in many cases you can use none. The truth is that it adds some cost and complexity and the suppliers side step the issue.
RS-485 is a poorly written standard with gaping holes and ambiguity that are traps for those applying it.
My 2 cents- curious to see what others say.
-
Cheap-assiness of the manufacturer. Not just component cost, but the "someone else's problem" mindset. I understand that not every random device (e.g. with RS485 being a rarely used extra feature) have those, but I would expect a specific freaking hub product to have configurable (e.g. by switches or jumpers) termination and biasing resistors for ease of install and use.
We have a controller product (basically always modbus master) with two RS485 buses and I opted for a three-way mechanical SMD switch where you can choose termination, termination+bias and none. Cost of components is negligible even when this is a relatively low-cost product.
A thousand have been sold and in 100% of installs the correct position has been T+B. Still, we are not even considering dropping the switch. It's such small expense and gives such boost in flexibility and ease of install that we think having it is a no-brainer. We are surprised how others want to push a relatively complex technical problem into poor electricians who almost never have competence in understanding pecularities of modbus biasing and RS485 termination.
-
The reason is simply that RS485 is meant for a multidrop configuration with short stubs to each device and with only two termination resistors one at each loose end of the multidrop cable.
Using RS485 in a star configuration (with or without termination resistors) is wrong, it does "work" in many cases but may be totally unreliable in other cases, there will inevitably be an impedance mismatch at the star point.
A permanent termination resistor built-in to the hardware therefore makes little sense for the hardware manufacturer unless the hardware is made for a specific application where the hardware will always be at one of the loose ends of the multidrop and the network is well defined. For example RS485 bus between boards within the same equipment. For a generic RS485 hardware it's not always the case that it is at the loose end of the multidrop.
In some cases the termination resistor is not just a simple resistor either but it could be an ac termination or split 60ohm with low pass filter.
I understand the usefulness of having a built-in switchable termination resistor it would surely cover the vast majority of applications, but quite frankly I see the cable termination as part of the wiring rather than the RS485 hardware itself. I've designed several products using RS485 and never included built-in termination (I sometimes do add a footprint for a termination resistor but never mounted it). It's not so much a BOM cost issue, I think it is more an issue in adding a method to enable/disable the termination in a product that it typically meant for rugged/industrial environments. If you add a switch it would often need to meet some IP rating, you need to handle ESD at that switch, etc... it adds quite a bit of complexity for something that in reality will only be used on a small percentage of the units. The industry also typically expects wire termination to be external so you'd often have the wiring installed with terminations by the wiring installer.
Edit: On re-reading the OP's post I realized that what he refers to as star topology is in fact using hubs and repeaters so that is not actually a star topology but rather a multitude of point-to-point topologies, in which case it is of course correct and requires terminations at both nodes in each point-to-point branch.
-
. If you add a switch it would often need to meet some IP rating, you need to handle ESD at that switch, etc... it adds quite a bit of complexity for something that in reality will only be used on a small percentage of the units. The industry also typically expects wire termination to be external so you'd often have the wiring installed with terminations by the wiring installer.
one way of doing it is to add the termination on board and an extra pin so you only need to jumper two pins to terminate
-
....I sometimes do add a footprint for a termination resistor but never mounted it...
Copy that. I "always" add a footprint for a termination resistor... and they are "never" used.
Speaking of AC termination, there are tons of theoretical information available. However, is someone able to summarize what are the use cases in practice. I am interested when it is possible to use AC termination instead of a termination resistor.
sw guy
-
but quite frankly I see the cable termination as part of the wiring rather than the RS485 hardware itself. I've designed several products ...
Of course you see it that way because it tremendously helps you with your design work, pushing the problem forward >:D
And sometimes it's the right solution, it depends on the target audience of your product. Ignoring designers and looking at your customers (for whom the product should be designed!), there are three sorts:
1) Those who have maybe heard the term "RS485" once or twice, and never carry any resistors with them. Normal electricians.
2) Those who have wired up many RS485 buses in their life and know there must be 120-ohm termination resistor, maybe even carry a few with them or at least know where to buy them.
3) Those who know what "failsafe biasing" is and carry other resistor values with them, are able to measure (e.g., with handheld oscilloscope) and debug RS485/modbus buses. They build complex industrial control system out of modules.
For example, out of our installer base basically everybody belongs to 1. They wire up energy meters, solar inverters, battery inverters, EV chargers and other building automation stuff to our controller. And significant % of these devices are actually hard-wired to have 120-ohm termination making them point-to-point only devices. Others have jumpers or switches to enable termination, just like our box. These are slave devices and possibly take care of termination of one end, but leave biasing as "someone else's problem".
And we are that someone else. If we try to push it to installers, all we get are very unhappy customers.
Maybe you deal with mostly group 3, maybe 2. Then it might be indeed a great idea to leave the problem for the installer to solve. They can apply whatever AC termination scheme they wish.
-
but quite frankly I see the cable termination as part of the wiring rather than the RS485 hardware itself. I've designed several products ...
Of course you see it that way because it tremendously helps you with your design work, pushing the problem forward >:D
I wouldn't say this is 'pushing the problem', signal reflection and hence the need for proper termination is fundamentally a cable problem not an RS485 problem.
This is like blaming a singer for the echo and expecting them to bring sound absorber panels with them!
If it is a device meant for a specific system or pre-defined panel installation, I agree there is a strong argument in favor of built-in (or built-in jumper connectable) termination. The AB DH485 is a typical example of this. However for a generic RS485 device the argument is much weaker especially considering that all of the connector and cabling aspects in RS485 are completely non-standardized. With just the basic A and B connections there is already widespread inconsistency about labelling and polarities. I would imagine having some devices with an extra terminal for termination jumper other devices with fixed built-in termination, others with switch controlled termination, ...would just add more confusion, especially for the group 1 that you mentioned.
-
They should and they should also included pull up/pull down resistors so the lines don't just flap in the breeze.
I thought pullups/pulldowns were mostly optional (https://e2e.ti.com/support/interface-group/interface/f/interface-forum/522485/rs-485-ic-inputs-need-pull-ups) and sometimes even discouraged (https://electronics.stackexchange.com/questions/284778/rs485-pull-up-pull-down-and-eol-resistors), with only the termination resistors being necessary? I've only ever wired in the termination/EOL resistor.
Which is actually extremely useful as a quick go/no-go check, 120 ohms on the line means you've most likely got the right cable pair, 60 ohms once you add the resistor at your end as a double check.
And for @Siwastaja, there's a (2a) type, "carries a bandolier of 120 ohm resistors in their tool belt".
-
Cheap-assiness of the manufacturer. Not just component cost, but the "someone else's problem" mindset. I understand that not every random device (e.g. with RS485 being a rarely used extra feature) have those, but I would expect a specific freaking hub product to have configurable (e.g. by switches or jumpers) termination and biasing resistors for ease of install and use.
That was my feeling as well, the hub constitutes one end of the bus (or at least the downstream ports do since they're isolated bus segments) so they should have termination resistors. I've worked with gear from the same vendor where device A has it jumper-settable and documented, device B has it but it's undocumented, and device C doesn't have it.
-
They should and they should also included pull up/pull down resistors so the lines don't just flap in the breeze.
I thought pullups/pulldowns were mostly optional (https://e2e.ti.com/support/interface-group/interface/f/interface-forum/522485/rs-485-ic-inputs-need-pull-ups) and sometimes even discouraged (https://electronics.stackexchange.com/questions/284778/rs485-pull-up-pull-down-and-eol-resistors), with only the termination resistors being necessary? I've only ever wired in the termination/EOL resistor.
For most async serial applications of RS485 (including modbus and similar protocols) pull up / down bias resistors are mandatory. Unfortunately a lot of people believe nonsense like this and it is one of the things that makes RS485 a disaster.
Also, transceivers that claim to have "failsafe biasing" which is a terrible and misleading name can usually not be trusted unless you are staying in the same chassis. You need real bias resistors if you run cables between devices.
Leaving out the bias resistors creates the worst possible system: one that always works on the bench and usually works in the field.
-
Is there some technical reason why you'd build a hub, whose entire job is to constitute one end of an RS485 bus, without the termination resistor that this entails, or is it just a case of not-my-job?
Because the placement of the termination resistor is based on the wiring, not on the role.
-
I wouldn't say this is 'pushing the problem', signal reflection and hence the need for proper termination is fundamentally a cable problem not an RS485 problem.
This is like blaming...
Talking about blame is interesting because it has built-in assumption that things go wrong and unhappiness ensues ;D
I mean, as designers we are the best experts possible on stuff like signal reflection. If we can do anything to help our customers with it, we need to do it. For example in products that are often placed at the end of the bus, that means adding easily configurable termination. In products that are often modbus masters, that means adding configurable bias resistors - I know it's not related to master role per se, just "once in the system somewhere", but at master is a logical place to do it because the condition of having exactly one (no less, no more) master matches the condition of having exactly one (no less, no more) set of bias resistors.
And then of course, documentation is paramount, because our customers usually are not signal integrity experts. What type of cable to use, when to enable our integrated resistors or when to add external resistors.
With Chinese modbus slave devices it is very usual to not see any mention of termination resistors at all. We then measure with a multimeter if there is a permanent built-in resistor, making the device easier to install but point-to-point two-device bus only. Quite often there is.
-
For most async serial applications of RS485 (including modbus and similar protocols) pull up / down bias resistors are mandatory. Unfortunately a lot of people believe nonsense like this and it is one of the things that makes RS485 a disaster.
Also, transceivers that claim to have "failsafe biasing" which is a terrible and misleading name can usually not be trusted unless you are staying in the same chassis. You need real bias resistors if you run cables between devices.
Leaving out the bias resistors creates the worst possible system: one that always works on the bench and usually works in the field.
This post should be cross stitched and framed and put on the wall of the coffee room with spotlights aimed at it at every company designing or installing RS485/modbus stuff.
-
With Chinese modbus slave devices it is very usual to not see any mention of termination resistors at all. We then measure with a multimeter if there is a permanent built-in resistor, making the device easier to install but point-to-point two-device bus only. Quite often there is.
I do that too, which is how I found out about the present-but-undocumented ones I mentioned.
On a vaguely related note, I finally found the application note on termination types (https://www.ti.com/lit/an/snla034b/snla034b.pdf) that I remembered reading years ago but lost track of... which was also a chance to refresh my understanding of the different types.
-
Speaking of AC termination, there are tons of theoretical information available. However, is someone able to summarize what are the use cases in practice. I am interested when it is possible to use AC termination instead of a termination resistor.
sw guy
A few posts back- SW guy asked about AC terminations and it fell aside. Another poorly understood deal...
The idea of an AC termination, a cap in series with the termination resistor, is a power saving technique that usually doesn't apply to 485. Since the feflected waves are steps with fast rise times, AC terminations solve the termination problem (the cap is a short to the steps) but don't draw any DC power with the bus in a fixed on state. RS-485 in its usual form is a "tri-state" kind of bus for non talkers so this shouldn't be an issue. A 485 node is high impedance when receiving and only drives the but when its enable to talk. AC terminations are more applicable to RS-423 (used in Apple talk, etc).which is very similar to 485 but doesn't use the tristate feature. The idea is to not have DC current just heating up termination resistor and wasting power. RS-485 is sometimes run in a non-duplex mode where the bus is never floated- applications like PIN pads in retail often are run to a back room hub.
Another related idea is "unit loads". RS-485 was initially designed to have a maximum of 32 drops on a bus. This is related to the fan-out of the drivers to the fan-in of the receivers. Maxim (my old employer) and others made 1/4 unit load and 1/8 unit load devices that maintained the fan-out of the drivers but raised the input impedance thus allowing up to 256 nodes on bus.
This topic is near and dear to my heart, I managed the standard products new product machine at Maxim where we proliferated the original CMOS MAX485 for the 75176 type devices in every way imaginable. I spent a lot of time talking to 485 users about their issues and we designed parts to try to address these needs. I came to really despise 485- though it made a lot of money for the semi companies chasing problems.
-
This topic is near and dear to my heart, I managed the standard products new product machine at Maxim where we proliferated the original CMOS MAX485 for the 75176 type devices in every way imaginable. I spent a lot of time talking to 485 users about their issues and we designed parts to try to address these needs. I came to really despise 485- though it made a lot of money for the semi companies chasing problems.
The problem is, as semiconductor designer you can only do so much. Sure features like slew rate control for controlling EMI are really useful, or you can reduce power consumption, increase ESD ratings, make sure your IC does not blow up at short circuit or accidental application of say +12V, useful stuff like that - but you really can't do much on the worst real world problems that appear on the field, namely failure to bias and failure to provide ground lead.
As one recent train wreck thread on RS485 biasing showed, even people working in this field do not fully understand the consequences of the bus idle level on UART-based RS485 protocols like modbus. Bias-resistor-less transceivers are suggested from time to time and chip manufacturers of course like to market them, but they are no help at all if you need interoperability, as is almost always the case with MODBUS. If you can design all bus participant devices in-house you can as well drop MODBUS completely as unnecessary complication which it is. But if you need to interoperate, most others just keep using the traditional transceivers with traditional hysteresis / levels. As long as even one uses them, you need the bias resistors, or those slaves keep seeing start bits on any random noise and become unresponsive, or worst case, shout replies on the bus.
-
https://mx-en.rs-online.com/product/siemens/6sl32550vc000ha0/71560658/ ;)
-
https://mx-en.rs-online.com/product/siemens/6sl32550vc000ha0/71560658/ ;)
Broken website. "You are blocked". Fuck you rs-online.
-
It's very common for DMX devices to have switchable termination resistors, where you'd only select it on the last device. Obviously a relay and the associated logic/control takes a bit of space and costs money.
The other way is to have a termination resistor in an XLR housing that you manually plug into the last device. Ironically the "not my problem" type approach is more expensive for the consumer as the XLR termination resistors cost more than a relay.
The RS485 transcievers are usually rated for an output load of ~55 ohms, ie either 2x 120 ohm cable lengths in parallel, or a single cable in parallel with a termination resistor.
-
It's very common for DMX devices to have switchable termination resistors, where you'd only select it on the last device. Obviously a relay and the associated logic/control takes a bit of space and costs money.
Yeah. If it has to be software controllable a smaller and more affordable (than a mechanical signal relay) photo-mosfet can be used. A simple DIP switch is even lower cost, especially if you are going to have a DIP switch there anyway to configure something else, then an extra contact plus a 120-ohm 1206 resistor would cost only a few cents. If you assign any cost for customer dissatisfaction and them trying to source a resistor or your special terminated end-plug, the switch+resistor is cheaper. Similarly, if you have to ship a special end plug, it's at least ten times more expensive than the switch+resistor on PCB, and this is not even assigning any cost for the packaging of the extra part. And then customer loses it so it's of no value anyway.
-
For most async serial applications of RS485 (including modbus and similar protocols) pull up / down bias resistors are mandatory. Unfortunately a lot of people believe nonsense like this and it is one of the things that makes RS485 a disaster.
Also, transceivers that claim to have "failsafe biasing" which is a terrible and misleading name can usually not be trusted unless you are staying in the same chassis. You need real bias resistors if you run cables between devices.
Leaving out the bias resistors creates the worst possible system: one that always works on the bench and usually works in the field.
This post should be cross stitched and framed and put on the wall of the coffee room with spotlights aimed at it at every company designing or installing RS485/modbus stuff.
Well, I never really thought about the problem or worried about it until I had a system that was deployed in the field with a few hundred systems with ~15 nodes each where I started getting a few systems with random but data dependent corruption (e.g., on each system specific communication patterns were much more likely to cause a problem).
-
They should and they should also included pull up/pull down resistors so the lines don't just flap in the breeze.
I thought pullups/pulldowns were mostly optional (https://e2e.ti.com/support/interface-group/interface/f/interface-forum/522485/rs-485-ic-inputs-need-pull-ups) and sometimes even discouraged (https://electronics.stackexchange.com/questions/284778/rs485-pull-up-pull-down-and-eol-resistors), with only the termination resistors being necessary? I've only ever wired in the termination/EOL resistor.
Which is actually extremely useful as a quick go/no-go check, 120 ohms on the line means you've most likely got the right cable pair, 60 ohms once you add the resistor at your end as a double check.
And for @Siwastaja, there's a (2a) type, "carries a bandolier of 120 ohm resistors in their tool belt".
If you're talking about a multi-drop setup, each transceiver should be in a receiver/high(ish) impedance state until they need to drive the bus. So the idle state leaves it more susceptible to noise, at least in my experience the transceivers weakly set the lines to a logic high, but don't drive the lines to the sames voltage as you'd expect if they're in transmit mode.
The added biasing resistors just give you more margin for noise/error. It's all dependent on whether your intended environment is noisy, like the worst case industrial environments.
Just to add as well, I've seen quite a few diagram from Texas Instruments et al, showing fairly low values like 330 ohms to 5V and GND, but I've never used anything that low. 10k or 4.7k sets the lines just fine for my needs, but I'm also not doing anything industrial. It's more just to overcome any potential manufacturing variation in transceivers as I'm not sure if any and every transceiver is guaranteed to result in the bus being a logic high when all units are in an idle state. Also, the idle state resistors are only on one device, ie the master, or the client if you're talking MODBUS.
Edit again: Using 330 ohms on each line to 5V and GND respectively, then 150 across the lines should give a termination close to 120 ohms?
ie ((2x330)^-1 + 150^1)^-1 ~= 122 ohms
So I guess you could hard-wire that combination of resistors on your master device.
-
in my experience the transceivers weakly set the lines to a logic high
Receivers that weakly set lines to logic high are specified as being fail-save with lines open, but lines are open only if you have not terminated bus.
So I guess you could hard-wire that combination of resistors on your master device.
Provided that you force your master device being at one bus end what not always is the best solution. And to ensure the correct voltage along the whole bus you have the same polarization being done at the other bus end.
In 90s we have tried with such polarization but:
- switching on termination is more complicated/understandable for users compared to single resistor,
- we didn't found any solution allowing the bus to function normally with any one slave device having its supply switched off (when this 'any one' happens to be that one ensuring bus polarization).
At the end of 90s we found transceiver being specified as fail-save for open and short bus and decided to use them instead of polarizing the bus. For bus shorted (0V at bus set by terminal resistors) they read logic high (with 50mV noise margin, if remember well).
If the device at which terminal resistor is switched on have its supply switched off the terminal resistor still works and all other devices can communicate without any problem.
-
Well, I never really thought about the problem or worried about it until I had a system that was deployed in the field with a few hundred systems with ~15 nodes each where I started getting a few systems with random but data dependent corruption (e.g., on each system specific communication patterns were much more likely to cause a problem).
The problem is that people think RS485/modbus is an "industrial quality" "very robust" "against noise" and "long wiring" and whatever marketing bullshit. In real systems with real misunderstandings (e.g. lack of biasing, grounding through parasitics) it's closer to a Arduino tutti frutti dupont cable contraption: works on the lab table and often works on the field with near-zero noise margin.
People overestimate how demanding industrial environments are. Often crappy hobbyist kludges would work well in industrial environments if they were allowed. RS485/modbus has social acceptance in industry, but in practice is often on the same level as those kludges, people just don't know it. Until it fails, and then RS485/modbus specialists are brought in. Or problem sidestepped without them, doing random changes until it seemingly works again, hobby way.
-
The added biasing resistors just give you more margin for noise/error. It's all dependent on whether your intended environment is noisy, like the worst case industrial environments.
This is technically correct but how you use the word "more margin" is easily misleading. The point is, without the biasing resistors (using standard transceivers), you start with no noise margin at all. So yeah, you need more margin for the thing to operate at all except by sheer luck. Many discussions on topic make it sound like bias resistors would be giving some extra margin on top of something which already works, but this isn't the case. In fact, even with optimized resistor values, you would still be limited to 1/10th (or maybe 1/5th, check the math, don't trust my word) to what is claimed to be the noise margin of RS485 bus.
Just to add as well, I've seen quite a few diagram from Texas Instruments et al, showing fairly low values like 330 ohms to 5V and GND, but I've never used anything that low. 10k or 4.7k sets the lines just fine for my needs
You can find appnotes that dive deeply into calculating bias resistor values, how they affect the noise margins and max unit loads. Without re-checking the math, I would handwave that 10k is still in the zero-ish noise margin which you don't want. Somewhere around 500-1000 ohms should be the correct range; the idea is you have to bias the receivers beyond the hysteresis band. After your idle levels go beyond the hysteresis band, only then you are in a defined state, and at that point noise margin is zero and starts increasing as you decrease the resistor values further.
With no resistors at all, or 10k resistors, you would be in the hysteresis band, noise margin is zero (or negative if you allow it to be defined that way), and the line state is undefined.
Really, without the bias resistors the system "works" by the fact that the 120-ohm termination resistors tie the lines together so that not many mV of noise easily couples, and in the typical implementation whoever shouts sets their UART to IDLE level before disasserting its DRIVER ENABLE signal, so that line is strongly driven into IDLE state before being released. This sets all receivers to output the idle state, which then remains when the line goes into undefined state (within hysteresis band) - the receivers "remember" the last valid state which was IDLE. All you need is a single noise event of a few mV to disrupt that memorized state and "kill" the receivers into receiving endless START bit. You see, being right in the middle of the undefined range, in the hysteresis band, means that the wrong state will be remembered indefinitely, too.
-
The problem is that people think RS485/modbus is an "industrial quality" "very robust" "against noise" and "long wiring" and whatever marketing bullshit. In real systems with real misunderstandings (e.g. lack of biasing, grounding through parasitics) it's closer to a Arduino tutti frutti dupont cable contraption: works on the lab table and often works on the field with near-zero noise margin.
People overestimate how demanding industrial environments are. Often crappy hobbyist kludges would work well in industrial environments if they were allowed. RS485/modbus has social acceptance in industry, but in practice is often on the same level as those kludges, people just don't know it. Until it fails, and then RS485/modbus specialists are brought in. Or problem sidestepped without them, doing random changes until it seemingly works again, hobby way.
That is also my experience, many think as long as you're using RS485 you can wire it up in whatever way is convenient and she'll be alright! The truth is if someone does not understand the fundamentals of RS485 wiring, termination, biasing, layout, shielding, etc... he shouldn't be doing RS485 wiring in the first place.
So I fully agree with all that of course, but I think this strengthens my view that all of this is a 'wiring installation problem' not an 'RS485 hardware problem'. When I am doing an RS485 installation, I want the wiring to be in place, with all terminations, biasing, etc.. independently of any hardware that will be attached to it. I'm not relying on a mix of inconsistent devices from different manufacturers, with a possibly undocumented implementation, to handle bus termination and biasing for me. None of this is standardized in RS485 so all I expect from a device manufacturer is to stick to the lowest common denominator of an RS485 transceiver with adequate protection. That is the same reasoning that I apply in RS485 hardware design.
-
Edit again: Using 330 ohms on each line to 5V and GND respectively, then 150 across the lines should give a termination close to 120 ohms?
ie ((2x330)^-1 + 150^1)^-1 ~= 122 ohms
So I guess you could hard-wire that combination of resistors on your master device.
Why would you do that? You place 2x 120 Ohm resistor between A and B, at the two ends. No branches, no Ys. No I'm going to invent new stuff that's not in the standard, no getting creative about the termination.
Failsafe biasing is not for the RS485 line. It's for your device. It's there, in case the wire would break, or only one wire would be connected, the random noise isn't going to write your temperature controller to a million degree for example. Because that two resistor sets the A and B and therefore the R pins default to a fixed state instead of floating randomly.
RS485 is a very reliable system if designed and installed correctly, but you have to follow the rules. If you do that, the wire could be kilometer long and you could install dozens of nodes and it's just going to work properly to eternity.
-
You write you want to use a "hub" (repeater, whatever) to make a local star point. If you do not have termination resistors in the star point, then you can route two branches from one "output" of your hub.
I don't really understand why termination resistors are built into nodes in the first place. It is the end of the cable that needs termination, and not the nodes.
For a while I have used CAT-5 cables and two RJ-45 connectors for my nodes, and I also made a few RJ-45 connectors which just have a resistor in them. So a node receives either two cables, or it receives a cable and a termination resistor. This works quite well, but it also has some disadvantages. My (custom protocol) bus has both power (24Vdc) and data, and with this setup whole sections of the bus are temporarily disconnected from the bus if I want to add or remove a node. The power is now also routed through all the connectors and the PCB's.
I think one of the best solutions is to use the plug-able 3.81mm pitch phoenix headers The holes are big enough to accept two wires, or a wire and a leg of a wired resistor. You can even insert such connectors in the middle of a cable by stripping the insulation and doubling it up without cutting the copper. This is probably a bit of a nuisance to do, but probably also good for reliability.
-
Why would you do that? You place 2x 120 Ohm resistor between A and B, at the two ends.
You do that so that when the bus is connected correctly and in operation but idle the bus is held in the space state. Otherwise A and B will be at the same voltage and any amount of noise can be interpreted as a mark transition. Read the messages above.
-
No I'm going to invent new stuff that's not in the standard, no getting creative about the termination.
Biasing is in standard. In Modbus standard:
If one or several devices need polarization, one pair of resistors must be connected on the RS-485 balanced pair :
- a Pull-Up Resistor to a 5V Voltage on D1 circuit,
- a Pull-Down Resistor to the common circuit on D0 circuit.
The value of those resistors must be between 450 Ohms and 650 Ohms. 650 Ohms resistors value may allow a higher number of
devices on the serial line bus.
In this case, a polarization of the pair must be implemented at one location for the whole Serial Bus. Generally this point is to
choose on the master device or on its Tap. Other devices must not implement any polarization.
https://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf (https://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf)
If your device uses bias-less transceivers, you MUST per modbus standard document it, so that installers can see if all devices on a bus use such transceivers and leave bias resistors out. In practice this is risky because someone can add another device later which needs biasing.
Failsafe biasing is not for the RS485 line. It's for your device.
It is for all devices and complete functioning of the bus.
It's there, in case the wire would break, or only one wire would be connected,
No, failsafe biasing has nothing to do with wires breaking. This is a very common misconception because of the poorly chosen name. Either "Failsafe biasing" (standard solution per modbus standard) or using biasless transceiver ICs FOR EVERY DEVICE on the bus is mandatory for normal operation under all normal operating conditions, not failures or special cases.
RS485 is a very reliable system if designed and installed correctly, but you have to follow the rules.
Including the rule of having biasing which you clearly have trouble with understanding. You would have understood all of this if you did not routinely ignore those who try to explain how things work.
Read the messages above.
He won't, because he puts sensible people into his ignore list and brags about it. Insteads, he concentrates on confusing others with incorrect information instead of simply ever questioning himself. He has managed to build his own one-person echo chamber where bullshit leaks out and no corrections flow in.
--
And everything said in modbus standard applies to any other UART-based protocol over RS485. But Modbus is by far most popular.
-
Why would you do that? You place 2x 120 Ohm resistor between A and B, at the two ends.
You do that so that when the bus is connected correctly and in operation but idle the bus is held in the space state. Otherwise A and B will be at the same voltage and any amount of noise can be interpreted as a mark transition. Read the messages above.
No, you need 200mV or more voltage level to say it's a 0 or a 1.
You need the 120Ohm resistors, because thats how the entire thing works.
It has to be no less and no more than two 120Ohm resistors.
You don't need any other fail safe-ing, unless you used a transceiver from the 1980s.
https://www.analog.com/en/resources/technical-articles/rs485-cable-specification-guide--maxim-integrated.html (https://www.analog.com/en/resources/technical-articles/rs485-cable-specification-guide--maxim-integrated.html)
It's really not "any amount" of noise. There needs to be a metric shitton of noise to induce a 120 Ohm terminated shielded twisted pair to more than 200mV.
-
Note also that the modbus standard does not leave much room for creativity here:
First, modbus standard does not use term "fail-safe biasing",
Second, inclusion of pull-up and pull-down resistors is mandatory unless every device on the bus is specifically documented not to need them
Third, the value of resistors must be between 450 - 650 ohms. Not 10kohm, not 1kohm, not 330 ohm.
Of course that leaves non-modbus protocols using RS485 but as long as they are asynchronous serial depending on start bit detection, the same advice holds.
-
It's really not "any amount" of noise. There needs to be a metric shitton of noise to induce a 120 Ohm terminated shielded twisted pair to more than 200mV.
This is obviously not true if you glanced at transceiver datasheets: on the receive side, the negative going threshold ain't 200mV in general, it's some bullshit value that starts at VTt+ - Vhysteresis, and ends at -200mV. You obviously haven't dealt with real RS485 systems because in real life these buses fail all the frickin time without the bias resistors. I've personally debugged a stubborn link that was failing in a box, was really short and isolated! The designers failed to consider the common mode voltage ranges, as well as the biasing.
Compare these double digit mV headrooms with what CAN has (~volts), and re-consider using it unless absolutely mandatory, or you can hard-wire the direction.
-
This is obviously not true if you glanced at transceiver datasheets: on the receive side, the negative going threshold ain't 200mV in general, it's some bullshit value that starts at VTt+ - Vhysteresis, and ends at -200mV. You obviously haven't dealt with real RS485 systems
If he actually looked at those very same biasless "modern" transceiver ICs he claims everybody should be using, he would instantly see they offer 50mV of threshold, not 200mV, one quarter of what he claims.
Best option really is try to use biasless ICs whenever available AND use the standard bias resistor values as described in the Modbus specification - combination of the two measures is quite acceptable -, AND remember that RS485 is a three-wire, not two-wire bus. It's still not the greatest thing on Earth at all but at least then it works.
-
It's really not "any amount" of noise. There needs to be a metric shitton of noise to induce a 120 Ohm terminated shielded twisted pair to more than 200mV.
This is obviously not true if you glanced at transceiver datasheets: on the receive side, the negative going threshold ain't 200mV in general, it's some bullshit value that starts at VTt+ - Vhysteresis, and ends at -200mV. You obviously haven't dealt with real RS485 systems because in real life these buses fail all the frickin time without the bias resistors. I've personally debugged a stubborn link that was failing in a box, was really short and isolated! The designers failed to consider the common mode voltage ranges, as well as the biasing.
Compare these double digit mV headrooms with what CAN has (~volts), and re-consider using it unless absolutely mandatory, or you can hard-wire the direction.
That's a lot of words for describing that "I failed to connect the ground of an isolated transceiver properly", and "I don't understand how CMRR would effect my input sensitivity".
With some assumptions and personal attacks mixed in.
-
You do that so that when the bus is connected correctly and in operation but idle the bus is held in the space state. Otherwise A and B will be at the same voltage and any amount of noise can be interpreted as a mark transition.
However if you're using your RS485 bus to run modbus then random noise, even if it does cause a transition, is never going to be mistaken for a valid modbus-serial PDU.
-
However if you're using your RS485 bus to run modbus then random noise, even if it does cause a transition, is never going to be mistaken for a valid modbus-serial PDU.
... at least it shouldn't, if the slave checks for CRC and is not buggy.
However, the question if slave misbehaves, while important, is secondary. Primary consequence even with perfectly designed slave is that the slave will not receive the intended message. The UART sees the false start bit and keeps listening, a little bit later setting framing error flag or similar. The situation is rectified when the master makes a new transmission - which gets missed by the slaves! - and then the transceivers leave at the correct idle state (latching the last state actively driven on the line), and hopefully get the next master transaction right.
But if the master polls e.g. once a second, there is a whole lot of time and opportunity for a repeated glitch. Hence opportunity for the comms to fail permanently.
Usually this is caused by combination of poor grounding and lack of biasing. Fixing just grounding usually seems to fix it, but with no biasing the noise margin is negative, the system always operates inside the hysteresis band.
Think about it this way: it is equal to communicating with 5V microcontroller GPIO by using a signal which sits at 2.5V all the time, utilizing the fact that when it's periodically 5V and returns to 2.5V, the value read does not go to '0' inbetween because the hysteresis of the IO logic.
The bus is not designed to work like this. But what people miss is the layered specification. RS485 spec leaves the biasing question to be solved by the next layer (which makes sense, because if the protocol chooses "one always active" strategy then there is no problem). Next layer, e.g. modbus then specificies the bias resistors (because it depends on all transmitters idle being normal, and start bit detection).
Just follow the standards.
-
And everything said in modbus standard applies to any other UART-based protocol over RS485. But Modbus is by far most popular.
I see that you have big experience with practical Modbus usage, but this sentence is not true. Everything about modbus may be applies to some UART-based protocols but not to all.
OSDP standard (that I don't know perfectly and I hate it because after it got EN-IEC number forces us to increase 100x current consumption on RS485 transmissions) is UART-based protocol and need not biasing. The problem of false start bit is solved by keeping by transmitter bus in logic high state for longer than one byte time before first byte is send so whatever error byte receiving was started it is finished before start bit of first byte of frame.
How a problem of such 'wrong' bytes at the beginning is solved - I don't know but it's not an unsolvable problem.
When reading once more what I have written I remind that they start each communication with specified byte what certainly helps a lot.
You don't need any other fail safe-ing, unless you used a transceiver from the 1980s.
I'm not sure what you have in mind. I have never made a statistic, but when I need to find transceiver with fail-save receiver (for open and short) than only few can be found among hundreds of RS485 chips. So problem with biasing is not only with transceivers from 1980s. I have noticed that transceivers I can accept are (by chance) much more expensive than transceivers I don't accept.
Of course that leaves non-modbus protocols using RS485 but as long as they are asynchronous serial depending on start bit detection, the same advice holds.
It is the same what I commented above.
You obviously haven't dealt with real RS485 systems because in real life these buses fail all the frickin time without the bias resistors.
Since (at the end of 90s) we started to use fail-save (very important - for open and shorted bus) transceivers we not notice any problem (we don't use biasing). There are probably about 5000 of our RS485 buses working all the time. Most in office environment, but I believe some in industry.
About 10..15 years ago we got the mail from one of installers that the building they recently installed our system was hit directly by lightning and all systems with long cables (alarms, telephone exchange) failed. Also more than 50% of ethernet ports in computers were damaged. Only our system was still working. Installer finished with: "Now everyone will earn money and we will get nothing."
was really short and isolated! The designers failed to consider the common mode voltage ranges, as well as the biasing.
I don't understand you. When (20 years ago) I was using isolation at RS485 (4kV, 4.2pF in trafo + may be 3pF (I'm not sure) in ADuM isolator) I blocked by transils the transceiver common mode voltage tolerances. If I have up to 8kV (isolations at both ends) common mode voltage difference than adding 7V to it is pointless. Those time I was asking to connect third GND wire, but now I think it was an error. If in GND loop you have two about 7pF breaks you need not to connect GND between transceivers. Having common mode input voltage in accepted by receiver range is done by elements protecting A, B lines.
-
OSDP standard (that I don't know perfectly and I hate it because after it got EN-IEC number forces us to increase 100x current consumption on RS485 transmissions) is UART-based protocol and need not biasing. The problem of false start bit is solved by keeping by transmitter bus in logic high state for longer than one byte time before first byte is send so whatever error byte receiving was started it is finished before start bit of first byte of frame.
This is very clever and same could be done on modbus. But since it's not on the standard, nothing can be done, it's not like modbus standard could be significantly changed anymore.
We could dream about a better protocol. I would use a header such as U8 slave_id, U16 length of payload in bytes, U8 CRC of the header, then rest of the message with another CRC at the end. Knowing validness of length and recipient in advance allows skipping whole messages (after that short header), allocating buffers, reading just for the correct number of bytes without weird inter-message timers like in modbus. But it's easy to dream.
-
But since it's not on the standard, nothing can be done,
I don't suggest anything be done with modbus.
I have only said that conclusion that everything (about hardware) that is needed by modbus will also be needed by any other UART based RS485 communication is unjustified.
Our own communication (anyone can send if have something to say) I will also understand as UART based. We use UART to send and receive bytes, but to find that bus is busy we use direct detecting start bit at bus (microcontrollers (not sure, but may be all) allow the input pin being connected to UART and also read/generate interrupt as GPIO).
-
How to calculate/know component values for AC termination? I believe R still equals to the impedance of a cable. The optimal C depends on parameters - at least the cable length. On one of the Analog's app note values are 120R/3n3 for 222ft.
sw
-
We could dream about a better protocol. I would use a header such as U8 slave_id, U16 length of payload in bytes, U8 CRC of the header, then rest of the message with another CRC at the end. Knowing validness of length and recipient in advance allows skipping whole messages (after that short header), allocating buffers, reading just for the correct number of bytes without weird inter-message timers like in modbus.
While I agree that'd be a good idea, the problem with these second-system-effect updates is that it's almost impossible to stop once you've got started (I mean it's like cocaine mixed with heroin), and then you end up with something like the newer Bluetooth specs.
For an interesting example of not falling prey to this too much, look at the I2C to I3C update... although like IPv4 vs IPv6 there still seems to be a lot more I2C being deployed than I3C.
-
We could dream about a better protocol. I would use a header such as U8 slave_id, U16 length of payload in bytes, U8 CRC of the header, then rest of the message with another CRC at the end. Knowing validness of length and recipient in advance allows skipping whole messages (after that short header), allocating buffers, reading just for the correct number of bytes without weird inter-message timers like in modbus.
While I agree that'd be a good idea, the problem with these second-system-effect updates is that it's almost impossible to stop once you've got started (I mean it's like cocaine mixed with heroin), and then you end up with something like the newer Bluetooth specs.
For an interesting example of not falling prey to this too much, look at the I2C to I3C update... although like IPv4 vs IPv6 there still seems to be a lot more I2C being deployed than I3C.
Yeah. However if you take a closer look, Modbus is incredibly complex for what it achieves (exchange of data at numbered addresses). It is almost surprising it is coming from 1970's with that much complexity. Not only you need two timers for the timeout management, on software level you have multiple address spaces (one for each function code). Super weird +1 addressing notation no one except one manufacturer out of 100 follows for maximized confusion. Both 1-bit registers almost no one use and 16-bit registers, where the only purpose is premature optimization of performance for reading a lot of 1-bit statuses, but the whole protocol isn't performance optimized anyway so it makes no sense whatsoever anyway. Separate incompatible functions for write multiple and write one register when you could just always use write multiple with n=1. For example it is normal to see that product A only accepts function code 0x06 and product B only 0x10.
The whole protocol screams of no design at all and ad hoc feature creep.
The "new modbus" should not be shinier and fancier v2.0, it should be more primitive and simpler; it should be how modbus is actually used, only a tiny subset of the spec. Problem right now is that everybody implements different subset (unlike those few who license a complete modbus implementation).
But I also would not use RS485 for that new shiny bus. CAN would be cleaner.
But this is just meaningless shitposting I'm doing here, we can dream. I'm dealing with home automation and building management stuff and it's total ad-hoc mess, I have actually never seen a single even nearly modbus standard compliant device, everybody does what they want to get some test product to work with another test product on a lab and then sell it. We write separate integration guides (connection guidelines) to every product we support because the manufacturers can't do that, and then every driver follows different conventions. But there is no way to just come up with an alternative system and somehow make the manufacturers use it. And maybe there is no need, the current system works quite OK once you grasp it.
Excellent example of the second-system effect you mention is SunSpec, which is basically useless because it's so much v2.0-by-committee that less than 5% of the target audience (solar or battery system inverter manufacturers) actually use it because it is so complex and difficult. And I'm glad no one uses it so that we have avoided supporting it, too. They also require a certification process to call your product SunSpec compliant, because they know it is so difficult and complex. Yet the only SunSpec product I have had to deal with claiming to be SunSpec compliant was not complying to the spec so that I had to add workarounds anyway :-//
-
But I also would not use RS485 for that new shiny bus. CAN would be cleaner.
I remember reading CAN controller description once (20+ years ago). It was extremely complicated from my point of view.
I have never used CAN, but in my opinion it is worse than RS485.
I just want to say my opinion and not to start a discussion on this topic.
I don't like that one state in CAN is 'strong' while second is 'weak'. My intuition tells me that weak state is more susceptible to interference. When testing burst you capacitively couple them to cable. They can do more when the wires have a weak forced voltage.
In small RS485 system (controller + 2 readers), assuming 4 device attendance control frames in each 4 seconds, I estimate collision risk for asynchronous frame being about 0.000006 (6us risk time happening 4 times in each 4s). If you imagine (one door small system) 100 people in/out each day (400 frames a day - in/out and confirmation) the frame collision will happen once per year. So once per year you will lose one frame time (1..2ms) at bus. For big system (like 50 devices on bus) it is of course bigger but even you lose 2ms each minute it is all the time 0.0033% bus time lost. I suppose that CAN losses about 50% of bus throughput just because each bit have to be stable at whole bus length before next bit can be send.
-
I remember reading CAN controller description once (20+ years ago). It was extremely complicated from my point of view.
Oh, CAN is very simple for user. You don't have to deal with coming up with arbitration, addressing etc. code as you need on RS485 because that's all standardized and easily available in hardware (on every $1 MCU peripheral). You were probably reading documentation on how to implement such controller, but the point is you don't have to.
Plus, if you write similar detailed specification about modbus over RS485 (including flow diagrams of all function codes) it's going to be much longer.
I don't like that one state in CAN is 'strong' while second is 'weak'. My intuition tells me that weak state is more susceptible to interference.
Intuition easily leads you wrong. CAN has excellent signal integrity. It's similar to always-driven RS422/485, so approx ten times better than RS485/modbus which relies on either 50mV shifted hysteresis transceivers or those bias resistors which are ten times weaker than the termination resistance.
I suppose that CAN losses about 50% of bus throughput just because each bit have to be stable at whole bus length before next bit can be send.
You are very correct that CAN compromises simplicity of its arbitration system, baud rate and maximum physical bus length. Number of devices is not a problem, but if you want a kilometer long bus then you are limited to something like 50kbps IIRC or so due to arbitration delay.
CAN goes to 1Mbps no problem but only within a vehicle / limited floor area at industrial site. I think something like 30 meters.
Then again most RS485 systems I deal with communicate at 9600bps. Streaming high bandwidth data like video, I suggest Ethernet instead.
CAN systems are reliable because they truly only need termination resistors (no bias resistors), and naming conventions are coherent and strong. Unlike the A/B/+/- mixup mess of RS485, nobody disagrees on the meaning of CANH and CANL, and forgetting GND is quite rare*. I don't think I have ever seen non-functional CAN system, unlike non-functional RS485 systems which are commonplace.
*) the GND thing is more social than technical; but with modbus/rs485 there is so much misinformation and wrong practice out there that it's very hard to fight against it. CAN started over from a clean table and does not have this legacy.
-
RS485 and missing GND wire...
At work, we're at the device level, not compontent level and most of the RS485/422 interface I come across has been done without GND wire. Mostly, I believe, this is because 95% of the "interface documentation" from manufacturers of various devices "always" just shows two (or four) wires and "never" shows a GND wire.
I'm trying to get the point across that it's "wrong" and that from now on we should implement a GND wire. Needless to say, it's hard....
Can anyone point me to a good reference that clearly explains the fact that a GND reference is indeed needed (or at least the proper way) that I can use to to convince colleagues of this fact. The best reference I've found so far is Texas Instruments AN-1057 but I'm still having a hard time convincing my colleagues because "it's been working fine before".
-
Can anyone point me to a good reference that clearly explains the fact that a GND reference is indeed needed (or at least the proper way) that I can use to to convince colleagues of this fact. The best reference I've found so far is Texas Instruments AN-1057 but I'm still having a hard time convincing my colleagues because "it's been working fine before".
If the protocol is Modbus, then the modbus standard. It's a pretty authoritative document with strong must wording:
https://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf (https://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf)
"a third conductor must also interconnect all the devices of the bus : the common"
There is no discussion about it. If the device has no connector for ground/common wire, it is not modbus compliant. If the wiring does not use ground wire, it is not a modbus bus.
Also, if the bus does not have bias resistors and there is even single device on the bus which does NOT document it can be used bias-less, the bus is not modbus compliant. It is broken by standard and needs to be fixed.
Be very careful with appnotes published by Texas and other chip manufacturers. Some are very good; but some are utterly wrong (rehearsing old industry hearsay instead of correct facts) like the one tzsaboo linked to earlier.
If the protocol is not modbus, then it's more difficult to give authoritative statements about necessity of biasing and ground wire.
When we encounter these shit devices, which is more common than it should be, we assume they use PE for RS485 common and instruct our install partners to connect the RS485 GND of our box to PE as well. The signal common path is a mess from EMC and probably the combination would fail tests, but it's not our responsibility; our box has the connectors and it passes EMC.
-
Thank you!
We deal with various protocols. It might be MODBUS, it might be NME0183 or it might be some unknown protocol riding a RS485 or RS422 bus between two devices from the same manufacturer where my task is simply to interconnect the two. At the wiring level this has mostly been done without a separate GND wire and it seems we've gotten away with it. Now that I'm trying to say it's "not correct" I'm having a bit of a hard time building my case so to speak :-)
Be very careful with appnotes published by Texas and other chip manufacturers. Some are very good; but some are utterly wrong (rehearsing old industry hearsay instead of correct facts) like the one tzsaboo linked to earlier.
This bothers me deeply. How should one know what's good and what's utterly wrong. For example, my goto reference TI AN-1057 saysAlthough the potential difference between the data-pair conductors determines the signal without officially
involving ground, the bus needs a ground wire to provide a return path for induced common-mode noise
and currents, such as the receivers' input current. A typical mistake is to connect two nodes with only two
wires. If you do this, the system may radiate high levels of EMI, because the common-mode return current
finds its way back to the source, regardless of where the loop takes it. An intentional ground provides a
low-impedance path in a known location, thus reducing emissions.
This is at the hardware level, what rides on the bus (be it MODBUS, NMEA or whatever) is secondary.
Could one argue that this is simply not correct and that a GND wire is just optional extra?
-
Can anyone point me to a good reference that clearly explains the fact that a GND reference is indeed needed (or at least the proper way) that I can use to to convince colleagues of this fact. The best reference I've found so far is Texas Instruments AN-1057 but I'm still having a hard time convincing my colleagues because "it's been working fine before".
I looked (not reading) through AN-1057 and Figure 8 is one that is most important in this matter.
It is more the problem of EMC and less (but still) the problem 'it's been working fine'.
RS485 drivers generate unneeded common mode voltage. Looking in MAXIM MAX3082 datasheet the sources of Vcm are ΔVoc (max 200mV) and tDSKEW (max 200ns). Connect driver outputs A to B with two identical resistors in serie and observe with oscilloscope voltage at point between resistors when transmitting. ΔVoc is typically small but skew generates pulses of about 1V amplitude or more.
Not sure at that moment (I was doing such calculations 20 years ago) but if CM return path is not along A,B wires about 20mV Vcm is enough to exceed the emission limits specified in EMC standards while here we can have it much bigger. What makes emission bigger also makes sensitivity bigger. If receiving area is big (because of no GND connection along bus wires) then CM current generated by external disturbances is bigger and (because not 100% symmetry) it is partially converted into differential signal what is added to useful signal and at some level...
What counts is the common mode current times common mode circuit area. If you add GND wire along your signal wires you limit the problem by making area small. If you isolate driver (but with so small isolation capacitance that it breaks current in frequencies you operate) than you limit the problem by making current small.
I use slew-rate limited drivers (like MAX3082) so I don't have high frequency in my common mode signals. For them isolation barier having about 8pF is practically a break reducing common mode current to almost 0. In such case I think GND connection is not needed and only 2 wires are OK.
But when you transmit power to driver through isolation you generate common mode current by your DCDC isolated converter. To limit it you can break isolation with for example 1nF capacitor and you not have the isolation with very small capacitance so you are back at need of using GND wire between devices.
I used MAX845 to have as symmetry as possible (to limit CM voltage) isolated supply for transceiver and I used trafo having only 4pF and I have used ferryte beads in serie with DCDC. This construction passed EMC tests even without 1nF capacitor across isolation so it allowed to use only 2 wires without GND wire.
At least in my opinion.
Just imagine RS485 driver as Common mode voltage generator connected from your PCB GND (GND connected to Earth) to A,B (A,B imagine as single wire). If you have isolated RS485 than imagine also second noise generator connected (with DCDC capacitance in serie) between Earth and your GND. You should see that breaking isolation with capacitor you reduce noise from one source increasing noise from the second source.
-
It is more the problem of EMC and less (but still) the problem 'it's been working fine'.
You are right, it's either or both. Some form of common mode voltage equalization is needed for the bus to function. If explicit wire is not used, then there is usually some parasitic route. If it's poor enough, it might not even work at all, not even on lab. If it's good enough, then it might even pass EMC. Then there is large grey area which works usually fine but does not pass EMC.
But really, there should not be separation of "works" and "passes EMC". The only reason EMC regulations exist are for things to work well. So saying something that does not pass EMC "works" is like saying "I can drive under influence because I'm a good driver even when I drink". It is just psychopathic behavior.