An AR488 based calibration system project - Page 1
Forum section: electronics / general

author: rhb
author_rank: Super Contributor
timestamp: July 27, 2019, 12:31:06 am
content: @vindoline suggested this belonged in the USA Cal Club: Round 2 thread. However, in writing this I realized it really is a thread of its own.for prior context start here:https://www.eevblog.com/forum/projects/ar488-arduino-based-gpib-adapter/msg2565660/#msg2565660As a use case consider checking my RF gear. I need to step through a series of frequencies and power levels and feed the output of my 8648C to the spectrum analyzers, frequency counter and power meter. I could use a splitter to feed the SAs and counter, but I need to use an SMA relay to feed the power meter. My 8560A can't check 8648C harmonics of 3 GHz, but the 8566B can. By switching the 8548C to the 8560A, 8566B, 5386A and 438A in sequence using SMA relays I can check them all against each other. At each step of the 8648C I'll want to step the attenuators and ranges on the 8560A and 8566B. That's a *huge* amount of work to do manually. What it needs is a host PC program that reads tables in CSV format which describe each step in the test sequence.With a GPSDO feeding the counter all I need is a good cal on the 438A and one the power sensors. Ideally that could come from a fast rise time square wave tied to the primary voltage reference and a limited range Kelvin-Varley divider. So all that would need a regular cal is the voltage reference and the divider. Everything else would be derived from those by first principles. The GPSDO either works or it doesn't.TiN is critical of using relays, which is quite legitimate at the level of accuracy he's pursuing. But he doesn't do RF and I don't need basic voltage and resistance accuracies below 10 ppm. In fact, I'd be hard pressed to come up with a use case that required 100 ppm. My goal is to be able to do an annual cal of my own bench without it requiring so much effort I don't do it.If the relay selection is not built into AR488, then I either need a GPIB relay controller or I need to control two USB devices. AR488 can be a controller or a device. So a GPIB controlled switching unit needs all the functionality of AR488. I have three 44421A boards with terminal blocks, but nothing to drive them yet. So a Mega controlling those would give me 60 channels. That's overkill for the lab cal application. But being able to use the same FW base for a bare bones GPIB-USB interface, an enhanced version able to control a small number of relays for the cal application or a GPIB port scanner device by simply changing compile time flags seems to me a very sensible thing to project. It scratches the itch.I bought a $40 GPIB-USB device on Amazon, but it was Windows only and would not work on Win 7 Pro 64. I've been rather less than enthused about buying one of the flood of counterfeit HPAK and NI devices. Via the Cal Club I discovered a good solution, the AR488 FW.my primary concern at present is simple. Is there other functionality which would be desirable? I do things in small steps and test at each little step. But knowing where I am going is important. It's painful to realize you have to discard a bunch of work because you didn't recognize a fundamental limitation in the initial design.Have Fun!Reg

author: maxwell3e10
author_rank: Frequent Contributor
timestamp: July 27, 2019, 05:11:42 am
content: I had some discussions with WaveyDipole about possible ways to soup-up the AR488 program earlier in that thread. Basically the idea is to move to it as many functions that would normally be performed by the computer as possible. As a simple example, it can read data from a meter at a fast rate, average them and output to RS232 at a slower rate. Or, closer to your application, perform a scan of frequencies, while periodically switching ranges or relays, and outputting data that can be logged directly to a file.From programmatic perspective, one needs to add just two basic functionalities: 1) a string to number conversion, so some responses from the GPIB device are intercepted by the program to perform arithmetic operations and 2) a more clear loop structure to be able to alternate between an internal loop and external commands. With a few such generic functionalities, one then should be able to program more specific applications.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 05, 2019, 11:07:54 am
content: The first step would be to identify whether the data being sent back from the instrument is a measurement or reading. If one were sending ++read commands, then the expected response ought to be a measurement and the command handler could flag it up. Its a bit more difficult when you send meas? or other direct scpi command as this is being treated as data being sent to the instrument. So now we might perhaps need to not only look for ++ commands but look for SCPI patterns as well.Next we need to decipher the format of the data being sent back from the device, and as we know all meters and devices use a standard format... So assuming the reply is a simple one line measurement, then we need a flexible parser that can pick out the digits, exponentials, polarity (+/-) and possibly the measuring unit if available then do the processing (min/max/avg etc) and finally pass the information back to the host computer. It is not impossible, but not straightforward either. Intercepting and storing the responses from the GPIB device is the easy bitIt is something I am willing to look at, but it may take some time to develop.

author: LazyJack
author_rank: Frequent Contributor
timestamp: September 05, 2019, 12:28:47 pm
content: Well, my 2cents. AR488 should remain what it is, a GPIB interface. I would very much refrain from building all kinds of functionalities into it, for several reasons. First of all, simple is beautiful and well maintainable, working. If one starts adding functions to it, it will end up people requesting all kinds of all stuff and finally we'll end up with some extremely complicated poor man's labView somehow crammed into an arduino. Which will first start migrating into larger and larger arduinos, then into RPi,s and by that time we'll have commands like ++calculate_phase_noise_at_10kHz_while_averaging_daily_drift.If we really need hardware, because we cannot do something in the software that drives the whole test setup, we should have a separate, highly flexible and configurable measurement controller (opensource of course). Or simply write the stuff in labView or any similar function package.

author: maxwell3e10
author_rank: Frequent Contributor
timestamp: September 05, 2019, 01:49:20 pm
content: Most people don't have Labview for hobby use. One typically uses EZ-GPIB or Python. Certainly one can do most things with them using a host computer, but having a tighter time control of a dedicated processor can be an advantage.There is a danger of feature creep and it would be hard make a parser that works with all responses. But just like with EZGPIB_ConvertToFloatNumber, one can use a few primitives to construct macros for a particular application.

author: rhb
author_rank: Super Contributor
timestamp: September 05, 2019, 10:48:04 pm
content: I'd be very uncomfortable with adding parsing of instrument responses to AR488. I very much doubt that you could get a parser with decent error handling in even an ATMEGA 2560.With Pis and Beagles as cheap as they are, I think that processing of instrument responses should be done elsewhere. The ATMEGA compute cycles are better used speeding up communication with a host.I finally completed a 2 device Uno based interface. It still needs an enclosure. I got severely sidetracked by the nanoVNA. I'm going to implement ++temp to read the ATMEGA internal temperature sensor, but that's probably as far as I will go until WaveyDipole completes the work he is doing.While he does that I'll build a 2560 based unit and set up my HP 16500 logic analyzer so I can verify bus timing, etc. Once he is done I'm going to write a Makefile system to build and test AR488 and also generate .ino files for various targets using different pin choices. For example, it would be nice to be able to take a headerless Uno or Mega, install a 24 pin header and then connect GPIB devices via ribbon cable and IDC connectors.My goal is to maintain full compatibility with existing devices, simplify porting to new devices and provide comprehensive testing. The only functionality I want to add is a real time clock, temperature and humidity sensing, relay control and an external trigger strobe for devices which accept that. One can sense the 328P internal temperature sensor and there is one pin left to provide a trigger signal on the Uno. Everything else will require a 2560. I am more than slightly OCD about software quality. I wrote a pair of 15,000 line libraries, one a parser built with lex and yacc, neither of which ever had a bug reported in over 12 years of heavy use before the package was retired because of obsolescence.