So is 5V recommended where possible?
I used 5V and I think of GPIB as a 5V bus, although you might get away with 3v3.
Note that the important difference between 3v3 and 5v pro micros is not the voltage, which can be fairly easily changed, but the crystal. If run from 3v3 you can only use 8Mhz, so a 16MHz 5V version can't just have the regulator enabled / added.
If you use 3v3 / 8Mhz , also note when you program it that you need to choose an 8MHz board version. I'm not sure if the USB will work if you misconfigure it. Certainly delays and serial baud rate will be wrong.
If iot will work at 3v3 with no buffers that's useful as the pro micro has got very much more expensive than it used to be, and a cheaper alternative would be good.
I have a problem getting AR488 running on a Arduino Pro Micro, 5V version (I also have a Nano and no problems there).
I use AR488 ver 0.51.18. Building and uploding to the Pro Micro works fine. The Pro Micro shows up as serial port 18 in the terminal program. The terminal program does not complain when making a connection. But the Pro Micro just does not react on commands - 0 bytes received - regardless what I send (e.g. ++ver should produce an output and does with the Nano).
Any suggestions what I could try to get it running?
Try a minimal echo program that echoes every character received. For each character received, toggle the LED. When you upload and get nothing back, you can detect by the LED if its receiving characters and fails to send. I have one chinese board that is "unreliably" sending characters. You can program it most of the time, verification usually fails and you get a lot of garbage or nothing back from the board.
An echo program works (also at 115200-speed). Moreover I tried with two different Pro Micro. They however are from the same source.
I found the problem. In the source, as coming from github, there are two Arduinos defined for the 328P architecture:
/*** UNO and NANO boards ***/
#elif __AVR_ATmega328P__
/* Board/layout selection */
#define AR488_UNO
#define AR488_NANO
//#define AR488_MCP23S17
//#define AR488_MCP23017
Following the instructions that only one per architecture should be uncomented, the code worked on the Pro Micro. Why this affects the Pro Micro, but was no problem with the Nano, is strange. Well the important thing is it works now.
I found the problem. In the source, as coming from github, there are two Arduinos defined for the 328P architecture:
I am a little bit confused as the Pro Micro doesn't use a 328P, it has a 32U4 (Leonardo compatible). So it should never go through that path for the Pro Micro...
I know. Therefore I wrote it is a strange behaviour.
I produced/populated two boards based on user Jay_Diddy_Bs design:
https://www.eevblog.com/forum/projects/ar488-arduino-based-gpib-adapter/msg4483507/#msg4483507, many thanks
The sourcecode was changed accordingly as described in the SN7516x GPIB transceiver support-section.
Im able to control a Keysight 33509B Function generator just fine, but have trouble with reading/querying any response from a device like a DMM.
So i can control for example the voltage range of a Keysight 34401A and 34465A and they show a measurement when sending "MEAS?", but both wont send back the measurement in any ++eos/auto/read-configuration and *IDN? also wont get me any response.
Does anyone know what i might be doing wrong?
The parts i used are all from Mouser, so i dont suspect defective hardware.
Edit: Found the error. The //#define SN7516X - modifications had to be done in the config-file, not in the .ino itself, duh.
Anyone here with a 3458A?
Everything works so far, but i cant get a nonblocking method to work with the AR488 attached to a Raspberry Pi:
I want to use STB? to poll available measurement data, so that i can do other stuff while the 3458A takes its sweet 4s time for each 100NPLC-sample.
Alternatively a RQS-solution might work, but cant get that to work also.
Any idea what im doing wrong? Apparently the 3458A never sets the weighted sum of the STB to >=128, while this method worked a few years ago with a GPIB-USB-HS-adapter.
Attached are a code snippet that reads x samples at selectable NPLCs of 1/10 or 100, tested, works.
The attached SRQ-method doesnt work for me..then again im a really bad programmer.
Any idea what im doing wrong? Apparently the 3458A never sets the weighted sum of the STB to >=128, while this method worked a few years ago with a GPIB-USB-HS-adapter.
You're never reading the status byte inside the while loop. You're reading the SRQ line with the ++srq command, which can only return a 0 or 1 (SRQ not asserted or SRQ asserted) so naturally, when you test that value, it will never be 128. Instead, try using the ++spoll command ("++spoll 22\r\n" in your case). This should give you the value of the status byte for your instrument.
Got a bit of an issue and would like to ask for debugging help. I tried using TestController over a Nano based AR488 with an HP 34410A DMM connected to a laptop and it doesn't work.
Using the AR488 Utility it is possible to talk with the nano and to identify the DMM configured at address 1 on the GPIB.
Date,COM #,Status,Message
9:33:02 pm,COM7,Send,++ver
9:33:02 pm,COM7,Recieved,"AR488 GPIB controller, ver. 0.51.18, 26/02/2023"
9:33:11 pm,COM7,Send,*idn?
9:33:12 pm,COM7,Send,++read
9:33:12 pm,COM7,Recieved,"HEWLETT-PACKARD,34401A,0,9-5-2"
However using TestController (latest verion) it cannot identify the DMM
;; AR488 B:1 Device HEWLETT-PACKARD,34401A, do not match: null
Tried a second nano on the same PCB and same issue. The PCB seems ok, no shorts, solder joints are fine and connections from arduino to the GPIB connector measure ok.
I've been using a Pro Micro based AR488 with the same HP 34410A DMM on the same laptop and that just works fine. Therefor I think my software is configured correctly. AR488 Utility gives exactly the same reply and TC configured according to the different virtual COM port van identify the DMM and return measurements fine:
;; Found Agilent 34401A on AR488 A:1
For what it's worth 1: With the Nano the first ++ver message sent always fails. Subsequent messages all work. With the Pro Micro the first message never fails.
For what it's worth 2: The Nano is new old stock and having the 'old' arduino bootloader.
For what it's worth 3: On the Pro Micro the send and receive LED's seem on all the time. Not with the nano.
I tried using TestController over a Nano based AR488 with an HP 34410A DMM connected to a laptop and it doesn't work.
Using the AR488 Utility it is possible to talk with the nano and to identify the DMM
......
However using TestController (latest verion) it cannot identify the DMM
I have seen this problem mostly with Chinese Nano clones. They are still rebooting during the TC init, and are not ready in time for answering TestControllers *IDN? question.
The solution is to add a extra line in the 34401A device definition file:
#resetDelay 3.5See the TestController documentation:
https://lygte-info.dk/project/TestControllerConfigDevice%20UK.html#Arduino_startup_resetRegards, Gertjan.
Just wanted to note that I just made a pull-request to the ESP32 repo to introduce ESP32S2 support.
General support has already been there - what's new is the support of the USB-peripheral in the ESP32-S2 module.
This allows to build simple and small adapters.
I attached photos of my first rev... it features ESD protection and programs via the internal USB and uses the same for comms.
Of course, rev1 has some medium d'oh... so there will rev2 in the close future.
Maybe this one will get open-hardware (I need to check all the 3d models, footprints,... to see if there's some licensing/copy-right issues).
If there's some additional demand (I guess, I'll need 10 for my museum...ähhh... lab to get rid of all these GPIB cabling), I could make my batch bigger.
Regards
even some PRO may give you problems there is some who have different boot-loaders for 32u4 chips ... and they way to make them work ... and they where a nightmare to fit in arduino ide ...
just to let you know ..
I have seen this problem mostly with Chinese Nano clones. They are still rebooting during the TC init
Tried those delay settings to no avail unfortunately.
there is some who have different boot-loaders for 32u4
Yes, Coromonadalix, and for the nano too. Your message gave me the indirect hint to try selecting an Arduino Uno as target in the IDE as that is near the same as the Nano except for the physical size. And that made it work!
The nano with the old bootloader appears to be in a frantic reboot loop. This issue was mentioned before already in this thread, but of course one has to read that particular message from a year ago and make the link to this case.
Bright thoughts to everyone! I tried to compile the project in ArduinoDroid application for sndroid smartphones and I'm getting a lot of compilation errors. the project is not going to happen.
https://github.com/Twilight-Logic/AR488/issues/42I also tried to compile the project in the Arduino IDE online editor - the project is assembled but does not generate hex code.
Can anyone help me by uploading for me the HEX file for Nano on atmega328 here or other sites? I don't have a computer, just a smartphone, so I can't use the Arduino IDE standard
Can anyone help me by uploading for me the HEX file for Nano on atmega328 here or other sites? I don't have a computer, just a smartphone, so I can't use the Arduino IDE standard
See attached.
I didn't know it was possible to flash an Arduino from a smartphone...
Just wanted to note that I just made a pull-request to the ESP32 repo to introduce ESP32S2 support.
General support has already been there - what's new is the support of the USB-peripheral in the ESP32-S2 module.
This allows to build simple and small adapters.
I attached photos of my first rev... it features ESD protection and programs via the internal USB and uses the same for comms.
Of course, rev1 has some medium d'oh... so there will rev2 in the close future.
Maybe this one will get open-hardware (I need to check all the 3d models, footprints,... to see if there's some licensing/copy-right issues).
If there's some additional demand (I guess, I'll need 10 for my museum...ähhh... lab to get rid of all these GPIB cabling), I could make my batch bigger.
Regards
Thanks. I will have a look at that.
There is actually already a fork of this project targeting the ESP32 which adds a couple of additional protocols. You can find it here:
https://sr.ht/~douardda/AR488-ESP/I would like, at some point to add those features to this project but haven't had a chance to analyse the code in detail. Maybe I will get some time this winter....
Bright thoughts to everyone! I tried to compile the project in ArduinoDroid application for sndroid smartphones and I'm getting a lot of compilation errors. the project is not going to happen.
https://github.com/Twilight-Logic/AR488/issues/42
I also tried to compile the project in the Arduino IDE online editor - the project is assembled but does not generate hex code.
Can anyone help me by uploading for me the HEX file for Nano on atmega328 here or other sites? I don't have a computer, just a smartphone, so I can't use the Arduino IDE standard
Also didn't know it was possible to compile on an Android phone. Must have a look at that!
BTW, I have seen and responded to your logged issue.
Hi folks,
I am lately experiencing trouble with the HC-06 Bluetooth module, which I have hooked up to the AR488 adapter.
The AR488 works flawlessly, but the HC-06 seems to drop data packets. The number of bytes received on the PC side is quite often less than the number of bytes sent by the AR488. To double-check I had replaced the HC-06 by a USB to serial adapter and no problems there.
Has anybody experienced such a problem with the HC-06? Any ideas what the cause could be?
Tom
I think I have found the problem:
My latest batch of HC06 modules appears to be built with faked chips.
These only work without data loss up to 57,6 kBaud!
An earlier batch of the same modules from a different supplier shows no problems at all at
115,2kBaud.
SO BEWARE OF FAKE MODULES!
Tom
I think I have found the problem:
My latest batch of HC06 modules appears to be built with faked chips.
These only work without data loss up to 57,6 kBaud!
An earlier batch of the same modules from a different supplier shows no problems at all at
115,2kBaud.
SO BEWARE OF FAKE MODULES!
Tom
If you have a sample from both batches maybe you can publish a side by side picture to help future users chose them properly. Of course, if they're identically looking then is a tough choice.
Cheers,
DC1Mc
If you have a sample from both batches maybe you can publish a side by side picture to help future users chose them properly. Of course, if they're identically looking then is a tough choice.
Both HC-06 modules are looking identical. They can be distinguished by querying the firmware version:
Good:
AT+VERSION
hc01.comV2.0
Bad:
AT+VERSION
OKlinvor
V1.8
But the bad one may also just be a clone of a working linvor device. Anyway, reducing the baud rate on the HC-06 and the AR488 adapter to 56k also fixes the problem.
Tom