Voltcraft CT-20TDR Display-Reparatur (Deutsch / German)

Hi zusammen,

diesmal auf Deutsch, weil ich annehme, dass Voltcraft außerhalb von Deutschland nicht großartig bekannt ist...

Die heutige Reparatur dreht sich um einen Kabeltester CT-20TDR von Voltcraft, der z.B. über Conrad Electronic oder Völkner verkauft wird. Damit lassen sich Netzwerk- und Telefonkabel schnell auf Durchgängigkeit testen. Durch ein herausnehmbares Gegenstellenmodul kann man auch installierte Kabel testen. Die Preisklasse ist ca. 150 Euro.

Leider gibt es einen oft auftretenden Fehler, der vielleicht erklärt, warum so viele dieser Geräte bei den einschlägigen Marktplätzen als defekt angeboten werden. Der Fehler zeigt sich so:

Das Problem ist, dass auf einem mehr oder weniger breiten horizontalen Balken keine Pixel mehr erscheinen. Bei LCDs kennt man das, oft sind es die Kontaktstreifen aus Gummi mit eingelassenen leitenden und nicht-leitenden Oberflächen, die diesen Komponenten in Englisch den Namen "Zebra strips" verpasst haben. Diese Streifen können sich über die Jahre leicht ablösen. Wenn man sie neu positioniert oder dafür sorgt, dass sie etwas mehr Andruck an den Kontaktflächen haben, sind solche Probleme einfach zu beheben.

Leider ist es in diesem Fall komplizierter, denn es handelt sich beim CT-20TDR um ein LC-Display, das eigene Intelligenz an Bord hat, sprich ein Chip-On-Glass (COG) sorgt für die Ansteuerung der Pixel und wird über ein vorgegebenes Protokoll vom Gerät angesprochen. Statt Zebra Strips kommt hier ein Flachbandkabel (FFC, Flat Flex Cable) zum Einsatz. COGs sitzen, wie der Name schon verrät, direkt auf demselben Glas wie das Display, und die Kontaktierung erfolgt über transparente Leiterbahnen, die auf das Glas aufgebracht werden. Wenn hier eine Kontaktschwäche herrscht, ist das mit normalem Werkzeug nicht mehr zu reparieren.

Hier ist es sogar noch schlimmer, denn der Kontakt ist nicht nur schwach, sondern für einige Zeilen im Display komplett unterbrochen. Der Grund dafür ist allerdings gut versteckt. Bei den COG-Displays verbirgt sich der Chip oft unter einer schwarzen Silikonschicht, die als Schutz gedacht ist, beim hier verwendeten Display sind auf ganzer Breite des Displays sowohl der Chip als auch alle von ihm weg- und zu ihm hinführenden Leiterbahnen unter Silikon begraben. Auch das Flachbandkabel bekommt an der Stelle, wo es auf dem Glas aufgeklebt ist, von der Silikonschicht noch etwas Schutz, damit es nicht so leicht abreißt.

Die Ursache des toten Streifens auf dem Display konnte ich erst sehen, nachdem das Silikon entfernt war:

 

Mittig unten unter der grauen Anzeigefläche ist der Chip zu erkennen, von dem nach unten das Flachbandkabel wegführt. An der linken unteren Ecke des Displays hat das Glas mehrere Bruchstellen.

Hier noch mal aus der Nähe:
 

Und noch näher. Im Gegenlicht lassen sich bei genauem Hinsehen die Leiterbahnen erkennen, die hier durch den Glasbruch mit unterbrochen wurden:

An dieser Stelle ist klar, dass dieses Display nicht zu retten ist. Durch irgendeinen Umstand wurde das Display an dieser Ecke zu stark gebogen. Ich vermute, dass das Gerät heruntergefallen ist. Das sollte man wohl besser nicht passieren lassen, auch wenn das Gehäuse einen sehr soliden Eindruck macht.

Wie leider üblich ist am Display selbst keinerlei Hersteller oder Modellnummer ersichtlich. Da es zum Austausch aber auf jeden Fall das Gerät verlassen muss, kommen wir nun zum Ausbau. Dazu ist leider Entlöt-Equipment notwendig, weil das Display eine Hintergrundbeleuchtung mitbringt, die aber nicht über das Flachbandkabel versorgt wird, sondern über zwei eingelötete Pins an den Ecken unten links und rechts. Diese müssen ausgelötet werden, bevor es weitergehen kann. Man kann mit gebotener Vorsicht auch die Pins einzeln so weit erhitzen, dass sich das Display in die Gegenrichtung wegziehen lässt.

Erst danach kann man das Display an den zwei Kunststoffclips, die oben rechts und links um die Platine herumgreifen, ablösen und sieht dann das darunter gesteckte Flachbandkabel. Aus dem Verbinder löst man es, indem man den dunklen Sicherungsbalken nach oben klappt:

Dazu auf der Seite, wo das Kabel hineinführt, mittig von unten vorsichtig unter den Balken gehen, z.B. mit einem Fingernagel oder einem Kunststoffwerkzeug, und diesen nach oben klappen. Dann lässt sich das Flachbandkabel ohne Kraftaufwand herausziehen.

(sorry, leider habe ich es versäumt, für diese Prodzedur mehr Fotos mit anderen Perspektiven zu machen)

Die Lötaugen müssen dann von verbleibendem Lötzinn befreit werden, damit das neue Display dort wieder Halt findet (im Bild sind beide markiert):

 

 

Jetzt gilt es, am defekten Display einen Hinweis auf Hersteller und Modell zu finden. Das ist in diesem Fall leider praktisch unmöglich. Am Display selbst findet sich leider gar nichts, die Rückseite ist komplett weiß, was man hier sieht, ist der Kunststoffrahmen, in dem die Hintergrundbeleuchtung und das LC-Display miteinander verbunden / verklebt sind.

 

Einen Hinweis, der aber nicht wirklich hilft, gibt das Flachbandkabel mit folgendem Aufdruck auf der Vorderseite:

In jeder möglichen Konstellation führt eine Google-Suche nicht zum Erfolg, es scheint keinen Hersteller (mehr) zu geben, der so einen Artikel führt.

Zumindest verrät uns die Produktbezeichnung, dass wir ein 128x64-Pixel-Display haben. Dass die Auflösung der X- und Y-Achse in der Artikelnummer auftaucht, ist sozusagen eine universelle Norm. Aber viel mehr lernen wir hieraus nicht.

Was letztendlich die Veranstaltung rettet, ist der Verbinder. Dieser hat eine spezielle Beschaltung, über die ich einen passenden Ersatzartikel finden konnte:

Zunächst fällt auf, dass einige Pins gar nicht verbunden sind und das Kabel dadurch auch schmaler wird. Aus 34 Pins am Verbinder werden nur 20 durchgeleitete Verbindungen. Angenommen, Pin 1 sei hier ganz links, dann wissen wir zumindest schon einmal:

• Pin 1-15: verbunden
• Pins 16-20: NC
• Pins 21-22: verbunden
• Pins 23-24: NC
  
• Pin 25: verbunden
• Pins 26-30: NC
• Pins 31-32: verbunden
• Pins 33-34: NC

Die Nicht-verbundenen (NC) Pins sind jeweils Gruppen von 5 zusammenliegend, dann 2, dann noch einmal 5 und noch einmal 2.

Da ich mit der Artikelbezeichnung nicht weiterkam, habe ich dann COG-LCDs im Netz gesucht, die eine ähnliche Beschaltung haben und Eigenschaften haben, also:

• LCD mit COG
• 128x64 Auflösung
  
• monochrom
• hintergrundbeleuchtet
• 34-Pin FFC-Verbinder mit 0,5mm Pin Pitch
• Anzeigefläche gemessen ca. 71 x 39mm 
• Gesamtgröße ca. 80 x 55mm

Bei den meisten Modellen, die man so findet, sind alle 34 Pins in Benutzung, vermutlich für die unterschiedlichen Protokolle, die man beim Sprechen mit dem COG verwenden kann. Es blieb eigentlich nur folgendes Display übrig:

Crystalfontz CFAG12864Q1-TFH

Shopadresse: https://www.crystalfontz.com/product/cfag12864q1tfh-128x64-low-power-backlit-lcd-display

Gemäß Datenblatt, das man sich dort herunterladen kann, sind die Gruppen von genutzten und nicht-genutzten Pins identisch:

Datasheet CFAG12864Q1 Series, Release Date 2022-07-18, (C) Crystalfontz America, Inc.

Nun hätte man noch sichergehen können und per Oszilloskop die Beschaltung nachprüfen können, aber es wäre extrem mühsam gewesen und hätte ggf. nur dazu geführt, dass auch das Crystalfontz-Display kein passendes Ersatzteil ist.

Zunächst sah es aus, als müsse man das Display in Amerika bestellen zum Stückpreis von 17,94 US-$ plus Versandkosten von rund 50 US-$. Das macht die ganze Sache wirtschaftlich unsinnig, denn das defekte Gerät habe ich für ca. 60€ gekauft, und natürlich sollte die Reparatur nicht noch einmal so viel oder noch mehr kosten - mit dem Unsicherheitsfaktor, dass nur der Verbinder passt, aber das Protokoll nicht.

Dann fand ich heraus, dass es in Deutschland einen Distributor für das Display gibt, nämlich die Fa. LC-Design. Diese vertreibt Crystalfontz-Displays und hat einen gewissen Vorrat auf Lager. Was nicht da ist, kann in USA bestellt werden und ist dann innerhalb von ein paar Wochen lieferbereit.

Hier der Link zum Distributor:

https://lc-design.de/crystalfontz-intelligent-display-module/

Über Kontakt via E-Mail habe ich das besagte Display angefragt und bekam es auf Vorauszahlung innerhalb von ca. 3 Wochen per DPD zugestellt. Gekostet hat das Display 23,78€ netto, dazu kamen noch 6,70€ Versand ebenfalls netto. Zu zahlen waren also 36,27€. Das ist zwar angesichts des Wertes, der hier erhalten werden soll, auch schon grenzwertig, aber ich habe es mal riskiert.

Crystalfontz ist deutlich auskunftsfreudiger mit Angaben zu dem Display, wie man am Aufdruck auf der Rückseite erkennt:

Abgesehen von dem Flachbandkabel, das auch die nicht genutzten Leitungen in voller Breite überträgt, ist es äußerlich von dem ursprünglich verbauten nicht zu unterscheiden. Nach unten führen auch die zwei Hintergrundbeleuchtungs-Pins an exakt der richtigen Stelle heraus.

Hier ein Blick auf das bereits angeschlossene Crystalfontz-Display. Man erkennt hier auch die erwähnte schwarz-glänzende Silikonschutzschicht am unteren Rand des Displays.

Gelb markiert ist die Stelle, an der das Flachbandkabel geknickt werden muss, damit es komplett unter dem Display liegt, wenn alles wieder montiert ist. Andernfalls kann es nach unten hervorschauen und in den Bereich der Tasten gelangen. Das ist weder für die Funktion der Taste gut noch für das Kabel selbst, das keine überflüssige Bewegung oder Verwindung erfahren sollte. Die Flachbandkabel machen einmaliges (!) Knicken gut mit und halten die so gegebene Form auch.

Zum Anschließen schiebt man das Flachbandkabel mit den Kontakten zur Platine schauend in den Verbinder ein. Dies geht nur, wenn der Sicherungsbalken geöffnet ist, also 90° vom Verbinder absteht. Das Kabel schiebt man genau gerade in die Führung ein. Schaut ggf., ob das Kabel versehentlich unter statt in den Verbinder geschoben wurde. Nach ca. 1-2mm des Weges sollte das Kabel am Anschlag sein und sich nicht weiter einschieben lassen. Der etwas dickere Plastikstreifen am Ende des Kabels hilft dabei, und das Kabel sollte möglichst auch an keiner anderen Stelle angefasst werden. Dieser Streifen schaut am Ende noch gute 5mm heraus. Wenn das Kabel gerade sitzt, den schwarzen Sicherungsbalken wieder nach unten klappen und durch leichtes Ziehen am Kabel prüfen, ob die Verbindung wirklich fest ist.

Hierbei bitte äußerste ACHTUNG! Die Flachbandkabel mögen ausschließlich Zugbewegungen entlang ihrer Längs-Achse. Wenn man so ein Kabel zur Seite verwindet, kann es schnell reißen und ist dann kaum zu reparieren. Man kann es auch relativ leicht durchreißen wie ein Stück Papier. Denkt beim Zug-Test auch daran, nicht am Display zu ziehen, sondern dazu das Kabel irgendwo mittig anzufassen, sonst reißt die Verbindung vielleicht am Display selbst, und dank der Silikonschicht hält dann trotzdem noch, was eine schwer zu findende Fehlerquelle darstellt. Es geht bei diesem Test auch nur darum, festzustellen, dass das Kabel nicht vollkommen locker war und einem einfach wieder entgegen kommt. Also nur ganz leicht ziehen, auf keinen Fall mit Kraft!

Nun setzt man das Display an die passende Stelle, so dass die zwei Kunststoffklammern in die Aussparungen in der Platine greifen. Leider sind diese Klammern etwas kürzer geraten als beim Original, so dass sie (zumindest bei meinem Versuch) nicht wirklich halten. Ich habe mir dann damit beholfen, das Display an der oberen Seite links und rechts mit einem Klebestreifen an der Platine zu befestigen, damit es sich nicht im Gehäuse frei bewegt. Im unteren Bereich wird das Display durch die zwei Lötkontakte der Beleuchtung gehalten.

Lohn der Mühe:

Erfolg! Das Crystalfontz-Display zeigt alles so an, wie es soll. Es ist nichts spiegelverkehrt, es gibt keine Bildstörungen, und auch die Hintergrundbeleuchtung funktioniert 1:1, die Polarität stimmt also auch.

Möglicherweise hat Crystalfontz also das ursprünglich verbaute Display auch als OEM geliefert. Jedenfalls ist der Kabeltester damit jetzt endlich wieder voll einsetzbar.

Wer es mag, kann bei Crystalfontz übrigens ein gleich beschaltetes Display in weiß-auf-blau bestellen statt der Darstellung schwarz-auf-grau. Die Artikelnummer dazu lautet CFAG12864Q1-TMI, also TMI als Appendix statt TFH. Es müsste ansonsten genausogut funktionieren, da es lediglich als Produktvariante geführt wird. Ich habe das aber nicht ausprobiert! Klar ist jedenfalls, dass man die weiß-auf-blau darstellenden Displays nicht lesen kann, wenn nicht die Hintergrundbeleuchtung die ganze Zeit aktiv ist. Beim schwarz-auf-grau-Display kann man bei einigermaßen gutem Umgebungslicht auf diese verzichten.

So, ich hoffe, dass ich hiermit ein paar dieser Geräte vor dem Müllberg retten konnte, denn wahrscheinlich sind 9 von 10 Ausfällen auf das Display zurückzuführen.

Wenn Ihr zu der Reparatur noch Fragen habt oder einen eigenen Erfolg vermelden könnt, freue ich mich über entsprechende Kommentare.

Bis zum nächsten Mal!

Joe

SSH Login to Squeezebox Radio / Touch / Controller

Sometimes you may feel the need to see what's going on behind the scenes in your Squeezebox. The menus may offer some test functionality already but for the curious that's not satisfying enough.

The Squeezebox models mentioned are based on Dropbear which is essentially a tiny linux designed for embedded SoC (System on Chip) hardware where performance is not exceptional. So it's really lightweight but still features an actual Linux kernel that supports multi-tasking, memory management and more, basically on just any hardware.

Linux, as most of you probably know, has great built-in support for networking. A root shell is available via SSH (Secure SHell) that you can connect to wirelessly or wired. It's not particularly user-friendly in that it's just a text-based console, nothing graphic about it. Those who are more experienced with Linux will immediately feel at home as a lot of the usual commands works, such as cd, ls, rm, top, cat, tail, and so on.

The risk of destroying anything is rather low as the file system that you are seeing in there is basically a RAM-disk and is always refreshed when the device is powered up after a cold start. You should still be careful and make backups of files you modify. Don't hold me liable if any of this goes south. Please continue only if you agree you do this on your own risk!

By the way, you won't notice any difference on the user side of your Squeezebox while the SSH port is open or being used. It will behave as always, depending on what you do in the root shell it might be a bit slower maybe.

So how is all of this done?

As usual, it's not just the push of a button.

First I need to disappoint all Transporter, Boom, Receiver, Classic, SliMP owners. SSH is not available on your platform. Unfortunately no way is known about how to connect to their kernel. Maybe it isn't possible at all, or only via JTAG debugging which is way out of my skillset.

So we are focusing here on the three models I know support SSH: Touch, Radio, and Controller.

All of these offer an option to enable the SSH port. By default it is off so the device won't be reachable via SSH at all. This is preferable if you fear that somebody in your network might hijack your Squeezebox. Turning the port off entirely is the best and safest way to ensure nobody gets in there.

Enabling the SSH Port (22)

The option can be found in the menu here:

• Settings (Einstellungen)
  
• Advanced (Erweitert)
  
• Remote Login (Remote-Anmeldung)
• Enable SSH (SSH aktivieren)

The screen shown in the last step also reveals what you need to specify to connect and authenticate:

So another reason to keep the SSH port closed is the very weak protection of the root account. I think the password cannot be permanently changed and even if it could, it might interfere with functions the Squeezebox relies on.

Our takeaways here are:

SSH user name: root

Password: 1234

IP address: (varies depending on your network configuration)

The port is open as soon as you click the Enable SSH menu and the little bright box appears to indicate the option is now active. You can toggle it off in the same place at all times.

Okay, so far for the Squeezebox part of this.

Accessing the SSH Shell

SSH uses TCP port 22 by default. What you need is a piece of software to connect, and it needs to be able to handle secured connections. On Windows, PuTTY is one of the best tools for this purpose, and it's free to download, too. Linux has ssh built in already and does not need anything beyond that.

Linux

To set up the connection and start using it, just start a terminal of your choice and enter the following command:

ssh 192.168.74.40 -oKexAlgorithms=+diffie-hellman-group1-sha1 -c aes128-cbc -o PasswordAuthentication=yes -o PreferredAuthentications=keyboard-interactive,password -o PubkeyAuthentication=no -l root

So what's all this? SSH accepts tons of parameters. Usually it is enough to specify just the target you want to connect to. However, the Squeezebox uses some very outdated key exchange and encryption algorithms that SSH won't easily accept so it needs to be made to.

The first parameter is the target IP address which in the case of my demo here is 192.168.74.40 but is something else in yours. Find the one that applies in your case in the Enable SSH screen (example screenshot above).

The -oKexAlgorithms parameter adds the SHA1 algorithm to the applicable algorithms for just this one command. All these options can also be made permanent but that's not desirable for security reasons. So we are adding it here to ensure that the next SSH connection you make will rely on only the secure and up-to-date mechanisms again.

-c aes128-cbc adds one of the encryption ciphers that the Squeezebox supports. It's also known to be rather weak nowadays so SSH must be forced to use it anyway.

The remaining -o parameters ensure that SSH won't accidentally pick up one of your public keys (from ~/.ssh) for authentication. The Squeezebox wouldn't know how to deal with that anyway. So we force it here to ignore any personal keys you might have.

-l root tells SSH to use the user account root to connect.

 

SSH will immediately connect once the command has been submitted, and ask you for the password after a short period. Enter 1234 and press <Return>.

This is what you will see:

 

 

 

The announcement about the RSA fingerprint will happen only once, SSH will register the remote host (-> your Squeezebox) and remember you agreed to the risks of connecting to it.

 

Sorry, could not resist showing this in Cool Retro Term, it's so much more fun that the dry plain text consoles. If you're interested, here is the source:

https://github.com/Swordfish90/cool-retro-term

If you like snap images, you can get it ready-to-go from here:

https://itsfoss.com/cool-retro-term/ 

Windows

Windows does not offer an integrated SSH tool, and Telnet which you can install as a feature won't cut it because it does not support key exchange and encryption (as far as I know - please correct me if this is no longer true).

So you will need a terminal program installed in your system. I recommend PuTTY as it is very feature-complete, vastly adjustable, and free do download without any nagging ads built in.

I won't go into the details of installing PuTTY, you can find plenty of information on that elsewhere.

Get PuTTY from here: https://www.putty.org/

After you have installed and started it, the window will look something like this:

 

 

Enter the IP address that your Squeezebox showed you on its screen into the Host Name (or IP address) box - as shown above.

Port 22, and the SSH connection type are preselected so you are basically ready to go. Click Open near the bottom right corner:

 

 

This is the point where Linux ssh would completely refuse the connection as it's too unsafe by today's standards. PuTTY lets you decide. Click Yes to go on.

The next prompt is about the Squeezebox host key that is still unknown to PuTTY and therefore untrusted:

 

 

The red crossed-out section belongs to the RSA2 key that the Squeezebox identifies itself with. This might be individual per device but my impression is that it's same for all of them. Anyway, to help me sleep at night, I obfuscated that portion of the screenshot.

You need to click Yes again to continue to the shell. PuTTY will register the key in its internal store and not ask you again. If you answer No, you will still connect but the key won't be registered and you will see the same prompt again next time you connect.

This is what you should see / enter:

 

Now enter root as the user name and 1234 as the password. You won't see any screen echo as you enter the password so be careful during your input. That is to make sure that nobody else can look over your shoulder and steal this secret from you *sniggle*. But that's a Linux default behavior and usually makes a lot of sense.

After submitting the credentials, you are logged in. Congratulations!

Once the Connection is Up (Linux and Windows)

The final number sign (#) in the console is the Dropbear standard prompt where you can now enter commands that directly execute inside the Squeezebox!

Terminating the Connection

Linux is very forgiving about abrupt connection termination but if you want to be graceful, you can enter the command exit to get out of the console. In Linux, you will be back in your regular terminal, exactly where you were before issuing the ssh command. PuTTY will close the window that represented your session once it has ended.

Looking around

Task Overview

Use the top command for a task manager:

Mem: 42156K used, 20220K free, 0K shrd, 7724K buff, 13604K cached
CPU:  34% usr   2% sys   0% nic  63% idle   0% io   0% irq   0% sirq
Load average: 0.25 0.40 0.21 2/39 709
  PID  PPID USER     STAT   VSZ %MEM %CPU COMMAND
  579     1 root     R    29580  47%  33% /usr/bin/jive
  631   579 root     S     8712  14%   2% jive_alsa -d default -c default -b 30000 -p 2 -s 16 -f 3
  704   648 root     R     2952   5%   1% top
  554     2 root     SW<      0   0%   0% [wlan_main_servi]
  546     1 root     S     3032   5%   0% /usr/sbin/inetd
  533     1 root     S     2956   5%   0% /sbin/syslogd -S
  648   646 root     S     2952   5%   0% -sh
  581     1 root     S     2952   5%   0% /sbin/getty tty3 9600 VC vt100
    1     0 root     S     2948   5%   0% init
  535     1 root     S     2948   5%   0% /sbin/klogd
  580     1 root     S     2948   5%   0% init
  620     1 root     S     2948   5%   0% udhcpc -R -a -p /var/run/udhcpc.eth0.pid -b --syslog -i eth0 -H SqueezeboxController -s /etc/network/udhcpc_action
  646   546 root     S     2644   4%   0% dropbear -i
  277     1 root     S <   2052   3%   0% /sbin/udevd -d
  571     1 root     S     1908   3%   0% /usr/sbin/wpa_supplicant -B -Dmarvell -ieth0 -c/etc/wpa_supplicant.conf
  538     1 root     S     1828   3%   0% /usr/sbin/watchdog
  573     1 root     S     1816   3%   0% /usr/sbin/wpa_cli -B -a/etc/network/wpa_action
  163     2 root     SW<      0   0%   0% [mtdblockd]
  193     2 root     SW<      0   0%   0% [s3c24xx-spi-gpi]

The list goes on a lot longer than shown here.

This gives you a quick overview of the memory and CPU usage and what processes are responsible for their consumption, updating about every 5 seconds. The most CPU-intensive processes are listed first. You will normally see jive here which is the process responsible for making a Squeezebox out of it all. It presents the user interface, listens to user input events, updates the display, and coordinates network and audio hardware control, among others. 

Exit out of top with <Ctrl-C>, or more gracefully, just pushing the <Q> key.

System Log

To trace the system log, you can enter the following:

tail -f /var/log/messages

This will show you the last 10 lines in the messages file, and keep updating if new content is appended to the file. <Ctrl-C> terminates tail and you will be back at the prompt.

If you want to review the entire file, use:

less /var/log/messages

less allows you to browse the file line by line or page by page, or jump to the end of it with <G> for instance. There are many more capabilities in less (despite the name). However, it won't update if the file has changes. You need to re-issue the command in order to see the latest content. Less can be quit with the <Q> key.

dmesg will give you the kernel log that was written from the moment the kernel was booted far enough to have file system access. So this shows very early stages of the startup processes and might reveal valuable information if you suspect a malfuction. Usually, dmesg will just dump the entire log into your console (around 160 lines) and you have to scroll back to the top to see all of it. If you want to page through it, type in:

dmesg | less

SD Card Access

Most people don't even know it but there's actually an SD card slot hidden in the battery compartment of the Squeezebox controller!

 

The battery needs to be removed in order to access the slot. Unfortunately, modern SD cards appear unreadable, probably the firmware supports only very old versions. A Nokia 128MB MicroSD card from my collection can be read without any trouble and auto-mounts to /media/mmcblk0p1, whereas a newer 16GB SanDisk model won't mount at all:

# cd /media
# ls
mmcblk0p1
# cd mmcblk0p1/
# ls -la
drwxr-xr-x    2 root     root           512 Jan  1  1970 .
drwxr-xr-x    1 root     root             0 Jan  1  1970 ..
-rwxr-xr-x    1 root     root         60416 Sep 29  2013 HXCFE_V1_8_2_40.upd
# 

Cool, eh?

So you can now copy (cp) files from and to the card as you wish.

The Touch also has an SD slot which is more well-known because it is exposed. I'm speculating here but probably it can be accessed inside SSH.

If you would like to copy and store some files, maybe exchange them with a PC or whatever, and find scp tpo troublesome to use, the SD card might be a comfortable way out. I will investigate further about the compatibility to SD cards in general, and add information here. For now, I think the older the card, the better the chance to make it work, at least in the Controller.

The Touch will probably support much newer cards as well as higher capacities are certainly desirable for the built-in Logitech Media Server.

SCP

Cool, just found out that SCP does work if SSH access is enabled! So if you want to retrieve any files from your Squeezebox Radio, Touch, or Controller, you can do so by this command (on Linux!): 

scp -O -c aes128-ctr -o PasswordAuthentication=yes -o PreferredAuthentications=keyboard-interactive,password -o PubkeyAuthentication=no -oKexAlgorithms=+diffie-hellman-group1-sha1 root@{ip}:/etc/squeezeplay/userpath/squeezeplay0001.bmp .  

Replace {ip} with the IP address that your Radio was assigned. The path shown is where the screenshots are stored if no SD card is used.

I think it might be easier to use Windows and tools like WinSCP to do this more visually but showing the most complex approach may give you a direction. 

While we are at it...

Making Screenshots 

If you want to make a screenshot of what is currently shown on the display, keep the PAUSE and REW buttons pressed at the same time until you hear a confirmation sound. A small popup will also inform you the screenshot was saved.

The Squeezebox Touch and Controller will preferredly write on the SD card if one is inserted, as far as I understand (didn't check this yet, sorry). If no SD card was set or no SD slot is available such as in the Radio, the screenshot is stored in internal memory and probably volatile, i.e. won't survive the next power cycle. 

Conclusion

So that's it for now, I'm curious what ideas you all might have how to utilize the SSH interface and whether anything useful can be done with it.

Feel free to ask any questions you might have, and let's explore this a bit!

Have a good time, and stay safe!

Vacuum Fluorescent Displays - How they fail (focus on Squeezebox)

Here are some examples of a burnt-in display plus filament starvation. The photos may help you identify what problems your Squezeebox max have, and assess the situation, figure out if it's worthwhile to replace the display etc.

First let me say that the Noritake itron displays used in the Squeezebox 1, 2, 3 (aka Classic), Boom, and Transporter are pretty solid. They rarely fail by themselves. There is some smartness in the form of chip-on-glass circuitry in the glass housing which helps reduce the pin count and also simplifies the driving circuitry.

There are some cases where a display is invariably defect so there is no way around replacing it, for instance:

• display body or seal broken: the vacuum is replaced by air rushing into the glass housing which inhibits the electron flow and may cause filament wires to melt which may inflict more driver damage (see below: filament wire rupture).
  You can identify a ruptured display by obvious cracks, sometimes they are really hard to see. What definitely indicates air ingress is the getter(s) in both top corners of the MN32032A, and the right top corner of the MN16032G(B). The purpose of the getters is to burn off the last bits of Oxygen after the display was sealed, resulting in a mirror finish on the inside of the glass near the getter when this operation was successful. A similar coating is found in regular round vacuum tubes, in most of them the mirror area is considerably larger.
  The glass near them should be rather dark and look like a smoked glass mirror in back light:
  
  
  
  
  This is from an intact display. The next pictures show the getters when the seal was broken:
  
  
  
  
  
  
  
  The getter(s) turned white with a bit of mist around them, and parts of the previously silverish coating even fell off as little white flakes inside the display. The coating inside of the glass is no longer reflective.
  The reason for this can be found here:
  
  
  
  
  On the lower-right corner, the seal that goes completely around the display has two gaps, evident in the rainbow patterns, elsewhere it's just a consistent dark-grey. The corner was hit by something, some glass shattered off, and a crack can be seen in the vertical spacer, about 1cm left of the point of impact:
  
  
  
  
  
  
  
  This is very easy to identify without even opening the Squeezebox if you look closely. If you see white getters, you know trouble lies ahead. No question: once this happened, the display will no longer shed the tiniest bit of light. As it's not possible to re-seal the glass housing and enable the getters another time (their special coating has burned off in production already), this is a terminal damage.
  
  
• line driver defect, for instance showing as one or multiple pixel lines staying dark: this means that one of the chip-on-glass components has an internal failure. As they are inaccessible from the outside, there is no fixing this.
  
  
• filament wire rupture: the filament wires are mounted on flexible spring contacts to ensure that they are always under a given amount of tension so they won't touch the grid that is directly beneath them. As the wires expand and contract depending on their temperature, the springs also serve to compensate for that. If a wire ruptures, it may cause short circuits against the grid as well as other heater wires. This is clearly visible by horizontal black bars across the entire width of the display as well, or if the grid circuitry is hit, by a complete failure of the display. Here is one where the red arrows shown the torn wire, and the burn mark the shortcut caused at the yellow arrow (+5V at a high current meet +55V grid voltage!):
  
  

But in my experience, >98% of the cases are just aesthetics. The displays are still readable to some degree but no longer beautiful to look at:

Noritake MN32032A (in a Squeezebox 3 Classic) with heavy aging signs

 

Another reason for bad visuals is well-discussed here and is mainly specific to the the Squeezebox Boom where the circuitry powering the filament heater wires is failing. This is what Noritake calls filament starvation, the outcome of which is shown below in photos.

My conclusion is that there is no immediate need for panic if a display is getting darker. It will always be readable at least in dark environments. If it gets completely dark from one day to another, the problem is elsewhere, in most cases the power supply mentioned in the previous paragraph.

These visual issues (but not total defects) are documented in the following pictures:

1. horizontal striping (irreversible)
   caused by the heater wires in the places where they are closest to the pixels. Naturally, these pixels will receive more electrons than others around them vertically, so along the six heater wires the pixels will darken a bit faster than the others. This is similar to burn-in, but in this case not caused by the contents shown on the display. Even brand-new displays have this right from the start, but it gets more pronounced over time. Apparently, horizontal striping is somewhat immanent in the design.
   
   
2. vertical striping (mostly repairable)
   caused by the grid boundaries. The grid is actually not a single one but split into groups, each 4 pixels wide and covering the entire height of the display area. Electrically no segment is connected to a neighbouring one, and I cannot say why, but under the gap that separates two grid segments, the pixels may look darker. It depends on these factors:
1. brightness setting: lower brightness settings cause a more pronounced vertical striping
2. filament starvation: the less power the heater wires are getting, the more apparent this kind of artifact is becoming
   
   One example here that illustrates how much more dramatic vertical striping becomes along with filament starvation (top photo) vs. the same display with the filament starvation fix applied (bottom photo). Needless to say, both were taken at the same brightness setting:
   
   

 


3. shadows (irreversible)
   caused by burnt-in pixels. The illumination in a VFD is achieved by a phosphor coating on every pixel that emits light when subject to an electrical charge. This coating sputters away a tiny bit in the course of the reaction. The resulting degradation depends on the brightness of the pixel (the higher brightness, the faster it degrades) and the duration the pixel is lit. This means that even with a less bright setting, a constantly-illuminated pixel will sooner or later be darker than surrounding ones, causing shadows. This is comparable to pixels in a plasma TV where the problem is well-known from broadcast station logos permanently being shown in the same corner, appearing as dark shadows whenever something bright is shown in the spot that is not covered by the logo itself.
   Unfortunately, there is no way of refreshing the pixels. Once they have burnt in, they can only get even worse.
   
   
4. overall darkening (irreversible)
   over the years, the displays lose brightness across their entire surface while they are powered on, no matter if they are showing anything or not. A contributor to this is the fact that a Squeezebox will always keep the VFD powered, even in standby / off modes, and even if no "screensaver" is employed to ruin the display but it shows absolutely nothing. I assume that either the heater wire coating sputters away over time, or the phosphor coating just ages with higher temperatures. The heater wires have that name for a reason, and a temperature of 45°C near them is quite usual.
   In many cases the entire display appears darker because of filament starvation (only applicable for the Boom model). It's easy to find out by the fix discussed here. You will observe a much brighter display after the fix was applied if the power circuitry of the Boom caused filament starvation before.
   
   
5. left/right edge darkening (repairable)
   no photos on this one as I haven't had a unit with this issue in a while. Filament starvation in its final stage will cause the display to fade out near the left and right edges considerably more than in the center.
   
   

Taking Photos of VFDs

...is not as easy as one should think. The problem is that they are actually flickering which the eye cannot perceive, similar to tube-based TVs, where it's actually just a single dot that makes up the entire picture, but persistence of vision, combined with screen material that holds its brightness for a small amount of time, helps us see it all as one image.

It's completely different when you use a camera. Smartphone cameras are a bit better because software may help them compensate the striping artifacts that come from shutter speeds and CMOS sensor sampling rates different than the rate at which the subject refreshes. DSLRs like I am using take a picture at a given exposure time. I am far from experienced on this matter. Basically it would be ideal to have the camera shutter open for just a single refresh cycle of the display. But that does not just depend on the mains input frequency but rather on the scan rate of the grid segments in the VFD and the way it is driven by the software. Actually I have not measured the exact frame rate of the VFD employed in a Boom and don't know exactly what needs to be done to take this kind of measurement. Anyway, it's high enough to trick the eyes into perceiving smooth animations and stable imagery.

The camera sensors are picking the image up so fast that they may just pick up one small segment of the display being illuminated. That is because it actually is illuminated only in slots, not entirely.

Let my try to explain this with some pictures.

Here is a photo taken at 1/500 second exposure time. It's the same mode as in all the other photos, the display shows a fully illuminated surface with all pixels on.

Somewhat expectedly, this area gets only half the size at 1/1000 seconds exposure:

The bright area would get smaller and smaller with shorter exposure. The best my DSLR can do is 1/8000th of a second, and that still gets at least the equivalent of about two columns illuminated 100%. For me there is no telling how fast the scanning actually goes.

Not let's try and calculate the refresh rate. We can see from the second picture that in one millisecond we find a total of eight blocks which are not completely black, with four in the center which are 100% bright, and adjacent columns which are partially illuminated (fading in on the right and fading out on the left side).

Let's assume that we have the equivalent of 5.5 fully-illuminated columns in total here. This approximately matches considering that we have the equivalent of between 10 and 11 columns in the 500 millisecond shot in the top photo.

The grid in the MN16032 display has 54 sections (or columns) as shown here:

The small contacts at the bottom of each grid section make this easy to see. I have counted them in groups of five and found a total of 54 contacts.
The grid segments are arranged to cover 1.5 pixels on the left, then 52 segments covering 0.5 + 2 + 0.5 pixels up to one on the very right edge which covers 2.5 pixels. Sum it up and we get 1.5 + 52 * 3 + 2.5 = 160 pixels. Just about right.
To simplify the grid math, let's make this a total of 53 columns across the width of the display area (each covering 3 pixel columns). We are only off by one pixel then, shouldn't matter too much.


A full sweep from left to right, illuminating all pixels, would take (53 / 5.5) / 1000 seconds which is about 9.6 milliseconds. The inversion to compute how many times that is per second results in ~104 Hz if I'm not mistaken.
It might be more like exactly 100 Hz instead, eventually there is heavy guessing involved ;o)
Please feel free to comment if this approach is complete BS. This is not my focus of experience.

The challenge is adjusting the camera sensor exposure time accordingly. To get a photo that reveals what the eye sees, no more no less, it needs to be closely adjusted to the display timing or multiples thereof. This is rather complicated to do which is why I decided to use gray filters and choose a longer exposure (in the range of 3.5 to 6 seconds). This flattens out the effects of areas which are illuminated more frequently than others in the swift period a normal photo would take.

But unfortunately, I did not care for this in the first run so the photos of the old display will show a brighter vertical stripe that appears in different positions. This is where the illumination of the previous cycle "overlaps" with the next cycle. The exposure was a tad bit too long. This makes the respective parts of the display appear brighter than the rest. As the scanning goes from left to right and, in each segment, from top to bottom, the stripe appears to be a bit askew.

How To Drive The Display

The Built-In Way - Possible With Every Squeezebox Classic and Boom (sorry, Transporter does not have it)

All the photos show a display that is fully illuminated. The Squeezebox offers no simple way or mode to get there. There is a built-in test pattern though that might help you estimate the status of your display. You will need a Squeezebox infrared remote control with a 10-digit keypad though. The small standard Boom remote control won't help you as it does not have the required buttons.

See here for a video: https://youtu.be/58rniC6mIMw

WARNING: You may need a firmware reset to get back out of this mode, so please be aware that this may affect your settings, including the Wi-Fi access key etc., all of which can get lost and may need to be re-entered. Therefore, it's best to use the test pattern only if you are sure you have all data to set the Boom up from scratch afterwards. 

This is how to start the test pattern mode:

• disconnect your Squeezebox from power (this means unplug it)
• using the infrared remote control, keep the digit "4" pushed down
• power up the Squeezebox and be sure to direct the infrared remote control towards it
• the boot logo will appear and immediately be replaced by the test pattern which will continuously scroll from right to left
• this mode will be permanent and be re-entered even if you power-cycle the Squeezebox

To end the test pattern mode, you will need to perform a factory reset:

• disconnect your Squeezebox from power
• using the infrared remote control, keep the digit "1" pushed down
• power up the Squeezebox and be sure to direct the infrared remote control towards it
• the boot logo will appear and the Squeezebox may restart another time, displaying "firmware reset" or similar
• you may have to reconfigure a lot of the settings at this point :-|

The LMS DisplayTest Plugin

The test mode served me well a few times to take very very long exposures to have the same effect as if the display was all-on for a longer period of time. But the plugin I created makes this a lot easier now. It can be navigated to in the Extras menu and will immediately turn all pixels on at the currently-set brightness. That's all it does, but this is also all that's needed to diagnose the state of a display. I may add more functionality as time passes but currently I would not know what other functionality might be useful.

The plugin can be downloaded from here:

https://github.com/JoeMod2017/squeezebox-DisplayTest-Plugin.git

Installation and usage instructions are contained in the README.md file next to the three plugin files. If you have any questions, use communication facilities right inside the GitHub page, or the comments section in this post, or e-mail me at johannesfranke74@gmail.com

I have tested the plugin against my Transporter (where both displays light up - yay!), a Squeezebox Boom, and in TripleFat 0.1.1, a Java-based SLIMP3 emulator, to verify that the 2x40 text character display is also fully illuminating. Also used SoftSqueeze 3.9 for an impression of an emulated Transporter.
This was NOT tested yet against a Squeezebox v1 because I have none available. Its 280x16 display might not have all the support it needs yet.

TripleFat 0.1.1 emulation of a SLIMP3 text display in DisplayTest mode

SoftSqueeze using the Transporter skin and running the DisplayTest plugin

Effects of Filament Starvation (In Old Displays)

Anyway, let's eventually get to the example pictures. I took them all from the same unit with the same photo settings (exposure, aperture, ISO etc). The PCB was already out of the device so the display is not covered by anything. It has all of the symptoms shown above (except #5). I'll explain how each is presenting here. Pictures are in pairs, showing the situation before the filament starvation fix, and after it was applied.

Squeezeboxes have seven brightness settings overall:

• automatic - depends on ambient light (in the Boom), or some internal magic if no ambient light sensor exists (all other units), and adjusts brightness between levels 1 and 5
• 5 = brightest
• 4
• 3
• 2
• 1 = lowest
• off

Never mind the skewed brighter or darker areas, they are a result of camera shutter speed vs. display refresh rate as discussed in the "Taking photos" chapter above.

Brightness level 5 of 5 (brightest)

before fix:	after fix:

The highest brightness levels expose shadowing and uneven lighting very well. Horizontal striping is also clearly recognizable. Filament starvation is mostly visible in the form of vertical striping.

Brightness level 4 of 5

before fix:	after fix:

The difference to level 5 is not huge. What becomes clear here is that applying the filament starvation fix may bring the display back up to a brightness that it would otherwise only reach in the next-higher brightness setting. Compare the "after fix" picture here to the "before fix" picture of brightness 5/5 above, and you will know what I mean.

Horizontal striping is more pronounced in both situations, and will become clearer along with less brightness.

Brightness level 3 of 5

before fix:	after fix:

Again, things get a little more dramatic, shadows are beginning to inhibit the readability to some degree, and behind the grey smoke screen of the Squeezebox display covers, it might be barely enough to be visible to the outside.

Brightness level 2 of 5

before fix:	after fix:

A fresh display would still appear somewhat readable and clear in this setting. Striping (horizontal + vertical) is very pronounced now, as well as shadowing. Through the usual front panel screen it will hardly be readable at all, even at night.

Brightness level 1 of 5 (darkest)

The display was too dark already so the camera would not pick up a lot, not even with the fix applied. Therefore, there are no pictures for this mode.

Effects of Display Starvation (In New Displays)

Now let's compare all of this to the situation after the display was replaced by a brand-new one.

I remember the shock that I got after replacing a Boom's VFD. It looked very similar to this:

This is a medium brightness, and back then I was not able to have all pixels on, instead I observed the logos that scroll in from right to left as the Boom powers up, and especially the "squeezebox" logo that fills the entire width of the display looked heavily faded left and right. All that with a display that came straight from the factory.

Noritake helped me figure out why that is. Since then I know it's filament starvation.

So here is a new display in the same unit from which I took the comparison pictures above. Again, I switched back and forth between the 3-diode fix being engaged and disengaged.

Brightness level 5 of 5 (brightest)

before fix:	after fix:

This illustrates that even a brand-new display won't be perfectly even in all respects. This is perfectly okay and needs to be accepted.

Brightness level 4 of 5

before fix:	after fix:

Brightness level 3 of 5

before fix:	after fix:

Brightness level 2 of 5

before fix:	after fix:

Brightness level 1 of 5 (darkest)

Again, the camera didn't pick up a lot with the gray filters in front of the lens. So the darkest setting is still well visible for the eye but no way for me to get photos that convey this impression properly.
Anyway, where the old display appeared completely dark in the "one higher than off" setting, the new display has something to show, even though I cannot prove it in pictures here.

Conclusions

Dear readers, I hope you found this interesting and informational.
Feel free to ask if you have any questions or additions.