On 19 Aug 2013 00:33:03 GMT, josephkk <joseph_barrett@sbcglobal.net> wrote:>On Sat, 17 Aug 2013 13:39:54 -0700, omega wrote: > > >> https://www.circuitlab.com/circuit/jqmsj8/screenshot/540x405/ >> >> Even better, if those are tri-state gates, you can drive the OE's of >> each gate independently in order to change which chains are active. The >> RS-485 DE function consists of turning all the OE's off. >> >> AFAICT the Line_Driver.PDF circuit drives directly at all times, then >> can switch the 2 different EQ'd forms in on top of that. If my idea >> above works, you'd have 8 options instead of just 3. >> >> That make any sense or am I just smoking something? > >I suspect what you have is ordinary ignorance. > >Get a copy of TIA-485, it is reasonably priced at TechStreet. > >There are some basic ideas to learn: differential signaling, >bit serial protocol, tri-state trnsmitters. It is not Manchester encoded.485 is an electrical logic-level spec; it says nothing about encoding or protocols. -- 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
Discrete custom design of RS485 driver
Started by ●December 21, 2012
Reply by ●August 19, 20132013-08-19
Reply by ●August 19, 20132013-08-19
On Sun, 18 Aug 2013 20:21:01 -0700, John Larkin wrote:>>I suspect what you have is ordinary ignorance. >> >>Get a copy of TIA-485, it is reasonably priced at TechStreet. >> >>There are some basic ideas to learn: differential signaling, bit serial >>protocol, tri-state trnsmitters. It is not Manchester encoded. > > 485 is an electrical logic-level spec; it says nothing about encoding or > protocols. >Do you have a copy, I do. ?-)
Reply by ●August 19, 20132013-08-19
On 19 Aug 2013 20:18:55 GMT, josephkk <joseph_barrett@sbcglobal.net> wrote:>On Sun, 18 Aug 2013 20:21:01 -0700, John Larkin wrote: > > >>>I suspect what you have is ordinary ignorance. >>> >>>Get a copy of TIA-485, it is reasonably priced at TechStreet. >>> >>>There are some basic ideas to learn: differential signaling, bit serial >>>protocol, tri-state trnsmitters. It is not Manchester encoded. >> >> 485 is an electrical logic-level spec; it says nothing about encoding or >> protocols. >> > >Do you have a copy, I do. > >?-)I think we have one around here, somewhere. Wiki says "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." http://en.wikipedia.org/wiki/RS-485 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
Reply by ●August 21, 20132013-08-21
On Mon, 19 Aug 2013 13:50:30 -0700, John Larkin wrote:> On 19 Aug 2013 20:18:55 GMT, josephkk <joseph_barrett@sbcglobal.net> > wrote: > >>On Sun, 18 Aug 2013 20:21:01 -0700, John Larkin wrote: >> >> >>>>I suspect what you have is ordinary ignorance. >>>> >>>>Get a copy of TIA-485, it is reasonably priced at TechStreet. >>>> >>>>There are some basic ideas to learn: differential signaling, bit >>>>serial protocol, tri-state trnsmitters. It is not Manchester encoded. >>> >>> 485 is an electrical logic-level spec; it says nothing about encoding >>> or protocols. >>> >>> >>Do you have a copy, I do. >> >>?-) > > I think we have one around here, somewhere. > > Wiki says > > "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." > > http://en.wikipedia.org/wiki/RS-485 > > At any rate, there's no law against using an RS485 link to transmit > Manchester, or delta-sigma, or isochronous data, or anything else.Really? Let's see: The Title reads: "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. Perhaps you are just a bully? ?-))
Reply by ●August 21, 20132013-08-21
On 21 Aug 2013 05:21:12 GMT, josephkk <joseph_barrett@sbcglobal.net> wrote:>On Mon, 19 Aug 2013 13:50:30 -0700, John Larkin wrote: > >> On 19 Aug 2013 20:18:55 GMT, josephkk <joseph_barrett@sbcglobal.net> >> wrote: >> >>>On Sun, 18 Aug 2013 20:21:01 -0700, John Larkin wrote: >>> >>> >>>>>I suspect what you have is ordinary ignorance. >>>>> >>>>>Get a copy of TIA-485, it is reasonably priced at TechStreet. >>>>> >>>>>There are some basic ideas to learn: differential signaling, bit >>>>>serial protocol, tri-state trnsmitters. It is not Manchester encoded. >>>> >>>> 485 is an electrical logic-level spec; it says nothing about encoding >>>> or protocols. >>>> >>>> >>>Do you have a copy, I do. >>> >>>?-) >> >> I think we have one around here, somewhere. >> >> Wiki says >> >> "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." >> >> http://en.wikipedia.org/wiki/RS-485 >> >> At any rate, there's no law against using an RS485 link to transmit >> Manchester, or delta-sigma, or isochronous data, or anything else. > >Really? > >Let's see: > >The Title reads: > >"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. >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.>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.Deprecates? How so?> >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.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?> >Perhaps you are just a bully? >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
Reply by ●August 22, 20132013-08-22
On Wed, 21 Aug 2013 07:20:50 -0700, John Larkin wrote:>>> Wiki says >>> >>> "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." >>> >>> http://en.wikipedia.org/wiki/RS-485 >>> >>> At any rate, there's no law against using an RS485 link to transmit >>> Manchester, or delta-sigma, or isochronous data, or anything else. >> >>Really? >> >>Let's see: >> >>The Title reads: >> >>"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. >> >> > 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. > >>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. > > Deprecates? How so? > > > >>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. > > 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.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.> > What sort of data encoding do you read the spec as allowing? Async ASCII > at 110 baud? >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.> >>Perhaps you are just a bully? >> >> > Bully? All my comments were technical. You have just gone personal. >Not at all the facts, you started the bullying. I just stood up to you. You don't like it one bit do you? ?-))
Reply by ●August 23, 20132013-08-23
josephkk <joseph_barrett@sbcglobal.net> writes:> On Wed, 21 Aug 2013 07:20:50 -0700, John Larkin wrote: > > >>>> Wiki says >>>> >>>> "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." >>>> >>>> http://en.wikipedia.org/wiki/RS-485 >>>> >>>> At any rate, there's no law against using an RS485 link to transmit >>>> Manchester, or delta-sigma, or isochronous data, or anything else. >>> >>>Really? >>> >>>Let's see: >>> >>>The Title reads: >>> >>>"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. >>> >>> >> 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. >> >>>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. >> >> Deprecates? How so? >> >> >> >>>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. >> >> 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. > > 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.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!>> What sort of data encoding do you read the spec as allowing? Async ASCII >> at 110 baud? >> > 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. >> >>>Perhaps you are just a bully? >>> >>> >> Bully? All my comments were technical. You have just gone personal. >> > Not at all the facts, you started the bullying. I just stood up to you. > You don't like it one bit do you?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:>>>> At any rate, there's no law against using an RS485 link to transmit >>>> Manchester, or delta-sigma, or isochronous data, or anything else.What precisely is there to disagree with in that? -- John Devereux
Reply by ●August 30, 20132013-08-30
On Sunday, August 18, 2013 1:20:57 PM UTC-7, Joerg wrote:> This information would be on pages 16, figures 19 and 20: >=20 > http://www.ti.com/lit/ds/symlink/sn65hvd50.pdf >=20 > Take figure 19, for example. That's the low level side in there. If the > current goes from 25mA to 70mA the device sags off by 1V. That indicates > a source resistance of about 25ohms when pulling low. >=20 > The top of page 4 has minimum values for the differential drive > capability for 54ohms and 100ohms.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?> Maybe I misunderstand this but the best is usually to remain at 50% duty > cycle and NRZ-code.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.> Slow-mode can be a problem with such piggy-back schemes.What do you mean by "piggy-back schemes"?> If the scheme requires this much tuning I think it should either be > auto-tune or force a repeater structure where the nearest device must > re-transmit messages meant for another device down the line in that > direction.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.> TVS would require a diode in series because they have tons of > capacitance and this messes up you signals (muffles them). But better > would be some sort of temporary disconnect or series resistance > increase. Something that only reacts to changes in bus DC voltage if > they are fast and large (in either direction). Gets involved in terms of > parts count though.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?> That sounds like the "bus from hell" :-)Yeah, that's why work on the TDR subsystem has been put off for now.> I am not sure that USB clamping will be strong enough.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.
Reply by ●August 30, 20132013-08-30
omega@omegacs.net wrote:> On Sunday, August 18, 2013 1:20:57 PM UTC-7, Joerg wrote: >> This information would be on pages 16, figures 19 and 20: >> >> http://www.ti.com/lit/ds/symlink/sn65hvd50.pdf >> >> Take figure 19, for example. That's the low level side in there. If >> the current goes from 25mA to 70mA the device sags off by 1V. That >> indicates a source resistance of about 25ohms when pulling low. >> >> The top of page 4 has minimum values for the differential drive >> capability for 54ohms and 100ohms. > Sorry for my ignorance in this area (like I said earlier, analog and > me just don't get along), but how would that compare to e.g. a 74F > gate drive? >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: http://www.nxp.com/documents/data_sheet/74F245.pdf 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.>> Maybe I misunderstand this but the best is usually to remain at 50% >> duty cycle and NRZ-code. > Generally yes, which is why I'd really like to keep the duty cycle > closer to 30/70% rather than 10/90%. Putting fixed gates around the > R/C will enable me to dial that in, by selecting gates where Vil and > Vih are near the appropriate points for the 3.3v VCC. Right now > though, it works for certain chips 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 legitimate Vil and Vih for the microcontroller > > The latter can be locked-in with surrounding gates, the former is > still dependent on the driver structure. >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.>> Slow-mode can be a problem with such piggy-back schemes. > What do you mean by "piggy-back schemes"? >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.>> If the scheme requires this much tuning I think it should either be >> auto-tune or force a repeater structure where the nearest device >> must re-transmit messages meant for another device down the line in >> that direction. > Auto-tune is what I propose above, using failure counters to find the > best option. ...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.> ... 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 would 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 perfect 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 would expect there to > either be relatively little difference between the received signal at > each point on the bus, *or* there to be various standing waves and > all kinds of ACK/NAK patterns along the length. >Then you'd have to cook up your own "more-tolerant" protocol. That might make this solution unpalatable.> - cut bus: a device with two discrete interfaces, plus heavy power > decoupling (pass 36VDC via SSR but heavily block the overlaid 485 > signal). Based on my high-level packet structures, it can spend most > of it's time just shorting the R/D D/R lines together between the two > interfaces, and only pull them apart when the protocol dictates > otherwise. > >> TVS would require a diode in series because they have tons of >> capacitance and this messes up you signals (muffles them). But >> better would be some sort of temporary disconnect or series >> resistance increase. Something that only reacts to changes in bus >> DC voltage if they are fast and large (in either direction). Gets >> involved in terms of parts count though. > I have seen some variation with the presence of the TVS, but haven't > quantified it yet. Do you mean diode in series with the bus itself? > That would be a problem with a half-duplex bidirectional setup, > right? >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.>> That sounds like the "bus from hell" :-) > Yeah, that's why work on the TDR subsystem has been put off for now. >But it's fun :-)>> I am not sure that USB clamping will be strong enough. > I'll look for some "larger" parts and see what I can find. The > theory of using that class of parts is correct though? >Yes, but it must be able to stomach whatever max current spike you are expecting.> 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 there.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. -- Regards, Joerg http://www.analogconsultants.com/
Reply by ●August 31, 20132013-08-31
On Fri, 30 Aug 2013 09:15:29 -0700 (PDT), omega@omegacs.net wrote:> >> If the scheme requires this much tuning I think it should either be >> auto-tune or force a repeater structure where the nearest device must >> re-transmit messages meant for another device down the line in that >> direction. >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: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.>- 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 would 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 perfect 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 would expect there to either be relatively little difference between the received signal at each point on the bus, *or* there to be various standing waves and all kinds of ACK/NAK patterns along the length.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.
