"RS-485 only specifies electrical characteristics of the generator and the receiver. It does not specify or recommend any communications protocol, only the physical layer. Other standards define the protocols for communication over an RS-485 link."
formatting link
At any rate, there's no law against using an RS485 link to transmit Manchester, or delta-sigma, or isochronous data, or anything else.
--
John Larkin Highland Technology, Inc
jlarkin at highlandtechnology dot com
http://www.highlandtechnology.com
Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom laser drivers and controllers
Photonics and fiberoptic TTL data links
VME thermocouple, LVDT, synchro acquisition and simulation
"Electrical characteristics if generators and receivers for use in balanced didigal multipoint systems".
So you first paragraph seems ok.
Wikipedia is while usually correct is NOT considered athoratative by itself, nor by much of anybody else seriousily concerened with accuracy.
Having just reread both TIA-485 and the referenced document TIA-422 i fine the following:
While the standards do support manchester encoding (my suprise), the wording depreciates the use of it.
But i would really like to know how you conflate delta-sigma and isochronous into the language of the standard. I could find nothing in the standards that would support this. OTOH this it typical of the kinds o flights of fancy you so typically take, and then claim that the standards "support", when no such language exists within the standard.
It's right in this case: "485" is like "TTL" : it's about how to send 1 and 0, not about what they mean or what is encoded.
Deprecates? How so?
Exactly the point: the standard does not address coding; it talks about logic levels. Applying *any* form in information coding or timing is necessarily an act of design, a "flight of fancy." Since I can (and do) push Manchester over an RS485 link, it does support it. It works.
What sort of data encoding do you read the spec as allowing? Async ASCII at 110 baud?
Bully? All my comments were technical. You have just gone personal.
--
John Larkin Highland Technology Inc
www.highlandtechnology.com jlarkin at highlandtechnology dot com
Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom timing and laser controllers
Photonics and fiberoptic TTL data links
VME analog, thermocouple, LVDT, synchro, tachometer
Multichannel arbitrary waveform generators
You are deliberatly missing the point. TIA-485 does not address delta- sigma or isochrounous. It is "out of scope" of the standard. Alleging that it supports something out of scope is silly.
And you just started in on the bullying again. You put words in my mouth of a position i never took to try to make me look the fool.
Not at all the facts, you started the bullying. I just stood up to you. You don't like it one bit do you?
Joseph, you are arguing about nothing, for the sake of it apparently. JL's original wiki quote above is spot on and furthermore you agree with it entirely from everything you have written since! The standard does not specify encoding, encoding is outside its scope, blah blah blah, you are both saying the same thing now but JL said it first and then you initially contradicted it!
You are manufacturing a disagreement out of nothing, just to be argumentative. Look again at the original wiki quote above. You already say first paragraph is OK which only leaves:
Sorry for my ignorance in this area (like I said earlier, analog and me jus t don't get along), but how would that compare to e.g. a 74F gate drive?
Generally yes, which is why I'd really like to keep the duty cycle closer t o 30/70% rather than 10/90%. Putting fixed gates around the R/C will enabl e me to dial that in, by selecting gates where Vil and Vih are near the app ropriate points for the 3.3v VCC. Right now though, it works for certain c hips for a combination of reasons:
- the differential sag through the capacitive coupling is slow enough (for certain drivers, e.g. *not* the max3292) that longer low/high periods stay consistent as long as the primary bitrate is kept high enough (e.g. 4Mbaud)
- the digital R output (again *not* the max3292) through the R/C gives legi timate Vil and Vih for the microcontroller
The latter can be locked-in with surrounding gates, the former is still dep endent on the driver structure.
What do you mean by "piggy-back schemes"?
Auto-tune is what I propose above, using failure counters to find the best option. A repeater is another method I'm thinking of, but in two different possible forms:
- uncut bus: if a packet from the master is received properly by the first N units on the bus, but not after that, the theory would be that unit N wou ld be able to retransmit, and that would provide something the rest of the bus can hear, then repeat the answers back. However, while that makes perf ect sense in a "wireless" scenario where N+1 can't hear the master because of low signal, I'm not sure the coupled 485 bus will behave similarly. I w ould expect there to either be relatively little difference between the rec eived signal at each point on the bus, *or* there to be various standing wa ves and all kinds of ACK/NAK patterns along the length.
- cut bus: a device with two discrete interfaces, plus heavy power decoupli ng (pass 36VDC via SSR but heavily block the overlaid 485 signal). Based o n my high-level packet structures, it can spend most of it's time just shor ting the R/D D/R lines together between the two interfaces, and only pull t hem apart when the protocol dictates otherwise.
I have seen some variation with the presence of the TVS, but haven't quanti fied it yet. Do you mean diode in series with the bus itself? That would be a problem with a half-duplex bidirectional setup, right?
Yeah, that's why work on the TDR subsystem has been put off for now.
I'll look for some "larger" parts and see what I can find. The theory of u sing that class of parts is correct though?
I was also thinking about higher-voltage protection, either from lightning or significant ground potentials (this bus will be strung out over 100's or maybe 1000's [if it works] of feet in outdoor environs), and ran across an email showing some very tiny gas-discharge tubes that might do the trick t here.
If you take the 74F245 bus driver you can see under high-level output voltage (top of page 3) that it is weaker when pulling up:
formatting link
Most of all, these are bipolar technology devices and those typically don't have much oomph pulling up, only pulling down they have some muscle. They can never pull all the way to the upper rail even for low currents. Usually you are better off with a CMOS device.
If you need the ultimate in drive power I suggest to look at FET gate drivers. Those are in the single digit ohms.
The driver could be made almost as low in impedance as you want to. But it will be "home-brew", in other works not all in one chip.
Sorry, what I meant was when you can have a plethora of transceivers in a fairly random order, in other words where your system must be tolerant to ghastly and a priori unknown reflections on the line.
Can work but I have sometimes replaced such digital methods with analog ones. Where the circuit really looks at some waveform patterns and adjusts those.
Then you'd have to cook up your own "more-tolerant" protocol. That might make this solution unpalatable.
I means bus to ground and between lines A and B. If you hang a TVS there it will greatly muffle the data signal. There has to be a small signal diode in series with each TVS. Then the TVS's capacitance charges up and after that not much more current flows. Unless the 36V whopper transient comes along, then you may lose a few bits in data but that is better than seeing smoke coming out of TSSOP packages.
But it's fun :-)
Yes, but it must be able to stomach whatever max current spike you are expecting.
Gas-discharge is good but the voltage at which they come on is too high for semiconductors.
There are two ways of protection, opening or shunting. Opening tolerant to several hundred volt (untill the gas-discharge comes on) gets involved, lots of parts. Shunting usually is very reliable but will dissipate any surge energy and must be respectively beefy.
With a clean NRZ method there is also another option, signal transformers. They won't let any DC bother you. This is what I do for defibrillator-proof medical gear which is tested with a slow and very powerful (as in many amps) 5kV surge. Those are real whoppers and it has heppened that a server of PBX system at clients had to be reset after the test.
Auto-tune is typically implemented either by special known "training" messages or having a long preamble in front of each message. Relying on just message CRC checks will take a _very_ long time to auto-tune.
On a shared (Modbus style) half duplex network in a master to multidrop slave configuration, you have to be very careful that each slave knows, when the master speaks or when some slave responds. You really have to use heavy protected data direction and slave addresses, so that the wrong slave does not respond (garbling all traffic).
How many retries are you going to do, in order to get the message through ?
Anyway, auto-tune is usually implemented at each receiver and require an ADC and some DSP processing (e.g. "56k" phone modems, 8VSB US digital-TV).
Trying to use master transmit side auto-tune with some slow speed feedback would require a large number of "training" packets in the beginning and the slave would have to respond, how many of the bits get through OK, not just go/no go.
At a constant bit rate in a not properly matched network, the reflection could quite well kill the reception at the first slave for certain bit patterns.
As I said previously, you are banging your head against the wall, when trying to use some base band or single carrier system in an unknown network, in which the branches are longer than 1/10 of the wavelength. Instead of looking at individual "RS-485" like chip characteristics, you really should consider some multitone method to transfer the data in that hostile environment.
You can do it by looking at transitions and reflection spikes on the data. Mainly because the OP is using an NRZ scheme where you have a transition in each data bit.
Yup. There is almost no way around that, except maybe analog circuitry with RF parts in there. I've done one with a uC and analog but it was highly unorthodox.
That could be handled by a versatile auto-controlled matching network. But there are limits, like when there is an almost total signal-cancel because the line length happens to create an exact notch filter. Then one needs to have at least one other data rate available which is not an exact multiple of the original rate.
I'll second that, multi-tone really wins in such situations.
This does not have a guarantied transition at each bit.
With asynchronous communication with 8 data bits, one stop bit, no parity bit, you have only one known transition at the beginning of the start bit. Look what happens when you send 00 and FFh
00: idle(1), start(0), 8 x data(0), stop(1), idle(1)..., next start(0) FF: idle(1), start(0), 8 x data(1), stop(1), idle(1)..., next start(0)
The length of the idle period can be anything from zero (back to back characters) to infinity and the time is not a multiple of the bit clock. Thus only one known transition in 10 bits.
Other methods, such as biphase (e,g, Manchester) will have more frequent transitions. Bit stuffing (e.g. SDLC/HDLC, CANbus) will automatically insert one extra opposite polarity after five consecutive 1's or 0's thus having at least some edges to resynchronize.
g or significant ground potentials (this bus will be strung out over 100's or maybe 1000's [if it works] of feet in outdoor environs), and ran across an email showing some very tiny gas-discharge tubes that might do the trick there.
There's the possibility, if you use a self-clocked serial scheme (MFM, Manc hester, FM1, FM2, NRZ... there's lots of 'em) of transformer-coupling. The old App leTalk scheme used RS-485-like drivers and worked that way, on cheap telephone wi ring. With proper attention to termination, it was good for about a kilometer.
True. Sorry, I was still in the med tech corner of my world because I just did an interface. There we use NRZ a lot. In the OP's case it has to be Manchester code.
Yes, got to do Manchester here. Otherwise the auto-tune could take too long.
Yeah, that seems like the best bet, although I'd potentially lose the multi
-bit tunability based on increased footprint (I've got a fixed, very small space to work in)
At this point I'll look into anything that might possibly work. I'm pushin g to build a testbed where I can back up and do some experiments without th e constraints I'm currently working under, so a home-brew transmitter would be possible to play with.
I was under the impression that for the most part reflections were caused b y branches, which my system doesn't really have in the sense that I've seen them defined. The units on the bus have maybe 3/4" or less between the va mpire tap point and the transceiver.
Not really sure how I'd do that in any kind of automated way with the syste m I've got. It's all driven by AVR Xmega parts at 32MHz, there's really no way to get enough oomph to analyze the signal in any meaningful way at run time.
Yeah, that's really not my idea of a fun project. I'd much rather go with the cut-wire repeater arrangement, especially given the massive bandwidth h it I'd take.
I spent a few months on that project, and pretty much spun my wheels. When the time comes I really want to find somebody else to do it...
Yeah, it would be in addition to lower-voltage protection.
So I thought about that, but wouldn't the coil resistance of dozens of tran sformers on the line blow things out of the water? Or would the transforme rs be capacitively coupled to the line themselves? I've seen that arrangem ent in the very few schematics I've seen of power-line systems.
The biggest problem there (so to speak) is the size of such transformers. They're getting crazy-small, but I've got a *tiny* space to work in. I've got a 3mm max height limit, and the biggest open space I've got is *maybe* a centimeter square.
On Saturday, August 31, 2013 12:10:54 AM UTC-7, snipped-for-privacy@downunder.com wrot e:
In my case I think I can keep it mostly constrained, because there are only a few combinations of transmitter/receiver that I care about. The control ler can broadcast a pseudorandom set of all the various possibilities with their parameters built into the packets, then slow-query all the units on t he bus for their received packet counts, split into each transmit arrangeme nt. Find the "best" bin for each unit that has a 99+% receive rate for tha t batch, go with that. Rinse/repeat for each unit on the bus transmitting back to the master. In theory I can take several minutes to do this.
The protocol very clearly dictates who speaks when so there are no issues t here except in dealing with timeouts for situations when e.g. one unit spea ks and the next one hears it but the controller doesn't, etc.
Depends on how far I can get the hardware in terms of low PHY error rates.
Yeah, would love to have that but don't have that option at this point.
By "not properly matched" do you mean improper termination (I'll be shippin g a terminator "unit"), invalid branches (mine are maybe 3/4" *max* from th e wire to the chip), or something more involved?
Oh you have no idea ;-(
I'd love to, but I haven't found any solutions that fit my power, space, an d datarate budgets. If there's a reasonable way to implement OOK or FSK at 1Mbps or better using the existing UART pins and packet protocols I've got , I'd be all over that.
On Saturday, August 31, 2013 12:59:28 PM UTC-7, snipped-for-privacy@downunder.com wrot e:
I'm using Manchester throughout, so when the bus is active there are either 250ns or 500ns highs and lows, nothing more. The start/stop bits aid in t hat of course.
I have hand-written transmit and receive ISRs that take the raw packets and handle preamble, header, data, and CRC with ISR-time lookups from a Manche ster table, etc. Takes 50-60 cycles out of the 80 cycles I have per UART b yte (4Mbps vs. 32MHz), but the Xmega has 3 priority levels so I can do othe r stuff in lower priority interrupts and at this point I never lose an inte rrupt (afaict).
I have encoding options built in, so that *if* the bus is happy with just t he start/stop transitions (e.g. it doesn't sag too fast between edges) I ca n also transmit un-encoded data, although the preamble and header is *alway s* Manchester. The control bits for the modes are in the Manchester-encode d packet header, so it switches on a per-packet basis as received.
So you have a T-connector, with the branch less than 20 mm long, but the real question is how the main wire is routed.
If it is a single bus structure with
terminator - Station_A - B - C - ..... - Station_Z - terminator
Things are OK.
The 20 mm branch length from main bus at 4 Mbit/s compares well with other cabling system. At 10 Mbit/s, the Vampire tap in 10Base5 Thick Ethernet and the BNC T-connector 10Base2 coaxial bus has similar branch length. In Profibus DP (RS-485 on well specified twisted pair cable) at 12 Mbit/s and up to 100 m that 20 mm is too much, at 1.5 Mbit/s short wire branches (well below a meter) from the main bus may be used.
However, if you have a random cable segment mess (fixed pitch font)
terminator -- A -- B --+-- C -- D -- E -- terminator ! +-- F -- G --+-- H -- terminator ! terminator -- J -- I --+--- K -- L -- terminator
you are going to have problems, if the segment lengths are more than 5 m at 4 Mbit/s.
Some passive star coupled topology with ferrites placed at strategic places might work, as used in some CANbus installations (essentially RS-485 up to 1 Mbit/s).
You don't have to lose that because many drivers come in quads and amazingly small packages, such as this one:
formatting link
Best way to go on a project like this.
Understood, but it's not just branches that reflect RF on a line. Any time you hang a capacitance to a transmission line you have created a reflection point. The impedance is no longer a clean 100ohms or whatever at that point.
One of the tasks at hand is to minimize this added capacitance. What I did on clock lines was to tap in via a hotrod RF transistor instead of directly with a logic input. That dropped it down from 5pF a pop to under 1pF. With the driver part that gets to be more difficult. The output devices will inevitably have more capacitance even when off. Same for a series mux if you go that route.
Neutralizing that capacitance by a regenerative trick might work. If you do that and it works hand out barf bags before you start the design review :-)
Without enough computing horsepower and ADC you can't do it. But something has got to set the ratios for any equalization scheme. At least if there can be ad hoc changes in the bus configuration.
Or, as I believe someone suggested, a multitone RF protocol. However, then you need "micro-modems" at each node.
Nah, solve it and you'll be da hero :-)
If you get too many of them clustered too close together, yes, they will load down the line. One trick is to make the transformers wideband, meaning that they present a very high impedance when not loaded on the tap-off side yet reach to 5MHz or wherever you need them to go up to. On a typical transformer the rule-of-thumb is to have the open inductive reactance at least 4x the cable impedance at the lowest frequency to be transmitted or received. Here you'd need a lot more.
You can capacitively couple them to the line but if there is not need to have a differential DC signal you wouldn't have to.
That's enough space for a signal transformer. If that 1cm^2 has to contain the whole transceiver that is a tall order. Almost calls for a custom IC design.
Looks promising, though I'm confused as to why they give different source a nd sink values for the high and low sides, you'd think the two FET pairs wo uld be the same. OTOH I guess that difference could be used to my advantag e.
Yeah, I just have to convince them that even though it looks like a step ba ckward, it'll get us forward faster, since I can build test boards that don 't have the insane density and collection of hard-to-hand-assemble parts th at I have to work with now.
Yeah, I can clearly watch the effects as I add more units to the bus:
formatting link
In this case I believe the test actually involved simply turning on each dr iver's RE in turn to increase the number of stations listening. All 6 unit s were connected and powered on the line during each capture, just the RE's were different. You can see the leading edge of the waveform becoming una cceptable pretty quickly. I think the point where packet loss became signi ficant was about 7-8 units.
IIRC that was with the max13451.
My boss suggested that without any details, implying that I could receive t he signal and have units automatically loop it back. Seems to me the probl em is a) there'd be too much latency between the receive and re-transmit, a nd b) the retransmitted signal might end up causing feedback all over the p lace.
I've got a PLL-driven clock line dedicated to the interface circuit current ly unused, but I could use that to drive and sync a multitone protocol if t here's any way to get 1+Mbps out of it and fit it on the board.
Would be nice.
You just started speaking alien ;-(
No, that's just the biggest single space. The board is ~1.13" round with a 2x10 2mm connector on top center, the area equivalent of WS2812 'smart' LE D to one side of that, and 2x 2x7 0.5mm connectors on the bottom opposite s ides. The rest of the board is free for all this stuff, albeit with seriou s height restrictions. 3mm up and maybe 1.5mm against the parts on the bot tom side board.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.