Making Screenshots of Test Equipment Old and New(tomverbeure.github.io)
tomverbeure.github.io
Making Screenshots of Test Equipment Old and New
https://tomverbeure.github.io/2024/11/29/Making-Screenshots-of-Test-Equipment.html
26 comments
> 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?
Overshadowed?
In the popular HN discussions. They generate more fuss
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...
https://github.com/tomverbeure/fake_parallel_printer
https://tomverbeure.github.io/2023/01/24/Fake-Parallel-Print...
> 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
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
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/
[0]: https://prologix.biz/product/gpib-ethernet-controller/
Not to mention the preponderance of Chinese fakes on the market that die after a few months
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...
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.
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.
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.
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.
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)?
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)?
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
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
Can you maybe use multiple logic analyzers and sync them by connecting one channel of every logic analyzer to the same clock signal?
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.
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...
[1] https://tomverbeure.github.io/2022/06/17/HP16500a-teardown.h...
[2] https://tomverbeure.github.io/2023/12/26/Controlling-an-HP-1...
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.
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.
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.
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.
None of this equipment is "old" if the screenshot doesn't involve a film camera mounted to the CRT.
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.
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.
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.
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.
which is vestigial nonsense on a DSO.
... which I needed about 30 minutes ago to capture the first qualifying event on my DSO, using a pulse-width trigger.
... which I needed about 30 minutes ago to capture the first qualifying event on my DSO, using a pulse-width trigger.
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...
> My Siglent SDS 2304X was my first oscilloscope.
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.