Yet Another USB GPIB Interface (yaugi) - Page 1
Forum section: electronics / general

author: essele
author_rank: Frequent Contributor
timestamp: October 18, 2019, 01:48:00 pm
content: I know there are quite a few of these being developed, but I thought this was sufficiently different to warrant publishing.As the name suggests this is a USB to GPIB interface, along the lines of the Prologix adapter (or many other examples.)The reason I started building this was that I couldn't find anything that was sensibly priced or easy to use and it seemed like a fun and fairly straighforward project ... there is no commercial intent here, I'm very happy to open source it if anyone finds it useful.The basic idea is:- Driven by a PSoC 4200L MPU- No interface chips (to keep the cost down)- Supports USBUART already, potential for USBTMC- EEPROM support for storing settings- Potential to hardware accelerate the GPIB handshake- More usable interactive interface (for setup etc)- Open drain GPIO's allow detection of GPIB device- Low cost, not much more than the CPU and connector.The PSoC has everything pretty much built in including full speed USB, so UART over USB capability and potential for USBTMC, it should be able to do both at the same time with a composite device configuration.As far as cost goes ... there's not a lot to it... the CPU, the main connector, a 10-way programming header, the USB socket, a poly-fuse, a diode, and a few decoupling capacitors ... the led's and button are optional and not used at the moment.Using mouser/digikey etc, even for a one-off, it should be not far off £10 in components, and with connectors from eBay or Aliexpress you can shave another couple of pounds off. Five boards from JLCPCB are $2 plus shipping. It's pretty easily hand soldered.Obviously without the standard GPIB interface IC's it's not technically meeting the GPIB spec, so it won't support a full length bus with lots of devices ... I've only tested with one device currently, but I would be suprised if it didn't work with a handful and sensible cable lengths.The programmable hardware aspect of the PSoC means that you can build the handshake into hardware and acheive improved speeds, certainly better than you get with bitbanging ... I haven't done this yet, it's next on my list.Currently I'm implementing the Prologix command set, and I've added some features to make the interactive experience a bit better, simple command line editing, last command recall etc. It won't be used once in an automated system, but it makes setting it up and testing much easier.I've also added a few other bits to improve usability, for example the option of auto read-after-write only if the last command included a "?".I've only tested it against a 34401 so far, I've got a few other devices to test with (K2000, Prema DMM, Datron calibrators) but I certainly don't have a wide range, so this is somewhere I could do with some help, specifically with more complex devices, subaddressing, binary data transfers etc.Next things I'm planning on looking at:- Finish off command set- Hardware acceleration of handshake / DMA data transfer- Bootloader support to allow firmware upgrade over USB- Design of a new board to fit into a sheilded connector (potential)- USBTMC and Composite USBIf there's any interest, I'll stick the code and KiCad files into GitHub ... if not, that's fine also!Lee.

author: sokoloff
author_rank: Super Contributor
timestamp: October 18, 2019, 01:53:02 pm
content: Very nice; there’s definitely going to be interest here!

author: Black Phoenix
author_rank: Super Contributor
timestamp: October 18, 2019, 02:44:47 pm
content: One more here interested.

author: Magnificent Bastard
author_rank: Regular Contributor
timestamp: October 18, 2019, 05:27:19 pm
content: I'm interested also-- please do post on GitHub, as there are many more people that will no doubt be interested!

author: essele
author_rank: Frequent Contributor
timestamp: October 18, 2019, 05:41:27 pm
content: Great - I’ll try to get it all uploaded tomorrow!

author: JBeale
author_rank: Frequent Contributor
timestamp: October 18, 2019, 07:34:28 pm
content: Looks like a very reasonable design. I think the people who would be using this kind of DIY interface board probably don't have a big rack of GPIB devices to control. Given the cost of just one genuine GPIB cable, you might as well use one board per instrument, instead of using more GPIB cables.

author: Bicurico
author_rank: Super Contributor
timestamp: October 18, 2019, 07:39:21 pm
content: Hi.I am definitely interested.One important aspect for me is the transfer speed.The chinese cloned Agilent USB GPIB adapters achieve quite high transfer rates.Being able to build something similar speed-wise would be great.The other aspect is of course how to communicate through this adapter. Would it simulate a RS232 or RJ45 port?Regards,Vitor

author: ebclr
author_rank: Super Contributor
timestamp: October 18, 2019, 07:59:10 pm
content: Another interested, with PSoC, will be even better

author: artag
author_rank: Super Contributor
timestamp: October 18, 2019, 09:04:05 pm
content: Quote from: Bicurico on October 18, 2019, 07:39:21 pmWhat would you test speed against ?I did some measurements on the AR488 adapter described elsewhere and was getting about 44us per handshake. This is very misleading though - it was reading the *idn response from an HP53131A and the HP is limiting the speed before the AVR bitbanger does. And then there's all the overhead of setting up the transfer (addressing) and sending the data back to the host.So the overall speed of the transaction will work out way slower than this 22k/s, but the actual micro is capable of going faster against a faster instrument. It really needs to be measured against something doing much longer transfers without the instrument limiting it. I'm unlikely to get to the sub microsecond times that full bus IEEE-488.2 speed would permit but I can probably improve on what I'm seeing now. Maybe 100k ?I don't think I've got anything suitable : the instruments I have with display screens that might do a big screen dump have ethernet and USB, not GPIB. Can you suggest a test subject ?

author: pigrew
author_rank: Frequent Contributor
timestamp: October 18, 2019, 09:39:02 pm
content: Very nice, I like it.I recently implemented USBTMC/USB488 as part of the "tinyusb" stack (which I've been using with the STM32), though it isn't at all optimized for speed. USBTMC is complicated if one wants to fully meet the specification (the reset/clear/abort states are tricky).The USBTMC spec describes communication with only a single device. However, it does leave the opportunity open for vendor messages which could be used to change the address on the bus. Parallel poll may also need a special vendor command. On the other hand, the whole adapter might be cheap enough (< US$20) that it would be reasonable to give each device its own adapter (reducing the need for special commands). Though for properly implement triggering, one really does want all the devices connected on the same bus.I'd be happy to look over a proposed interface on how to map USB488 to be a GPIB controller, or write up a draft if you're interested.(And as a sidenote, I had been considering developing an adapter along the same lines, except using a STM32 and with the SN75ALS161/SN75ALS162 driver ICs.)Quote from: artag on October 18, 2019, 09:04:05 pm12 Mbps (full speed) USB sends packets every millisecond. One shouldn't expect full-speed USB to have a latency any better than this. High speed (480 Mbps) USB can have latencies of 125us (micro-frame), or maybe 1us for interrupt tranfers. One should be able to get bulk transfers up to maybe 5 Mbps over full speed USB. So, maybe this is the direction future development... to implement a high-speed USBTMC based adapter. (Or maybe you're only counting the timing of talking to the device, not the extra latency due to USB... anyway, it's something to think about)

author: Theboel
author_rank: Frequent Contributor
timestamp: October 18, 2019, 11:29:54 pm
content: Interested

author: james_s
author_rank: Super Contributor
timestamp: October 18, 2019, 11:43:25 pm
content: Looks nice and clean. Personally I would have used a standard USB type B rather than the fragile mini or micro given how big and chunky GPIB stuff is. Also if the connectors are on the other side of the PCB it would probably be easier to put it in an enclosure. I suppose in a pinch some big heatshrink tubing would probably sufficiently protect it though.

author: maginnovision
author_rank: Super Contributor
timestamp: October 19, 2019, 01:12:53 am
content: I'd probably modify to use through hole for USB and solder a cable. Looks good though.

author: chickenHeadKnob
author_rank: Super Contributor
timestamp: October 19, 2019, 03:04:57 am
content: To esseleWhat is the part number of the right angle gpib connector you are using and does the hole pattern align to a 0.1 inch grid, that is match a perf board? I ask because the NorComp connectors I was looking at don't align. thanks.I was hoping to avoid buying an extra solder cup connector just for prototyping .

author: essele
author_rank: Frequent Contributor
timestamp: October 19, 2019, 06:13:28 am
content: So the connector is a NorComp one I'm afraid, so you are correct the pins are not on a 0.1" pitch.Also, for note, the symbol and footprint you can get from Mouser is wrong ... firstly the pin numbering is incorrect, and when corrected (based on pin 1) it's then back to front.The first problem is the reason I have v1.1 of the board, and the second problem is the reason the connector is on the back -- I seem to not be learning from my schoolboy errors! ;-)I've also grabbed a few connectors from eBay, which are a little cheaper (but same pitch):https://www.ebay.co.uk/itm/Centronics-Plugs-Sockets-PCB-PCB-R-Angle-and-Ribbon-Cable-Mount-14-50-Way-EB/391507935311?ssPageName=STRK%3AMEBIDX%3AIT&var=660671677953&_trksid=p2057872.m2749.l2649... and I'm just waiting for some from Aliexpress, which are a great price if they are ok:https://www.aliexpress.com/item/32795413098.html?spm=a2g0s.9042311.0.0.5f974c4dp84EeUOn the USB connector ... this was originally just an experiment, the longer term plan was/is to build this into one of those shielded connectors with the usb cable soldered on. I'm waiting for some of those to arrive to see if it will all fit.The timing questions are interesting ... I'm going to connect up a scope later and see if I can get a good view of timing, as with @artag I suspect I will also be limited by the device I'm using at the moment.EDIT: I'm seeing good bursts of about 23uS per handshake during either *IDN? or READ?, although some bytes are much slower than that ... all of which I think is the device. It manages around 12uS per handshake for the four bytes sent to change talker/listener. All of this is with a 2uS settle time. If I get a chance later today I'll try some other devices, this was a 34401A.

author: artag
author_rank: Super Contributor
timestamp: October 19, 2019, 09:12:33 am
content: I've had (male, straight and RA) GPIB connectors from that ebay vendor and am very happy with them. Not sure who the manufacturers are - there's no logo on them - and they have a screw thread in the lugs (unlike the Norcomp ones I can see at Digikey).They have the usual pitch, not 0.1". However, my first prototype used a right angle connector (which therefore has quite long pins) and I cut away part of the plastic bracket to free the pins up. They could then be pulled far enough apart to fit perf board.I've also got a few spare pcbs from my first revision of the board : it was designed to be easy to track rather than efficient in operation and I'm happier with the second version. But those will work perfectly to adapt the microribbon pinout to a 24 pin DIP.

author: essele
author_rank: Frequent Contributor
timestamp: October 19, 2019, 09:21:21 am
content: Just soldered some test wires on and looked at the whole handshake ... it was taking about 6us to do the handshake (for receiving), but with a few inlines that's now about 4us ... but it is indeed the 34401A that's adding all of the delays, there's about 19us from NDAC/NRFD to the next DAV, although sometimes more than double that.Ignoring device added delays and if you assume 2us for data settling (I'm not looking at the data lines), then this would be approximately an 8us best case, so theoretically about 120kbytes/s with bit banging. (Notwithstanding getting that data over USB.)I've just tried a Keithley 220 ... it's nice that it just worked! However the best case byte I see there is about 180us, again with some much slower, in response to just about anything (haven't read the programming details, it always seems to return the same stuff.)

author: artag
author_rank: Super Contributor
timestamp: October 19, 2019, 09:51:31 am
content: That ties up nicely with what I saw on the AVR - of the 44us, about half was waiting for the response. The AVR code is written for clarity rather than speed which also makes it nicely adaptable for different pinouts, but I would think it could be brought closer to your 6us.I'm interested in trying this on a Cypress FX2 - it's what the HP (and clone) interfaces use, albeit with extra hardware. The FX2 has its own handshake assist logic but I don't know if it's sufficient to do the GPIB handshake yet.However, shaving a few more us off the handshake has limited returns if the typical instrument is fairly slow. It's only worth doing (other than for the satisfaction!) if there's some common device that has a lot of data to transfer and the hardware to do it fast. I would think some NI ADC would do - they did after all develop the short-cut handshake in IEEE488.2 and claim up to 4Mbytes/s, I think - but unfortunately high speed NI ADCs are likely to be rare, expensive, and completely obsoleted by modern SDR hardware that takes advantage of USB3 speeds. A scope is perhaps the most likely candidate - common enough to be in use by amateurs and, up to 2000 or so, still likely to have a GPIB interface.

author: Fraser
author_rank: Super Contributor
timestamp: October 19, 2019, 10:10:23 am
content: I needed a USB to GPIB adapter a few years ago. There was very little choice at the time and I managed to buy a used ICS clone of the official NI unit. It is not a 100% compatible clone though.I looked at the Prologic unit but, at the time, it was not compatible with the software I was using.I am pleased to see this excellent project as I feared that GPIB had been effectively abandoned in recent years. Great workFraser

author: Bicurico
author_rank: Super Contributor
timestamp: October 19, 2019, 11:15:14 am
content: Quote from: artag on October 18, 2019, 09:04:05 pmSorry, I forgot to explain my "needs"!I use the GPIB interface to connect to older spectrum analyzer like the HP8594E or R&S CMU200/CRTU (technically not a spectrum analyzer, but offers this mode). What I do is to capture the trace, which is normally composed of around 500 samples. These are sent in plain text and this means a few kb per sweep.It would be nice if the GPIB interface would not be the bottleneck in this transmission, so that my software can render the spectrum as fast as possible.Take a look at my blog for further information:https://vma-satellite.blogspot.com/Regards,Vitor

author: artag
author_rank: Super Contributor
timestamp: October 19, 2019, 11:22:33 am
content: Thanks, Vitor.What interface are you using at present, and what speed does it achieve ?

author: dietert1
author_rank: Super Contributor
timestamp: October 19, 2019, 12:05:00 pm
content: GPIB is dead because it is so awfully slow, except for reading old DVMs and frequency counters. If you ever downloaded a DSO screen dump via GPIB you know what i mean. I think these yaugi projects are for somebody interested in learning details of this legacy data bus. Implementing it on a professional level including some API including reasonable exception handling is more than a man year. Also i remember that it needs to be largely configurable to work with all/many different devices, not just the ones you happen to use for test. One needs a logic analyzer and a HP 59401A or NI Measurement & Automation Explorer.If you have an application where you can't avoid using GPIB, keep away from the troubles of a partial implementation, but get one of those used HP USB adapters or a NI GPIB-ENET. My personal opinion.Regards, Dieter

author: essele
author_rank: Frequent Contributor
timestamp: October 19, 2019, 01:33:34 pm
content: Ok, I've done a bit of a bulk upload without a lot of sanity checking so it will need cleaning up over time, but I'll start working off of this version now...https://github.com/essele/yaugiIt is very much work-in-progress and not very tidy ... and you will need a PSoC Programmer if you want to use this (I'm using the MiniProg3, but there are a few choices if you want to make a cable up or change the header on the board.)The current approach is focused on interactivity, so you get some extra debug and there is some processing on the GPIB data so it's not suitable for binary data as it stands. I'll make the interactive bit a config option soon which should get it into a position where it could pass binary data ok.I'm slowly working my way through the ++ command set, just added eot_enable and eot_char ... lots still to do.

author: Bicurico
author_rank: Super Contributor
timestamp: October 19, 2019, 02:48:36 pm
content: Quote from: artag on October 19, 2019, 11:22:33 amI am using an Agilent 82357B USB-GPIB Interface.They cost around 70 Euro + Tax from Chinese sellers.Some say they are cloned, other says they are refurbished.Mine came in a sealed box with Agilent CD-ROM containing Connection Expert and certificates. The device looked as new, but might have been used before.My guess is that they are refurbished.Anyway, the speed is around 1.15MB/sec.Regards,Vitor

author: pigrew
author_rank: Frequent Contributor
timestamp: October 19, 2019, 04:43:55 pm
content: Quote from: pigrew on October 18, 2019, 09:39:02 pmReplying to myself after reading a bit more, I'm thinking that implementing multiple-device USBTMC is not a good idea. The reason to use USBTMC is so that the adapter can be used with VISA without needing to write any extra host drivers.The USBTMC spec doesn't provide a way to support multiple devices. USB does support having composite interfaces, but most microcontrollers limit the number of USB endpoints to around 8, which would only support one or two USBTMC interfaces per USB device. "advanced" GPIB features such as parallel poll, SRQ, GET, multiple-device commands, secondary controller, etc. would need to be avoided.There iswork on extending pyvisa to support Prologix interfaces, but this is only for pyvisa, and not NI or Keysight VISA.The feasible ways to make an open-source VISA-compatible GPIB adapter without needing to write any host-side driver code, seem to be (1) Reuse an existing adapter USB interface, like that of the NI or Keithley USB adapters, (2) use USBTMC with a single connected instrument, or (3) Use Ethernet, having an array of ports (one for each instrument), exposed as VXI-11 devices or repurposing the interface of an existing gateway.

author: artag
author_rank: Super Contributor
timestamp: October 19, 2019, 04:57:51 pm
content: Quote from: dietert1 on October 19, 2019, 12:05:00 pmFor new designs it may well be dead. USB, Ethernet, or VXi are likely to be interfaces of choice for a modern system design, and in any case a system costing thousands of dollars can easily afford the best existing commercially available interfaces. There is no economic valuie in rolling your own.However, although many of the people in this community are professional engineers we fill our home and self-employment labs with excellent secondhand equipment, often far superior to cheap modern replacements yet bought at bargain prices. This, to me, is the use-case for cheap home-made GPIB interfaces - allowing us to use that equipment to build more complex systems and acquire the data off them to process using cheap computing power.Quote from: dietert1 on October 19, 2019, 12:05:00 pmI agree with the educational aspect. But I disagree that it's otherwise useless. The vast majority of those instruments are slow, low data throughput and are entirely usable. A 6.5 digit DVM probably isn't going to read any faster than a tiny bitbanged interface can transfer data. There may well be some cases where it's a handicap but they can be considered on their merits. They don't need a blanket condemnation.I have a selection of HP logic analysers and an HP59401A. The 59401A is charming (reminds me of a 70's era minicomputer) but I think the most useful thing for GPIB debugging is probably a $5 Cypress FX2 board and Sigrok's protocol decoder. Perhaps add a scope for noise margin measurement and some adjustable bus loading (the 59401A documentation even encourages you to build your own bus loads).Quote from: dietert1 on October 19, 2019, 12:05:00 pmThe chinese clones/refurbs are worth considering if you want convenient compatability with existing host software, and I'm all for buying (and perhaps fixing) used equipment. But I don't think the prices on many of the more useful interfaces (like the ethernet ones) are worth paying. Bear in mind that NI in particular offers poor support for its hardware - the linux drivers are out of date and the NI programming environment ridiculously proprietary. They've failed to keep up to date with modern OSS thinking and are stuck in a windows-only timewarp. I do have a couple of NI interfaces but I can't see an advantage in using them.

author: james_s
author_rank: Super Contributor
timestamp: October 19, 2019, 04:59:22 pm
content: Quote from: dietert1 on October 19, 2019, 12:05:00 pmGPIB is alive and well, hence the proliferation of hobby interfaces for it. There is tons of old gear out there that lacks anything better, I've mostly used the interface I built to unlock options on older Tek scopes.I suppose from the perspective of modern gear in professional settings there is little need for GPIB anymore but that doesn't mean it's dead, rather it has achieved legacy status.

author: artag
author_rank: Super Contributor
timestamp: October 19, 2019, 05:03:35 pm
content: Quote from: pigrew on October 19, 2019, 04:43:55 pmAgreed. And a convenient way to make a multi-device ethernet adapter is to have a system controller (perhaps a raspberry pi or x86 SBC) that provides a clean network interface to the programmer and connects with USB or legacy (ISA or PCI) bus devices to the actual instruments.

author: dietert1
author_rank: Super Contributor
timestamp: October 19, 2019, 10:07:29 pm
content: A quick look at ebay showed several GPIB ENET devices at 50 to 130 bucks.Another reason why GPIB is dead: It does not use differential signals like USB and Ethernet. So it generates a lot more noise.Of course GPIB will exist some more time, similar to RCA connectors on high end audio equipment, that should be all digital nowadays. Last saturday a neighbour came by with a Technics receiver he had bought at the local flee market for 5 € and asked if i can fix that in case it doesn't work. I haven't been listening to analog transmissions for years, except in the car.Regards, Dieter

author: james_s
author_rank: Super Contributor
timestamp: October 19, 2019, 11:27:12 pm
content: Ironically in the US digital radio is essentially dead, it has managed to gain some foothold in cars but the majority of radio here is analog and most of the companies that were making non-car digital receivers have stopped. It was a silly proprietary system that never should have been allowed in the first place, a solution in search of a problem, it usually sounds like crap because they crank up the compression to fit more channels.

author: pigrew
author_rank: Frequent Contributor
timestamp: October 20, 2019, 01:22:00 am
content: Quote from: artag on October 19, 2019, 05:03:35 pmOne could bit-bang from a SBC, but I think it would take a FPGA or MCU to do things efficiently. For the protocol, I've been reading about VXI-11.2, VXI-11.3 and HiSLIP.However, I should bring the conversation back to the yaugi. I had the idea to write a VXI-11.2 server (in something portable like C or python), that would interface with the USB->GPIB adapter using the prologix protocol over USBCDC. This should be portable to most VISA implementations (and even handle the escaping of binary data). Or maybe HiSLIP would be a better protocol choice than VXI-11.2. Security would be easier as the server would only need to listen to localhost.

author: tkamiya
author_rank: Super Contributor
timestamp: October 20, 2019, 02:36:29 am
content: My understanding is that GPIB protocol itself is standardized but not how hosts communicate with it. No standard API exists for example. That means the application software or a custom made driver for that device in conjunction with custom application has to talk to it.So what happens to application for custom made DIY device like these? Are you limited to making your own applications, or can you use it with existing lab software of some type? I'm very much interesting in making it and that's why I'm asking.

author: maxwell3e10
author_rank: Frequent Contributor
timestamp: October 20, 2019, 02:38:23 am
content: essele,What is the current consumption of your adapter when running? I looked briefly at the chip specs, it should be only a few mA for the chip? This would be easy to get by stealing power from GPIB lines with diodes and a DC-DC boost converter.For testing GPIB speed I was playing with a PTS frequency synthesizer. It has a simple gate-based listen-only GPIB adapter and should be quite fast.

author: pigrew
author_rank: Frequent Contributor
timestamp: October 20, 2019, 03:53:02 am
content: Quote from: tkamiya on October 20, 2019, 02:36:29 amThere are two different interfaces involved. The first is the command language used by the instrument (often SCPI). This is unique to each instrument used, though sometimes abstracted with an Ivi driver interface which translates generic commands to the instrument-specific command.The other layer is the method of sending the commands to the instrument (like GPIB). Most commercial interfaces provide a VISA DLL which lets commands be sent using a standardized interface. VISA can be configured to use alternate transports like USB, serial, or TCP/IP. This project tunnels GPIB commands through a USB serial port (USBCDC) using a protocol created by Prologix for their commercial adapters. Note that there are no drivers written that let your end user software use standard VISA interfaces to perform IO through the prologix transport, so it isn't yet a drop-in replacement for a standard GPIB adapter. A translation layer (HiSlip server) to make it compatible with software that uses the standard VISA API could somewhat easily be written.

author: dietert1
author_rank: Super Contributor
timestamp: October 20, 2019, 07:34:48 am
content: Quote from: james_s on October 19, 2019, 11:27:12 pmWe are using a digital TV satellite that yields all audio channels which used to be radio in the past or CD/DVD media.By the way, some ten years ago we also made a USB-GPIB adapter, based on a XILINX CPLD and a FT245. It has a real bus interface and supports all the special GPIB functions. It achieves several MBytes per second when used as a pair to transfer data from one workstation to another. We made a C++ library with a high level API. So i know we can run independent of Microsoft and independent of NI, that was the main motivation behind it. But i also know our solution is still not mature. E,g, due to its near real time requirements it is not exactly "nice" to other processes on the machine.Smaller projects like this one here may be useful to abandon GPIB in the sense of the bus being replaced by a USB hub, with a separate 10 $ USB converter on each GPIB device.Regards, Dieter

author: essele
author_rank: Frequent Contributor
timestamp: October 20, 2019, 09:33:08 am
content: Quote from: maxwell3e10 on October 20, 2019, 02:38:23 amIt's currently using about 30mA ... but that includes a couple of unnecessary LEDs and absolutely no power optimisation.I did consider trying to power from the GPIB interface, but if the device is using 3K pull-ups as per the spec, then you're not going to be able to get much, even from all 16 lines. I had ruled that out in favour of PoE for an ethernet based device.

author: essele
author_rank: Frequent Contributor
timestamp: October 20, 2019, 09:47:08 am
content: I've just started looking at USBTMC ... it actually appears pretty straightforward for basic use (although as pigrew pointed out there are quite a lot of exception situations if you want to do it properly.)So the device is detected fine in Linux and OSX and I can get a request to it ... I haven't done anything with responses yet.In Windows it's picked up as a USB Test and Measurement device but it's then not showing up in any of the tools (I've been using "NI-VISA interactive control".)The behaviour changed when I added the serial number string to the config, it's now stuck saying "device setup in progress" in the control panel which it wasn't doing before, so I'm pretty sure it's something fairly minor with the config that I've missed.I'm comparing with a 34470a which works fine.Looking at a Wireshark USB trace everything appears to be identical, loads of descriptors gathering ... then the 34401a seems to respond to a URB_CONTROL_In message, where my device doesn't ... there there is a SET_DESCRIPTOR and a set of string queries on the 34401a where I'm just stuck.I am seeing a load of "URB_Interrupt In" messages on my device, so I may try without the interrupt endpoint as a test.EDIT: I was missing a SetPowerStatus() call, this seems to have cleared up the "device setup in progress" problem, so it all looks ok in Windows now, but still doesn't show up in NI-VISA. The device properties look identical, as do all of the events relating to the device, but still the same kind of traces. The interrupt messages are from a difference source, so not relevant here.EDIT2: If I try to open the device directly in NI-VISA using the "USB::0x....::0x....::MY12345678::INSTR" address I get an "unknown system error", if I change the serial number to something incorrect, then I get a "device not in the system" error. So despite not finding it in a scan, it knows it's there!EDIT3: Ok ... think I've figured it out ... the URB_CONTROL message seems to be a USBTMC specific message to EP0 which I need to trap and handle. Maybe next time I'll read the spec first ;-)EDIT4: Yep ... now working ... gets to the same place as with Linux and OSX, it was the USBTMC GET_CAPABILITIES request. Onwards and upwards!

author: pigrew
author_rank: Frequent Contributor
timestamp: October 20, 2019, 03:33:09 pm
content: For USBTMC, here are some other quirks I found:If you declare supporting 488.2, NI MAX will always send a *IDN?. If the IDN takes too long, it'll send a device clear. Issues will crop up if you don't implement device clear.CONTROL OUT transfers often don't go through in NI VISA on Windows (gives an error or data is corrupted).custom CONTROL IN transfers seem to work. I'd suggest implementing special features like address switching, etc, with INTERFACE CONTROL IN transfers, though you only have a few bytes to use for parameters (wValue). VISA has API functions to perform control transfers.Transfers in USBTMC are all half-duplex. You don't need to support having a bulk in active during a bulk out.You may want to override the behavior of the CLEAR_FEATURE EP on the bulk endpoints, but it isn't completely necessary.There's a special control transfer to request that a LED be blinked. NI MAX sends it when you connect, if you declare you support it.USB488 support requires that the interrupt endpoint be implemented.You want to implement USB488 so that you can READ_STATUS_BYTEPoll the SRQ line using a control IN transfer?The Prologix interface doesn't have any abort commands. Reads only stop at timeout or EOI from the instrument. So, there may need to be some code divergence between USBTMC and prologix here.

author: essele
author_rank: Frequent Contributor
timestamp: October 20, 2019, 06:26:07 pm
content: Thanks pigrew ... I don't think I'm quite at the stage where I need to worry about some of those yet.I've just got a proper request/reply setup working and can do basic queries with NI-VISA interactive control. I've got quite a few class requests to still implement, and I need to refactor a chunk of the older code to work better with the way the usb api works on PSoC ... which is actually a good thing since it's needed to get to a good place for higher speed binary transfers and will hopefully save a bit of memory.Is there a reason why you wouldn't just send the ++ commands and interpret them as normal? That way you don't need to setup anything special??

author: pigrew
author_rank: Frequent Contributor
timestamp: October 20, 2019, 06:48:16 pm
content: Quote from: essele on October 20, 2019, 06:26:07 pmThe reason would be compatibility with software that was written for other GPIB adapters (since they don't use the ++ syntax). It'd be nice if I can use the same pyvisa script to talk to instruments, independent of which adapter is being used.Unless the plan is to write a gateway server (perhaps using HiSlip) which would translate VISA queries to Prologix commands? In that case, it might be a good idea to keep the ++ syntax. I'm actually leaning towards this solution, but it also means that that there is less of a reason to use USBTMC instead of USBCDC.

author: essele
author_rank: Frequent Contributor
timestamp: October 20, 2019, 07:27:52 pm
content: I’m not sure I really follow ... there’s only really a problem if you are trying to connect to multiple devices via a single interface, otherwise it’s just config commands (which would persist via the EEPROM) ... and if you are trying to connect to multiple devices then you are deviating from USBTMC anyway and therefore you would have to be doing something different, ++ commands just seem a really easy way to do it.Actually you could probably present two USBTMC instances via a composite device, or up to four if you ditch the interrupt endpoints - that may be a better option for multi-device use.Anyway - I’ll focus on getting everything cleaned up first, we can worry about these details later.

author: niner_007
author_rank: Frequent Contributor
timestamp: October 22, 2019, 03:42:47 am
content: Quote from: essele on October 19, 2019, 06:13:28 amI though the same thing, but then I double checked, the pin numbering is correct, but it's from the front, not from the back:https://www.norcomp.net/rohspdfs/SCSI-050Ribbon/11Y/112/112-YYY-113R001.pdf

author: JohnG
author_rank: Frequent Contributor
timestamp: October 22, 2019, 02:22:29 pm
content: GPIB is not dead even in some professional environments.There are a number of reasons for this:Not all companies can justify buying new equipment for everything. Furthermore, some used equipment is commonly available, so spares are no problem. Maybe in 10 years...?New equipment is not bug-free, and worse, its bugs are not well documented on the web. Even equipment from Tier I vendors is not immune.USB does not have high noise immunity, especially if you have to use hubs. If you are working on switch mode power supplies, do yourself a favor and go buy yourself a great big bag of ferrite clamps up front. Also, expect to switch out hubs until you find one you trust. Ethernet is much better in this regard, since many routers have transformers.Finally, if you have a flexible test system where you are moving equipment around, USB is terrible. It can pull right out, or worse, just a little bit out. Ethernet is better unless the little tabs break off. GPIB doesn't have that issue, although the cables are cumbersome.John

author: pigrew
author_rank: Frequent Contributor
timestamp: October 22, 2019, 05:23:01 pm
content: I started implementing a HiSLIP gateway for Prologix (in Python using asyncio, even though I don't have any Prologix adapters...), but am now stuck. The HiSLIP protocol doesn't have an interface to request a read; it expects the device to immediately "push" responses. There appears to be no way for the gateway to know that it needs to address the GPIB device to talk. VXI 11.2 seems to be the appropriate solution to present a GPIB interface to VISA without writing an actual VISA implementation.Anyone interested in a partial implementation of a HiSLIP server in Python? I'm not sure if I should post it on github or not, since I'm abandoning the code. I've implemented connections and dispatching write & readSTB() requests to a worker thread (to synchronize them)

author: macboy
author_rank: Super Contributor
timestamp: October 23, 2019, 04:30:51 pm
content: Quote from: dietert1 on October 20, 2019, 07:34:48 amI agree. Writing software to efficiently andasynchronouslytalk to multiple devices sharing a single GPIB bus is a real pain. It is much easier to have one GPIB bus per device, and just communicate synchronously (i.e. allow a "READ" command to block the bus until the data is ready, etc.). Not only is the software much simpler, but you also avoid other troubles with multiple instruments on a bus... the slowdowns due to capacitance of the many cables, problems caused by too many powered-off instruments, etc.. Then there are the GPIB cables: thick and bulky, hard to route, hard do disconnect (held on with screws), and always expensive if you even can find them. One GPIB adapter per GPIB instrument is best, and the only practical way to do this is with these small, cheap yaugi orAR488type devices which plug directly into the instrument GPIB connector.

author: essele
author_rank: Frequent Contributor
timestamp: October 24, 2019, 07:23:53 am
content: One per device was certainly my original plan -- and the more time I spend working on the USBTMC stuff, the more it makes sense.My shielded connectors have arrived -- it's going to be fairly tight, but I think I should be able to get a board into the shield with a little creativity about how the connector is attached.dfb5b078460261d8d55a7988d6d14230 .gif(19.36 kB - downloaded 189 times.)I'm hoping to finish the first cut of USBTMC and USB488 at the weekend ... implementing this has been great, it's really helped to clean up the approach since there is a lot less 'interference' with the data, so I'll need to retrofit to the UART side of things.

author: essele
author_rank: Frequent Contributor
timestamp: October 27, 2019, 03:00:09 pm
content: I've put quite a few updates on GitHub now ... short summary:1. You can now select from USBUART, USBTMC, or a composite device on the TopDesign (composite is not implemented yet)2. USBTMC is done enough to test with NI-Interactive.3. Serial is tidied quite a bit, should be good for binary now.4. ++interact [0|1] added to switch between interactive mode and non-interactive modeI'm still working on USB488, and a number of GPIB features (like serial poll), but I think there's enough here now to test for both UART and TMC modes and it seems to work ok with Windows, Linux, and OSX.I'v also just designed and ordered a small board 33mm x ~14mm that should fit into the shielded connector ... on slow delivery though, since I want to get a few other things done first.

author: pigrew
author_rank: Frequent Contributor
timestamp: November 06, 2019, 01:36:06 am
content: I've made some progress on writing a Python/asyncio VXI-11 server, which I had mentioned above.My code likely will only run on Windows, since it's implementing its own portmapper (instead of using the system's). I'm able to connect to it and execute read/write commands using both KeySight and NI IO libraries. The server is written to be single-threaded which makes the design easier to analyze (it does support multiple simultaneous connections and links). I have not implemented either a USBTMC or prologix adapter, but this is the logical next step.Of note is that the KeySight IO libraries have a VXI-11.2 client (support for GPIB operations/commands on the bus) while it seems that NI does not. The KeySight libraries "prefer" to connect to (and lock) the entire bus, exposing it as a GPIB bus to VISA (so you use resources like GPIB1::5::INSTR). Internally, it's creating a single link, and sending raw 488 commands like ATN or REN to talk to the instruments.On the other hand, NI IO libraries may connect to the VXI resources over multiple links "gpib0,#" (# is primary address), and relies on the server to arbitrate the various link's access to the bus. "aborting" is seemingly not implemented. This mode seems more portable, and is what I'd normally want to use.Seemy source code at GitHub. (This is my first non-trivial python project.... I'm figuring out coding styles as I go....)PS: If this is too irrelevant to the adapter designed here, let me know and I'll create a new thread. I'm hoping to the server to a state where it could be used with the YAUGI and related hardware.

author: essele
author_rank: Frequent Contributor
timestamp: November 06, 2019, 08:46:11 am
content: Hi Pigrew -- this sounds very interesting, although I would have thought getting it to work with Linux would be useful then it opens up the option to use a Pi etc. If it's a dedicated system then you could just kill the normal portmapper as a starting point!I've got most of the bits now to build a few devices to ship to people to hopefully help with some testing ... I just need to sort the bootloader side of things to remove the need for the PSoC programmer -- that's the plan for this weekend.So if you'd like a device to help with this then I should be able to ship you one soon.

author: essele
author_rank: Frequent Contributor
timestamp: November 09, 2019, 02:29:38 pm
content: Ok, first attempt at the Yaugi that fits in the shielded connector...... all was looking good, power was fine, programming was fine, but the UART wasn't recognised .. turns out the bloody Amazon USB cable I had butchered used the opposite colour coding from the reference I had found, and then I pulled a pad off the board trying to fix it.My intention of using a cable tie as strain relief doesn't look like it will work as the head of the cable tie is too big and gets in the way of the plastic strain relief that's in the connector ... for this version I just got creative with a few bits of heat-shrink sleeving, which was ok, but it may need a bit more.It's really fiddly to put together, but I think it's going to be great ... will have a go at number two tomorrow ... although I might use a thinner USB cable, the Amazon one is a bit chunky, seems to be more general purpose and has other conductors in.

author: essele
author_rank: Frequent Contributor
timestamp: November 10, 2019, 02:05:23 pm
content: Ok ... a new day, a new cable ... a working device!I used some self-amalgamating tape to get some strain relief, seems to work really well.The bootloader is also done and working, so now you can update the firmware without needing a Cypress programmer.I've run out of PSoC's (I'm also using them on a USB BME280 based temp/humidy/pressure sensor) as I've got three on the go in prototypes. I've ordered a batch of ten which should allow me to build out the adapters I need, plus a couple that I can ship for help with testing.I'll get the GitHub updated with the new PCB and the bootloader stuff over the next few days.

author: trobbins
author_rank: Frequent Contributor
timestamp: November 14, 2019, 12:33:32 am
content: Adding some vias and backside pads in or around the usb cabling pads may make resoldering to the pads a bit more robust. You'd have to move the pcb text.

author: essele
author_rank: Frequent Contributor
timestamp: November 22, 2019, 12:18:06 pm
content: I think I've settled on this approach ...It solves the cable attachment problem, uses a through hole usb connector (which is also clamped in by the connector strain relief clamp), and overall is a lot less fiddly to put together ... takes about 30mins or so. Plus you now have your choice of cables/lengths to use.I do need to respin it once more as the pcb width going through the cable outlet was slightly too wide, not helped by the round rather than oval holes on the usb connector footprint, so it needed a little filing.So ... cost breakdown:PCBJLCPCB£ 1.70MCUCY8C4246AZI-L433£ 5.90Programming Header2x5 1.27mm AliExpress£ 0.07GPIB Connector(Aliexpress)£ 1.96USB Connector651005136521£ 1.00FuseMF-MSMF050-2£ 0.42DiodeMBR0520L£ 0.18Caps (3)2x1uF, 1x0.1uF£ 0.06I've allowed £1 for the USB connector, I'm using ones that came in a AliExpress "selection" which clearly will be much less than this, the footprint I've used is the 651005136521, but you don't seem to be able to buy that anywhere that I can find.The PCB's cost a total of £8.50 for a batch of 5 the vast majority of which is shipping costs, so £1.70 each -- clearly this reduces if you order more. If you only want one, then clearly you're going to have to pay for a batch.All costs are either what I paid or current Farnell or Mouser costs and include UK VAT, I didn't particularly look for cheap fuses or diodes, I just used the ones that were used in one of the dev boards.So that's a grand total of £11.29 ... so not quite under £10, but not far off ... and a far cry from anything else you could buy (and a lot more compact!)

author: maginnovision
author_rank: Super Contributor
timestamp: November 23, 2019, 03:12:00 am
content: Looks good.

author: niner_007
author_rank: Frequent Contributor
timestamp: November 23, 2019, 04:48:57 am
content: I’m not a big fan of the enclosure

author: Bud
author_rank: Super Contributor
timestamp: November 23, 2019, 05:03:42 am
content: Quote from: dietert1 on October 19, 2019, 12:05:00 pmLast year i attended a Keysight seminar where they had latest greatest gear that still had GPIB. I asked if Keysight is going to sunset GPIB. "Hell NO!" was the answer.

author: maginnovision
author_rank: Super Contributor
timestamp: November 23, 2019, 08:40:05 am
content: Quote from: niner_007 on November 23, 2019, 04:48:57 amI think you can make a few nice changes(preferably different enclosure and hardwired cable) by just putting in some extra cash. If you wanted a cheap barebones way to do usb-gpib this will work though.

author: essele
author_rank: Frequent Contributor
timestamp: November 23, 2019, 09:32:33 am
content: Quote from: niner_007 on November 23, 2019, 04:48:57 amQuote from: maginnovision on November 23, 2019, 08:40:05 amWow ... tough crowd!I'm not particularly mad on the enclosure either, but 24-Way Centronics connectors don't seem to be that popular any more so there's not a great choice, and I don't have a 3D printer (yet) to do something myself. If anyone can find something better, I'm quite happy to rework the board as needed.Also ... these are going to be tucked away at the back of an instrument ... is it that important?I do get that a hardwired cable is an option some people might prefer (I thought I was in that camp, but I think I've changed my mind) so both are options, in fact the original board with right angled PCB mount connector is also still an option, all three are fundamentally the same and use the same firmware. I have some of the hardwired cable PCB's if anyone wants one at cost (plus shipping), and I've got a batch of the new ones coming. (PM me if interested.)Also, I'll put all board details on the GitHub once I've made sure the new one is correct.As a side note .. I was reworking my USB code for an environmental sensor module yesterday and discovered that you can configure multiple "devices" in the USB config in the PSoC and then switch at runtime, so I'll add a config option to switch between UART and TMC, that's much nicer than having to have different firmware. Also looking at programatically returning the device and manufacturer strings, so you should be able to set them in the config and make it easier to figure out which device is which if you have a few.

author: maginnovision
author_rank: Super Contributor
timestamp: November 23, 2019, 06:34:21 pm
content: For me the hardwired cable is mostly about strain. It's a little awkward to be hanging a cable from that, also the extra distance it'd stick out. That could be fixed with a right angle USB cable though. I actually don't have a better enclosure in mind so I'd probably end up measuring to see what works, design it, and send it out to be made. I actually think it's good to have the "budget" version though. Honestly, if you have firmware that's open source and ready to go people can work around that however they'd like. The design you're doing could be the reference design.

author: essele
author_rank: Frequent Contributor
timestamp: November 23, 2019, 06:51:12 pm
content: Yes, fair points.I'm not sure the extra distance is too much of an issue, once you take into account the bend radius of the power lead, it's not really adding anything to the overall depth.(Assuming you're not using right angled power leads of course ... which bizarrely I am!)

author: artag
author_rank: Super Contributor
timestamp: November 23, 2019, 10:26:29 pm
content: This is why I arranged the cable to come out of the side on the design I did :https://www.eevblog.com/forum/projects/ar488-arduino-based-gpib-adapter/msg2718346/#msg2718346(admittedly, as you can see from the attached stacking connector, it was thewrongside. I'm addressing that.)

author: lordium
author_rank: Regular Contributor
timestamp: December 02, 2019, 06:14:54 am
content: This reminds me of something I made back when I needed this (which I still use today). Works with all equipment I've tested with (HP, R&S, TR from all ages).STM32, and USB connector can mount both top and bot for pulling cable left or right. Still have the code and kicad if anyone's interested.EDIT: added 7zip files, also noticed last code was old version, added new one ported to STM32CubeIDE

author: giovannirat
author_rank: Regular Contributor
timestamp: December 02, 2019, 10:02:07 am
content: Quote from: lordium on December 02, 2019, 06:14:54 amWould be great if you could share it....Thanks

author: Zinahe
author_rank: Newbie
timestamp: March 16, 2020, 12:39:34 am
content: Just wondering if there is any update on this project. I'm very interested. I've got a few old instruments that need some lovin'.Cheers,

author: essele
author_rank: Frequent Contributor
timestamp: March 17, 2020, 08:39:41 am
content: Hi Zinahe,I've been working quietly (and slowly!) on this in the background as my needs change.I've now put the focus on flexibility rather than GPIB transfer performance and I now have a bit of a framework that I can use for a variety of different devices that are built on the same basic PSoC MPU with USB.1. The Yaugi GPIB adapter2. A BME280 based temperature sensor3. A USB based switch unitSo the framework supports customisable commands and configs, supports saving configs to flash, supports dynamic switching between USBUART and USBTMC, and re-flashing using the PSoC host based firmware utility.On the GPIB side I've reworked the UART interface and moved away from Prologix compatibility in order to be a bit more prescriptive about whether a given command should expect a response or not which makes it easier to code a standard API for it.There's still a lot more to do but I'm really doing other things, so I'm only working on it as my needs dictate, over the weekend I got it working with my shiny new(*) 3458a, so I'm doing some data gathering at the moment and probably won't get back to working on the code for a week or so.(*) New -- as in new to me ... it's nearly 30 years old!

author: essele
author_rank: Frequent Contributor
timestamp: June 03, 2020, 12:44:27 pm
content: Just a heads-up as I've just got it powered up for the first time, but I've now pulled together a PoE (802.3af) version...It's using a W5500 attached to the PSoC, and an amazing tiny PoE module from Silvertel (less than $10 qty 1!!)https://www.silvertel.com/images/datasheets/Ag9900M-datasheet-ultra-miniature-isolated-Power-over-Ethernet-POE-module.pdfI haven't written any of the ethernet code yet, I've just checked that power is ok and that I have connectivity from the PSoC to the W5500. I've forgotten the bloody serial port, which will make debugging a little more painful although I may just bodge something in.I also think I'm breaking all the rules about isolation, but that should be just a board rework challenge once it's all up and running.