Measurement Control - Direction 2.

There are lots (or you can call nothing) happened since the last post regarding my measurement control application.

Name

I didn't like the random names I gave to this solution (Control software, interface, anything). Didn't look and feel professional. Finally I found a name for it: MeasureFlow

Registered a domain for it:

measureflow.org

(nothing there yet)

A github and a gitlab group:

https://github.com/MeasureFlow

https://gitlab.com/MeasureFlow

Software

I have the direction (partially). The software was plug-in based, but not other ways modular. I decided to architecturally separate the application to frontend and backend. The backend will be dotnet 6 based minimal REST API. The frontend is still question.

Started to write the backend. As the codebase doesn't need too much porting until we just talking about the instrument continuous measurement and not a complex workflow. So it is almost working (just didn't try out the last pieces yet)

Hardware

The ordered PCBs arrived (both the USB-GPIB and the USB-RS232). I was so fortunate in this chip demanding times to find 10 ATMEGA32U4 locally.

I didn't find the time yet to solder and test. Anyway it need firmware, so it is useless until I resolve the firmware related questions.

Firmware

We arrived to the point, what cause most of the troubles to me in this whole picture.

During the last week, in my free time I mostly tried to understand the USBTMC based implementation I found online. I didn't become a big fan of it. No proper reusable implementation of the USBTMC interface what corelate to the LUFA design principles. It is based on a not finished, so fuzzy LUFA demo, bad handling of the AVR pins, weird off interface configuration handling.

Tried to understand, how it is work, how can I port to my hardware. Originally I just wanted to exchange the pin layout for my own hardware design, but I know now, I can't stop there.

Last Sunday then I finally realized the biggest problem I have with this whole thing. What I found was shocking to me. Root of the problems is not the implementation, but the standard itself.

The standardizing board was thinking completely differently than myself.

Their intention: create a solution on instrument side what able to wrap the existing GPIB interface while moving the development to the native USBTMC interface

My intention is to create a device what can sit between the USB and several GPIB based devices, handle sub addresses also.

At first read you may not find too much difference between this two. The difference is that the standard doesn't contains anything to address the GPIB devices. It presume that the USBTMC device with USB488 extension connected to the USB port is a single instrument and not many of it.

If I would just deal with instruments without GPIB sub addresses, I would may live with this, but unfortunately this is not the case. I've VXI mainframes, Power mainframe with GPIB sub addressing.

Even if I dig further neither HP (Agilent/Keysight) nor National Instruments who manufacture USB-GPIB interfaces use USBTMC with USB488 extension in their devices (HP 82357B, NI GPIB-USB-HS). They use standard base device USB ID or vendor specific. Those are proprietary.

Back to my unit. Here I should decide, what direction should I chose while developing the firmware of my adapter. Here are a few possible path I can think of:

1. Resume working on my USB-CDC implementation (based on Prologix command set). It has drawbacks like CDC is slower than the USB native bulk endpoints, on the host side I need to port my own driver to the MeasureFlow software, will not be compatible almost any of the existing host side software stacks.
2. Use AR488 firmware. In addition to all of the drawbacks above, I need to implement the subaddressing (or secondary addressing), in their codebase as it still not implemented yet.
3. Mimic HP or NI interface. This is problematic from various standpoints. Lots of USB sniffing, possible copyright issues, etc.
4. Develop a USB composite device - check with poc if Keysight IO library supports this. The concept is to have one CDC device used as control channel (manual device setup, SCPI emulation, etc.). Generate dynamic USBTMC device for each GPIB device (primary and secondary address) based on automatic device discovery or manual setup.

Currently it looks like that the last one is the target, if I not run into unresolvable issues.

New Arrivals 3. - feels like Christmas

After the EU eliminated the €22 tax free limit for the incoming goods (I don't know if this was the reason), AliExpress changed the delivery method. They are collecting the things you ordered from various suppliers and put those to a single envelope. You get the envelope faster, from a trusted courier and not from the local post.

The packages inside. I feel like Christmas with many presents

Now, check, what is inside.

Binding posts and switches for my front panel project (https://pakahuszar.blogspot.com/2022/01/hp-e1300a-front-binding-posts-1.html). As those are here, I can take a few measurement to check, everything is in order with my design, and I can order the boards for it.

I'm using replacement fans in the E1300A originally designed for PCs. I'm not a big fan of  cutting the plugs from it and replace with the E1300A compatible one (yess, I'm an idiot). So I ordered connectors. With those I can create converters between the fan connector and the connector on the E1300A power board.

Back in December I bought a Keithley 236 SMU (didn't write about it here). It has triaxial connectors. Unfortunately, it is not easy to find (or cheap) triax connector or double shielded cable (the one has insulation between the two shielding layers). I think a bit further. The SMU measure between the inner core and the first shield. This means insulation between the poles, what is capacitance and therefore leakage current (yes, it is just picoamperes, but it has impact on the measurement at the levels where the SMU is working). So what if I use instead two cables shielded separately, and put those into a single external insulator.

For this I bought some pigtail cable for this. It is so tiny (1.3mm diameter), that I have doubts if I can work with it.

We will see, when the connectors also arrive.

In my free time, I'm still working on my measurement control software. On the side of trying out as many instruments as I can, I also want to test it with various GPIB interfaces (just USB based ones right now).

So I ordered an NI GPIB-USB-HS (I already have an Agilent 82357B).

From the packaging, markings it totally looks like original.

And the funny thing. It came from China, but it is manufactured here in Hungary.

And the last item for today.

I scored this unit locally for ~$20. I mainly bought it for the case itself (a solid modular eurocard size enclosure). It contains also a 24V PSU, four TDA2030 based power amplifiers and several connectors.

I plan to use the enclosure for my long abandoned (hopefully restarting) Curve Tracer project.