AR488 Arduino-based GPIB adapter

[WaveyDipole]

It looks like the Android app is a bit of a red herring. There is an official Arduino IOT cloud app which is a different beast. The other app mentioned in the earlier post has negative reviews and at least one post complains about code compatibility mentioning that code that compiles fine in the Arduino IDE generates lots of errors in this mobile app. I guess there is nothing to be excited about yet. For now, stick to the official Arduino IDE.

tom_lphi, that's an interesting note about HC-06 Bluetooth boards. Worth being aware of.

[lmester]

I have users of my HP 3478A multimeter control software that are getting checksum errors when trying to read the calibration data. This is happening with newer AR488 firmware versions. Older firmware works fine.

https://mesterhome.com/gpibsw/hp3478a/index.html

My program works with AR488 0.49.14 but fails with AR488 0.51.18.

Could wavydipole comment on what changes there may be between these two AR488 versions?

Code: [Select]


AR488 0.49.14 read calibration data cheksum good:

Reading calibration data.
**********
Verify checksums.
@@@CA@BLLLNLG : CkSum = (199 + 56) Checksum OK.
@@@@CABLLCOLO : CkSum = (207 + 48) Checksum OK.
@@@@@DBLLOELM : CkSum = (205 + 50) Checksum OK.
IIIIIDAEBAOKF : CkSum = (182 + 73) Checksum OK.
@@@@@@AEBMNML : CkSum = (220 + 35) Checksum OK.
@@@@@@@@@@@OO : CkSum = (255 +  0) Checksum OK.
IIIE@BADODEL@ : CkSum = (192 + 63) Checksum OK.
IIII@D@E@MNKG : CkSum = (183 + 72) Checksum OK.
IIIIIA@EDNNJL : CkSum = (172 + 83) Checksum OK.
IIIIII@ECDDKI : CkSum = (185 + 70) Checksum OK.
IIIIII@EABLKE : CkSum = (181 + 74) Checksum OK.
IIIIII@EBBOKA : CkSum = (177 + 78) Checksum OK.
IIIIII@EBMAKD : CkSum = (180 + 75) Checksum OK.
IIIIII@EBDOJO : CkSum = (175 + 80) Checksum OK.
@@@BF@CNOE@MB : CkSum = (210 + 45) Checksum OK.
@@@@BECN@@MMJ : CkSum = (218 + 37) Checksum OK.
@@@@@@@@@@@OO : CkSum = (255 +  0) Checksum OK.
IIIE@BCLCOBKJ : CkSum = (186 + 69) Checksum OK.
@@@@@@@@@@@OO : CkSum = (255 +  0) Checksum OK.

Reading calibration data complete.
Calibration data checksum valid.


------------------------------------------------


AR488 0.51.18 read calibration data checksum failed:

Reading calibration data.
**********
Verify checksums.
@@@CA@BLLGNLG : CkSum = (199 + 51) Checksum Fail.
@@@@CABLLCOLO : CkSum = (207 + 48) Checksum OK.
G@@@@DBLLOELM : CkSum = (205 + 57) Checksum Fail.
IIIIIDAEBAOKF : CkSum = (182 + 73) Checksum OK.
@@@@@@AEBMNML : CkSum = (220 + 35) Checksum OK.
@@@@@@@@@@@OO : CkSum = (255 +  0) Checksum OK.
IIIE@BADODEL@ : CkSum = (192 + 63) Checksum OK.
IIII@D@E@MNKG : CkSum = (183 + 72) Checksum OK.
IIIIIA@EDNNJL : CkSum = (172 + 83) Checksum OK.
IIIIII@ECDDKI : CkSum = (185 + 70) Checksum OK.
IIIIII@EABLKE : CkSum = (181 + 74) Checksum OK.
IIIIII@EBBOKA : CkSum = (177 + 78) Checksum OK.
IIIIII@EBMAKD : CkSum = (180 + 75) Checksum OK.
IIIIII@EBDOJO : CkSum = (175 + 80) Checksum OK.
@@@BF@CNOE@MB : CkSum = (210 + 45) Checksum OK.
@@@@BECN@@MMJ : CkSum = (218 + 37) Checksum OK.
@@@@@@@@@@@OO : CkSum = (255 +  0) Checksum OK.
IIIE@BCLCOBKJ : CkSum = (186 + 69) Checksum OK.
@@@@@@@@@@@OO : CkSum = (255 +  0) Checksum OK.

Reading calibration data complete.
Invalid checksum during calibration data read!
CalEd: inst com checksum fail!
Abort: COM fail cal Checksum failed.
Exit cal update.


[unseenninja]

Is there a particular reason why read_tmo_ms is limited to a maximum of 32,000 milliseconds? The code seems to handle the timeout as an unsigned long internally, allowing 4,294,967,295 milliseconds as the real maximum.

The Solartron 7081 takes 51.2 seconds to produce a full 8.5 digit reading. With the maximum allowed timeout of 32 seconds, there's no way to get the AR488 to wait long enough for it.

[Gertjan]

If you have to wait that long, consider that you are not using the right solution......
Waiting that long means that the entire GPIB  buss is blocked during the waiting time.

A better solution is to send a command requesting a measurement first, and then poll at regular intervals to check if there is an answer. Read about the++spoll command.

[robert.rozee]

[...] I have been considering using the Pico board instead

did the idea of using a RPi pico ever go anywhere? looks like with some series resistors the signal level differences shouldn't be too much of an issue - or there are plenty of little level-shifter boards out there.


cheers,
rob  :-)

[coromonadalix]

an RPI   would be more challenging to build and develop,  since rpi need an OS to boot  ... and you need to load  plugins etc ..

if i recall it does exist ...   https://www.hackster.io/lightside-instruments/the-gpib4pi-gpib-for-raspberry-pi-shield-4b3e9a

i think the actual project is more than enough ?

[caiser01]

an RPI   would be more challenging to build and develop,  since rpi need an OS to boot  ... and you need to load  plugins etc ..

You're talking about using a Raspberry Pi 0/1/2/3/4/5 for which there is a different solution as you pointed out.

robert.rozee was asking about the Raspberry Pi Pico, which is a microcontroller board (https://www.raspberrypi.com/documentation/microcontrollers/raspberry-pi-pico.html) and just needs to have the AVR firmware ported to it.

There is an Arduino core for the Pico that might simplify porting AR488 to it (https://github.com/earlephilhower/arduino-pico). It just needs someone with some time on their hands to do the work and test it.

[H.O]

Having it run on something like a W5500-EVB-PICO and use Ethernet instead of UART would be cool.
No, I'm afraid I'm not the guy for it and I don't expect it from anybody else - but it would be cool...

[wilhe_jo]

Well, it runs on a ESP32-S2 (see photo) with a minimum number of components!
That's the module, the connectors, some ESD protection and some passives to make the module happy.
I converted more or less every instrument to usb with these and put some remaining boards on Lectronz in case somebody else would want some...

Compared to eg. the RPi pico, this module provides a USB peripheral.

I thought of doing an Ethernet version (maybe a port to a ch32v307).
The problem with this is, that you have to seriously think about locking/unlocking equipment (GPIB isn't that good with multiple-"masters" on the "bus"...).
Additionally, you'd need power.
Of course, you could add PoE... but why?
Ideally, the converter is small enough to hide on the backside of the measurement instrument.

Frankly, I think a GPIB -> USB converter is really the best compromise.
Both, the Atmega328 (+ USB-serial IC) and the mega32u4 cost more than a ESP32-S2 module does.
So IMHO these offer the best bang-for-buck.

BTW: if someone really plans to look into making a nice web-interface for the ESP32, I'd be open to send out 1 or 2 of my devices to help out with hardware... ideally within Europe to keep shipping costs reasonable

73

[WaveyDipole]

Well after a long spell of illness during December and most of January, I have finally managed to push the latest release out. There has been some code re-factoring for better consistency, an ESP32 layout added and a couple of fixes (EOI, ++spoll) . I have also added a ++tct command, although not the remaining additional functions that the David Douards ESP32 verision includes.

To answer some of the above questions:

I have users of my HP 3478A multimeter control software that are getting checksum errors when trying to read the calibration data. This is happening with newer AR488 firmware versions. Older firmware works fine.

Might be down to the EOI bug (Issue 9) reported by m0pub? This has been addressed in the latest release which might be worth a try. Will be interested to know if the problem still persists.

Is there a particular reason why read_tmo_ms is limited to a maximum of 32,000 milliseconds? The code seems to handle the timeout as an unsigned long internally, allowing 4,294,967,295 milliseconds as the real maximum.

It is limited by the int variable used to store its value in EEPROM. In the original code the limit was even smaller. When I extended it, I thought 30 seconds was reasonable and not likely to be exceeded. The reason why an unsigned long is being used in the handshaking routine is because the value is being compared to millis, which is also an unsigned long. I am not fortunate enough to have an 8-digit meter, but there is no reason why a larger variable could not be used in the config struct to accommodate longer time periods. Of course that would require re-saving of EEPROM contents.

[...] I have been considering using the Pico board instead

did the idea of using a RPi pico ever go anywhere? looks like with some series resistors the signal level differences shouldn't be too much of an issue - or there are plenty of little level-shifter boards out there.

I did create a layout for the Pico (it is commented out in the current code) and ran some tests. Unfortunately, so far, unlike the ESP32, these have not been successful. It seems to be almost working, that is, I get a normal looking logic analyzer trace but is has slight errors. I am not yet sure of the reason for this but it may be that the Pico on its own is not capable enough to directly drive the bus, or it could be a timing issue. I need to find more time for testing. I had hoped to try the Arduino RP2040, but haven't got around to buying one of those yet.

Well, it runs on a ESP32-S2 (see photo) with a minimum number of components!
That's the module, the connectors, some ESD protection and some passives to make the module happy.

An interesting looking board. I see it is already up on Lectronz.

I thought of doing an Ethernet version (maybe a port to a ch32v307).
The problem with this is, that you have to seriously think about locking/unlocking equipment (GPIB isn't that good with multiple-"masters" on the "bus"...).
Additionally, you'd need power.

The other problem you have is that the Ethernet interface needs additional GPIO pins. An Arduino Mega Mini would have sufficient and the Pico might (would have to investigate further) if I can get it to work.... The ESP32 WROVER module also might although since it already has WiFi, that would probably make adding Ethernet redundant.

BTW: if someone really plans to look into making a nice web-interface for the ESP32, I'd be open to send out 1 or 2 of my devices to help out with hardware... ideally within Europe to keep shipping costs reasonable
73

Quite some time ago I had developed a web interface for the ESP8266. It had to be substantially re-written to run on the ESP32 and was in a working state but still in need of further development when I last worked on it. I have just recently added an ESP32 layout to the AR488 code and was planning to revisit that code and develop further into a web interface module that could be added in and used as an option. I do have an ESP32 devkit board which I can use although it does not have the ESD protection implemented in your board.

BTW, I can add support for the ESP-S2 to my project. I just need the pinout details.

[linux-works]

I do lots of web REST interfaces for the esp (8266 but I can move to esp32).

not graphical, but pure REST interfaces (gets and sets via simple routes or paths).

PM me if you want to discuss.

[wilhe_jo]

BTW, I can add support for the ESP-S2 to my project. I just need the pinout details.

Well, I made a pull request... https://github.com/douardda/AR488-ESP32/pull/1
My repo: https://github.com/WilheJo/AR488-ESP32

I'm defaulting to some esp32s2 dev-board for the usb-stuff.
ATM, I'm playing with the idea of sponsoring a usb-pid (there are some resellers).
That would make it easier to define the serial device name via udev.

I do lots of web REST interfaces for the esp (8266 but I can move to esp32).

not graphical, but pure REST interfaces (gets and sets via simple routes or paths).

PM me if you want to discuss.

Well, my board uses an esp32s2.
This is mainly because this one is cheap and has hardware USB.

As for the rest API: I have no real clue how that could be implemented for non-standard compliant equipment.
I have some older equipment hat is just ieee488 compliant... Absolutely no scpi -like communication.

I could think of some web socket interface that feeds the same streams that take data from the serial interface.
The webinterface would "just" provide a convenient way for humans to take to the bus manually.

73

[unseenninja]

Well after a long spell of illness during December and most of January, I have finally managed to push the latest release out.

I'm sorry to hear that. I hope you are feeling a bit better now.

Is there a particular reason why read_tmo_ms is limited to a maximum of 32,000 milliseconds? The code seems to handle the timeout as an unsigned long internally, allowing 4,294,967,295 milliseconds as the real maximum.

It is limited by the int variable used to store its value in EEPROM. In the original code the limit was even smaller. When I extended it, I thought 30 seconds was reasonable and not likely to be exceeded. The reason why an unsigned long is being used in the handshaking routine is because the value is being compared to millis, which is also an unsigned long. I am not fortunate enough to have an 8-digit meter, but there is no reason why a larger variable could not be used in the config struct to accommodate longer time periods. Of course that would require re-saving of EEPROM contents.

Thanks, but Gertjan's suggestion put me on the right track. I tell the meter to assert SRQ when it has a reading ready and then handle it with ++srqauto. Much more efficient!

[WaveyDipole]

BTW, I can add support for the ESP-S2 to my project. I just need the pinout details.

Well, I made a pull request... https://github.com/douardda/AR488-ESP32/pull/1
My repo: https://github.com/WilheJo/AR488-ESP32

Indeed. I have discovered that David Douard has added the ESP32 (and STM32) layout configurations to the platformio.ini file. I can pick them up from there and add them to this project.

[linux-works]

the way I'm doing my t/m remote control stuff is now focused on wifi REST calls for simple gets and sets.  for that, you dont need esp32, esp8266 is more than enough.  the only reason I'd HAVE to use a 32 is if I went with bluetooth for some reason.  some lower cost meters use BLE as their remote control and for that the esp32 would be ideal.

the meters I'm more interested in are those that have serial interfaces.  for that, software serial is more than enough for an esp class chip.

no usb wanted or needed.   certainly not 'real' usb.  usb-serial would be sort of ok, but micros usually cant do usb inputs, they are uart focused.  so having serial wrapped in usb is overkill and not useful to me.

for streaming output, websockets are fine.  espnow is also fine for some things (esp to esp comms).

but mostly I'm using just 'curl -s' to get and set things.  start polling, stop polling, get values, set config, restore config, etc.

I have power supplies, meters, dc loads and planning other things that use this method of config/control.

(in my last several jobs, I got into the json religion and never looked back.  connectionless fetches via REST are so simple and so fast, I dont see much need for other forms of remote control anymore)

I've been working on an api infra for all this so that the user only has to write a few lines to get all that up and running.

I do plan to release to my github but its not there yet, still under devel.  but its been running for a while now (years) and its proven itself in my labs.

[wilhe_jo]

the way I'm doing my t/m remote control stuff is now focused on wifi REST calls for simple gets and sets.  for that, you dont need esp32, esp8266 is more than enough.  the only reason I'd HAVE to use a 32 is if I went with bluetooth for some reason.  some lower cost meters use BLE as their remote control and for that the esp32 would be ideal.

Well, if you look at the espressif website, they recommend migrating from the ESP8266 to the ESP32-C2... so I'd call this EOL/obsolete...

the meters I'm more interested in are those that have serial interfaces.  for that, software serial is more than enough for an esp class chip.

But that's a totally different usecase to the AR488, right?
AR488 is about controlling IEEE488 aka GPIB... that's a multi-drop bus with interrupts, byte-wide data bus and handshake signalling.

no usb wanted or needed.   certainly not 'real' usb.  usb-serial would be sort of ok, but micros usually cant do usb inputs, they are uart focused.  so having serial wrapped in usb is overkill and not useful to me.

Are you sure? My boards programm via USB (just press a button to switch to the preprogrammed internal usb-bootloader), get power via usb and use usb for comms. That's just 1 single cable that can get extended with ease using active cables (I've done 10 without any issue in my 3d print farm).

for streaming output, websockets are fine.  espnow is also fine for some things (esp to esp comms).

but mostly I'm using just 'curl -s' to get and set things.  start polling, stop polling, get values, set config, restore config, etc.

I have power supplies, meters, dc loads and planning other things that use this method of config/control.

(in my last several jobs, I got into the json religion and never looked back.  connectionless fetches via REST are so simple and so fast, I dont see much need for other forms of remote control anymore)

Well, GPIB isn't really something you want to use in an connectionless environment.
You're better off blocking any but one concurrent connection!

At some point you'll try to run 2 tests using the same equipment by accident, and you'll mess up you readings... that's when you start to lock equipment carefully.
BTW. that's exactly what GPIB does. You lock the local "UI" when you control equipment via the bus.

I run a pre-compliance EMC lab with quite some equipment.
For my testing, I have created a Qt6 application (there are some UI things that are missing... but there are plans to get it published as open source) that abstracts the workflows, test equipment and (bus) interfaces.
In fact, the workflow doesn't bother whether I use my PMM 9060 receiver, or my trustworthy Advantest R3271 via an  Arduino AR488, my ESP32-S2 AR488 or some old galvant GPIB dongle.
Just replace the receiver in the measurement chain, and you're good to go.

The abstraction is done in software, and not on the interface to the hardware.... but again, different usecase...

Additionally, I don't want wireless comms to my equipment. Again, I run a EMC lab, and I have situations (eg. getting the radiation pattern of an antenna) where my EUT would kill any wifi comms, and I don't want any other active transmitter to have a clean reading... again, special usecase...

So there's a very, very good reason why USB is a good thing to control instruments.

Yes, Ethernet might be also an interesting solution, but getting POE right, tiny and reliable is way more difficult than "just" have a USB cable connected to 2 pins

I've been working on an api infra for all this so that the user only has to write a few lines to get all that up and running.

I do plan to release to my github but its not there yet, still under devel.  but its been running for a while now (years) and its proven itself in my labs.

Been there, done that... still not ready for publishing after 3 years of constant development... the problem is to make the UI.

Just a script-set isn't really what you want/need... maybe as a start, but at some point, you want to have nice graphic.

Then, you want to do protocols right in there, because why would you keep the protocol separate from the measurement, right?

After a while, editing the (json) config files gets boring, so you need some sort of config-dialogs.

It's endless....


73

[linux-works]

there is no sign of the wemos d1 mini EVER going out of style in my timeframe (where I'd care).  its a standard and its not going anywhere.  the esp32 fans really crack me up.  there's a place for both but to deny the older one makes no sense.  the d1 mini footprint is de-facto and they are cheap as chips with next day delivery possible.

if you dont need ble, then there's no compelling reason to have to use esp32.

I have those chips at home but have not actually had the need to go beyond an 8266.  seriously. 

[linux-works]

Just a script-set isn't really what you want/need... maybe as a start, but at some point, you want to have nice graphic.

I'm more about automation and so graphic and user-data fields and mousing is definitely not what I want.  and not my focus at all.  there are already too many graphical this and that and you can always make one IF you have a raw get/set interface that works.

json as the language and rest over port 80 as the transport is, again, a great way for automation to work network-wide.

before that, usb and serial to local systems made sense.  gpib was like that, too.  but now I see the world as networked and with things being able to send a get or set and get a simple ascii json reply back.  if you give me that, I can do anything after that.

if you give me graphics and user clicky, I have no desire to try to automate it or even use it.  just being honest.

so again, my focus is entirely on a sane remote api (json over rest) and while it wont be directly usable by scpi style clients, that's not a problem for me.  I just want the timestamped data so that I can do things with it myself.

[wilhe_jo]

there is no sign of the wemos d1 mini EVER going out of style in my timeframe (where I'd care).  its a standard and its not going anywhere.  the esp32 fans really crack me up.  there's a place for both but to deny the older one makes no sense.  the d1 mini footprint is de-facto and they are cheap as chips with next day delivery possible.

if you dont need ble, then there's no compelling reason to have to use esp32.

I have those chips at home but have not actually had the need to go beyond an 8266.  seriously. 

don't blame the messenger

The espressif website cleary hints to migrate from the ESP8266 to the esp32-c2 (that's actually the RISC-V series... so that's totally different to the "normal" esp32 series).
They make the chip, so they should know why they write something like this...

My choice for the ESP32-S2 was purely because of the USB peripheral and its availability.
Why should I add some additional IC when I can get something "better" (read: something that has everything I want from the beginning) for the same price without any drawback?

Just a script-set isn't really what you want/need... maybe as a start, but at some point, you want to have nice graphic.

I'm more about automation and so graphic and user-data fields and mousing is definitely not what I want.  and not my focus at all.  there are already too many graphical this and that and you can always make one IF you have a raw get/set interface that works.

json as the language and rest over port 80 as the transport is, again, a great way for automation to work network-wide.

before that, usb and serial to local systems made sense.  gpib was like that, too.  but now I see the world as networked and with things being able to send a get or set and get a simple ascii json reply back.  if you give me that, I can do anything after that.

if you give me graphics and user clicky, I have no desire to try to automate it or even use it.  just being honest.

so again, my focus is entirely on a sane remote api (json over rest) and while it wont be directly usable by scpi style clients, that's not a problem for me.  I just want the timestamped data so that I can do things with it myself.

Trust me, I made all this because IMHO everything not automated is a big problem from a business perspective... just leaves too much room for mistakes.


This software is not about "clicky". It automates several workflows you need for emc-testing (and some others).
BTW: "clicky" can be a way of automation (eg. generating default templates with 1 click instead of some commands on the shell).

But again...there are different use-cases

I don't care about the interface, I just don't see good use of REST in a situation, where you strictly have to have only 1 connection/session at a time.
If you corrupt data because you started by accident some other workflow that also uses a test-instrument, you did something terribly wrong in automation!

Additionally, this potential wifi-connection needs crypto.
There's no excuse to have some non-ssl service in 2024!

So a simple Websocket over HTTPS should be perfect.
You just accept a single connection and forward all bytes from/to the existing datastreams.

73

[WaveyDipole]

Well after a long spell of illness during December and most of January, I have finally managed to push the latest release out.

I'm sorry to hear that. I hope you are feeling a bit better now.

Thank you. Recovery has been a gradual recovery, but I am slowly getting there and almost back to a normal routine.

It is limited by the int variable used to store its value in EEPROM. In the original code the limit was even smaller. When I extended it, I thought 30 seconds was reasonable and not likely to be exceeded. The reason why an unsigned long is being used in the handshaking routine is because the value is being compared to millis, which is also an unsigned long. I am not fortunate enough to have an 8-digit meter, but there is no reason why a larger variable could not be used in the config struct to accommodate longer time periods. Of course that would require re-saving of EEPROM contents.

Thanks, but Gertjan's suggestion put me on the right track. I tell the meter to assert SRQ when it has a reading ready and then handle it with ++srqauto. Much more efficient!

Fair enough.I am glad to hear that the SRQ feature is being used and is actually useful!

BTW, I can add support for the ESP-S2 to my project. I just need the pinout details.

Well, I made a pull request... https://github.com/douardda/AR488-ESP32/pull/1
My repo: https://github.com/WilheJo/AR488-ESP32

Indeed. I have discovered that David Douard has added the ESP32 (and STM32) layout configurations to the platformio.ini file. I can pick them up from there and add them to this project.

I have now retrospectively added the ESP32 pinout configurations from the forked projects to this project. It should be noted however, that David Douard's version has flags to enable use of PSRAM and the built-in Bluetooth feature on the ESP32, which I have not implemented yet.

I do lots of web REST interfaces for the esp (8266 but I can move to esp32).

not graphical, but pure REST interfaces (gets and sets via simple routes or paths).

PM me if you want to discuss.

I did consider doing something with MQTT a while back. I had experimented with it for another project and it seemed useful, however that idea took a back seat. In any case, it would require an MQTT broker, e.g. running on a Pi or on the PC which adds a little complexity. I haven't really worked with RESTful APIs yet. Interesting idea though.

Additionally, this potential wifi-connection needs crypto.
There's no excuse to have some non-ssl service in 2024!

I tend to agree, even did back in 2020 when I first had a look at this. At the time it was feasible to set up a HTTPS server on an ESP32. It is a bit more complex because you have to create and set up an SSL certificate, but it does work. Encryption is expected these days. Unfortunately, at the time, unlike the ESP8266, the ESP32 SDK did not appear to have a native WebServerSecure library, only WebServer which was clear text. A third party library called esp_https_server library was available and could be used but was still in development. The syntax and methods were different from the ESP8266 version, so the code ended having to be almost totally re-written to work on the ESP32. Eventually I ended up with a working prototype (2 or 3 actually), but it felt rather less responsive to requests than the equivalent running on the ESP8266, which is odd since the ESP32 has hardware to run the encryption, whereas the ESP8266 had to do this in software. I plan to re-visit HTTPS on the ESP32 in the not too distant future.

[wilhe_jo]

Well after a long spell of illness during December and most of January, I have finally managed to push the latest release out.

I'm sorry to hear that. I hope you are feeling a bit better now.

Thank you. Recovery has been a gradual recovery, but I am slowly getting there and almost back to a normal routine.

It is limited by the int variable used to store its value in EEPROM. In the original code the limit was even smaller. When I extended it, I thought 30 seconds was reasonable and not likely to be exceeded. The reason why an unsigned long is being used in the handshaking routine is because the value is being compared to millis, which is also an unsigned long. I am not fortunate enough to have an 8-digit meter, but there is no reason why a larger variable could not be used in the config struct to accommodate longer time periods. Of course that would require re-saving of EEPROM contents.

Thanks, but Gertjan's suggestion put me on the right track. I tell the meter to assert SRQ when it has a reading ready and then handle it with ++srqauto. Much more efficient!

Fair enough.I am glad to hear that the SRQ feature is being used and is actually useful!

BTW, I can add support for the ESP-S2 to my project. I just need the pinout details.

Well, I made a pull request... https://github.com/douardda/AR488-ESP32/pull/1
My repo: https://github.com/WilheJo/AR488-ESP32

Indeed. I have discovered that David Douard has added the ESP32 (and STM32) layout configurations to the platformio.ini file. I can pick them up from there and add them to this project.

I have now retrospectively added the ESP32 pinout configurations from the forked projects to this project. It should be noted however, that David Douard's version has flags to enable use of PSRAM and the built-in Bluetooth feature on the ESP32, which I have not implemented yet.

I do lots of web REST interfaces for the esp (8266 but I can move to esp32).

not graphical, but pure REST interfaces (gets and sets via simple routes or paths).

PM me if you want to discuss.

I did consider doing something with MQTT a while back. I had experimented with it for another project and it seemed useful, however that idea took a back seat. In any case, it would require an MQTT broker, e.g. running on a Pi or on the PC which adds a little complexity. I haven't really worked with RESTful APIs yet. Interesting idea though.

Additionally, this potential wifi-connection needs crypto.
There's no excuse to have some non-ssl service in 2024!

I tend to agree, even did back in 2020 when I first had a look at this. At the time it was feasible to set up a HTTPS server on an ESP32. It is a bit more complex because you have to create and set up an SSL certificate, but it does work. Encryption is expected these days. Unfortunately, at the time, unlike the ESP8266, the ESP32 SDK did not appear to have a native WebServerSecure library, only WebServer which was clear text. A third party library called esp_https_server library was available and could be used but was still in development. The syntax and methods were different from the ESP8266 version, so the code ended having to be almost totally re-written to work on the ESP32. Eventually I ended up with a working prototype (2 or 3 actually), but it felt rather less responsive to requests than the equivalent running on the ESP8266, which is odd since the ESP32 has hardware to run the encryption, whereas the ESP8266 had to do this in software. I plan to re-visit HTTPS on the ESP32 in the not too distant future.

Wolfssl sems to be able to create self signs certificates on fly.
So you could have a partition holding certs for the IP addresses you get via DHCP...or the new key algorithms you get via updates.

The question is if someone needs this ...

Anyhow, I still would opt for a transparent (web)socket.
This would allow the existing software to use this minimal (if at all) changes.
I mean redirecting serial data via some TCP socket is nothing new...

Regards

[WaveyDipole]

I spent quite a bit of time investigating the HTTPS on the ESP32 and the situation seems rather discouraging from an Arduino IDE perspective. The Hessel esp_https_server library does not appear to have been updated for 4 years although it has arrived at a full version 1.0.0 rather than the point versions I was working with previously. It uses various encryption and webserver library components contained in the ESP32 SDK, but since these have been updated as time goes on, when you compile even the basic examples on Arduino, you end up with errors about missing files and warnings about deprecated and superseded library components. As the SDK moves forward, this will only become increasingly problematic unless someone forks the Hessel project and develops it further. I did initially try to make some adjustments to the library code, but things just went into a deeper and deeper mess. Its going to take a lot more time and knowledge than I have at present to update the library and bring it into line with the current ESP32 SDK version and then maintain it.

Another possibility would be to switch to working with Vscode and the Espressif ESP32 SDK framework rather than Arduino framework, which would be something of a learning curve. I already use Vscode, but have never worked directly with the Espressif framework, although I expect that anyone who is serious about programming the ESP32 does this already.

Previously I met with resistance trying to switch the project to Vscode and I appreciate that some may be more comfortable with the relative simplicity of the Arduino IDE rather than having to learn a new IDE environment. It is for this reason that I have kept the core project as and where it is. Of course, it is possible to maintain Arduino projects in both environments simultaneously, but out of of necessity, the ESP32 code would have to diverge. For this reason, a separate ESP32 version of the AR488 project might be the best way forward and such a project, created by David Douard, already exists.

The bottom line is that whereas it would be relatively simple to create an HTTP interface for the ESP32, implementing HTTPS as would be expected from a modern web interface is an entirely different problem. Quite why Espressif implemented an ESP8266 compatible WebServer library but omitted the WebServerSecure conterpart is something of a mystery. Perhaps it was easy to port WebServer as it is just software, but for the secure version, since the ESP32 hardware includes hardware encryption, porting it would likely require rewriting the encryption code and they perhaps didn't want the hassle of doing that and then maintaining of a separate fork of the code? Who knows.

Wolfssl sems to be able to create self signs certificates on fly.
So you could have a partition holding certs for the IP addresses you get via DHCP...or the new key algorithms you get via updates.

Thanks. I will have a look at WolfSSL and I see that is is available in the Arduino IDE. Having a separate partition is what I had in mind with the intention of containing the certificate and the served up web pages. Of course, just for a plain SSL connection, the certificate and maybe the a config file would suffice.

Anyhow, I still would opt for a transparent (web)socket.
This would allow the existing software to use this minimal (if at all) changes.
I mean redirecting serial data via some TCP socket is nothing new...

That's starting to look a more likely option, especially if I can get that connection SSL encrypted. Authentication and sending/receiving data over an encrypted TCP connection is one requirement, some form of protocol for submitting requests/queries is another and I guess REST might be one option for that.

[linux-works]

for some reason, I'm not overly bothered by the fact that controllers dont support native encryption like 'real hosts' do.

you're also on wifi and that's not super secure, either.

lets remember what we're doing.  this is test and measurement.  how 'secure' do you have to be?  no one's running finance apps on a microcontroller.

if I ever need more than the esp-style controller can do, that bumps me immediately up to a linux host of some kind (often an arm system).

I still prefer the instant boot and lack of backdoors (...) that simple controller systems offer.  managing a bunch of esp chips is so much easier than even one linux box (and I'm a multi decade sysadmin for unix).

[wilhe_jo]

Well, the esp can do SSL. It has hardware for good random numbers.
So it's actually 'just' a matter of figuring out how the cert should look like.
The result would be a self provisioning system.

ATM, I have some different tasks, that have priority, but I guess that would make an interesting project.

I don't really like Arduino and platformio... But I get the point why it's used here... It's just convenient to support many targets. However platform features are a problem.

So I agree that the WiFi interface is better implemented in the esp32 centric fork.

73

[linux-works]

even after all these years, the arduino ide build system is not muli-cpu aware.  it does not do the simple 'make -j8' kind of thing.  builds take forever.

but I still use their system since the end result is what I care about and the system is livable.  libraries are mostly all there and so are examples.

none of it is pro level but it can be if you put time in it.  and if you lock down the libs once you fix them