[HN Gopher] Making Screenshots of Test Equipment Old and New
       ___________________________________________________________________
        
       Making Screenshots of Test Equipment Old and New
        
       Author : zdw
       Score  : 127 points
       Date   : 2024-11-30 05:36 UTC (1 days ago)
        
 (HTM) web link (tomverbeure.github.io)
 (TXT) w3m dump (tomverbeure.github.io)
        
       | greatgib wrote:
       | This is really a great job!
       | 
       | This is the old style open source community that I love something
       | and that is often shadowed by big commercial open core projects
       | pretending that they need to change their license because others
       | are using they work...
       | 
       | Like in the good old time, such projects are often made by Linux
       | users just desperate to have a good solution to their problems
       | and happy to share it with others.
        
         | aspenmayer wrote:
         | > This is the old style open source community that I love
         | something and that is often _shadowed_ by big commercial open
         | core projects pretending that they need to change their license
         | because others are using they work...
         | 
         | Overshadowed?
        
           | rnewme wrote:
           | In the popular HN discussions. They generate more fuss
        
             | aspenmayer wrote:
             | I would tend to agree with you and OP, and I also
             | appreciate the project that TFA uses, which seems pretty
             | cool:
             | 
             | https://github.com/tomverbeure/fake_parallel_printer
             | 
             | https://tomverbeure.github.io/2023/01/24/Fake-Parallel-
             | Print...
        
       | guenthert wrote:
       | > The biggest take-away is that they're expensive (>$100 second
       | hand) and hard to configure when using Linux.
       | 
       | The original (or fake, who knows) from Agilent cost that much,
       | yes, but there is AR488 [1], which can be had for pocket money. I
       | have limited experience myself with it (I got the Agilent one),
       | but it seemed to work just fine.
       | 
       | The Agilent one is a bit tricky as its firmware is uploaded when
       | it powers up (is connected to USB) and changes then its ID. That
       | however is well documented and with recent versions of linux-gpib
       | should just work (it does for me).
       | 
       | Then there are GPIB host adaptors for ISA, PCI and PCIe busses.
       | The latter might be expensive and working PC MB with ISA hard to
       | find, but those with PCI are readily available on the secondary
       | market for reasonable prices. I made good experience with one
       | from CEC.
       | 
       | [1] https://github.com/Twilight-Logic/AR488
        
         | vq wrote:
         | I've had luck with the Prologix Ethernet<->GPIB adapters[0]. At
         | $500 I wouldn't call them cheap but they are a lot easier to
         | integrate than those old NI/Keysight PCI/USB-based interfaces.
         | 
         | [0]: https://prologix.biz/product/gpib-ethernet-controller/
        
         | georgeburdell wrote:
         | Not to mention the preponderance of Chinese fakes on the market
         | that die after a few months
        
       | c0nsumer wrote:
       | This is pretty slick. A fun next-layer would be adding on
       | something to automatically convert output and slot it into files
       | in directories or something. Maybe accessible via network, maybe
       | an SD card or so...
        
       | msarnoff wrote:
       | I work on old systems with big parallel buses, so a while ago I
       | bought a big HP 16500C chassis with something like 128 logic
       | analyzer channels.
       | 
       | It can handle a full 68000 bus no problem, but it's cumbersome
       | and unwieldy. (The X11 interface mentioned in the article is
       | nifty though, I remember having the same issue with fonts.)
       | 
       | I love my Saleae and even the cheap USB logic analyzers work fine
       | with Sigrok. But everything is either 8 or 16 channels.
       | 
       | I realize it's a niche-of-a-niche use case, but is anyone making
       | USB logic analyzers with 64+ channels at a hobbyist price point
       | (or DIY)?
        
         | msarnoff wrote:
         | Trivia: I looked through old sales brochures and did the math
         | and calculated that the price of that HP 16500C new, adjusted
         | for inflation, would be over $80,000. I paid $200, and I'm sure
         | there are plenty that people have just given away for free.
        
         | tverbeure wrote:
         | I upgraded from two 16500A boat anchors [1] ($20 a piece) to a
         | 1670G [2]. But you're right: I much prefer my DSLogic UPro 16.
         | Like many others, I've started designing my own 64 channel
         | logic analyzer, but like just as many, I never completed it.
         | There are almost no use cases. When I need to debug wide busse,
         | it's usually in an FPGA and then a signaltap is the way to go.
         | 
         | [1]
         | https://tomverbeure.github.io/2022/06/17/HP16500a-teardown.h...
         | 
         | [2] https://tomverbeure.github.io/2023/12/26/Controlling-an-
         | HP-1...
        
         | echoangle wrote:
         | Can you maybe use multiple logic analyzers and sync them by
         | connecting one channel of every logic analyzer to the same
         | clock signal?
        
         | bpye wrote:
         | Not 64 channels, but for 32 channels I'm a fan of the DSLogic
         | U3Pro32 [0]. DreamSourceLab did historically violate the GPL
         | license of Sigrok, but have since made the source code for
         | their fork available [1], unfortunately last i checked the
         | U3Pro32 wasn't supported in upstream Sigrok.
         | 
         | It does have trigger in and trigger out - so you might be able
         | to use multiple together - though I've not tried.
         | 
         | [0] https://www.dreamsourcelab.com/product/dslogic-series/
         | 
         | [1] https://github.com/DreamSourceLab/DSView
        
       | 4ntiq wrote:
       | > My Siglent SDS 2304X was my first oscilloscope.
        
       | jeffbee wrote:
       | None of this equipment is "old" if the screenshot doesn't involve
       | a film camera mounted to the CRT.
        
         | tverbeure wrote:
         | I don't really like the esthetic of _really_ old test equipment
         | so I tend to stick with stuff that's 1980s or later. Those
         | tends to have digital interfaces.
        
           | jeffbee wrote:
           | Yeah, they're not beautiful or really useful any more. I
           | think the old way of capturing screenshots with a Polaroid is
           | only interesting because it explains "single sweep" mode on
           | the scope, which is vestigial nonsense on a DSO.
        
             | contingencies wrote:
             | Single on Rigol at least seems to be a trigger mode, not a
             | display mode, the other options being 'auto' and 'normal',
             | both of which allow constant refreshes when the trigger
             | event re-occurs. This appears to be a distinct branch of
             | evolution from the semantic interface etymology you
             | reference.
        
             | kevin_thibedeau wrote:
             | I use single captures on digital scopes all the time to
             | avoid losing intermittent signals when it is hard to get
             | what you want with normal+stop. It's also sometimes
             | annoying on scopes with normal/auto multiplexed onto the
             | start operation to switch back to normal mode through menus
             | when a single button is right there.
        
       | contingencies wrote:
       | Some modern systems use an ethernet kludge known as LXI.
       | https://github.com/lxi-tools/lxi-tools works easily: _lxi
       | screenshot -a <ip>_ See https://github.com/lxi-tools/lxi-
       | tools/wiki#background-infor... or example workflow at
       | https://github.com/vk2diy/adxi/blob/main/kicad-pcbs/adxi/REA...
        
         | tverbeure wrote:
         | Yeah, a couple of years ago I wrote blog post that goes over
         | all the different protocols:
         | https://tomverbeure.github.io/2020/06/07/Making-Sense-of-
         | Tes....
         | 
         | None of my equipment has LXI though, and the Ethernet equipment
         | that I have has been painful to use. See the Siglent troubles
         | in this blog post, or older equipment which often doesn't
         | support DHCP at all.
        
           | contingencies wrote:
           | It seems everything is an SCPI-derivative these days, and
           | that is a protocol family not a protocol, one which could
           | only be ill-defined and heavily vendor-extended/interpreted
           | to the point of assumed uninteroperability at best. That
           | said, it works. I wouldn't buy new test equipment now without
           | LXI or some similarly scriptable interface. Manual
           | configuration just creates too much scope for error during
           | testing. Coming from software, electronics is hard enough
           | without the fuzz-factor of human fur-ball and fat-finger
           | physics frappery. Automation is worth its weight in gold,
           | even if you don't value your own time highly. And the
           | lifetime for equipment that can be automated is much higher
           | as it can become part of fixed production or test setups and
           | thus handily serve in-place as precision automation for
           | common unit operations. Even just the documentation value of
           | "these were the settings, this was the (precise or relative)
           | time" is infinitely higher than manual fudge-work. That's why
           | this good gear is going cheap - nobody commercial wants it,
           | because it's behind the 8 ball from an era where flying solo
           | with fuzzy manual process was fine. Skilled as any IC's
           | engineering may be, if they get hit by a bus the company
           | would prefer to have dropped $10K extra on test equipment
           | this side of Y2K.
           | 
           | I guess that's why it's nice to see this project - because
           | you're essentially helping to rescue gear that would be
           | discarded for hassle-factor or manual-only interface and
           | providing some portion of modern functions.
        
       | buccal wrote:
       | Nice overview. What should be mentioned is that HPGL and EPS (PCL
       | maybe as well) are vector formats and you can use Inkscape to
       | edit and convert them to SVG or PDF files. Vector formats provide
       | great lossless scaling and other advantages.
        
         | tverbeure wrote:
         | The EPS output of the HP 54825A is definitely a bitmap though.
         | 
         | I personally prefer the screen cap to a close a possible to the
         | original screen to keep the old school look. Vector output
         | don't have that.
        
       | eitally wrote:
       | I used to run software development for the rest engineering and
       | quality tools used internally by Sanmina (high-tech electronics
       | mfr). Granted, we had some control over the hardware in use at
       | our factories, but we have been doing similar work to this since
       | about 2007. The screen caps were just to reinforce the [much
       | easier to extract via API] parametric data, but it was surprising
       | how frequently a test engineer referred back to them.
        
       ___________________________________________________________________
       (page generated 2024-12-01 23:01 UTC)