GP-IB 3.

More than two month elapsed since I wrote about my GP-IB adapter project.
In this two month many things happened:
Hardware:
Redesigned the board a bit (v1.1). The new version is a bit tricky. Originally I used female gender connector, what is not ideal, as it cannot be connected to the instruments directly, just through a cable. The reason: I didn't find male connector on the market on first trial for affordable price.
I had a second attempt, and now I have male connectors. I didn't wanted to put to much effort in the redesign, so just added an option to swap the USB connector to the back side of the board.
So if you populate the board with female GP-IB connector, both the connectors goes to the front side, if you use male connector, both of the connectors are goes to the back side.
This board is not ordered yet, because I want to combine it with other projects of mine.
Git:
The repository has been reorganized. I have public and private repos. Public for sharing the project, private for working on it. Now the public repo only contain the hardware design (more to come). The design packaged with my shiny new KiCAD packager. At least it makes the schematic readable to anybody. Location: https://gitlab.com/suf/suf-electronics-gpib
Software:
The software side become a bit messy.
I had problems with the original source code:
1. The original license, what makes the software "incompatible" with my design
2. As much I read this source code, more and more dislike it. Using a single .ino file, for a growing size project become unreadable, unmaintainable to me.
3. Many thing is missing from the implementation.
I started to write a completely new software based on my problems. I wasn't carefully looked around for the software implementation. My software was 50+ percent ready (mostly working already) when Szabolcs Szigeti in the comments on my post here https://www.facebook.com/groups/muszerek/permalink/2481846092072731/ pointed out (sorry, it is in Hungarian), that a different implementation also exists https://github.com/Twilight-Logic/AR488
I didn't tested it yet, but looks like solving most of my problems:
- The author by coincidence has chosen the same pins for the ones was missing from the original implementation as me (REN, SRQ). This means, this software should run without modification on my hardware
- Implemented most of the missing functions
I still have my feelings with the code structure (it become more than 3000 lines in a single file)
I had no time to test it yet, but if I can use it for the purpose I wanted, I'll probably drop (or postpone) my implementation (maybe just finishing the inevitably necessary things and release it).
Next:
- Try the things I currently have
- Order and build the upgraded design
- Decide the future of this project

KiCAD packager

As I mentioned previously here: http://pakahuszar.blogspot.com/2019/07/chain-of-events.html
I started to write a program for KiCAD ot package the projects and overcome the problems when I share my designs.
Released a working (but probably buggy, and incomplete code) here: https://gitlab.com/suf/packagekicad. Please use the 0.2Beta tag
It is able to build a new symbol library (others come later) from the current environment with all of the used components in the current design, replace them in the schematic file. So when you move the project trough source control or other way, anybody can open it without missing components. Yes, the rescue lib can handle this, but asks questions, and the original KiCAD gitignore remove the cache used for rescue lib. Also doesn't handle the unintentional library upgrades.
The documentation is not yet exists. So I just write the usage here:

dotnet PackageKiCAD.dll <project name/directory>
Options:
-R Recursive
-cl Clear local symbol table. Keep only the packaged library on the list.

I'm using TortoiseGIT for my projects. It allows to automate the packaging. So the project gets packaged before every commit, if configured.
This is what I've done:
Opened the TortoiseGIT interface and selected Hook Scripts

Added a new script:

The "Run when working tree path is under" should point to the repository root in question. That's it.
Further development is coming.

Chain of events

I always think, why I start more projects than I finish.
One cause is the chan of events. I start something, than something is missing is missing from it, what forms an other project, than I miss something from it - other project and the chain of events formed. Have several open things, nothing finished.
Check the current one:
I wanted to recreate my music listening environment. The first path is from vinyl.

1. Repaired the crossovers in my Mission 705 loudspeakers (replaced a few ancient Tesla caps)

2. Repaired my NAD 5120 turntable (removed the original built in cable, added a few RCA connectors, replaced the belt, adjusted the arm lift)

3. Wanted to build a new RIAA corrector. It is based on the award winning design from the '80s. Created by a local HiFi Magazine here in Hungary named HFM-I. Actually built it, but just wrote about it on my Hungarian language blog (http://it-pro-hu.blogspot.com/2019/02/hfm-i-ujragondolva.html, http://it-pro-hu.blogspot.com/2019/03/hfm-i-2.html, http://it-pro-hu.blogspot.com/2019/04/hfm-i-3.html

4. And here is the place where my "chain of events" starts. It came into my mind, that I'd like to measure what I built before put it into my system. Bought an HP 8903B Audio Analyzer (not just for this project, it was in my plans for a while already).

5. U1. I have a good set of instruments, but it wasn't a requirement to connect them to a PC until now (I was thinking, I'll do that once upon a time). For generating a graph from the 8903B it become absolutely necessary. Unfortunately didn't find a GP-IB interface what I like, so the first unplanned project born. Found an Arduino based interface, but absolutely hated the hardware, so designed a new one (http://pakahuszar.blogspot.com/2019/04/gp-ib.html, http://pakahuszar.blogspot.com/2019/04/gp-ib-2.html)

U2. Didn't like the software of the interface, neither the license, nor the implementation. Started to write a completely new code from scratch (still unfinished, it will be testable soon, if it doesn't end as unfinished project as many before).

U3. Somebody asked upon my posts, if I want to sell the GPIB interface boards I created. Started to think - why not?
If I sell it, I want to organize the hardware designs and the software correctly. Don't want to publish unfinished design, or software, so I built up a git branching model for myself to achieve this. Here surfaced my old problem again. The library handling of the KiCAD is horrible. I want to publish the hardware design without external dependency (I mean, if somebody opens the schematic, get real components instead of boxes with question marks). Tried to use KiCADs archive plugin. Unsuccessfully. Registered, but it not even started. After few days of searching, asking, got no solution.

So, the Unplanned-3 project born. Create an application (not a KiCAD plugin) what automatically manage this mess on my hardware projects (I started it in .Net Core 2.1, got some progress, but this is a topic for a further post)

Let see! This is one way how my unfinished projects are born.

GP-IB 2.

The boards are arrived a few days ago.

I made a few but not fatal mistakes with the board, and left a few room for improvement also:

• Cosmetic: the board designation is on a wrong layer
• Order: only ordered 5 boards (I think 10 would be the same price)
• Room for improvement: the board uses female IEEE-488 connector. With a few modifications it can be used with male connector also
• Room for improvement: proper mounting holes
• Room for improvement: isolated (it needs some investigation if it required)
• Room for improvement: buffering + bus protection

During the weekend I built and tried it out

The CH340G USB Serial interface was working for the first trial.
The ISP was working for the first trial - uploaded the Arduino bootloader.
The software built and uploaded without problem.
The communication via the terminal emulator with the firmware worked without problem.

Now go and get an instrument to try it out.
As I previously mentioned, I built this interface to communicate with my HP Audio Analyzer. This equipment is not a cheap one if we are talking about a home lab, so I didn't want to sacrifice for the first test. I have several HP 3478A multimeters on hand. Two of it even not part of my lab setup.
So, I tried to communicate with it.
Half success:
When I send a command to the instrument, it does nothing.
When I send a ++read command it responds with the value actually on the instrument's screen.
I was thinking, what could be the problem.
The original design pull down the GPIB PIN 17 (REN - Remote Enable) to the ground. In my build it is connected to one of the MCU pins, to be able to further develop the project. Naturally the original firmware doesn't handle this. So I added a few lines of code to pull the REN pin to low, and the system started to work immediately.

The first goal of this project successfully achieved. The design files of the board can be find here:
https://gitlab.com/suf/suf-electronics-gpib

As the owners license of the source code doesn't allow modifications, without consent, I'm not publishing the either the original source code or my modifications. I'm intend to contact the author to discuss about the license.

Last but not least:
Many thanks for Emanuele Girlando for his great work.

Home references - Resistance

It is a long standing dept for myself.
I bought a few Vishay S Series precision foil resistors to act as resistance standard for my home lab.
I was thinking what would be the best enclosure for them, and in the long thinking process finally the resistance standard process is shelved.
A few weeks ago finally I ordered small aluminum boxes and binding posts for this.
The boxes, binding posts arrived, so I put everything together. As this is a quite simple thing, so not too much to talk about. Here are the pictures:

Measured (the 4 wire mode here is unavoidable):

All of the four values (100 ohm, 1K, 10K, 100K) boxed, labeled:

After finished the labeling, I was thinking about, how can I protect the paper labels from the usual dust in the lab. Here come the advantage of being father of three school age kids. The transparent adhesive foil we use to protect the textbooks are perfect here (and I've tons on stock).

GP-IB

In the past years I collected a good amount of test equipment. I mostly using them as standalone instruments (except my PC based oscilloscope).
I recently bought this nice Audio Analyzer on the eBay

I realized, that most of the measurements I bought this unit for are require PC connection.
Even I found a software for it:
http://www.pmillett.com/hp_8903_software.htm

As most of a bit aging test equipment only have HP-IB/GP-IB/IEEE-488 interface for the PC connection. No USB, Ethernet, whatever today's fancy stuff.
Buying a decent GP-IB interface is not so easy/cheap today. Yes, I found a few on various sources, but was not happy with any of it. So I decided to build my own.
Found this project on the internet:
http://egirland.blogspot.com/2014/03/arduino-uno-as-usb-to-gpib-controller.html
Based on this, I designed a board:

Ordered it, so I'm waiting to arrive, to continue the project.

TCA530

My dear friend Peti Racz called me a few weeks ago. He asked for a Philips  TCA530 IC. This one is located in plenty of ancient radio tuners as power supply for the varicap diodes.
The IC is not in production for years now. It is only available on eBay for insane price. For $30-60 it is incredible and you not even know if it is genuine.
Fortunately there are circulating on the internet a few circuit what can replace it. He picked one for me, I looked around for explanation, datasheet, other notes to check if it is feasible. Corrected a few things on it based on notes and my thoughts.
My goal was simple. Didn't wanted to put a big wired in board, but something tiny, fits in the place of the original IC.
Here is the result:

It is just a bit larger than the original DIP-16 package, and substantially higher. I hope, it will fit.
Waiting for the result on the first tuner...