non-pipelined fast ADC...

[Chris]

On 08/31/20 23:27, Phil Hobbs wrote:

On 2020-08-30 23:05, John Miles, KE5FX wrote:
On Friday, August 28, 2020 at 9:47:41 AM UTC-7, Phil Hobbs wrote:
Its main drawback is that you can have the RF or microwave band
displayed, but not both at once. Still, for 2 cents on the dollar one
really can\'t complain too loudly.

Sure it can!

http://www.ke5fx.com/sweep_0_24G.gif

In single-sweep mode at least...

I\'m a happy user of your GPIB Tools via a Prologix GPIB-Ethernet
adapter. Thanks for making them available!

Cheers

Phil Hobbs

By concidence, i\'m currently writing libraries and app to drive
the Prologix adapter. The idea is to make an instrument
agnostic system, driven by a plain text strings in a command
file, thus bypassing the need for instrument specific drivers.
It\'s up to the user to decide what to send to the instrument as
command strings.

The Prologix has a large command set, some of which take args
and some don\'t and often needs to be in a particular mode for
the command. Have the network layer written, with a Prologix
layer that normalises the commands into a single list. It also
remembers what mode it\'s in to avoid repetitious mode commands.
So far, that\'s all working and currently working the top level
command language design.

This was prompted by having a load of old HP and other kit in the
lab, much of it with gpib interfaces. An ongoing
requirement for data logging capability and more. Did have a
look at the hp software packages, but felt like bloatware from
the start, Gb on disk and expensively protectionist to boot. It\'s
a bit of work, but keeps coding skills alive in semi retirement
and can make it do just what I want, rather than hp\'s idea.
It will be opensourced eventually...

Chris

 

[John Larkin]

On Mon, 31 Aug 2020 18:33:02 -0400, Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:

On 2020-08-30 22:46, jlarkin@highlandsniptechnology.com wrote:
On Sun, 30 Aug 2020 21:48:49 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

On 2020-08-30 20:58, whit3rd wrote:
On Sunday, August 30, 2020 at 4:06:50 PM UTC-7, Phil Hobbs wrote:
On 2020-08-30 17:08, whit3rd wrote:

... if you lock it to the XO with any variant of phase-locking,
it\'s NO LONGER phase-locked to the trigger event, and the
measurement is worthless. Just cancel the trigger-caused start
phase against an XO-caused start phase, and ignore the absolute
frequency of the LC entirely (unless you think it drifts enough
in a few milliseconds to matter).


You\'ve never actually used a state-of-the-art digital delay
generator, I gather. Good ones have jitter down around 10 ps over
fairly long periods. Even the SRS DG535 I bought ~25 years ago had
jitter less than 100 ps, and newer ones are much better.

The idea that an LC oscillator could hold the necessary phase
accuracy for milliseconds is ridiculous.

There\'s no milliseconds required on phase accuracy;

As the wise man said, \"When you find yourself in a hole, stop digging.\"

Reiterating point 1: you\'ve obviously never used a state-of-the-art DDG,
at least not at a level where you needed to knew what it did.

that\'s only for the LC frequency drift from a measurement cycle to a
subsequent calibration cycle. It\'s not necessary for the LC to give
an accurate sine, just a repeatable waveform, and any jitter is
irrelevant

An accurate, repeatable, low-jitter delay on an asynchronous waveform is
what a DDG is all about. See point 1.

except as an addition to the thermal-noise contribution.

How would you estimate the thermal noise contribution exactly?

Cheers

Phil Hobbs

A pretty good triggered LC oscillator will pile up jitter at very
roughly 1 picosecond RMS per microsecond. The junk it takes to start
and stop it compromise the Q some. So it\'s good to close the PLL and
lock it to a crystal within a microsecond or two.

A cheap XO will have jitter of maybe 20 ns RMS per second, less if you
get a good one by accident. A $70 OCXO will be roughly a thousand
times better.

The XO or OCXO will improve greatly with a cover to keep air currents
from wafting over it.

Especially at low modulation frequencies. Gerhard and I were discussing
that yesterday in the tantalum caps thread--thermal drifts give rise to
very steeply rising baseband noise.

Cheers

Phil Hobbs

Given a charged capacitor, with some tempco of capacitance, is charge
conserved as the temperature changes? If so, the voltage across the
cap is immediately modulated by temperature wobbles.

The XO situation is made worse by the dissipation of the oscillator.
The air only has to change velocity to mess up the frequency.

 

[Phil Hobbs]

On 2020-08-31 19:19, John Larkin wrote:

On Mon, 31 Aug 2020 18:33:02 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

On 2020-08-30 22:46, jlarkin@highlandsniptechnology.com wrote:
On Sun, 30 Aug 2020 21:48:49 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

On 2020-08-30 20:58, whit3rd wrote:
On Sunday, August 30, 2020 at 4:06:50 PM UTC-7, Phil Hobbs
wrote:
On 2020-08-30 17:08, whit3rd wrote:

... if you lock it to the XO with any variant of
phase-locking, it\'s NO LONGER phase-locked to the trigger
event, and the measurement is worthless. Just cancel the
trigger-caused start phase against an XO-caused start
phase, and ignore the absolute frequency of the LC
entirely (unless you think it drifts enough in a few
milliseconds to matter).


You\'ve never actually used a state-of-the-art digital
delay generator, I gather. Good ones have jitter down
around 10 ps over fairly long periods. Even the SRS DG535
I bought ~25 years ago had jitter less than 100 ps, and
newer ones are much better.

The idea that an LC oscillator could hold the necessary
phase accuracy for milliseconds is ridiculous.

There\'s no milliseconds required on phase accuracy;

As the wise man said, \"When you find yourself in a hole, stop
digging.\"

Reiterating point 1: you\'ve obviously never used a
state-of-the-art DDG, at least not at a level where you needed
to knew what it did.

that\'s only for the LC frequency drift from a measurement
cycle to a subsequent calibration cycle. It\'s not necessary
for the LC to give an accurate sine, just a repeatable
waveform, and any jitter is irrelevant

An accurate, repeatable, low-jitter delay on an asynchronous
waveform is what a DDG is all about. See point 1.

except as an addition to the thermal-noise contribution.

How would you estimate the thermal noise contribution exactly?

Cheers

Phil Hobbs

A pretty good triggered LC oscillator will pile up jitter at
very roughly 1 picosecond RMS per microsecond. The junk it takes
to start and stop it compromise the Q some. So it\'s good to close
the PLL and lock it to a crystal within a microsecond or two.

A cheap XO will have jitter of maybe 20 ns RMS per second, less
if you get a good one by accident. A $70 OCXO will be roughly a
thousand times better.

The XO or OCXO will improve greatly with a cover to keep air
currents from wafting over it.

Especially at low modulation frequencies. Gerhard and I were
discussing that yesterday in the tantalum caps thread--thermal
drifts give rise to very steeply rising baseband noise.

Cheers

Phil Hobbs

Given a charged capacitor, with some tempco of capacitance, is
charge conserved as the temperature changes?

If it\'s running open-circuit, sure.

If so, the voltage across the
> cap is immediately modulated by temperature wobbles.

Yup. The parts advertised as capacitors for that sort of job tend to be
NP0/C0G, which are pretty blameless, but when you start getting down to
parts in 1E11, things get less simple.

The XO situation is made worse by the dissipation of the oscillator.
The air only has to change velocity to mess up the frequency.

That too. Styrofoam covers a multitude of sins.

Cheers

Phil Hobbs


--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

 

[Phil Hobbs]

On 2020-08-31 19:12, Chris wrote:

On 08/31/20 23:27, Phil Hobbs wrote:
On 2020-08-30 23:05, John Miles, KE5FX wrote:
On Friday, August 28, 2020 at 9:47:41 AM UTC-7, Phil Hobbs wrote:
Its main drawback is that you can have the RF or microwave band
displayed, but not both at once. Still, for 2 cents on the dollar one
really can\'t complain too loudly.

Sure it can!

http://www.ke5fx.com/sweep_0_24G.gif

In single-sweep mode at least...

I\'m a happy user of your GPIB Tools via a Prologix GPIB-Ethernet
adapter. Thanks for making them available!

Cheers

Phil Hobbs


By concidence, i\'m currently writing libraries and app to drive
the Prologix adapter. The idea is to make an instrument
agnostic system, driven by a plain text strings in a command
file, thus bypassing the need for instrument specific drivers.
It\'s up to the user to decide what to send to the instrument as
command strings.

The Prologix has a large command set, some of which take args
and some don\'t and often needs to be in a particular mode for
the command. Have the network layer written, with a Prologix
layer that normalises the commands into a single list. It also
remembers what mode it\'s in to avoid repetitious mode commands.
So far, that\'s all working and currently working the top level
command language design.

This was prompted by having a load of old HP and other kit in the
lab, much of it with gpib interfaces. An ongoing
requirement for data logging capability and more. Did have a
look at the hp software packages, but felt like bloatware from
the start, Gb on disk and expensively protectionist to boot. It\'s
a bit of work, but keeps coding skills alive in semi retirement
and can make it do just what I want, rather than hp\'s  idea.
It will be opensourced eventually...

Chris

Sounds super useful for what we do. Please keep us posted on your progress!

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

 

[Chris]

On 08/31/20 04:05, John Miles, KE5FX wrote:

On Friday, August 28, 2020 at 9:47:41 AM UTC-7, Phil Hobbs wrote:
Its main drawback is that you can have the RF or microwave band
displayed, but not both at once. Still, for 2 cents on the dollar one
really can\'t complain too loudly.

Sure it can!

http://www.ke5fx.com/sweep_0_24G.gif

In single-sweep mode at least...

-- john, KE5FX

Just a thanks for your page on restoring tubes, \"for the brave
experimenter\". Gave me the confidence to fix the tubes in 85xx
series analyser display sections here. Didn\'t take notes, but
the setup was a 250v tube ht transformer for isolation,
a bridge rectifier, a current limiting resistor and a variac
on the tx primary. Fed unsmoothed dc between the
tube grid and cathode. Heater voltage from DC psu, turned up
to bright orange, the dangerous bit . Turned up the variac
initially to 20mA for around 10s, but not much change, so
turned up to 50mA limit or so and saw sparks inside the tube.
After a few seconds, current drops down. A couple of sessions
like that, 10 secs or so each and voila, the tube works with
perfect focus, though the intensity pot needs to be at 60 or
70%, to look right. Suspect that the tube had done a lot of
hours...

Chris

 

[John Larkin]

On Mon, 31 Aug 2020 19:28:58 -0400, Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:

On 2020-08-31 19:19, John Larkin wrote:
On Mon, 31 Aug 2020 18:33:02 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

On 2020-08-30 22:46, jlarkin@highlandsniptechnology.com wrote:
On Sun, 30 Aug 2020 21:48:49 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

On 2020-08-30 20:58, whit3rd wrote:
On Sunday, August 30, 2020 at 4:06:50 PM UTC-7, Phil Hobbs
wrote:
On 2020-08-30 17:08, whit3rd wrote:

... if you lock it to the XO with any variant of
phase-locking, it\'s NO LONGER phase-locked to the trigger
event, and the measurement is worthless. Just cancel the
trigger-caused start phase against an XO-caused start
phase, and ignore the absolute frequency of the LC
entirely (unless you think it drifts enough in a few
milliseconds to matter).


You\'ve never actually used a state-of-the-art digital
delay generator, I gather. Good ones have jitter down
around 10 ps over fairly long periods. Even the SRS DG535
I bought ~25 years ago had jitter less than 100 ps, and
newer ones are much better.

The idea that an LC oscillator could hold the necessary
phase accuracy for milliseconds is ridiculous.

There\'s no milliseconds required on phase accuracy;

As the wise man said, \"When you find yourself in a hole, stop
digging.\"

Reiterating point 1: you\'ve obviously never used a
state-of-the-art DDG, at least not at a level where you needed
to knew what it did.

that\'s only for the LC frequency drift from a measurement
cycle to a subsequent calibration cycle. It\'s not necessary
for the LC to give an accurate sine, just a repeatable
waveform, and any jitter is irrelevant

An accurate, repeatable, low-jitter delay on an asynchronous
waveform is what a DDG is all about. See point 1.

except as an addition to the thermal-noise contribution.

How would you estimate the thermal noise contribution exactly?

Cheers

Phil Hobbs

A pretty good triggered LC oscillator will pile up jitter at
very roughly 1 picosecond RMS per microsecond. The junk it takes
to start and stop it compromise the Q some. So it\'s good to close
the PLL and lock it to a crystal within a microsecond or two.

A cheap XO will have jitter of maybe 20 ns RMS per second, less
if you get a good one by accident. A $70 OCXO will be roughly a
thousand times better.

The XO or OCXO will improve greatly with a cover to keep air
currents from wafting over it.

Especially at low modulation frequencies. Gerhard and I were
discussing that yesterday in the tantalum caps thread--thermal
drifts give rise to very steeply rising baseband noise.

Cheers

Phil Hobbs

Given a charged capacitor, with some tempco of capacitance, is
charge conserved as the temperature changes?

If it\'s running open-circuit, sure.

If so, the voltage across the
cap is immediately modulated by temperature wobbles.

Yup. The parts advertised as capacitors for that sort of job tend to be
NP0/C0G, which are pretty blameless, but when you start getting down to
parts in 1E11, things get less simple.

The XO situation is made worse by the dissipation of the oscillator.
The air only has to change velocity to mess up the frequency.

That too. Styrofoam covers a multitude of sins.

Cheers

Phil Hobbs

After experimenting with small phenolic potting-shell type covers, and
little drawn-aluminum ones, I concluded that the best insulation
inside a component cover is air.

Cheapest, too.

 

[Phil Hobbs]

On 2020-08-31 20:05, John Larkin wrote:

On Mon, 31 Aug 2020 19:28:58 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

On 2020-08-31 19:19, John Larkin wrote:
On Mon, 31 Aug 2020 18:33:02 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

On 2020-08-30 22:46, jlarkin@highlandsniptechnology.com wrote:
On Sun, 30 Aug 2020 21:48:49 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

On 2020-08-30 20:58, whit3rd wrote:
On Sunday, August 30, 2020 at 4:06:50 PM UTC-7, Phil Hobbs
wrote:
On 2020-08-30 17:08, whit3rd wrote:

... if you lock it to the XO with any variant of
phase-locking, it\'s NO LONGER phase-locked to the trigger
event, and the measurement is worthless. Just cancel the
trigger-caused start phase against an XO-caused start
phase, and ignore the absolute frequency of the LC
entirely (unless you think it drifts enough in a few
milliseconds to matter).


You\'ve never actually used a state-of-the-art digital
delay generator, I gather. Good ones have jitter down
around 10 ps over fairly long periods. Even the SRS DG535
I bought ~25 years ago had jitter less than 100 ps, and
newer ones are much better.

The idea that an LC oscillator could hold the necessary
phase accuracy for milliseconds is ridiculous.

There\'s no milliseconds required on phase accuracy;

As the wise man said, \"When you find yourself in a hole, stop
digging.\"

Reiterating point 1: you\'ve obviously never used a
state-of-the-art DDG, at least not at a level where you needed
to knew what it did.

that\'s only for the LC frequency drift from a measurement
cycle to a subsequent calibration cycle. It\'s not necessary
for the LC to give an accurate sine, just a repeatable
waveform, and any jitter is irrelevant

An accurate, repeatable, low-jitter delay on an asynchronous
waveform is what a DDG is all about. See point 1.

except as an addition to the thermal-noise contribution.

How would you estimate the thermal noise contribution exactly?

Cheers

Phil Hobbs

A pretty good triggered LC oscillator will pile up jitter at
very roughly 1 picosecond RMS per microsecond. The junk it takes
to start and stop it compromise the Q some. So it\'s good to close
the PLL and lock it to a crystal within a microsecond or two.

A cheap XO will have jitter of maybe 20 ns RMS per second, less
if you get a good one by accident. A $70 OCXO will be roughly a
thousand times better.

The XO or OCXO will improve greatly with a cover to keep air
currents from wafting over it.

Especially at low modulation frequencies. Gerhard and I were
discussing that yesterday in the tantalum caps thread--thermal
drifts give rise to very steeply rising baseband noise.

Cheers

Phil Hobbs

Given a charged capacitor, with some tempco of capacitance, is
charge conserved as the temperature changes?

If it\'s running open-circuit, sure.

If so, the voltage across the
cap is immediately modulated by temperature wobbles.

Yup. The parts advertised as capacitors for that sort of job tend to be
NP0/C0G, which are pretty blameless, but when you start getting down to
parts in 1E11, things get less simple.

The XO situation is made worse by the dissipation of the oscillator.
The air only has to change velocity to mess up the frequency.

That too. Styrofoam covers a multitude of sins.

Cheers

Phil Hobbs

After experimenting with small phenolic potting-shell type covers, and
little drawn-aluminum ones, I concluded that the best insulation
inside a component cover is air.

Cheapest, too.

Assuming that the cover is small enough that convection doesn\'t occur.

For a given geometry there\'s a critical temperature gradient at which
convection starts to dominate.

Long ago at UBC I took a stellar structures class taught by the
estimable Prof. Jason Auman, one of the pioneers of computer modelling
of stellar structure and evolution.

In stars, near the core the energy transfer is dominated by radiation.
At some point nearer the surface, a convective instability starts,
which rapidly achieves the speed of sound, which at a million degrees C
in a mostly-hydrogen ambient is on the order of 100 km/s, enough to
homogenize the convective layers pretty thoroughly. (Magnetic effects
start to become important nearer the surface.)

All of which is to say, that a sufficiently-small air-filled insulator
is as good as an ideal solid insulating material.

Cheers

Phil Hobbs


--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

 

[Bill Sloman]

On Tuesday, September 1, 2020 at 10:05:38 AM UTC+10, John Larkin wrote:

On Mon, 31 Aug 2020 19:28:58 -0400, Phil Hobbs
pcdhSpamM...@electrooptical.net> wrote:

On 2020-08-31 19:19, John Larkin wrote:
On Mon, 31 Aug 2020 18:33:02 -0400, Phil Hobbs
pcdhSpamM...@electrooptical.net> wrote:

On 2020-08-30 22:46, jla...@highlandsniptechnology.com wrote:
On Sun, 30 Aug 2020 21:48:49 -0400, Phil Hobbs
pcdhSpamM...@electrooptical.net> wrote:

On 2020-08-30 20:58, whit3rd wrote:
On Sunday, August 30, 2020 at 4:06:50 PM UTC-7, Phil Hobbs
wrote:
On 2020-08-30 17:08, whit3rd wrote:

<snip>

The XO situation is made worse by the dissipation of the oscillator.
The air only has to change velocity to mess up the frequency.

That too. Styrofoam covers a multitude of sins.

After experimenting with small phenolic potting-shell type covers, and
little drawn-aluminum ones, I concluded that the best insulation
inside a component cover is air.

Cheapest, too.

If the cover is small. The Rayleigh number matters, and this depends linearly on the volume of air enclosed by the cover.

If it \'s less than 500, there\'s relatively little convective heat transfer. If it gets up 100,000 you get turbulent convection currents and they transfer a lot more heat, and do it erratically.

https://en.wikipedia.org/wiki/Rayleigh_number

If the cover is less than a inch (25mm) across, you don\'t get much convection at all, and what you\'ve got isn\'t turbulent.

--
Bill Sloman, Sydney

 

[whit3rd]

On Monday, August 31, 2020 at 5:05:38 PM UTC-7, John Larkin wrote:

After experimenting with small phenolic potting-shell type covers, and
little drawn-aluminum ones, I concluded that the best insulation
inside a component cover is air.

Still air, yes. You can keep it still with a bit of fiber (like, a blanket)
which is why glass fiber insulation shows up a lot.

For cinderblock, it was once determined that you could fill it with peanut
butter, and it\'d be a better insulator than empty (because the large-ish
void allows air circulation).

Cheapest, too.

Peanut butter, at $2 per pound, is not widely recommended.

 

[Gerhard Hoffmann]

Am 01.09.20 um 01:12 schrieb Chris:

By concidence, i\'m currently writing libraries and app to drive
the Prologix adapter. The idea is to make an instrument
agnostic system, driven by a plain text strings in a command
file, thus bypassing the need for instrument specific drivers.
It\'s up to the user to decide what to send to the instrument as
command strings.

The Prologix has a large command set, some of which take args
and some don\'t and often needs to be in a particular mode for
the command. Have the network layer written, with a Prologix
layer that normalises the commands into a single list. It also
remembers what mode it\'s in to avoid repetitious mode commands.
So far, that\'s all working and currently working the top level
command language design.

This was prompted by having a load of old HP and other kit in the
lab, much of it with gpib interfaces. An ongoing
requirement for data logging capability and more. Did have a
look at the hp software packages, but felt like bloatware from
the start, Gb on disk and expensively protectionist to boot. It\'s
a bit of work, but keeps coding skills alive in semi retirement
and can make it do just what I want, rather than hp\'s  idea.
It will be opensourced eventually...

I had some problems with my Agilent 89441A control program that
became unreliable over the years. It used the BNC-Ethernet
interface via an Amazon converter box to the normal 1 GB LAN.

You simply open port 5002 on 192.168.178.38 or whatever and then
you can dump / read ordinary GPIB strings to/from that port.
Last year, this communication often got stuck and finally it was
unusable.

I decided to circumvent this by using real GPIB via a Prologix
USB <--> GPIB dongle. The program got an option -488 and I
inserted a multiplexer software layer just above the Ethernet
access. That was easy since the de/composition of control
strings stayed the same.

But I never could make the last 5% of the Prologix interface work.
BTW it\'s nowhere specified what happens in the case of a timeout
and the Prologix documentation refers mostly to third parties
on the net.

I then found out what the problem was with the LAN/socket interface.

If you switch data direction, you need to fseek() even if this
is just an empty call. The newer Linux kernels seem to be
more picky about that, with older kernels it just used to work.

Now that the LAN works again I have no motivation to complete
that Prologix option.
I think I have given the program to someone on s.e.d.
The update is available.

Cheers,
Gerhard

 

[Chris]

On 09/01/20 07:39, Gerhard Hoffmann wrote:

Am 01.09.20 um 01:12 schrieb Chris:

By concidence, i\'m currently writing libraries and app to drive
the Prologix adapter. The idea is to make an instrument
agnostic system, driven by a plain text strings in a command
file, thus bypassing the need for instrument specific drivers.
It\'s up to the user to decide what to send to the instrument as
command strings.

The Prologix has a large command set, some of which take args
and some don\'t and often needs to be in a particular mode for
the command. Have the network layer written, with a Prologix
layer that normalises the commands into a single list. It also
remembers what mode it\'s in to avoid repetitious mode commands.
So far, that\'s all working and currently working the top level
command language design.

This was prompted by having a load of old HP and other kit in the
lab, much of it with gpib interfaces. An ongoing
requirement for data logging capability and more. Did have a
look at the hp software packages, but felt like bloatware from
the start, Gb on disk and expensively protectionist to boot. It\'s
a bit of work, but keeps coding skills alive in semi retirement
and can make it do just what I want, rather than hp\'s idea.
It will be opensourced eventually...

I had some problems with my Agilent 89441A control program that
became unreliable over the years. It used the BNC-Ethernet
interface via an Amazon converter box to the normal 1 GB LAN.

You simply open port 5002 on 192.168.178.38 or whatever and then
you can dump / read ordinary GPIB strings to/from that port.
Last year, this communication often got stuck and finally it was
unusable.

I decided to circumvent this by using real GPIB via a Prologix
USB <--> GPIB dongle. The program got an option -488 and I
inserted a multiplexer software layer just above the Ethernet
access. That was easy since the de/composition of control
strings stayed the same.

But I never could make the last 5% of the Prologix interface work.
BTW it\'s nowhere specified what happens in the case of a timeout
and the Prologix documentation refers mostly to third parties
on the net.

I then found out what the problem was with the LAN/socket interface.

If you switch data direction, you need to fseek() even if this
is just an empty call. The newer Linux kernels seem to be
more picky about that, with older kernels it just used to work.

Now that the LAN works again I have no motivation to complete
that Prologix option.
I think I have given the program to someone on s.e.d.
The update is available.

Cheers,
Gerhard

I\'m writing this system in layers, with a test harness for each
to give the code a good thrashing to detect errors. I\'m developing
under Solaris 10, gcc, makefiles etc and had some weirdness with
the networking layer as well. Nprmally, one would just open a socket
to connect to the device and port, then a read to get the return data,
but this didn\'t work. Tried various variations on that, but
eventually settled on a select() call to check for data, then a read()
which works fine most of the time, Rewrote the code as a little
state machine with retries which made it nearly 100% good. Slight
mods to the makefile and it builds and runs fine under FreeBSD 12 as
well. Not tried Linux, but should build ok there as well. No windows
version is planned, unix only for now. Have had
a test harness running for weeks, reading an old Keithley dvm and
has done over 10 e6 reads with just 2 errors, so may be good enough,
but may revisit that later. Network loading does seem to affect it,

Of course, fseek() is an os level call, not Prologix, but suspect
the Prologix firmware may have corner cases and may occasionally
drop command frames, but can\'t be sure...

Chris

 

[Gerhard Hoffmann]

Am 01.09.20 um 13:50 schrieb Chris:

Of course, fseek() is an os level call, not Prologix, but suspect
the Prologix firmware may have corner cases and may occasionally
drop command frames, but can\'t be sure...

Nonono, the fseek() was needed to make the LAN socket interface
work again, it has nothing to do with the Prologix.

I have a backburner project with some LTC2500-32 ADCs and a
BeagleBone Black playing FFT analyzer (because of this sh*tty
89441A 1/f noise behavior), and its S/W interface is like the
89441A: GPIB / SCPI over LAN socket. Then the PC side needs not
much of a change.

BTW, You can compile FFTW (the fastest FFT in the west) without
any problems on the BBB with its NEON floating point unit.
That wasn\'t much more than downloading and \"make, make install\".

cheers, Gerhard

 

[Chris]

On 09/01/20 13:39, Gerhard Hoffmann wrote:

Am 01.09.20 um 13:50 schrieb Chris:

Of course, fseek() is an os level call, not Prologix, but suspect
the Prologix firmware may have corner cases and may occasionally
drop command frames, but can\'t be sure...

Nonono, the fseek() was needed to make the LAN socket interface
work again, it has nothing to do with the Prologix.

Yes, that\'s what I was saying. Normally, if you open a unix
socket, it stays open until closed, but needing an fseek to
refresh access sounds like a network tuning parameter, or bugs
in the os network layer, perhaps keepalive timeout ?. Developing
under Solaris 10, which worked fine, but needed to add retries
and timeouts to the network code for FreeBSD. Stevens books on
network programming are the bible here, but it certainly didn\'t
work out of the box as described in the book. Suspect Linux may
have simalar issues, but would want to know why that was
happening. Assume you use Wireshark or tcpdump to debug ?.

I have a backburner project with some LTC2500-32 ADCs and a
BeagleBone Black playing FFT analyzer (because of this sh*tty
89441A 1/f noise behavior), and its S/W interface is like the
89441A: GPIB / SCPI over LAN socket. Then the PC side needs not
much of a change.

BTW, You can compile FFTW (the fastest FFT in the west) without
any problems on the BBB with its NEON floating point unit.
That wasn\'t much more than downloading and \"make, make install\".

cheers, Gerhard

Application is long term characterisation of voltage reference
drift. The LM199 / 399 is out of production fwir, but some Ebay
sellers have the mil / 883 qualified 199 parts for sale, which are
in theory prescreened. The 399\'s are noisy and drift a lot
initially, but settle down after a couple of months running. The
199\'s settle down faster, but even they have an ageing
characteristic. Have a 8.5 digit Solartron 7081 with gpib interface
and that should be good enough for the task, hence the initial
need for a sorted package to drive it..,

Chris

 

[Fred Bloggs]

On Tuesday, August 25, 2020 at 2:34:31 PM UTC-4, John Larkin wrote:

Does anybody know of one? I\'d like to digitize 6 bits or so, really
fast. Most fast ADCs take 3 or 4 clocks to process the data. Even 4
bits might work.

Classic \"flash\" ADCs were fast, but needed 2^N comparators.

There was a class a A/D called folded cascode by my recollection but not called that anymore. Front end would flash the input into 2-bits and then a fast pipeline would take it from there to get 6-bits or more total. They were uncomplicated. National had some in their last days, so did Maxim. Maybe they fizzled away.

 

[John Miles, KE5FX]

On Monday, August 31, 2020 at 3:27:07 PM UTC-7, Phil Hobbs wrote:

I\'m a happy user of your GPIB Tools via a Prologix GPIB-Ethernet
adapter. Thanks for making them available!

Likewise, big fan of your book! Still waiting on the sequel.

-- john, KE5FX

 

[John Miles, KE5FX]

On Monday, August 31, 2020 at 4:58:20 PM UTC-7, Chris wrote:

Just a thanks for your page on restoring tubes, \"for the brave
experimenter\". Gave me the confidence to fix the tubes in 85xx
series analyser display sections here.

You\'re welcome -- that sounds about like what I\'ve seen, and what
others have reported. 20 mA isn\'t enough to do anything, and 70 mA
is probably more than necessary/advisable.

I will say that I\'ve always found it necessary to tweak the trimpots
for best results, rather than just readjusting the intensity control.

Definitely have never seen sparks in the tube during this process.
Wonder what does that? I guess there\'s enough material flaking off
of the cathode surface to bridge the K-G1 gap momentarily?

-- john, KE5FX

 

[server]

On Wed, 2 Sep 2020 00:08:42 -0700 (PDT), \"John Miles, KE5FX\"
<jmiles@gmail.com> wrote:

On Monday, August 31, 2020 at 3:27:07 PM UTC-7, Phil Hobbs wrote:
I\'m a happy user of your GPIB Tools via a Prologix GPIB-Ethernet
adapter. Thanks for making them available!


Likewise, big fan of your book! Still waiting on the sequel.

-- john, KE5FX

I sent a copy of Phil\'s book to the co-founder of a giant laser
lithography company. He hated me for doing that because it absorbed
him for a week and he couldn\'t get anything else done.



--

John Larkin Highland Technology, Inc

Science teaches us to doubt.

Claude Bernard

 

[Chris]

On 09/02/20 08:18, John Miles, KE5FX wrote:

On Monday, August 31, 2020 at 4:58:20 PM UTC-7, Chris wrote:
Just a thanks for your page on restoring tubes, \"for the brave
experimenter\". Gave me the confidence to fix the tubes in 85xx
series analyser display sections here.

You\'re welcome -- that sounds about like what I\'ve seen, and what
others have reported. 20 mA isn\'t enough to do anything, and 70 mA
is probably more than necessary/advisable.

I will say that I\'ve always found it necessary to tweak the trimpots
for best results, rather than just readjusting the intensity control.

Definitely have never seen sparks in the tube during this process.
Wonder what does that? I guess there\'s enough material flaking off
of the cathode surface to bridge the K-G1 gap momentarily?

-- john, KE5FX

I did tweak the pots as well, but suspect the tube is low on normal
emission, due to hours powered up in a past life.

As for the sparks, while the current was limited via series resistor,
there could have been as much as 100 volts off load, depending on the
Variac setting on the primary. Had the idea that the use of unsmoothed
rectified dc at a reasonable voltage might cause vibration in the
tube elements at 2 x line frequency, but can\'t verify that. Whatever,
but it cured the problem completely...

Chris

 

[John Miles, KE5FX]

On Wednesday, September 2, 2020 at 6:40:59 AM UTC-7,

I sent a copy of Phil\'s book to the co-founder of a giant laser
lithography company. He hated me for doing that because it absorbed
him for a week and he couldn\'t get anything else done.

Yep, it\'s like the AoE X-chapters volume in that regard. If I open it
for any reason, that\'s it for the rest of the afternoon.

-- john, KE5FX