Measurement Control - Direction

Things are changing.

When I restarted my instrument control projects, I had a clear path ahead of me. Then I realized a few things, have to rethink the whole project, my view on it.

I found this project: https://github.com/xyphro/UsbGpib

This is exactly, what I need. I'm 90% sure now, that the firmware I developed for my own board is needless (issues can surface, when I try to adopt it to my hardware and software ecosystem, but it is highly unlikely).

My control software has an additional layer above the VISA. I was thinking to eliminate it, but figured out that I have some instruments on hand what uses HID, or proprietary USB based protocol, what I can't put under the VISA umbrella.

I have a big dilemma regarding the future development. I mean the desktop application of the measurement control.

The situation:

In the software development today is everything about the mobile, web and cloud. It is clear, the word is going to this direction. Even myself as a DevOps professional working on cloud based web projects for several years now.

But...

Always this disturbing "but".

But the instrument control in my hand is a bit different. What I see and feel, the instrument control, visualization applications are mainly not built around web technologies. Those are still desktop apps. I don't want to change this. It is more convenient to use this applications, easier to communicate directly with the hardware, etc.

I started to develop it in C# on .NET Framework with Visual Studio using WinForms. This platform where I have the most experience. If I keep my lazy attitude on it, I can keep it this way and just forget my dilemma. Actually I develop it to myself, so I not really need to care about it.

But something is itching in my mind. The technology above is getting outdated. I also use those projects for learning. So the question is: Which direction?

The other driving factor is Linux. Should I create a multiplatform app? For myself, not necessary. If others want also to use it, that is a requirement.

So the options I see now:

• Keep this, continue the development and just forget it?
• Move to the .NET 6, WPF, MVVM to have a never platform? This means no Linux support, the only thing I can hope, that somebody create a usable version of the MAUI on Linux.
• Move to .NET 6, and use some 3rd party UI (Avalonia or UNO Platform, QT, whatever)?
• Just forget the complete C# and .NET ecosystem and move somewhere else?
• Python has PyVISA for instrument control. I not really like Python, and still need to find a UI
• Java has desktop frameworks, but what to do with the instruments?
• Node.js has Electron, but the VISA support libraries questionable.
• Any other direction didn't pop to my mind?

I try to collect (at least partially) the requirements:

• Native desktop application
• Hardware communication (Serial, USB-HID, IVI stack like Keysight IO Library Suite, USB-TMC, etc.)
• GUI elements - Dialogs, Data Grids, Text controls, and most importantly charts
• Pugin architecture (the pugins for the instruments, communication platforms should be handled separately, need to be expandable)
• Network handling
• File system handling

Maybe there are more requirements. These ones I can see now.

So, If you have thoughts on this, please share with me! 

USB-GPIB Interface v2.1

 

This is a small upgrade, bug fix of my previous ATMEGA32U4 based USB-GPIB interface. The previous had some flows. It had collision between the bootloader LED handling and the GPIB signals. Completely mixed up the original Arduino signals to be able to use the interrupt handling of the processor. Also used a full 8 bit port for the data bus to be able to read/write once and not bit by bit.

• For this version I chose a bit different view:
• Try to stick to the original Arduino Leonardo pin configuration as much as I can
• Give up the interrupt handling except for SRQ line
• Kept the 8 bit data bus
• Made it configurable - you can choose between the pin config used by the AR488 project and the 8 bit data bus above (the AR488 version doesn't need custom bootloader)
• Keep the capability of the using the activity LEDs
• Added serial debug port

Later this design will be based on this adding the proper GPIB line drivers. This design is only capable to drive one instrument (maybe good for more, but I rather not try).

The schematic:

The PCB design:

The "exploded" 3D model:

Yes I know that the gender of the connector is not the correct on (but who knows today, what gender is appropriate), but I didn't find 3D model of it and It wasn't so important, just to represent the size for model design.

Here you can find the complete design:

https://gitlab.com/measurementcontrol/gpibinterfacehardware

With this design the number of finished designs in the group is rise to two so here is the time to order the PCBs.

New workshop

Finally it is official. It was a big fight with the bureaucracy at the local municipality to achieve this. I've a new workshop. It will be lot of money and work until I can move in (I expect a few month for this).

USB-RS232 Interface

As implementation of my plan to continue to work on my measurement control solution, first I done the design of the USB-RS232 interface. It could be, that this is not the last version of it, but the design is done for now.

It is based on the CH340G chip what I used for my ESP8266 programmer with great success, also have it in various chinese USB-Serial cables, Arduinos, 3D printer boards and almost never had a single problem with it. To achieve the proper signal level I added an MAX232 to it.

Probably this solution is not optimal as it is lack of all of the RS232 signals, but I think it is good enough for now (I don't want to put much more effort into it for now).

The schematic:

The PCB design:

As you may realize from the schematic and the PCB, it has a "dual" USB connection. It means the USB signals are exists both of an micro USB connector and a pin header. This solution give the versatility to use the device with USB connector or soldered in cable.

According to this concept I designed two different enclosure.

With USB connector:

And with cable connectivity:

You can realize that the board color is gray on the exploded views above. The reason is that I wasn't able to import color 3D model to the OpenSCAD what I use for 3D modeling.

The original 3D view looks like this:

Currently I'm not planning to order the board yet because I want to panelize it with the next version of my GPIB hardware what I'm designing right now.

All of the design files you can find here:

https://gitlab.com/measurementcontrol/rs232interfacehardware

Also as I planed reorganization of my measurement control things, all of the connecting repositories will appear here:

https://gitlab.com/measurementcontrol

Measurement Control - reboot

Preface

In the recent years I put substantial amount of work in controlling my various instruments from computer. The goal is to achieve some added values, like logging, better visibility, more functions, etc.

Looks like I a bit failed with this, as none of the things reached the usability state.

Even I put aside the thing months ago. Now I feel the need to restart the project and achieve some "working" result.

Plans

Reorganize the source repositories

This is needed as I learned many things in the recent years from my work on git (branching strategies, release management, etc.)

Create an USB-RS232 interface

I've a few devices using RS232 interface instead of (or on the side of) GPIB. Yes you can buy USB-Serial interfaces for nuts. Why you need another? Most of the things you can buy has no proper signal levels. They use TTL levels instead of RS232 levels. Most of the professional instruments require proper levels. The interfaces with proper signal levels are not cheap or you risk buying something on Aliexpress what states it correct, when not.

Redesign USB-GPIB hardware

My ATMEGA32U4 based interface working perfectly. In the recent years I realized a few things regarding to it, what feels like some adjustments are needed:

• Create a physical design what can be mounted a 3D printed enclosure
• Abandon the unnecessary connectors added for future improvements like display, additional device control, etc.
• Add serial debugging capability (according to AR488)
• Maintain bootloader compatibility with Arduino Leonardo
• Also keep the advantage of using a complete 8bit bus of the MCU for data transfer (require modified bootloader
• Maintain software compatibility with AR488 (https://github.com/Twilight-Logic/AR488)
• Add activity LEDs (the original Arduino Leonardo has those)
• Proper GPIB interfacing with TI chips (in a different HW version)

Maintaining AR488 compatibility doesn't mean I intend to drop the development of my own firmware. I still not a fan of the 3000+ lines of code in a single source file and the AR488 still doesn't support GPIB subaddressing. I've several instruments (VXI mainframes, power supply mainframe), what require subaddressing. On the other side it has device mode, TI GPIB chips support, what is missing from mine and support from software like sigrok.

Proper bootloader for USB-GPIB

I created a bootloader for the the v2.0 of my board. This was a result of an incident caused by reusing the USB activity LEDs of the Arduino Leonardo, killing my GPIB communication. The issue was resolved then, but the result is poorly documented (https://pakahuszar.blogspot.com/2020/04/gp-ib-5-v20-board.html), hard to reproduce and killing the activity LEDs instead of relocating them.

Now I'm trying to create a maintainable buildable, and properly installable solution. Also want to allocate a proper PID/VID from pid.codes

Power supply control software

My virtual instrument software is able to do many things but I realized it is too much for the first iteration.

There are many things already achieved with it, but for the reboot I want to have more realistic goal. So using the plugable driver support from it, I want to just create a power supply control software for my many supplies (even the HP 66000A mainframe is useless without software control as I don't have keyboard for it). I don't want to add higher functions yet.

Further...

Sure, I don't want to stop here, I want to reboot the virtual instrument software, my curve tracer, etc.

But those are cloudy right now, and if I lose my focus on it, this project tsunami will be shelved. Again.

Terraform, Cloudformation and Cognito

Some things what more of my professional side than the hobby, electronics, maker things.

I'm working with IaC tools since... don't even remember. I started with AWS CloudFormation around 2014 (not sure, it is cloudy. 😆).

When I learned about Terraform, I had a fear, that I'll not get the full functionality of AWS. The CloudFormation is a native tool. Something developed by a 3rd party should fall behind the native tool of the provider.

I started using Terraform as the customer required it. So switching from Cloudformation to Terraform wasn't my decision. The fear I described above just become reality when the customer didn't wanted to upgrade the AWS provider in their deploy agents, so it wasn't the fault of HashiCorp or the Terraform community. Also, writing Terraform code is much more convenient, give you more capabilities on processing, converting the required information.

A few weeks ago, after three years exclusive Terraform work, I got a project what use CloudFormation again.

There was a - I guessed - super easy task. Publish the secret of a Cognito User Pool Client into an SSM Parameter Store value as Secret String.

In Terraform this would look like this:

// Create Cognito User Pool
resource "aws_cognito_user_pool" "pool" {
  name = "pool"
}

// Create Cognito User Pool Client
resource "aws_cognito_user_pool_client" "client" {
  name = "client"
  user_pool_id = aws_cognito_user_pool.pool.id
  generate_secret     = true
}

// Publish to SSM Parameter Store
resource "aws_ssm_parameter" "secret" {
  name        = "/production/cognito/clientSecret"
  type        = "SecureString"
  value       = ${aws_cognito_user_pool_client.client.client_secret}
}

And we are done.

Try the same in CloudFormation.

Can the AWS::Cognito::UserPoolClient object export the secret? Nope. Ref: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cognito-userpoolclient.html

Can the AWS::SSM::Parameter object create SecureString? Nope. Ref: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ssm-parameter.html

Here my previous theory on the "CloudFormation should be ahead of Terraform" fall.

I tried several things finally this was working (One small comment: the import cfnresponse is in a separate line. It is not because of my lazyness. It is because otherwise the infrastructure doesn't realize, the cfnresponse.py should be added to the zip as it is not a part of the pip repo):

Resources:
  # Create Cognito User Pool
  UserPool:
    Type: "AWS::Cognito::UserPool"
    Properties:
      UserPoolName: pool

  # Create Cognito User Pool Client
  UserPoolClient:
    Type: "AWS::Cognito::UserPoolClient"
    Properties:
      AccessTokenValidity: 15
      AllowedOAuthFlowsUserPoolClient: false
      ClientName: client
      GenerateSecret: true

  # You need a lambda to
  #     - read from the cognito user pool client
  #     - write to the parameter store
  #     - report back to the CloudFormation when finished
  CognitoSecretExporterLambda:
    Type: AWS::Lambda::Function
    Properties:
      FunctionName: CognitoSecretExporter
      Runtime: python3.9
      Role: !GetAtt CognitoSecretExporterExecutionRole.Arn
      Handler: index.handler
      Timeout: 30
      Environment:
        Variables:
          CognitoUserPoolId: !Ref UserPool
          CognitoUserPoolClientId: !Ref UserPoolClient
          ssmParameterName: /production/cognito/ClientSecret
      Code:
        ZipFile: |
          import boto3, os
          import cfnresponse

          def handler(event, context):
              CognitoUserPoolId = os.environ['CognitoUserPoolId']
              CognitoUserPoolClientId = os.environ['CognitoUserPoolClientId']
              ssmParameterName = os.environ['ssmParameterName']

              # Read Cognito
              cognito = boto3.client('cognito-idp')
              response = cognito.describe_user_pool_client(
                  UserPoolId = CognitoUserPoolId,
                  ClientId = CognitoUserPoolClientId
              )
              cognitoClientSecret = response['UserPoolClient']['ClientSecret']
              print(cognitoClientSecret)
              ssm = boto3.client('ssm')

              # Write to parameter store
              response = ssm.put_parameter(
                  Name = ssmParameterName,
                  Description = '[CF] Cognito Client Secret used by the WebApp',
                  Value = cognitoClientSecret,
                  Type = 'SecureString',
                  KeyId = 'alias/aws/ssm',
                  Overwrite = True,
                  Tier='Standard'
              )

              # Report success to CloudFormation
              responseData = {}
              responseData['Data'] = 120
              cfnresponse.send(event, context, cfnresponse.SUCCESS, responseData) 

  # Trigger the lambda from the CloudFormation stack
  CognitoSecretExporterInvoke:
    Type: AWS::CloudFormation::CustomResource
    DependsOn: CognitoSecretExporterLambda
    Version: "1.0"
    Properties:
      ServiceToken: !GetAtt CognitoSecretExporterLambda.Arn 

  # IAM Role for the lambda above
  CognitoSecretExporterExecutionRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: CognitoSecretExporterExecutionRole
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
        - Effect: Allow
          Principal:
            Service:
              - lambda.amazonaws.com
          Action:
            - sts:AssumeRole
      Path: "/"
      Policies:
      - PolicyName: root
      PolicyDocument:
          Version: '2012-10-17'
          Statement:
            - Sid: EnablePutLogEvents
              Effect: Allow
              Action:
                - logs:CreateLogGroup
                - logs:CreateLogStream
                - logs:PutLogEvents
              Resource:
                - '*'
            - Sid: ReadCognito
              Effect: Allow
              Action:
                - cognito-idp:DescribeUserPoolClient
              Resource:
                - !GetAtt UserPool.Arn
            - Sid: ParamStore
              Effect: Allow
              Action:
                - ssm:DeleteParameter
                - ssm:PutParameter
                - ssm:GetParameter
              Resource: 
                - !Sub arn:aws:ssm:${AWS::Region}:${AWS::AccountId}:parameter/production/cognito/ClientSecret

Gigabyte and modular power supplies

On the side of the CNC router project (as always) I started an other one. This is clearly just a PC project. Build a NAS from the things I have on hand (ceiling cleanup 😂).

During the long years, I used several - called modular - ATX power supplies. Those things allow you to clean up the cable jungle a bit, what always shown up inside the PC cases, by allowing you to detach unnecessary cables from the PSU. These are the peripheral cables used for the mass storage, graphics cards, etc.

The connectors on the supplies for the modular PSUs are not standardized, usually use the same kind of connector (2 row, 6 or 8 pin, Molex Mini-Fit).

Yes, I bought PSUs from different vendors (Gigabyte, Chieftec, etc.). Yes, I never labeled the cables. And yes, I keep those in one box. This means, I don't have a clue, which cable belong to which PSU.

For the NAS PSU I needed several cables (in hot swap bays, I plan to use 14 disks). If I mix those up, I can imagine the firework it can cause.

The subject currently is a 550W Gigabyte Odin (I also have an 800W somewhere just not found in the ceiling yet). I downloaded the manual of it. It has the connector pinout in question. (Indicated, not to use it as is bad)

I started to starch my head. None of the cables in the box has this pinout.

DMM on. Measure.

My suspicion become true. The manual is garbage.

This is the correct pinout (the connector drawing is from Molex and show the connector on the PSU itself), and it correspond to all of the cables in my box (it is maybe a coincidence, but Gigabyte, and Chieftec use the same pinout):

CNC Router Reborn 1.

Back in 2014 I bought a CNC Router on the Aliexpress. I learned how to use it. It had several issues, what I wanted to, and started to fix.

Exchanged the undersized linear power supply to two switching ones, designed (and put substantial amount of work) into a new spindle controller. Made several mistakes (like broke one of the power supplies, later killing it completely during a repair effort). Even designed (and started to build) a dust collector for it.

At the end of the day I realized, that the unit will never fulfill my requirements. So I gave it up. Once collected some controller parts, to make it work just on "as is" bases, but left the thing lying around in my workshop.

The substantial problems I had:

• Realized, the the 3040 form factor just a bit small for me. I rather go with 6040 or even 6090
• The 300W (later changed to 400W) spindle motor is too small for me. The used brushed DC motors have very low torque at low speed. For milling aluminum it would need low rpm, high torque. I can't put bigger motor (or even low power BLDC) into the 52mm holder. To put a bigger holder I would need to replace the complete Z-Axis, as the holder made from a single piece of metal with the bearings and ball screw nut integrated.

Finally I decided, it would cost to much, to make it perfect, while the size kept still too small.

I'm here around 5 years after I last touched it.

I constantly pushing my son, to do something other than computer games, in his free time. A few weeks earlier he come up with some idea. We realized that he will need a CNC Router for his project.

I felt, that this is a good opportunity to rebuild my CNC router and also put me back on track.

The plan:

Build a new controller box for the CNC router, put together a new toolchain for it. I want to do this with mainly the parts I already have. The goal is to sell the CNC3040 at the end of the day to be able to build a bigger one.

The control box:

An old PC midi tower. This kind of thing always lying around as I live from computers in the last almost 30 years.

• A mini-ITX motherboard: Gigabyte GA-E6010N - this one I bought newly
• 8GB DDR-3 RAM - had it already
• 60GB SSD - had it already
• 600W 48V PSU for the spindle motor - from the last CNC repair effort
• 100W 24V PSU for the stepper drivers - from the last CNC repair effort
• 350W Chieftec PC PSU for the motherboard and the GRBL controller - had it already
• Solid State Relay - had it already
• GRBL controller board - bought for the CNC years ago
• TB6600 stepper drivers - bought for the CNC years ago
• Spindle speed controller - bought for the CNC years ago
• Connectors - scavenged from the old CNC controller box

1. I put together just the PC on my desk to install the control software

Installed an Ubuntu Desktop 20.04 LTS onto it. Switched to LXQt to decrease the resource requirements. Installed Docker on it (from my work I became a Docker junkie in the last years), and added a CNCjs container. It still need some tuning, but it can only be done, when the controller is connected and I see what needed.

First mission accomplished. The CNC.js started to work.

2. Start to put together the control box

Drilled out some pop rivets from the PC box back. Removed the extension card holder/ATX cutout assembly. Cut it into two piece at the first extension card (the first card can be used even on a mini-ITX board). When it was done, put it back with new pop rivets.

Cut a few HDD holder ears in the 3.5" bay. It was needed to be able to assemble the 100W PSU in. Fortunately there was a few holes on the bottom for mounting the PSU without drilling.

Cut two L shaped aluminum extrusion for the 600W PSU to fit it into the 5.25" bay. After some drilling, threading, sanding, it went into it's place.

From the old PC PSU connector male (I have it unassembled) created a cable for the SSR and assembled the SSR in (It fit into the holes of the case top fan).

The idea with the SSR to be able to start the two additional PSUs when the PC soft start button pushed.

I altered the PC PSU a bit.

• Added a bigger hard switch to be able to handle the two additional PSU
• Added a screw terminal block switched mains output - I don't want to see more than one mains outlet at the back of the box.
• Replaced the noisy (faulty) fan

Assembled the things above plus the PC motherboard, SSD drive into the cabinet.

I know, that this thing doesn't look more like a standard PC (nothing interesting in it, we built like this hundreds of times), but more to come.

Restarting

As you may noticed, I didn't write anything since March. I wasn't too active before in the last two years either.

Many things happening right now around me, what is connected to the blogging, my hobbies even my work.

I'm planning to write more frequently from now on. Restart few previously abandoned projects. We will see, if this plan come true.

9/11

Let me tell a story. My story.

1996 December

I was visiting New York with my mother. It was on an invitation from a friend of my grandmother. We were there for more than 3 weeks. I don't want to write here about the full trip, just highlight two details.

We were visiting the Empire States Building (the top of it). Waiting for more than 5 hours in the line to get to the elevators. Even become dark when we where able to reach the roof and see the city from there.

On the last day of the trip, just a few hours before we left, I seen a sign somewhere that at the Pier 86 you can see the USS Intrepid museum. Unfortunately we had not enough time for the visit. It was in my mind: Next time.

2000

I was involved in the printing industry. We were planning a trip to Düsseldorf to Drupa exhibition. My father got seriously ill, so we canceled the trip. Next year held a similar exhibition in Chicago the PRINT 01. 

2001 September 6.

My father got better, so we headed to Chicago. The trip was organized by the Hungarian printing association. Altogether 10 people went there. We decided to visit New York at the end of the trip for two days.

2001 September 9.

Arrived to New York. Took a bus ride to have some view as for some of the people this was the first visit. We were even at the WTC to look around.

2001 September 10.

Two of our colleagues wanted to go to the WTC, next day, in the early morning, to see the city from the top. They also invited me. I decided, rather not go there. First I was on a skyscraper trip 5 years before, second, I wanted to visit the USS Intrepid, what I missed in 1996.

The two colleagues didn't speak English, so they decided to come with me to the museum.

How coincident can save your life

EPROM burning 21/25V 2.

 As it wasn't a big deal project, I made the drawings fast, and ordered the boards. Also as I didn't want to use some fancy SMPS for the boost voltage conversion, so I picked the good old MC34063 used a switchable feedback divider and that's it.

The board is arriving from the JLCPCB, with the cheapest manufacturing and shipment method. I left this project laying around for a long while now. I'm not willing to pay any extra for my laziness.

EPROM burning 21/25V 1.

 After my last Fake in China post, I continued to work on the 2716 EPROM burning. I ordered a second batch of 2716's from a different source. The new series looks more promising:

Same chip size, two different date code. I think this is still a chinese copy, but may works.

Also, I've a different issue here, what I just barely realized last time.

The TL866II programmer what I use, doesn't support the 21V Vpp printed on the top of the case. Even, according to the original ST documentation, it should be 25V. The programmer only support 18V. It is not enough, even the chips would be genuine.

I found a solution in a forum: https://pinside.com/pinball/forum/topic/program-21v-25v-roms-in-lower-voltage-programmers

This is great, just I don't like it.

This is a hack solution to me. I want to have a proper adapter, I'd like to see the pin detect function still works, I want to use a regular wall wart adapter instead of a lab supply, I want to have the 21V/25V programming voltage switchable, I want to protect my TL866II from faulty chips.

I asked a question on a forum, how the pin detect function of the programmer works. On the side I had a cloudy idea in my head:

What if: I just connect the original programmer pint to the chip through a diode, while clamp the programmer side to the ground with a high value resistor. In addition use one n-channel mosfet, with a zener to detect if the voltage from the programer is more than - let say - 12V. With this n-channel mosfet pull to the ground a p-channel mosfet's gate connected to the external programming voltage and the chip's Vpp.

On the side of why even you need those chips, why you not build another programmer from scratch like answers I got to relevant:

The schematics of the TL866II:

https://proghq.org/wiki/images/3/3c/TL866II_Schematic.pdf

And a kind of solution from a german site:

https://www.dr-bosch.com/volker/umbau/index.html?#VppAdapter

This later link contains a schematic, what is exactly the same what I have in my mind except it was realized with bipolar transistors instead of mosfets

Károly Molnár, István Sümegi - Thank you for the links.

So the project starts here. The real programming in this case can wait.

In addition to the mentioned circuit I plan to add a boost converter with switchable output (21V/25V from a 12V input), plus a zener and a resistor for every pin to protect the programmer.

This is how my abandoned projects are come into existence. :-D

The design will be available here when it is ready for this:

https://gitlab.com/suf/suf-electronics-TL866II-HV-EPROM

Hi-Fi Rack - Motorized turntable tray 3.

This year I decided, to complete some previously abandoned projects of mine. I'd like to finish one of those in every month. It is just a plan and not a promise (I don't want to fell into the trap of unkept new year's resolutions).

The first one in the row (for January) is my motorized turntable tray. The previous posts about it can be seen here:

• https://pakahuszar.blogspot.com/2019/12/hi-fi-rack-motorized-turntable-shelf.html
• https://pakahuszar.blogspot.com/2020/01/hi-fi-rack-motorized-turntable-tray-2.html

Since I restarted January, many things happened with it:

• Added the final electronics
• Changed the TI DRV8825 stepper driver to Trinamic TMC2209
• Almost completely rewritten the code, based on TMCDriver and AccelStepper, while keeping the original touch sensor library.
  
• There was an achievement from my side, that after a long struggling period, my 3D printer is back online and working stable, so I was able to add 3D printed parts. This way a new cable management arm come into picture instead of the unreliable tape used previously. It is used for the touch sensor cable and the mains cable. For the audio cable I may create a second arm sometime.
• I also 3D printed the holder for the connector at the back panel.
• Created a kind of power breakout box (temporary solution until the proper supply is made):
  It has:
• +12V - Wall Wart adapter for a time being
• +5V  - Wall Wart adapter for a time being
• Earthing (for the touch sensor)
• Serial connection
• Mounted it into it's final place

While I was writing the serial communication part of the code (it will be used later), a weird issue raised.

The connection to the PC just created unusable data stream. A complete mess. Even I changed the USB-Serial adapter. I didn't understood why. Then an idea pop into my mind, and...

Yes, I used a 12MHz crystal instead of 16MHz. This means, everything working correctly, except the serial communication. When I used 115200 on the arduino side and 86400 on the terminal side, the communication eventually started to work normally.

I didn't wanted to keep it this way, so changed:

The complete electronics, in it's place with the motor and the cable management arm

The power breakout box

Now only a few things left to do:

• A better GT2 pulley mount
• A second cable management arm for the audio cable
• The next phase of the project, what will contain the proper power supply also

Working on my desk:

Project finished, mounted into it's final place:

The design and the code reside here:

https://gitlab.com/suf/suf-hifi-rack

Fake in China (EPROMs)

 When I opened the HP 8903B Audio Analyzer I realized, that the rom memory on the processor board is assembled from various chips from various providers, what I not really like. The EPROMs anyway need reprogramming after a few decades, to keep the instrument working in stability.

As I didn't want to erase the originals, I had the plan to create a complete new EPROM set. The 2716 and 2516 EPROMs are not available anymore from any of the regular suppliers. So I went to the eBay to find some. Ordered 20pcs. Arrived from China:

I know, that the manufacturers time to time change the process of the devices kept on the market. But come one! Three different chip size, with the same date code?

Guys, you can do better job than this! :-D

Anyway, I tried. One out of the twenty acted like an EPROM in the programmer, even this one was failing during the programming cycle.