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

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

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

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

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.

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

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

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

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&nbsp; 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