Re: RE: Re: RE: Re: RE: Re: Fine Tuning Shifting

On 11/11/2024 12:53 PM, cyclintom wrote:

On Sat Aug 17 07:16:07 2024 zen cycle  wrote:

On 8/16/2024 5:57 PM, cyclintom wrote:

On Fri Aug 16 13:45:41 2024 Zen Cycle  wrote:

On 8/15/2024 3:55 PM, cyclintom wrote:

On Thu Aug 15 14:31:03 2024 Zen Cycle  wrote:

On 8/15/2024 12:41 PM, Jeff Liebermann wrote:

On Wed, 14 Aug 2024 19:22:06 -0400, zen cycle
<funkmasterxx@hotmail.com> wrote:
>

On 8/14/2024 3:35 PM, cyclintom wrote:

>
>
Flunky just talks ahbout crap that he doesn't know about. Notice how
he could not answer how you measure the length of a wire
electronically? That's because he personally doesn't know how to use
an oscilloscope. Which comes as no

>
Or, It could be because Jeff answered it as well as I could so I didn't
feel it was worth commenting, but since you insist, here's how you test
cable length with _out_ using dedicated TDR equipment:
>
- Connect a pulse generator, an oscilloscope, and the cable under test
together with a T connector (Typically BNC, but adaptors may be required
depending on the equipment.
- set up a pulse generator to single pulse, starting with a 1 nS width,
5 V P-P.
- Set up the scope to trigger on the single pulse from the generator,
with the pulse from the generator being displayed at the extreme left of
the display.
- Adjust the time base of the oscilloscope until the reflected pulse
appears on the right side of the display while manually initiating the
pulse on the generator.*
- Longer cable lengths may make the returned pulse not quite
discernible. When the trigger pulse is no longer visible, increase the
pulse width until it is visible, then begin adjusting the time base
again until the reflected pules is visible (It may also be necessary to
increase the pulse amplitude).
- Once the reflected pulse is visible, measure the distance between the
trigger pulse and the reflected pulse on the scope as time delay (Hence
the term Time Domain Reflectometry).
- PLug this delay into the propagation delay value for the cable under
test, and do the math.
>
* setting up the generator to a repetitive pulse could prove problematic
in that the trigger pulse period my be shorter than the propagation
delay of the cable under test giving a confusing display. A competent
technician could manage it, but given the bizarre and completely
non-nonsensical method you described, it's well beyond your comprehension.

>
Yep.  That's how a TDR works.  However, I have a few quibbles.  Using
a 1 nsec wide pulse is difficult to see on the oscilloscope.  The rise
time on a commodity 100 MHz bandwidth oscilloscope is about 3.5 nsec,
which makes seeing a 1 nsec pulse difficult.  Minimum would be a 350
MHz oscilloscope.

>
That's true of low-end scopes. Most modern production* models can latch
onto it with no problem, with the added benefit of calculating the
period between the trigger and the reflected pulse as a measurement
function even if the pulse is too narrow to visibly discern, provided
the amplitude of the reflection is high enough for the scope to see of
course. Sampling rate is just as important here.
>

>
It's much easier to produce and see a 1 nsec rise time step waveform
(either rising of falling).  That's what the cheap square wave TDR
devices use:
<https://www.youtube.com/results?search_query=tdr+74ac14>
Even if the scope does not have adequate rise time to be able to see a
1 nsec pulse, it can see something with a 1 nsec step.  The
measurement point will need to be visually approximated but at least
it will be visible.

>
And this is exactly why a dedicated TDR tester is of much more use. I
presented this method to show tommy-can't-do how TDR fundamentals work -
something he is woefully mis/underinformed about.
>

>
It is possible to create nsec (and picosec) pulse widths using step
recovery diodes:
<https://en.wikipedia.org/wiki/Step_recovery_diode>
<http://www.hp.woodshot.com/hprfhelp/5_downld/lit/diodelit/an918.pdf>
<https://arxiv.org/pdf/1610.07115>
However, that's overkill for measuring cable lengths, where a cheap
74AC14 oscillator and Schmitt trigger squaring amp are sufficient.
>

>
I saw a demo sometime ago of a guy using a 9V battery with a momentary
switch and an in-line resistor as the pulse stimulus for measuring a
long cable spool, it actually worked pretty well.
>
*by production model I mean something intended for use in a production
facility as GP test equipment. 500MHz/1Gs models were a bit expensive
back then, but not too bad on the 2nd hand market these days
https://alltest.net/categories/products/54825A-Agilent-Keysight
>
>
-- Add xx to reply
>

Pretending to explain something to Liebermann who knows nothing is pretty silly. Why did you say that you didn't need a repetitive trigger and then say that "Sampling rate is just as important here."?

>
I didn't write that you don't need a repetitive trigger. I wrote that
you don't need a repetitive pulse from the generator.
>
Besides that, there's no such thing as a repetitive trigger. For normal
waveform analysis Oscilloscopes have Auto, Normal, and Single Sweep
trigger settings. For TDR you can't use Auto, it must be either Normal
or Single. If you _are_ using a repetitive pulse using amything but
Normal would be pointless (can you tell me why?)
>
There's no relationship between any trigger setting and sampling rate of
the scope other then higher rates give less less aliasing and better
capture of high transient/slew signals
>

>
Did I misunderstand you or did you say that you were triggering an o-scope on the echo?

>
yes, I didn't write anything even remotely similar to that.
>
One tgriggers on the starting pulse and measure TO the echo. But perhaps
I misunderstood you.
>
"Set up the scope to trigger on the single pulse from the generator with
the pulse from the generator being displayed at the extreme left of
the display"
>
"Adjust the time base of the oscilloscope until the reflected pulse
appears on the right side of the display while manually initiating the
pulse on the generator"
>
"measure the distance between the trigger pulse and the reflected pulse
on the scope as time delay"
>

I gave you real numbers because I used a PWM signal in the real world.

>
No, you didn't. PWM is used mainly for motor speed control and lighting
intensity control as well as a few other applications where precise
variable control is needed. It is not, and never has been, used for
testing cable length. A PWM signal is a continuous pulse stream. It
would be nearly impossible to see a reflected pulse with a continuous
pulse stream from the source.
>
>
    I was partner in a telephone installation firm and we paid real money
for real rolls of interconnect wire and the larger the roll the more you
paid for it. No sense in throwing money away. So you bought rolls of
wire as close to the correct size as possible and that meant from the
interconnect board in the basement of skyscrapers to whereever the
interconnect room was for the company employing our services might be.

>
And we were WELL paid. I was making twice as much working as a telephome installation technician as I was designing and programming medical instruments. I was offered a job working on a Respiratory Gas Analyzer. So I trained a replacement that my partner only had to pay wages. He was disappointed that I dissolved the partnership, but it was just as well as he had a heart attack and died a year or so later. I had no idea of how to install the upper floor actual telephone systems. My job was interconnecting to Bell. And the Bell technicians were TERRIBLE at that. Their interconnect panels looked like loose spaghetti.

>
-- Add xx to reply
>

>
>
>
>
Stop pretending that you're an EE, you're nothing more than a QC paperwork wonk.

>
funny, my degree and job title say something very different
>

You don't fucking understand ANYTHING.

>
I understand that you're a pathetic, broke, broken down drunk who has
created an entire alternate reality of his past in order to try to
convince others of his importance.
>

You couldn't understand a simple C program

>
No matter how many times you repeat that lie, it will never become true.
>

that didn't do anything but flash some LED's

>
says the guy who didn't even realize the design included a peripheral
ADC, then couldn't answer the question about why he didn't use the ADC
integrated into the ucontroller.
>

and then to cover your ass you said that you could program but it was boring.

>
I've met software engineers who are bored with hardware design, and
hardware engineers (like me) that are bored with software.
>

You CANNOT be a digital designer without the ability to program.

>
Who ever said I was a digital designer? certainly not me.
>

And you cannot be a designer without the ability to know what the digital capabilities of complex chips are.

>
Which is exactly how I knew that your ucontroller had an integrated ADC
that was more than adequate for you application.
>

Stop with your continuous bullshit.

>
Like PWM is used to test cables?
Like fiber optic cables are called light lines?
>
>
>
>

>
I'm sorry that you never could understand electronics engineering but THAT IS NORMAL. 80% of all college graduate don't work one single day in their major. So count yourself lucky.

>

 

Still digging back to august looking validation? sorry tommy, it's not going to help.

  Why do you insist on saying you can program when I posted a program that did nothing but blink an LED and you couldn't understand it.

hmmm... I seem to remember you getting flummoxed over my question of using a 24 bit A/D converter - starting with the fact that you couldn't understand where I got that information.

Even if you didn't realize that the signals were flashing an LED anyone that could program would be able to see that it was generating two signals of varying signal length.
 You constantly lies about you knowing how to program demonstrates why you do not work as an engineer.

Sorry tommy, I answered all your questions about your silly little program. Just because you ignored my responses doesn't mean it didn't happen.
--
Add xx to reply