Fluke (Philips) PM3082 Oscilloscope Repair 1.

I'm continuing here an almost 8 year old story:

http://pakahuszar.blogspot.com/2014/09/engineer-joke.html

http://pakahuszar.blogspot.com/2014/10/engineer-joke-continuance.html

Just in nutshell, what happened since:

I left the oscilloscope, as is for additional three years, without touching it. Unfortunately the processor board gone from the eBay, so I didn't buy it.

After this three years. I brought it to a friend, who run a repair shop. He found some issues in the high voltage PSU, repaired it. Later he started to blame the I2C bus, as it has some problems, what hold the entire control, and didn't able to pinpoint it. Once he will go back and put more effort into it.

The whole thing got forgotten. A few weeks ago, I went to him to pickup some of my donor audio equipment, and picked up the oscilloscope with it. So it is now in my new lab.

Switched it on. The errors are the same. So it not get worse in the last years, what is great from a standpoint.

With the I2C bus error in my mind. I started to go over of the schematics of the oscilloscope (just the analog board is 18 A3 pages itself - Jesus!).

Collected all of the I2C bus connected ICs from all of the boards into an Excel sheet, with the connection points need to cut for troubleshooting. One thing started to get clear during the schematics reading. Let me explain:

If I would design something with I2C control, I would put the I2C capable ICs on the bus, with different addresses and that's it. Philips did it a bit differently. There are some ICs (TTL compatible serial-to-parallel shift registers mainly), what is not I2C compatible, just connected to the I2C lines and has additional control signals (it is weird to my taste, but this is the case).
Also I realized that the front panel board has no I2C connections. It is connected to the processor via a parallel bus.

In the view of the information above, I started to reevaluate the "I2C bus has a problem" sentence.

Go through the errors on the screen, one-by-one:

1. "NO BATTERY BACKUP" - Irrelevant, it needs 3 AA cells what is not inserted yet
2. "WRONG A1 HARDWARE VERSION" - It is checked with one of the shift registers mentioned above. It can be else than the I2C bus as it has different control signals
3. "CANNOT COMMUNICATE WITH UFO" - The front panel is not I2C, so it definitely not I2C related
4. "NO ACKNOWLEDGE ON I2C BUS" - It can be I2C related, but... If something hold the I2C bus because of the dual purpose mentioned above, can be something else also

If we assume, there is only one error causing all of the problems (likely, but not for sure), it lead us to a different direction. The A3 processor board contains a 74HCT259 providing reset for the UFO and control signals for the I2C connected non-I2C ICs. It is the first what I suspect instead of any I2C ICs.

Without logic analyzer, I wouldn't touch it further.

According the service manual, there is a raiser card exists for measuring things: 5322 218 61479

Looking on the internet, nothing come up on it. There is no other reference than this manual. Not a photo, an expired auction, an internet archive page. It virtually doesn't exists.

On the other side, it is not a highly specific thing. I redesigned it, based on the available information, according to my needs:

The oscilloscope also has a 50 pin IDC cable connection here and there. So I also designed a breakout for it:

I already ordered the boards from China. I put this repair aside until those things arrive. The oscilloscope waited for 8 years, so a few additional weeks doesn't count.

In addition I found a completely broken PM3082 on the eBay for a (few) bucks.

So I bought it. The minimum goal is to create one working oscilloscope from this two. But who knows. Maybe both can be brought back to live.

Now I wait for the things to arrive: boards from the JlcPCB, connectors from AliExpress, broken scope from Italy.

New Arrivals 6. - (special edition)

Today, I only want to write about one thing arrived, as it is a bit special to me and need some more attention.

This is a bit strange, nostalgic story.

In my childhood I was living behind the "iron curtain". There we have very little possibilities to get things from the western part of the world. I had obsession to music, the audio electronics in my teenage years. Even I was "working" as a DJ in the school. I had two cassette decks, built a mixing station for this.

I was eagerly need a headphone. My mother time-to-time had the opportunity to travel to the west. Once she bought a headphone for me (some no-name thing, but I was really happy with it).

Years elapsed, more and more Hi-Fi things arrived to the country. To support the music and Hi-Fi loving audience, a magazin appeared on the local market: http://www.hifimagazin.hu/

Once they was running a headphone test: http://hifimagazin.hu/HFMCD/HFM/CIKKEK/HFM2410.HTM

There were AKGs, Beyerdinamics, Sennheisers, etc. the good big names. Those were first unavailable in the country and also as a moneyless student, I can't afford them even if it would be on sale locally.

I just find the KWH HOK-80 on the list, what got good verdict, was available for the money acceptable to me, so I bought it based on the article.

It had great sound, but you had the feeling when you put it on, like your head would be in a machine vice.

You can't tolerate this "comfort" for a long time.

I was a gadgeteer kind of guy already these days. So I built the orthodynamic panels from this headphone to the one I got from my mother years ago. Case closed, I had a good enough headphone (Also built headphone amp for it).

Few years later after the "iron curtain" fallen, I got other interests, turned to the computers instead of the audio electronics. Once I landed the already unused mixing console and the headphone to a friend.

Never seen them again.

Two-three weeks ago (30 years after the story above) I read an article about some highend Technics loudspeakers https://longkft.hu/audioblog/technics-sb-afp1000/ (it was a repost on the facebook).

The article is talking about the east-german headphone I had previously also as the technology is the same as the one used in the Technics monster.

When I read it, the long forgotten story above pop into my mind.

Looked around on the eBay, and found a HOK-80 for a few bucks. Today arrived.

Even this one arrived in the original box, with the original documentation and warranty card.

What a surprise, the original east-german invoice was also in there.

165 east-german mark. I was looking around the exchange rates. If I'm not mistaken, it would be €33 today.

Nothing changed regarding the comfort. The vice feeling on your head is still there.

My son has a gamer headset. He completely destroyed the cabling, the switch and volume knob of it. Finally I bought a bluetooth one for him (can't hurt the cable). I just throw the headset to a drawer years ago with the thought "I'll repair it later" - never happened.

Now I picked it. It would be a good donor candidate for my new project. I want replicate, what I did in the '80s (sort of).

I will build the orthodynamic drivers into this Gigabyte headset's shell, add a proper, detachable headphone cable and done. This will be one of my next projects.

Octoprint in docker

[Updated: 2024.03.10]

This is just a short title of this article. I would rather call it: "Octoprint in those chip shortage times"

Today it is not so easy or cheap to acquire a good platform for Octoprint. Raspberry Pi almost seized to exists. If you can buy it somewhere it cost a lot.

I'm a DevOps guy nowadays for profession. I fell in love with the containerized (and orchestrated, cloud based iaC) infrastructures. The Octoprint is a good candidate for this, as itself is unable to handle more than one 3D printer.

Actually I've several tasks in the lab, what need server side background computing. So, I just picked up an old (not too old) PC from my ceiling (the most important requirement to have a 64bit CPU already).

Installed a shiny new Ubuntu 22.04 LTE Server on it. There is only thing I installed during the setup process: OpenSSH. I don't install Docker from snap, what suggested by the install process. It caused problems to me, so I leave it out for now.

At the first login I switch to root console (sudo su). I do this for comfort. I asked for password once during this process.

Docker

Install docker from docker's repository (instead of Ubuntu)

curl -s https://download.docker.com/linux/ubuntu/gpg | gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/docker.gpg --import
chmod 644  /etc/apt/trusted.gpg.d/docker.gpg
add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
apt update
apt install docker-ce docker-ce-cli containerd.io
apt upgrade -y

Note: If you run it on Raspberry PI the [arch=amd64] should be changed to [arch=arm64]

Static IP

I suggest to fix the IP address of the machine some way. Right now I'm using a pathetically shitty router from the provider, but at least it is able to add static lease to the DHCP service, so I choose this. On the other side I'm not so fortunate with it's DNS service. So with the naming I'll relay on the host file and not a DNS.

Proxy

I'd like to be able to access the services with name, instead of IP address and port. To be able to achieve this, the first thing I install is the jwilder/nginx-proxy, what I use frequently for this task

docker run -d -p 80:80 --restart=always --name=proxy -v /var/run/docker.sock:/tmp/docker.sock:ro jwilder/nginx-proxy

[Update]

After installing everything when I tried to use Octoprint, this came up at upload printable gcode:

The reason: the proxy is not configured for long HTTP requests. Means the start command for the proxy above need to be adjusted a bit.

You will need the following:

mkdir -p /data/nginx-proxy

chmod -R 777 /data

echo "client_max_body_size 25m;" > /data/nginx-proxy/custom.conf

docker run -d -p 80:80 --restart=always --name=proxy -v /var/run/docker.sock:/tmp/docker.sock:ro -v /data/nginx-proxy/custom.conf:/etc/nginx/conf.d/custom.conf:ro jwilder/nginx-proxy

Portainer

As I'm using mostly command line to manage docker, it is a good idea to have a kind of dashboard to see, what is happening. I'm using Portainer for this for a long time now. Here is the first time when it advisable to have a folder, or a named volume on the host to map as data into the container. Here I choose a folder for this. It will allow me later to mount some external storage (NFS in a NAS device in my case) to hold and backup this data.

So just add some folder for it (we will need one for Octoprint also, so I create it here also):

mkdir -p /data/portainer
mkdir -p /data/octoprint-geeetech

For security it is not the best choice, but as right now we don't know the user id of the Portainer  (Octoprint) container, so I gave access for those data folders for everybody inside the computer

chmod -R 777 /data

Install the Portainer:

docker run -d -e VIRTUAL_HOST=portainer.it-pro.local -e VIRTUAL_PORT=9000 --name=portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v /data/portainer:/data portainer/portainer-ce

Now try out if our Portainer is working. You need to add the Portainer in the name resolution in some way. Either as a CNAME record to the DNS or the host file in your client machine. In my case it is the later one on my Windows machine (c:\windows\system32\drivers\etc\hosts)

This case I add the following:

192.168.0.10    portainer.it-pro.local

From your browser you can connect to the Portainer and setup your user:

Device file

If you connect more than one USB-CDC device (Serial over USB, most of the 3D printers fell into this category), you are in trouble. In Linux the devices are not stick to the device file. While you run a single Octoprint on a Raspberry Pi this is not a problem, while you only connect one printer, always get the same device file. In our case it is not evident. This is why I use a "trick" here. Create an alias (soft link) for the device. Giving a name to it, based on the USB Vendor Id (VID), Product ID (PID), and the serial number. Here I should give a small note. The CH340 series Chinese USB Serial converter chip frequently used in the 3D printers, can't be differentiated from each other, as it has no serial number. So if you have more than one 3D printers based on it, you still in trouble.

First connect your printer to the PC, and run the following command:

lsusb -v

This will give back all of the parameters your device have. You can collect the VID, PID and the serial number from it.

My printer report this:

Based on this, you can add the creation of your device alias to the udev rules:

echo 'SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A903RZMJ", SYMLINK+="ttyGeeetech"' >> /etc/udev/rules.d/99-usb-serial.rules

Reload the rules:

udevadm control --reload-rules

You can check with ls -la /dev/tty* if the device file is in it's place

The udevadm command wasn't work for me (probably disconnecting and reconnecting the printer does the trick), so rebooted the machine, what resolved it:

Octoprint

Last piece of the puzzle is the Octoprint itself:

docker run -d --restart=always -v /data/octoprint-geeetech:/octoprint --device /dev/ttyGeeetech:/dev/ttyACM0 -e VIRTUAL_HOST=geeetech.it-pro.local -e VIRTUAL_PORT=80 --name octoprint_geeetech octoprint/octoprint

One additional line added to the hosts file:

192.168.0.10    geeetech.it-pro.local

Now you can connect to the Octoprint from your browser:

Here come the regular Octoprint setup (I don't want to discuss it here because you can find this in more appropriate places over the internet).

And the result:

If you want to use more than one printers, you should setup the folder (for the octoprint instance), the sticky device file and the Octoprint docker container for each.