AR488 Arduino-based GPIB adapter

[artag]

Yes, surface mount connectors are not robust, especially when as  small as a USB micro.
There is a design for a housing firther back in the thread. It can be 3d-printed and should give some protection. Ideally I would enclose the entire connector in the shell so you have to take it apart to change the cable. This is also how the HP 82537 housing works - it seems like a captive cable but it can actually be replaced.

[RichardM]

Thanks to WaveyDipole, the problem of the Mega hat is finally found. It is the wrong connection due to my misunderstanding of the GPIB connector orientation and the wrong library directly downloaded from the internet. What a serious mistake I have made!
I will correct and verify the design and update the status here as soon as possible.
The next thing I probably need to do is to desolder the expensive GPIB connectors...

That's great. Looking forward to the update.

Cheers

[T3sl4co1l]

Also, PCB pads can be epoxied back down to the board.  Bit of a messy proposition, but done carefully, it can be flat and serviceable (i.e. not glommed up over the pads/pins so you can still desolder the connector in the conventional way).  Or glommed up intentionally, to add reinforcement around the shell, particularly using a filled type epoxy (JB Weld being a common and effective candidate).

Tim

[ONLYA]

I finally got it right by reversing the connection. I spent a night trying to desolder the expensive connectors with only the soldering iron and solder sucker. No luck. I spent another night to rewire the route to a new connector and it is still reversed Seems like today is my lucky day
Recognise that the instrument beeps and shows "ERROR" when I type "*idn?" although I can see the identity with "++read". Not sure whether this is normal or not.

In the HP34401A software developed by Nx-1997, it is unable to communicate to Bluetooth emulated COM port. With USB connection, it still needs to change the address manually with PuTTy first to make it work.

As it can work with Bluetooth, the device can be powered with a 9V battery for mobility. I have built a small circuit to use TL431 and LED to indicate the voltage level is not less than 7.3V. The circuit resistor config depends on the LED spec. Measure the LED for the best indication.
It is noted that the overall average current consumption with the 9V Vin will be 190mA-210mA idle, ~250mA when working. So one 9V battery will last for 2 hours in theory. It may be around 1 hour or less in practice due to the voltage limitation of Vin.
However, as the 9V battery can still work until 5.4V, I am thinking of adding a voltage booster with 3 TL431 (I have quite a lot TL431 ) or a proper voltage regulator to make the battery can be used thoroughly when it is below 7V.
The PCB is small so there is no space for a 9V battery. The battery will be dangling around the device.

I will correct the PCB and update the schematic as soon as possible.

[WaveyDipole]

Removing the connector with a soldering iron and solder sucker is likely to be tricky. Sometimes adding a little solder to the joint first to enable better heat coupling helps, but the joints attached to the ground plane can be awkward as the ground plane sucks all the heat away very quickly.

[ONLYA]

I have updated my MEGA 2560 Hat design.

The connection is corrected and the connector shields (MH1, MH2) are connected to the GND.

A battery circuit is added. Instead of directly powering to Vin with a 9V battery, a step-up DC-DC IC is used for two to three AAA batteries. An additional indicator is added for low battery indication. For more details, see my repository (https://github.com/ONLYA/AR488-Bluetooth-Mega-2560).

Because of the Spring Festival, JLCPCB is currently on holiday so I have not quoted it yet. As I have made a huge modification here, I am not sure whether it is perfectly fine in theory even though I have double-checked the schematic and PCB. If someone wants to use the battery circuit, use it at your risk.

Removing the connector with a soldering iron and solder sucker is likely to be tricky. Sometimes adding a little solder to the joint first to enable better heat coupling helps, but the joints attached to the ground plane can be awkward as the ground plane sucks all the heat away very quickly.

It is really tricky to desolder a GPIB connector with those two basic tools. The original way did not suck all the solder and the remains became a thin layer in the hole, which is harder to get rid of. A better way (soldering iron and solder sucker on different sides) seems not able to be applied to this connector as I smelled plastic when I did this.
I do not want to waste those two connectors and two soldered ICs. I think it will be better for someone else with a proper desoldering tool to use them rather than left them in storage. If someone wants those two boards to salvage the components, I can give them for free while you still need to cover the postage fee.

[ONLYA]

I received my new designed PCB! It works perfectly fine and is able to be used with the HP34401a program! The pictures shown are under the condition of 3V battery voltage with Bluetooth. I do not have a screwdriver that turns the potentiometer to prove the Battery Low LED indication now.
A bit wondering why DAV signal timeout.

The first two are to prove the concept. The last two show it works with the HP34401a program.

[WaveyDipole]

Brilliant! Glad to see your revised board working! 

Thanks also to Niravk1997 (Nx-1997) for the HP Agilent Keysight 34401A Control and Data Logging software:
https://github.com/Niravk1997/HP-Agilent-Keysight-34401A-Control-and-Data-Logging-Software

Works with the HP34401A serial port and a VISA compatible GPIB adapter as well.

The DAV and subsequent timeout waiting for sender might be on account of the terminator. The default termination sequence is CR+NL. The HP34401A terminates SCPI sequences with a NL only but the interface will be looking for CR+NL and will be waiting for more data and then time out. Try it with:

++eor 2

This will tell the interface to expect NL only as the termination character.

[Jay_Diddy_B]

Hi,

I got some of these boards today:



I added to them to my order from JLCPCB. I will try them out in the next few days.

I soldered one together. and it works well.



I have built the AR488 before. I like the idea of using the Arduino Nan, it is about half the price of the pro micro.



Many thanks to WaveyDipole and Artag.

Also a special thank you for DavidKo for creating the panelized version.

Best regards,
Jay_Diddy_B

[tom_iphi]

Hi folks,

I'm using an individual AR488 adapter on each instrument, all of them connected via wifi (ESP8266).
This works very well in most cases.

BUT...
Now I am having the problem to synchronize a signal generator (HP8672A) and a power meter (Gigatronics 8541C).
The basic task is to step the output frequency and measure the power at each frequency.
Now, it appears to be quite a lottery as to when the data packets arrive at the instruments via the network.
Sometimes the power meter already starts reading while the generator has not yet changed the frequency.
This is nothing ultra-fast as I haven't managed to get more than about 10 readings per second out of the Gigatronics, even in swift mode.
Still the instruments are not always in sync.

Now my questions:

My generator is so old that it doesn't allow to read out the frequency or lock condition.
How can I make sure that the set frequency command has been dispatched by the AR488 adapter?
If I send a "++addr" command to the adapter and wait for the answer, can I be sure that the previous set frequency command has been completely dispatched to the instrument once I get the address answer or can the AR488 adapter reply while still processing the previous command?

And:
What happens when I send commands to the adapter in too rapid succession, which may happen for commands that do not invoke an answer?

And finally:
Does anyone have experience with fast reading measurements out of a Gigatronics 8541C? They advertise up to 500 measurements per second via GPIB but for single measurements (not block mode) I don't even come close to this. In swift mode I obtain 13 measurements per second.
This is the fastest sequence I could come up with:

Code: [Select]

++auto 0
++addr 15
AP     //sensor A
CW    //cw-mode, fastest
AE FM 0 EN  //averaging off
SWIFT FREERUN  //freerunning swift mode
++read
++read
++read
...
Any ideas what could be improved?
Btw, the Gigatronics terminates strings with CR+LF, so no problem from this side.

Many thanks,
Tom

[WaveyDipole]

If I send a "++addr" command to the adapter and wait for the answer, can I be sure that the previous set frequency command has been completely dispatched to the instrument once I get the address answer or can the AR488 adapter reply while still processing the previous command?

Each command is added to the buffer in sequence and processed in turn by the parser. A call to read or write to a device must complete its read/write cycle before returning back to the main loop when the next command in the sequence can be processed.

What happens when I send commands to the adapter in too rapid succession, which may happen for commands that do not invoke an answer?

Depends on what board you are using. If you are using a 32u4 based board and you enable RTS/CTS handshaking, the 32u4 will do hardware handshaking so the buffer should not overflow. However with boards that have other UARTs (16u2, CH340) may overflow their buffer if data is fired at them too fast. The result will be dropped characters and corrupted commands resulting in errors. The CH340 can be configured to do RTC/CTS handshaking as well but requires a couple of extra GPIO pins. It works on Windows, but Linux is a little more complicated as it needs an updated driver.

[tom_iphi]

Many thanks for the quick answer!

A call to read or write to a device must complete its read/write cycle before returning back to the main loop when the next command in the sequence can be processed.

Great, this should solve my synching problem. :-)

[tom_iphi]

Hi,

I am having trouble controlling an HP8350B with the AR488 USB adapter, while the same code runs fine with an original Prologix adapter.

Here is the code sequence I send to obtain the instrument identifier:

Code: [Select]

++addr 19<CR><LF>   //setting GPIB address 19
++eor 2<CR><LF>    //HP8350 answers with LF only, the Prologix doesn't need this
++auto 1<CR><LF>
IP<CR><LF>    //Instrument preset
OI<CR><LF>   //read identifier string

Through the Prologix I always get the full answer to the OI command, through the AR488 I mostly get nothing and sometimes a part of the string.
This is not a speed problem. I am doing this by hand through a terminal program for now. The AR488 does answer the ++ver command.
Also, the instrument indicates that it is being addressed when issuing the OI command. Strangely, it indicates already being addressed after the ++addr command for the Prologix, but not for the AR488.
Am I doing something wrong?
Am I overlooking something?

Thanks, Tom

[tom_iphi]

I am having trouble controlling an HP8350B with the AR488 USB adapter, while the same code runs fine with an original Prologix adapter.

Update:
This does not seem to be the fault of the AR488 interface.
The effect is very strange:
Using the KE5FX GPIB configurator I do get reliable responses from the AR488 adapter+HP8350B.
If I just unhook it from the KE5FX software and hook up my YAT terminal program thus not changing the AR488 settings I no longer get reliable responses, sometimes only part of the response string, sometimes no response at all. I'm observing this in parallel with a serial port monitor software, so I am dead sure the AR488 adapter did not get reconfigured during the software switchover.

Btw, using YAT the only setting that lets me receive data from the Arduino Leonardo 32U4 native USB serial interface is RS485 transceiver control setting. None of the alternative settings work.

Can someone give me a clue what the KE5FX serial port communication may do differently than my terminal program?

[tom_iphi]

I am having trouble controlling an HP8350B with the AR488 USB adapter, while the same code runs fine with an original Prologix adapter.

Update:
Setting eoi to 1 does the trick.
It is strange that the Prologix works with eoi set to 0.

[tom_iphi]

Question about the AR488-ESP8266-addon firmware:

I run my ESP8266 interfaces all in client mode connected to a local access point.
Now, if I happen to switch on the AR488-ESP8266 devices BEFORE I switch on the access point (it is dedicated to the lab and only running when I'm there), the access point won't be found and the ESP8266 comes up in AP mode. As far as I understand, the access data to the access point is lost then, correct? If I power the device down and back up when the local access point is running, it will no longer connect, but will come up in AP mode again. Thus, in such a case I'll have to manually re-connect all devices to the local access point, which is a lot of work.

Is there any way to avoid this? I do not need the device to come up in AP mode if the access point is off. But it should connect to the access point next time it is powered up again.

Thanks, Tom

[WaveyDipole]

Tom,

Although nothing is being saved to EEPROM, the WiFi chip does "remember" the last used settings, so I think the answer may be to comment out a bit of code in the startWiFi() function. You will see a statement like this:

if (startWifiStn("", "", AP.addr, AP.gate, AP.mask)) {
...
}else{
...
}

I think that the 'else' part with the the "Falling back to AP with defaults..." comment needs to be removed or commented out.  It is probably falling back to AP mode and when you try to connect again with the WiFi back up "remembering" that last settings which would now be the fallback AP settings. If it is stopped from falling back then it should hopefully just "remember" the last station settings. I will probably need to update the code accrodingly.

Thanks for pointing this out.

[douardda]

Question about the AR488-ESP8266-addon firmware:

I run my ESP8266 interfaces all in client mode connected to a local access point.
Now, if I happen to switch on the AR488-ESP8266 devices BEFORE I switch on the access point (it is dedicated to the lab and only running when I'm there), the access point won't be found and the ESP8266 comes up in AP mode. As far as I understand, the access data to the access point is lost then, correct? If I power the device down and back up when the local access point is running, it will no longer connect, but will come up in AP mode again. Thus, in such a case I'll have to manually re-connect all devices to the local access point, which is a lot of work.

Is there any way to avoid this? I do not need the device to come up in AP mode if the access point is off. But it should connect to the access point next time it is powered up again.

Thanks, Tom

Hi Tom,

using an ESP32 instead of an (AVR) Arduino may help here. Since the wifi management is part of the firmware, it's a bit easier to deal with this kind of situation.

For example, in my esp32 version of the AR488 GPIB firmware (https://github.com/douardda/AR488/tree/esp32), I've implemented an automatic communication port selection. It will switch between serial, wifi or bluetooth automatically depending on which gets activity (aka receive data or ++ commands).

Also in this firmware, the wifi parameters are modifiable via ++ commands and stored in the EEPROM.

David

[sixtimesseven]

Hi I've just built myself an AR488 with arduino micro. I can send commands like ++ver and receive a response back.
But I'm having some difficulty connecting to my Fluke8840a, command ++addr responds with 1 so i've set the hardware address to 1.
I'm hoping username kc9qvl is still on this forum as I see in post #412 he got it working.
I was hoping he could share the secret to get the Fluke chatting.
A random question, is the AR488 compatible with PyVISA?

Any updates on pyvisa?
Super usefull, so I'm surprised that I could not find anything on this topic.

[douardda]

By the way, I forgot to put here a few pics of my "modular" design (kicad files are available here https://github.com/douardda/ESP32-GPIB-pcb).

Here with the esp32 devkit v3 module:




The common GPIB connector board comes with the driver ICs (75160 and 75162) populated:


David

[WaveyDipole]

using an ESP32 instead of an (AVR) Arduino may help here. Since the wifi management is part of the firmware, it's a bit easier to deal with this kind of situation.

Can I ask whether you developed your code using a 30-pin or 38-pin ESP32? Only recently I recently became aware that a 38-pin version exists. Quite some time ago, when I was looking at this, I came to the conclusion that there were not enough pins on the ESP32 dev board to connect all 16 pins of the GPIB data and control buses combined. That conclusion was also influenced by the fact that on ESP8266 board I was testing at the time, several of the exposed pins could not be used as normal GPIO pins which substantially reduced the total number of actual pins available. My conclusion assumed this might also apply to the ESP32, although even now, I am still not sure whether that is the case. Naturally, the extra few GPIO pins on the 38-pin version would make a difference.

[WaveyDipole]

Over time there have been some questions about serial buffer overruns serial handshaking on Arduino boards. Some boards support handshaking, others do not. I have recently done some testing of RTS/CTS and XON/XOFF handshaking on the most commonly available UART chips. I thought this information might be of interest to some. Attached is a summary the results of these tests.

Using the test program, it was possible to send a test data file from one serial port to another without data loss, even when the receiving port was running much slower than the sending one. However, this only worked with certain UART chips but not others. The attached shows which UART chips will or will not support serial handshaking, the steps required and the problems encountered.

I do plan to implement the technique used in the AR488 code at some point in the near future and document the findings in the AR488 manual.

[tom_iphi]

Thank you very much for the very interesting report, John!
This is one thing I have always wondered about. A very useful compilation, indeed!
Btw, did my email with the article reach you?

Best regards, Tom

[douardda]

Over time there have been some questions about serial buffer overruns serial handshaking on Arduino boards. Some boards support handshaking, others do not. I have recently done some testing of RTS/CTS and XON/XOFF handshaking on the most commonly available UART chips. I thought this information might be of interest to some. Attached is a summary the results of these tests.

Using the test program, it was possible to send a test data file from one serial port to another without data loss, even when the receiving port was running much slower than the sending one. However, this only worked with certain UART chips but not others. The attached shows which UART chips will or will not support serial handshaking, the steps required and the problems encountered.

I do plan to implement the technique used in the AR488 code at some point in the near future and document the findings in the AR488 manual.

I've tested my version of the code with 2 (maybe 3, not sure) esp32 boards: a TTGO t8 and the DevKitC (38 pins).
My go to board is this later one today. (I've also made it work with a few STM32 Nucleo boards).

I indeed need all the available and compatible IO pins to make it work (a bit tricky to find which IO pin can be used to drive which line of the 7516x drivers, especially for the IO pins involved in boot config) especially when using the SN75162 driver driving the DC line individually (for now the firmware does not need this to be driven individually but I wanted to keep the possibility to do so).

I have not yet played with hw controls for the serial port, I may try at some point also. Nice job with your UART testing work!

David
 

   

[douardda]

By the way, forgot to mention that thanks to the wifi connection coming with the ESP32, it is possible to use serial over ip protocols. I've started to document this a bit. The resulting doc can be read here:

  https://douardda.srht.site/ar488-esp32/bluetooth.html

I have not tried yet to implement any kind of control protocol (using RFC 2217) but I may give a try to add at least some support for flow control (there is some support for XON/XOFF in RFC221 and there have been some work to extend this in like https://datatracker.ietf.org/doc/draft-edwards-telnet-xon-xoff-state-control/ but we'll see what's possible and useful.)