S-parameter test sets

[Terry Given]

Joerg wrote:

Hello Terry,

and best not to think about how the display appears on the 3577 or 3585.


The 3577 can't do spectrum display. Wish it could, that would free up
some lab rack space although its fan creates quite a racket.

Regards, Joerg

not as such, no. But I can do a magnitude-only plot of A (or B, or R).
so when considering excitation-and-response, it behaves the same as a
speccy with tracking generator.

And it uses the same display module as the 3585. I read the service
manual last night, and it sure as hell looks like there is a "digital
link" in there. Not that I am unhappy with the result.

Cheers
Terry

 

[Terry Given]

Joel Kolstad wrote:

Terry,

"Terry Given" <my_name@ieee.org> wrote in message
news:jm1we.10830$U4.1396447@news.xtra.co.nz...

One detailed read of the protocol was enough to kill that idea. What a
dog! Trust computer scientists to pick the most complex method of doing
anything.


What didn't you like about it? I've used USB before, and while it is somewhat
complex, if you're actually trying to achieve everything that USB does (power
control, plug and play, guaranteed delivery as well as bulk delivery, "dumb"
modes for initial boot of PCs with keyboards and mice as well as the standard
"smart" modes, multiple speeds, etc.), I think that much of the complexity is
needed. (I'd say the one place they got carried away was with control
reads/writes... and once they let the "software guys" loose on defining stuff
like HID, but that's no an inherent problem with USB itself).

---Joel

its been a while since I looked (despite desinging USB products quite
recently, I never write software so dont care about the protocol), but
it struck me as being overly complex. I should go read my USB 2.0 book
again, and try and recall what else I thought was crap. IIRC I didnt
like the hierarchical structure, but this was a decade ago.

Cheers
Terry

 

[Joerg]

Hello Terry,

The 3577 can't do spectrum display. Wish it could, that would free up
some lab rack space although its fan creates quite a racket.

not as such, no. But I can do a magnitude-only plot of A (or B, or R).
so when considering excitation-and-response, it behaves the same as a
speccy with tracking generator.

Magnitude-only on the 3577 is a successive sampling process with a very
slow ADC. So it relies on perfect tracking of generator and receiver.
Looking at a spectrum does reveal that "there is something at x MHz" but
the amplitude will jump around even at very slow scan rates.

Regards, Joerg

http://www.analogconsultants.com

 

[Rich Grise]

On Tue, 28 Jun 2005 18:49:29 +1200, Terry Given wrote:

Joel Kolstad wrote:
"Terry Given" <my_name@ieee.org> wrote in message

One detailed read of the protocol was enough to kill that idea. What a
dog! Trust computer scientists to pick the most complex method of doing
anything.

What didn't you like about it? I've used USB before, and while it is somewhat
complex, if you're actually trying to achieve everything that USB does (power
control, plug and play, guaranteed delivery as well as bulk delivery, "dumb"
modes for initial boot of PCs with keyboards and mice as well as the standard
"smart" modes, multiple speeds, etc.), I think that much of the complexity is
needed. (I'd say the one place they got carried away was with control
reads/writes... and once they let the "software guys" loose on defining stuff
like HID, but that's no an inherent problem with USB itself).

its been a while since I looked (despite desinging USB products quite
recently, I never write software so dont care about the protocol), but
it struck me as being overly complex. I should go read my USB 2.0 book
again, and try and recall what else I thought was crap. IIRC I didnt
like the hierarchical structure, but this was a decade ago.

The Customer wants easy. The Customer wants simple. The Customer wants
plug-n-play. The Customer doesn't want to think. USB is a nightmare on
the inside, but there are dedicated pepole who put up with it, because
the Customer wants crap like my little USD139 camera that just plugs
into my USB port, and just shows up. I suddenly have another drive,
with a bunch of jpg files on it. And USB also supports my HP transparent
scanner - a stunningly good deal - USD79 bucks! For a SCANNER!

So, yeah, for us engineering-types, USB is an abortion looking for
a coat hanger, but for the End User, it's a dream come true. I can't
help but think of that roommate I had several years ago, who had a
Macintosh. It used some kind of serial daisy-chainable interface,
where you'd just plug your peripherals into each other. One socket
on the back of the computer itself, and one little cable that went
to the keyboard, and then another little cable from the keyboard to
the printer, and another little cable from the printer to the ...

Well, you get the point.

At some point or another in the loop, somebody had to do the grunt
work.

Thanks,
Rich

 

[Terry Given]

Rich Grise wrote:

On Tue, 28 Jun 2005 18:49:29 +1200, Terry Given wrote:

Joel Kolstad wrote:

"Terry Given" <my_name@ieee.org> wrote in message


One detailed read of the protocol was enough to kill that idea. What a
dog! Trust computer scientists to pick the most complex method of doing
anything.

What didn't you like about it? I've used USB before, and while it is somewhat
complex, if you're actually trying to achieve everything that USB does (power
control, plug and play, guaranteed delivery as well as bulk delivery, "dumb"
modes for initial boot of PCs with keyboards and mice as well as the standard
"smart" modes, multiple speeds, etc.), I think that much of the complexity is
needed. (I'd say the one place they got carried away was with control
reads/writes... and once they let the "software guys" loose on defining stuff
like HID, but that's no an inherent problem with USB itself).


its been a while since I looked (despite desinging USB products quite
recently, I never write software so dont care about the protocol), but
it struck me as being overly complex. I should go read my USB 2.0 book
again, and try and recall what else I thought was crap. IIRC I didnt
like the hierarchical structure, but this was a decade ago.


The Customer wants easy. The Customer wants simple. The Customer wants
plug-n-play. The Customer doesn't want to think. USB is a nightmare on
the inside, but there are dedicated pepole who put up with it, because
the Customer wants crap like my little USD139 camera that just plugs
into my USB port, and just shows up. I suddenly have another drive,
with a bunch of jpg files on it. And USB also supports my HP transparent
scanner - a stunningly good deal - USD79 bucks! For a SCANNER!

So, yeah, for us engineering-types, USB is an abortion looking for
a coat hanger, but for the End User, it's a dream come true. I can't
help but think of that roommate I had several years ago, who had a
Macintosh. It used some kind of serial daisy-chainable interface,
where you'd just plug your peripherals into each other. One socket
on the back of the computer itself, and one little cable that went
to the keyboard, and then another little cable from the keyboard to
the printer, and another little cable from the printer to the ...

Well, you get the point.

At some point or another in the loop, somebody had to do the grunt
work.

Thanks,
Rich

Hi Rich,

you are dead right. I hooked up my digital camera to my pc for the first
time the other day. I plugged it in and it played. And yep, scanners
sure are cheap nowadays.

and the corollary is that when you have control over the hardware that
gets plugged into the interface, things can get a lot simpler. At the
time I was looking for a *cheap* hardware solution that did its own
buffering and error checking, so as not to burden the poor old system
processor, which was being beaten to death numerically.

Cheers
Terry

 

[Rich Grise]

On Wed, 29 Jun 2005 08:55:08 -0700, Joel Kolstad wrote:

"Terry Given" <my_name@ieee.org> wrote in message
news:6gmwe.11073$U4.1423465@news.xtra.co.nz...
At the
time I was looking for a *cheap* hardware solution that did its own
buffering and error checking, so as not to burden the poor old system
processor, which was being beaten to death numerically.

Intel is very much a fan of trying to do all the processing on their CPU --
they'd rather have people build $10 "WinModems" (signal processing is done on
the CPU) than $10 "smart" modems!

I had a very illuminating experience with winmodems, on my first W95
computer. I had never even heard of a "winmodem," it simply was the
one that came with the computer. In 1996, $1000.00 was a lot of money!
[still is, in my book -- Pig Bladder]

Anyway, I was just using the included software for email and junk,
and it was molasses-slow - I'd had better responses on the BBS
with DOS!

Then, for some unknown reason, I started investigating Linux. The
first thing _any_ of the Linux crowd were saying back in those days
was, "Get a real modem. Linux doesn't support winmodems." I had no
idea.

So, I went shopping, and found a "REAL(r)" modem or something like
that - maybe "Realtek" or something, that was guaranteed to work
on DOS.

I was astonished. I was flabbergasted. Even in Windoze, with the
new modem, my connection seemed a hundred times faster. Not that it
_was_, mind you, it just _seemed_ to be that way. During that
edjamacaishunal experience, I also got turned onto Eudora, the
mail program that doesn't have to be on-line to compose email,
but still, the difference between a winmodem and a real modem
was significant.

Of course, it's been some years since I've used a modem - I presume
that the 100MBPS ethernet cards don't depend on the CPU for their
signal processing, although, we all know what ass-u-me means. ;-)

Thanks!
Rich

 

[Joel Kolstad]

"Rich Grise" <richgrise@example.net> wrote in message
newsan.2005.06.29.18.25.15.857356@example.net...

Of course, it's been some years since I've used a modem - I presume
that the 100MBPS ethernet cards don't depend on the CPU for their
signal processing, although, we all know what ass-u-me means. ;-)

Not directly, but there's plenty of time spent digesting TCP/IP packets. In
fact, from what I've heard, the TCP/IP stacks are relatively complex in that
some "starightforward" implementation would be dog slow and bring the CPU to
its knees, so they have "fast path" code (for when all the packet come in the
correct order, there are no errors, etc.) as well as "special needs" code (dog
slow, but shouldn't be called that often). Apparently this is sophisticated
enough that people write journal papers about it!

There are such things as hardware level TCP/IP routers out there, but the $25
wireless routers one finds at Fry's don't fall into that category. Still,
it's absolutely astonishing that for $25 you get a fully functional, 54mbps
2.4GHz radio, a router, firewall, etc., all in a little box no bigger than a
hardback book. I remember looking at Telebit (are they still alive?)
netblazers back about a decade ago, and you got less functionality in a box
that at the time sold for >$1500!

---Joel

 

[Jim Thompson]

On Wed, 29 Jun 2005 08:55:08 -0700, "Joel Kolstad"
<JKolstad71HatesSpam@yahoo.com> wrote:

"Terry Given" <my_name@ieee.org> wrote in message
news:6gmwe.11073$U4.1423465@news.xtra.co.nz...
At the
time I was looking for a *cheap* hardware solution that did its own
buffering and error checking, so as not to burden the poor old system
processor, which was being beaten to death numerically.

Intel is very much a fan of trying to do all the processing on their CPU --
they'd rather have people build $10 "WinModems" (signal processing is done on
the CPU) than $10 "smart" modems!

P4's and up suck on numeric processing. That's why I switched last
year to AMD Athlon 64... runs circles around a P4.

...Jim Thompson
--
| James E.Thompson, P.E. | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona Voice480)460-2350 | |
| E-mail Address at Website Fax480)460-2142 | Brass Rat |
| http://www.analog-innovations.com | 1962 |

I love to cook with wine. Sometimes I even put it in the food.

 

[Keith Williams]

In article <9pr5c1p9e6ceecbd0b2hql0i0l72516oq6@4ax.com>,
thegreatone@example.com says...

On Wed, 29 Jun 2005 08:55:08 -0700, "Joel Kolstad"
JKolstad71HatesSpam@yahoo.com> wrote:

"Terry Given" <my_name@ieee.org> wrote in message
news:6gmwe.11073$U4.1423465@news.xtra.co.nz...
At the
time I was looking for a *cheap* hardware solution that did its own
buffering and error checking, so as not to burden the poor old system
processor, which was being beaten to death numerically.

Intel is very much a fan of trying to do all the processing on their CPU --
they'd rather have people build $10 "WinModems" (signal processing is done on
the CPU) than $10 "smart" modems!


P4's and up suck on numeric processing. That's why I switched last
year to AMD Athlon 64... runs circles around a P4.

P4s suck at integer arithmetic (they forgot the barrel-shifter integer
multiplier, D'oh!) and but aren't so bad at FP. AMD64 is a far better
choice, in any case.

--
Keith

 

[Terry Given]

Joerg wrote:

Hello Terry,

The 3577 can't do spectrum display. Wish it could, that would free up
some lab rack space although its fan creates quite a racket.


not as such, no. But I can do a magnitude-only plot of A (or B, or R).
so when considering excitation-and-response, it behaves the same as a
speccy with tracking generator.


Magnitude-only on the 3577 is a successive sampling process with a very
slow ADC. So it relies on perfect tracking of generator and receiver.
Looking at a spectrum does reveal that "there is something at x MHz" but
the amplitude will jump around even at very slow scan rates.

Regards, Joerg

Nice, thanks for the explanation - I have seen that behaviour while
playing, and wondered why.

Cheers
Terry