On Sunday, May 12, 2019 at 12:34:23 AM UTC-7, upsid...@downunder.com wrote:
> On 11 May 2019 15:18:46 -0700, Winfield Hill
> <hill@rowland.harvard.edu> wrote:
>
> >Rick C wrote...
> >>
> >> Winfield Hill wrote:
> >>> Winfield Hill wrote...
> >>>> Lasse Langwadt Christensen wrote...
> >>>>>
> >>>>> the STM have programmable slewrate on the IOs
> >>>>
> >>>> Aha! I'll see if our programmer can activate that.
> >>>
> >>> I miss-spoke, we're using an Atmel ARM SAM D21.
> >>> Not sure if they have programmable slew rate,
> >>> but datasheet says the I2C outputs have reduced
> >>> slew-rates. Hmm, the IO spec says 20-50ns with
> >>> a 10 to 400pF load. Well, anyway, I've added a
> >>> resistor (100-ohm) in series with the I2C lines.
>
> A twisted pair typically has an impedance of 100-120 ohs and since the
> transmitter has some output impedance, a smaller resistor should be
> sufficient to match to the line impedance.
The I2C transmitter has, in a sense, an output impedance, but it is a time dependent one. It is Low-Z when at logic low and Hi-Z when at logic high. That is (for any common I2C scheme), it is impossible to "match" I2C TXers and RXers to some fixed line impedance. (The line won't be properly terminated anyway. Slow slew can save I2C at the obvious cost of data transmission speed.
I2C signal integrity is like saying "Jumbo Shrimp." There are things that can be done, but it is (from the get-go) a crap system from the perspective of signal integrity.
> A 100 ohm resistor in the transmitter line will also reduce the low
> state noise margin. If the current through the open drain pull-up
> resistot(s) is more than 4 mA, this will reduce the low state noise
> margin by 400 mV, so if a conventional TTL receiver is used, this will
> kill the noise margin completely. Using 47 ohm series resistor and
> limiting the drain resistor current to 2 mA and the loss of noise
> margin would be only 100 mV.
>
> >>
> >> That seems excessive. Even with a 20 ns rise time
> >> the round trip on a 1 meter cable is around half
> >> the rise time. I think the magic number to ignore
> >> reflections is for the rise time to be 6 times the
> >> round trip delay. The capacitance you can expect
> >> on this run would very likely put the rise time
> >> higher than this threshold so no further actions
> >> would be needed to prevent reflections.
> >
> > Yes, I agree, but my worry isn't so much about
> > reflections, as about crosstalk. If a fast SCL
> > falltime induces an SDA signal, apparently this
> > can cause trouble. Fix with slow falltimes.
>
> I do not understand this crosstalk objections if CAT5/6 cables are
> used, with one pair for SCL and other pair for SDA. After all in
> 100/1000BasetT Ethernet, the whole symbol time is 10 or 8 ns (not just
> rise/fall time) and these cables are specified for up to 100 m.
>
> Of course, i you have split pairs, such as running SDA and SCL in the
> same twisted pair, there are going to be problems.
>
> >
> >> Do you think your rise time will be less than
> >> 60 ns?
> >
> > Yes, according to the spec, without the resistor.
> > Well, OK, I do have an 74HC4052 channel switch
> > in series; it may be about 100 ohms at 3.3 volts.
Reply by Winfield Hill●May 14, 20192019-05-14
Tim Williams wrote...
>
> "Rick C" wrote ...
>>
>> Maybe they make glands for flat cable, but I haven't seen them.
>> The ones I've seen are for round cable.
>
> I've seen seals that are a couple blocks of firm rubber
> clamped together then clamped again by a frame. For example
> a "stocks" shape (two blocks with facing semicircles cut out)
> that grips the cable. Two blank blocks would do for flat
> flex, if maybe not ribbon cable (because of its ribbed
> profile?).
We're still debating the best way to get cables in/out of the
beehive monitor case. The project P.I. wants to try individual
glands, on the removable top. Six cable connectors would be
assembled after running their wires through glands mounted on
the lid, with a painful PCB mating and cable-pulling step, to
mount the lid and dress wires, before tightening six glands.
I'm in favor of the mate-two-blocks approach, because the cable
connectors can be plugged in, strain-relieved with cable ties,
and remain as a single piece with the electronics. The lid,
with cable cutouts is mounted over. I did this last year,
using a mass of RTV for glands, but squeezable blocks would be
better. Our Raspberry Pi server boxes use two blocks, they're
fast and convenient to open and close, and they never leaked.
Their rubber pieces have considerable give, to accommodate any
wire type, or multiple wires.
--
Thanks,
- Win
Reply by Tim Williams●May 13, 20192019-05-13
"Rick C" <gnuarm.deletethisbit@gmail.com> wrote in message
news:522ae226-1c75-4405-9315-f8d34b16345d@googlegroups.com...
>Maybe they make glands for flat cable, but I haven't seen them. The ones
>I've seen are for round cable.
>
I've seen seals that are a couple blocks of firm rubber clamped together
then clamped again by a frame. For example a "stocks" shape (two blocks
with facing semicircles cut out) that grips the cable. Two blank blocks
would do for flat flex, if maybe not ribbon cable (because of its ribbed
profile?).
Tim
--
Seven Transistor Labs, LLC
Electrical Engineering Consultation and Design
Website: https://www.seventransistorlabs.com/
Reply by ●May 13, 20192019-05-13
crosstalk from a DATA edge into the clock line can cause a false clock edge.
and therefore an incorrect read of the data.
m
Reply by Rick C●May 12, 20192019-05-12
On Sunday, May 12, 2019 at 9:12:10 AM UTC-4, Winfield Hill wrote:
> Martin Riddle wrote...
> >
> > On 11 May 2019, Winfield Hill wrote:
> >
> >> Mounted RJ45 connector, but too big, cable too
> >> stiff, unsure of how the shielded variant works.
> >> Went to smaller, simpler RJ12 instead.
> >
> > There is plenum rated cable, it does not outgas
> > when burning eg; low smoke.
> > PVC is not too good for outdoor use.
> > Might want to check for RoHS/REACH compliance,
> > that way you will not get the phthalates.
>
> Interesting points. The little RJ12 cable we're
> discussing is outside, totally outside. Outside
> of the hive, and outside of my beehiove monitor.
> If my beehive monitor goes up in flame, I'm sure
> it'll outgas! It probably makes phthalates too.
> Little RJ14 phone cables may not be happy with
> an extended season of sunlight, but the Amazon
> RJ12 data cables look like they're more robust.
Look? They need to be rated for outside use. They need to be weather tight or the cable ends need to be behind glands to seal out moisture as well as the plastic being resistant to UV light unless you are putting them in a race. You seem to be greatly over designing the noise issue and under designing the environmental issues.
Maybe they make glands for flat cable, but I haven't seen them. The ones I've seen are for round cable.
--
Rick C.
++ Get a 1,000 miles of free Supercharging
++ Tesla referral code - https://ts.la/richard11209
Reply by Jan Panteltje●May 12, 20192019-05-12
On a sunny day (12 May 2019 06:20:05 -0700) it happened Winfield Hill
<hill@rowland.harvard.edu> wrote in <qb96i5010p2@drn.newsguy.com>:
>> But seriously, just use cable with individually
>> screened pairs, like I used audio cable, if you
>> want to cover a few meters.
>
> That's a thought, any with good pre-made connectors
> and four separate conductors (maybe two grounds)?
>> For more use special drivers if unidirectional
>> (no checking of SDA pulldown). Else go optical.
>> Optical fiber does not take that much space, is
>> 'trickety proof, a PIC as i2c to optical interface,
>> whatever.
>
> Yessir, can optical carry 3.3V power?
>
>> Reflections from inductive and/or delay-line
>> loads, i.e. not properly terminated?
>
> Unless those take round the world trips those
> will be sufficiently attenuated after some short time.
> How fast can bees fly? Why be in a hurry?
> A fly is different those can be really fast ;-)
>
> But seriously, just use cable with individually
> screened pairs, like I used audio cable, if you
> want to cover a few meters.
That's a thought, any with good pre-made connectors
and four separate conductors (maybe two grounds)?
> For more use special drivers if unidirectional
> (no checking of SDA pulldown). Else go optical.
> Optical fiber does not take that much space, is
> 'trickety proof, a PIC as i2c to optical interface,
> whatever.
Yessir, can optical carry 3.3V power?
> With wasps it would be easy, you give those
> individual stripes for different messages,
> and use a barcode scanner, training is needed.
>
> Other ideas ?
> ?
> ants?
Check my other thread, has schematic:
Five beehive sensor ICs (I2C and 1.8V max)
And my new thread,
RJ45, RJ12, RJ14 cables straight-through or crossover?
--
Thanks,
- Win
Reply by Winfield Hill●May 12, 20192019-05-12
Martin Riddle wrote...
>
> On 11 May 2019, Winfield Hill wrote:
>
>> Mounted RJ45 connector, but too big, cable too
>> stiff, unsure of how the shielded variant works.
>> Went to smaller, simpler RJ12 instead.
>
> There is plenum rated cable, it does not outgas
> when burning eg; low smoke.
> PVC is not too good for outdoor use.
> Might want to check for RoHS/REACH compliance,
> that way you will not get the phthalates.
Interesting points. The little RJ12 cable we're
discussing is outside, totally outside. Outside
of the hive, and outside of my beehiove monitor.
If my beehive monitor goes up in flame, I'm sure
it'll outgas! It probably makes phthalates too.
Little RJ14 phone cables may not be happy with
an extended season of sunlight, but the Amazon
RJ12 data cables look like they're more robust.
--
Thanks,
- Win
Reply by Jan Panteltje●May 12, 20192019-05-12
On a sunny day (Sun, 12 May 2019 19:38:40 +1000) it happened Clifford Heath
<no.spam@please.net> wrote in <AQRBE.46022$8B4.29667@fx02.iad>:
>On 12/5/19 5:16 pm, Jan Panteltje wrote:
>> On a sunny day (Sun, 12 May 2019 07:10:51 GMT) it happened Jan Panteltje
>> <pNaOnStPeAlMtje@yahoo.com> wrote in <qb8gu6$lpf$1@dont-email.me>:
>>
>>> On a sunny day (11 May 2019 19:13:48 -0700) it happened Winfield Hill
>>> <hill@rowland.harvard.edu> wrote in <qb7vgs02cif@drn.newsguy.com>:
>>>
>>>> Clifford Heath wrote...
>>>>>
>>>>> Winfield Hill wrote:
>>>>>>
>>>>>> I miss-spoke, we're using an Atmel ARM SAM D21.
>>>>>
>>>>>> but datasheet says the I2C outputs have reduced
>>>>>> slew-rates. Hmm, the IO spec says 20-50ns with
>>>>>> a 10 to 400pF load.
>>>>>
>>>>> Presumably the slew-rate limiting depends on the
>>>>> selected data rate, but the data sheet is pretty
>>>>> quiet on that.
>>>>
>>>> Here's their spec, fall time, for 0.7 to 0.3 Vdd:
>>>>
>>>> typ max
>>>> Standard/Fast 20 50 ns
>>>> Fast Mode + 15 50
>>>> High Speed Mode 10 40
>>>>
>>>> Yes, it changes with speed setting, but not much.
>>>> Slowest mode, dV/dt = 0.4 3.3V / 20ns = 66 mV/ns.
>>>> I = C dV/dt, with 75pF, that's i = 5mA, during
>>>> a 50ns transition. This is what can kill using
>>>> twisted-pair wires in a short USB cable. If we
>>>> have 75pF crosstalk with a 200pF load, that's
>>>> still a 28% Vdd interference signal, which is
>>>> smack on the 30% trouble threshold. Why only
>>>> slow to a fast 50ns transition with a 10us bit
>>>> interval? That's only 0.5%. That's why I made
>>>> more changes and added extra stuff.
>>>
>>> The rise - and falltime spec has little meaning, because the i2c system works differently.
>>>
>>> Data is sampled by the clock.
>>> As long as you wait long enough after each transition, data will be stable,
>>> and toggling the clock during stable data a million times due to oscillations in the transient will still read that data in
>>> correctly.
>>
>> Correction, maybe I spoke too soon, clock oscillations on edges may an have effect,
>> but it never seems to happen with capacitive loads or any loads I have tried.
>
>Reflections from inductive and/or delay-line loads, i.e. not properly
>terminated?
Unless those take round the world trips those will be sufficiently attenuated
after some short time.
How fast can bees fly? Why be in a hurry?
A fly is differrent those can be really fast ;-)
But seriously, just use cable with individually screened pairs, like I used audio cable,
if you want to cover a few meters.
For more use special drivers if unidirectional (no checking of SDA pulldown).
Else go optical.
Optical fiber does not take that much space, is 'trickety proof,
a PIC as i2c to optical interface, whatever.
With wasps it would be easy, you give those individual stripes for different messages,
and use a barcode scanner, training is needed.
Other ideas ?
?
ants?
Reply by Clifford Heath●May 12, 20192019-05-12
On 12/5/19 5:16 pm, Jan Panteltje wrote:
> On a sunny day (Sun, 12 May 2019 07:10:51 GMT) it happened Jan Panteltje
> <pNaOnStPeAlMtje@yahoo.com> wrote in <qb8gu6$lpf$1@dont-email.me>:
>
>> On a sunny day (11 May 2019 19:13:48 -0700) it happened Winfield Hill
>> <hill@rowland.harvard.edu> wrote in <qb7vgs02cif@drn.newsguy.com>:
>>
>>> Clifford Heath wrote...
>>>>
>>>> Winfield Hill wrote:
>>>>>
>>>>> I miss-spoke, we're using an Atmel ARM SAM D21.
>>>>
>>>>> but datasheet says the I2C outputs have reduced
>>>>> slew-rates. Hmm, the IO spec says 20-50ns with
>>>>> a 10 to 400pF load.
>>>>
>>>> Presumably the slew-rate limiting depends on the
>>>> selected data rate, but the data sheet is pretty
>>>> quiet on that.
>>>
>>> Here's their spec, fall time, for 0.7 to 0.3 Vdd:
>>>
>>> typ max
>>> Standard/Fast 20 50 ns
>>> Fast Mode + 15 50
>>> High Speed Mode 10 40
>>>
>>> Yes, it changes with speed setting, but not much.
>>> Slowest mode, dV/dt = 0.4 3.3V / 20ns = 66 mV/ns.
>>> I = C dV/dt, with 75pF, that's i = 5mA, during
>>> a 50ns transition. This is what can kill using
>>> twisted-pair wires in a short USB cable. If we
>>> have 75pF crosstalk with a 200pF load, that's
>>> still a 28% Vdd interference signal, which is
>>> smack on the 30% trouble threshold. Why only
>>> slow to a fast 50ns transition with a 10us bit
>>> interval? That's only 0.5%. That's why I made
>>> more changes and added extra stuff.
>>
>> The rise - and falltime spec has little meaning, because the i2c system works differently.
>>
>> Data is sampled by the clock.
>> As long as you wait long enough after each transition, data will be stable,
>> and toggling the clock during stable data a million times due to oscillations in the transient will still read that data in
>> correctly.
>
> Correction, maybe I spoke too soon, clock oscillations on edges may an have effect,
> but it never seems to happen with capacitive loads or any loads I have tried.
Reflections from inductive and/or delay-line loads, i.e. not properly
terminated?