AR488 Arduino-based GPIB adapter

[PerArdua]

Thanks - some interesting results.

Changing the termination char had no affect on the response of the E3632A. The users manual says that a command string must terminate with a <new line> character and that CR +LF is also accepted (page 114). However, I did try going through each of the four options on the 1650B (much older instrument). When using CR+LF, CR and none, the instrument did not respond at all. However, when appending a LF, it would throw an error message of:

"invalid character received: *IDN/<LF>"

I double, triple checked - and my termite terminal says I sent *IDN? - is the ? being removed somewhere?

[wilhe_jo]

hmmm...

My failure in making another arduino-based AR488 got me similar problems...
The spectrum analyzer switches to remote, but I don't get any response data.
I thought, I might got some fake AVR, but maybe there's another problem.

I'll see if I manage to do the xdiag-debugging the next days...

73

[PerArdua]

Thanks for the input wilhe_jo - it's both encouraging to know someone else has had similar issues, and perhaps equally discouraging haha. I'll chip in and say that I'm using official Uno and nano boards, so unless they have used fake AVR, then that is maybe not the issue. 

[dl6lr]

"invalid character received: *IDN/<LF>"

I double, triple checked - and my termite terminal says I sent *IDN? - is the ? being removed somewhere?

Look at the ASCII table. "?" is 0x3F and "/" is 0x2f, so one bit is missing (stuck low), this is bit 4 (in programmers counting, starting with bit 0) or DIO5 pin 13 on the GPIB connector. Other characters are *IDN which are 0x2A, 0x49, 0x44, 0x4E and <LF> which is 0x0A, none of those characters have bit 4 set. So I guess Data line for bit 4 DIO5 is stuck low or tied with a short to another bit and therefore forced LOW.

[PerArdua]

Thanks dl6lr - I'd not thought of debugging that way - thank you for the useful tip. Turns out that line was broken on a HPIB cable I was using to extend from my connector to the instrument! I moved the instrument so now I have it connected straight into the GPIB connected, connected to the Arduino. I've verified there are no shorts or other breaks - each pin is controllable using the xdiag function. Now I am back to receiving no message from the 1650B when sending *IDN? - this turn both CR+LF and LF shows I've sent *IDN? - but nothing happens. Sending a second results in a query interrupted message again. CR and none do nothing.

I will have connected a logical analyser to the arduino's outputs and taken a 3s measurement around the moment I hit send for a *IDN? command sent to addr 7. I could only take 8 concurrent measurements at a time, so I did two measurements - one showing data lines and one the control. The Arduino and Instrument were in the same configuration for both measurements (ie rebooted, single *IDN? sent, etc).

Is there a source for decoding the data on the GPIB? I tried looking through the standard, but couldn't find anything - is it simple ascii? I tried running the numbers through a binary to text converter but only got rubbish. I tried decoding using 1 for HIGH as well as 0 for HIGH, Ch0 connected to DIO1 -> Ch7 to DIO8. I've attached the measurement files as csv - though there isn't too much to them. Images are below.

From what I've understood from reading pin descriptions - the fact that EOI never asserts itself stands out - is this part of the problem?

[PerArdua]

I think I have figured it out...

Under the default configuration, the controller is not automatically configured to attempt to read a response from an instrument after a sequence that is not a controller command  (beginning with ++). *IDN? is one such command. As such, the ++auto 2 should be sent to the controller.

The 'correct' order of operations should be (based on my post from page 34):

1) Connect GPIB connector to instrument.
2) Connect USB between Arduino and PC.
3) Open serial port.
4) send ++ver
5) send ++auto 2
6) set address to 6 by ++addr 6
7) send *IDN?
?
9) win

Thanks to those who helped me with this - I've learned a lot more about debugging and GPIB than I anticipated.

[dl6lr]

Is there a source for decoding the data on the GPIB? I tried looking through the standard, but couldn't find anything - is it simple ascii? I tried running the numbers through a binary to text converter but only got rubbish. I tried decoding using 1 for HIGH as well as 0 for HIGH, Ch0 connected to DIO1 -> Ch7 to DIO8. I've attached the measurement files as csv - though there isn't too much to them. Images are below.

I don't know what type of LA you are using. Are you using sigrok? There is a IEEE488 decoder for sigrok. I have a Tek 1240 LA that supports GPIB directly with a pod adapter. Haven't used it yet.

[PerArdua]

I'm using a saleae logic 8 in their logic 2 software (confusing naming scheme).

Hope you have some luck with your device - were you using the ++auto 2 command?

[dl6lr]

I'm using a saleae logic 8 in their logic 2 software (confusing naming scheme).

Hope you have some luck with your device - were you using the ++auto 2 command?

So with the saleae you can use sigrok/pulseview.
I had no problems with all my AR488. Just use either ++auto 1 or when using ++auto 0 just issue a ++read for the response.

I had some problems using the KE5FX toolkit with my TDS scops, as it is "too slow" and the default ++read_tmo_ms will just let the read time out (and the timeout you configure in the toolkit is not honoured for unknown reason).

[WaveyDipole]

Thanks again JustJason - i admit the 10s caught me out - the AR488 manual doesn't mention it returns automatically haha.

I will add a note to the manual about the 10 second test interval as well as a reminder that GPIB signals are HIGH when inactive and LOW when active to this section of the manual.

[WaveyDipole]

I think I have figured it out...

Under the default configuration, the controller is not automatically configured to attempt to read a response from an instrument after a sequence that is not a controller command  (beginning with ++). *IDN? is one such command. As such, the ++auto 2 should be sent to the controller.

Indeed, after sending a query ('?' terminated) SCPI command, it is then necessary to read back the response with ++read. For convenience, the ++auto 2 command automatically sends a ++read after detecting a command ending with '?' but this is a somewhat non-standard approach.

[WaveyDipole]

Hi, with the last firmware version, Timelab (for my experience) doesn't work anymore with my Hp5334a. In particular, I cannot set the instrument in talk mode.

Has anyone had the same problem?

thanks in advance

Sorry to hear that! Could I have some more details please?
I am not familiar with Timelab. Is it this software: https://www.miles.io/timelab/beta.htm ?
Are you sending the sequence of commands to make the instrument enter talk mode manually, using a script, or is that being done by the Timelab software?
Which firmware version did it work with last, and does it still work with that version of the firmware?

If its the Timelab software that is sending the commands to switch the instrument into talk mode, then I will need to somehow explore what the software is sending to the interface.

[artag]

I'm using a saleae logic 8 in their logic 2 software (confusing naming scheme).

The problem with the Logic8 (I have one, it's fantastic) is that you really want more than 8 lines for GPIB. The sigrok decoder will work with the cheap Cypress breakouts. Just like the AR488 they can be handwired, but there's a pcb here

https://oshpark.com/shared_projects/1FVMoqoQ

Unfortunately oshpark charge by the square inch so this isn't as cheap as the 32u4 pcbs. It's under 10x10 though so the chinese suppliers can be incredibly cheap.

The cypress boards are are quite nice to build into devices like this to make a dedicated analyser pod. There's also a sigrok USB C PD decoder which I have in mind for the same treatment though probably using off-the-shelf USB C breakouts.
 
https://www.ebay.co.uk/itm/275071624433 (example supplier for no particular reason, there are many. search for fx2lp)

[tom_iphi]

Hi,

I think I have detected an incompatibility between the AR488 and the Prologix adapter that seems to cause an issue with the KE5FX VNA toolbox.
The issue is with the ++spoll command. The KE5FX software issues it with an address, i.e. ++spoll 16, where 16 is the primary GPIB address of the polled instrument.

Here is the command sequence that works successful with the Prologix adapter in combination with the HP8510B VNA:

++addr
  16
++spoll
  1
++spoll 16
  1

For better visibility I have indented the adapter responses. So far so good.

Now, here is the same sequence using the AR488:

++ver real
  AR488 GPIB controller, ver. 0.51.09, 20/06/2022
++addr
  16
++spoll
  1
++spoll 16
 => no response from the AR488 which causes the KE5FX VNA tool to lock up.

Have I misunderstood something or can there be done something about this problem?

Thanks and best regards,
Tom DG8SAQ

[tom_iphi]

Hi Artag,

The sigrok decoder will work with the cheap Cypress breakouts. Just like the AR488 they can be handwired, but there's a pcb here

https://oshpark.com/shared_projects/1FVMoqoQ

This is very interesting! Is there a description available how the sniffer board is connected to the Cypress board?
Also, is there a schematic for the pcb? Component values?

Thanks, Tom DG8SAQ

[artag]

Hi Tom,

The only components are connectors and the Cypress board. It fits right over the connector PCB.  I'll put a photo up.

[tom_iphi]

Hi Artag,

The only components are connectors and the Cypress board.

It seems there is a total of 16 resistors on the board. What about those?

I'll put a photo up.

Please do so, thanks!

Best regards, Tom

[artag]

Sorry, I'd forgotten those. They're not critical, just to protect the Cypress inputs. I used 2k2.

[tom_iphi]

Hi Artag,

that's very cool, many thanks!
I take it the two GPIB connectors serve as a thru connection, right?
What is the purpose of J1?

Best regards,
Tom

[artag]

Yes, the two connectors are in parallel with the Cypress chip tapping the data and control lines via the resistors. J1 is also in parallel with the other two connectors allowing a connector on a short ribbon cable to be used instead.

[tom_iphi]

Hi Artag,

can you possibly provide a definition file describing how the adapter board wires the GPIB bus to the Cypress board such that SigRock can decode it?

Many thanks and best regards,
Tom

[artag]

I've put the schematic and other Kicad files online at https://github.com/artgodwin/Sigrok-sniffer

[tom_iphi]

Great, many thanks!

[Jay_Diddy_B]

Hi group,

I would like to start by thanking WaveyDipole for the efforts that he has put into this great project.
I have built and used a few of the AR488 using the artwork from artag.

I would like to try a buffered version, using SN75160 and SN75161 buffers. Following the schematic that is provided in the AR488 manual have generated:

*** This has been revised ***



3D image - proposed placement





I have attached a pdf of the schematic.

I have six instruments on the bus. I think it would be more convenient to talk to the instruments through a single interface.

Does this make sense?

Regards,
Jay_Diddy_B
 SCH buffed AR488 DRAFT R2.pdf (78.15 kB - downloaded 107 times.)
[ Specified attachment is not available ]

[Jay_Diddy_B]

Hi group,

I just sent to the files for the buffered version to my favorite PCB vendor for fabrication. I will report back and share the files after I have tested the prototype.



Regards,
Jay_Diddy_B