Acquired TDS684C from ebay: Develop GPIB to USB Interface?

[LostTime77]

Hey guys:

I have recently decided to 'restart' my lab in my current abode after several years and a current job that is in flux. I used to have a small lab with some equipment, but ended up getting rid of all of it. I was looking to see if I could get a high bandwidth scope for cheap, so I went to ebay and came upon a TDS684C and paid $707 shipped. I went looking online and a new equivalent (by comparing pure bandwidth) scope was over $15K. I thought this was a steal. I also purchased a siglent 2 channel 200MHz scope for $300 on special as a secondary / backup scope.

The seller has stated the scope is in working condition; however, what I wanted was the ability to easily take screenshots in the modern day using USB. My plan was to buy some really cheap equipment (the siglent) and use it to "fix up" or modify the TDS684C. The TDS has a floppy drive and a GPIB & RS232 interface. I took a look online for USB to GPIB adapters and I came upon the cheapest one I could find at $75 new. For what these guys are putting on the PCB (essentially just a USB MCU and a few connectors), $75 is robbery to me. considering I can write that firmware myself. I am also of the opinion that test equipment for hobby stuff should be very low cost to entry. Lastly, I am not interested in what I personally would consider "hackey" solutions that look like slapping a few components together (I know they exist and have found a few).

My question is: would there be any interest in an "advanced" USB to GPIB interface? What I mean is not only including USB to GPIB device functionality to be hooked up to a PC, but also USB host functionality as well. What about including the ability to hook in a flash drive for screenshots or having some on board storage itself? How about converting the GPIB interface to a USB TMC interface?

I don't have a lot of experience with the GPIB interface specifically, so I am starting to look into it. I am aware it doesn't provide power output, therefore the device would have to include an on board battery for a mobile option. Additionally, I can see that not all devices seem to be equal in the command set, so maybe have some ability to store different profiles on the device for various operations. I am thinking maybe a small memory LCD with some buttons for navigating the configuration.

Too much? Not here to start any wars, just literally spit balling here and posing the question. I have done a little research on GPIB and it does not seem to be fully obsolete / dead. My usage scenario for making a mini interface device would be maybe it could be battery powered and you carry it to different equipment stations, perform some operations and move to the next. There are many different ways to skin the cat.

I am not a fan of slapping a raspberry pi onto everything, because I personally am not a fan of the whole Rpi environment being closed. I have also worked with Broadcomm professionally, and I absolutely dislike their company and business model -  you have to pull teeth just to get the most basic of information, even if you are a partner. As a device partner, I actually had to reverse engineer their own SPI port protocol on a GPS chipset because the jacks on the other end jerked us around and would only cough up a datasheet and not the RM (password locked by the way! Which I cracked to get rid of that annoying prompt every opening). You become a partner and get access to their "super secret" portal, which is down, broken, or slow, 90% of the time. But, Oh my! You only get access to the most basic of documents after (no joke) months of prying. How the hell am I supposed to talk to your chip that you sold us if I don't know how the SPI port works? No.. it was not some simple SPI interface - they implemented a layer on top of it which included header bytes that had to be correct. I only stumbled upon the right sequence by accident using a logic analyzer. I digress..........

For reference, I am an electronics engineer with many years of experience in hardware and software, especially with developing embedded USB stacks from scratch and know what this effort entails. I am not looking to make money off of the device described herein nor am I making any promises: is there a discussion here or am I just blowing smoke for something that would not be useful?

[Jwalling]

If you just want to save screen captures to a USB thumb drive, why not use a USB floppy drive replacement kit?
https://www.ebay.com/itm/392226360641?

[nctnico]

One of the things I have been contemplating is to take the video signals (digital), read these into a RAM using a CPLD and then use a microcontroller to write these to an SD card. Ofcourse this can be a USB stick too. Slightly more work since you need to pick up the video signals at the right point. I have done several CRT / STN LCD to TFT conversions over the years.

[capt bullshot]

Many years ago, I did an GPIB to Ethernet board (sorry, it's a German only page): http://wunderkis.de/scbrd/index.html
GPIB is quite simple to do, some GPIO and drivers are sufficient, data transfer can be done by simple  More interesting is to provide the PC side with a protocol that is understood by the most common PC drivers, not just your homebrew protocol (as I did), so one can use readily available PC software. Anyway, I'd prefer Ethernet over USB in my lab setup, and I don't use Windows, so a lot of this software isn't available for me anyway. I'd like to have screen copies transferred directly to the PC. I don't like intermediate steps e.g. using a thumb drive or whatever, so I wouldn't need any local controls or displays on the GPIB interface device itself.

[artag]

There are 2 or 3 home-made GPIB interfaces on this forum. The one I've been involved with is the AR488, which is based on arduino hardware but there are others.

One uses a Cypress SOC which may achieve higher speeds - these simple interfaces are usually biased towards cheapness rather than speed and don't have the FPGA and DMA channel needed to avoid bitbanging the interface.

They're adequate for most purposes but if you want the best out of screen transfers you might want something fast. It's only useful if your scope also has a fast interface though - in many cases the screen dump was expected to go to a printer, and high speed wasn't an issue.

I agree the RPi isn't properly open, but it's mostly the video and USB areas that have restrictions. Since the core of it is Linux, it's very open indeed. However if you do want complete documentation you might consider the Beaglebone. It costs more but doesn't have secret GPU code, and also has some very nice high speed programmable peripheral processors.

[Kilo Tango]

I came across this one some time ago " http://www.dalton.ax/gpib/ " looked quite good. In the best open source tradition, all the info seems to be there. Maybe a good starting point ?.

Ken

[LostTime77]

@Jwalling
I definitely did think about this; however, my problem is that I don't know if I am going to find a floppy drive kit that would exactly fit the slot in the TDS684C. Yes, I 'could' 3d print something, but I kinda wanted the device to look perfect and consistent with itself without holes or missing space. That was my thinking. Looking at ebay and the options, it seems the one you linked might be the right size.

@capt bullshot
I wouldn't see a huge issue in adding ethernet connectivity in addition to USB. The point with the GPIB to USB and having a flash drive there would allow people to easily take screenshots without having to do a floppy to USB mod on a scope, or if the scope does not have a floppy but has GPIB. I actually saw quite a few high end old scopes including Teks without the storage option. The adapter could provide several options for screenshots: on board storage, flash drive, SD card, or direct to PC. The reasoning for some sort of UI would be to switch between pre programmed GPIB command configurations due to each manufacturer having its own commands set. I have not gotten so far into GPIB to know if there is a way to auto identify what scope we are connected to in a standard way.

@artag
I am not in disagreement that there definitely exists many ways to skin the cat and that devices already exist. I am looking for a more plug and play and "professional" looking option. I don't mean it needs to have a case, but one PCB with the connectors and not a modified arduino or Rpi board. What you guys make definitely works. As Kilo Tango pointed out: more this http://www.dalton.ax/gpib/, less this https://sigrok.org/wiki/AR488. Again, this is completely my opinion, but if I were to 'sell' something for the professional market, I think people would prefer more of the first one.

@nctnico
This sounds interesting; however, could get overly complicated, for something in my opinion that is not really useful. If the intention is to take screenshots, why would I do this over the suggested GPIB adapter which could take screenshots, perform a myriad of other complex remote control actions, and be easily connected to 'any' test equipment with a GPIB port?

[Hexley]

What about including the ability to hook in a flash drive for screenshots or having some on board storage itself?

If saving screenshots to USB flash drive files is an important use case, then you might consider something like what I did for a TDS644B a few years ago, which allowed "printing" directly to a USB file system.

If you need full GPIB control, then this is obviously not the answer. But for me, I just wanted to grab bmp screen shots and paste them into Word files as part of lab notebook documentation. So I configured the scope for Centronics printer output, then grabbed the parallel data from the rear panel printer port and stored it on a USB flash drive.

Took a Cortex M3 module and three other chips.  2400 lines of code, most of which was due to creeping elegance (real time clock, LCD interface, header parsing to determine the file type in order to generate the proper file extension, etc.) Good weekend project.

[capt bullshot]

What about including the ability to hook in a flash drive for screenshots or having some on board storage itself?

If saving screenshots to USB flash drive files is an important use case, then you might consider something like what I did for a TDS644B a few years ago, which allowed "printing" directly to a USB file system.

Quite a nice project! Anyway, I'd prefer to skip the intermediate USB step, as I'm often writing reports while using the scope, and I'm always looking for the most convenient (lest keystrokes, mouse moves, plug moves, ...) to get screenshots into the report. In the past I've used e.g. a simple PC program that captured the serial print screen output and could paste the image directly into the report. Doesn't work anymore due to more modern PCs and whatever, so there'll be less screenshots in the reports since it's more inconvenient to transfer them.

[LostTime77]

Well, what I mean is that the device could feature several interfaces and you choose what you want to use. The device could feature both ethernet and USB interfaces and offer direct connection to a PC. The storage options could be there if you wanted to use them, but are not required if you connect directly to an external host (like a PC).