Trois Îles, Luxembourg

Restauring an old iRiver iHP-120, Part 1

In a time before smartphones, people used so called "digital music players" for portable music. One of them was the iRiver iHP-100 series, which came to the market in October 2003. It had up to 40 GB of storage, which was really a lot these days. It had a playback time of up to 16 hours. It had a remote control with a separate display. And it is the only pocket-size player I know that is also equipped with an optical line-in and line-out.

I got my player in 2004, and I used it for many years, until the hard disk started to show first signs of failing. Then I stored it away to save it for "special occasions" that never came. Many years later, I did not dare to charge it again, as I distrust over-aged Li-Po batteries that have been discharged for a long time. So my player became a Sleeping Beauty, waiting for the day it would be rediscovered and properly restored. The day was now.

In this first part, I will replace the original battery. In a second part, I will replace the 20 GB hard disk with a modern 128 GB MicroSD card, which is a lot more than the size of my entire music collection. After more than 16 years, it will be a modern portable music player again. (Well, sort of… I know it's still inferior to a smartphone.)

Before we start: Li-Po batteries are delicate. A damaged battery can cause severe damage to your home and your health. Please be very careful. If you're not confident enough for the operation, please ask someone for help.

The player is opened by removing the eight screws from the top and the bottom cap with a T6 screwdriver. The caps are glued in place, but can be pulled off with a bit of force. After that, the back cover can just be lifted off. The attached battery cable is very short, so be careful when lifting.

This is a photo of the inside. To the left is the battery pack that we are going to replace. To the right, we see the 1.8" HDD. Yes, the iHP uses an actual hard disk, with spinning platters and arms and all. In part 2, it will be replaced by a MicroSD card.

The battery connector is on the other side of the PCB, so we have to disassemble more. First we remove the HDD, it just needs to be gently lifted and then pulled out of the connector. There is a screw on each of the two side panels, they need to be removed as well. Then we remove all visible screws on the PCB.

The display frame is glued to the front cover, so we need to use a bit of force to remove the PCB. Be careful, the display is very sensitive to scratches. Also we don't want to have hairs and dust caught between the display and the front cover when we reassemble the device, so make sure you work in a clean and dust-free room.

Now we can disconnect the battery from the main PCB. Sadly, the power connector is in the way, so we need to twiddle with the connector and use a bit of force to get it removed. If you use a screwdriver, take care not to slip off and damage the PCB. Also, take care not short circuit the battery cable.

In the next step, we can remove the old battery pack. It is glued to the back cover, so we need a lever tool (e.g. a plastic opening tool) and some patience to gently remove it.

Be very careful when you remove the old battery pack. Do not use blades or pointy tools, and do not use force. The battery pack may burn if bent, damaged, or punctured.

You got the old battery removed now? Please don't just throw it away, but make sure it is properly recycled.

Before we insert the new battery, we should have a look at the cable first. On my replacement, the cable was considerably longer than the original one, so I decided to align it with the other corner of the back cover. If your cable is shorter, or if you are not sure, use the same corner as the original battery. In any case make sure that the cable is at the bottom edge of the back cover. If there is some of the glue tape left, it will firmly hold the new battery in its place.

If you think it was difficult to disconnect the old battery, you will find out that it is even more difficult to connect the new one. Check that the polarity of the connector is correct, the black wire must be closer to the USB connector than the red wire. Take care not to cut or break the wires while inserting the connector. If there is absolutely no way to push the connector into the socket, you need to remove the USB daughterboard. It can be unplugged after unsoldering the wires on its four corners.

I was lucky. After a few attempts and some frustration, I finally got the new battery connected.

When reassembling, make sure the battery cable is correctly routed like in the next photo. It must not be pinched anywhere. Now the PCB can be placed back onto the top cover again.

This is the right moment to check if there are visible dust particles or hairs caught between the display and the front cover. If so, use a photo lens brush to gently brush them away. Do not use a cloth, as it may cause tiny scratches.

Now close the bottom cover for a test. The battery cable should fit properly and should be tension-free.

After that, you can reassemble the device in the opposite order. Congratulations, you have given a new life to this amazing piece of hardware!

In the next part, we will replace the HDD with a MicroSD card. It will not just conserve some battery power, make your player faster and keep it cooler, but also greatly extend hard disk space for your music.

Access alternate certificates with acme4j

On January 11 2021, Let's Encrypt will change the default intermediate certificate from the cross-sign IdenTrust DST Root X3 certificate to their own ISRG Root X1 certificate.

The good news: The ISRG certificate is widely trusted by browsers by now, so the transition will be unnoticed by most users.

The bad news: The ISRG certificate is not included in Android devices before "Nougat" 7.1. These devices will show an error when trying to access sites that are signed with the new intermediate certificate. According to Let's Encrypt, stunning 34% of the Android devices out there shall be affected.

To mitigate the problem, Let's Encrypt provides an alternate certificate that is still cross-signed with the IdenTrust DST Root X3 certificate. If you have a web service that is accessed by a relevant number of older Android devices, you may want to use that alternate certificate. It will be available until September 29 2021. The IdenTrust DST Root X3 certificate itself will expire after that date, so this is a hard limit. Let's hope that the problem is going to be solved on Android side in time.

As acme4j fully implements the RFC 8555, it is easy to change your code so it will use the alternate certificate. Based on the acme4j example, this code block will use the first alternate certificate if present, and falls back to the main certificate if not:

Certificate certificate = order.getCertificate();
certificate = certificate.getAlternateCertificates().stream()
        .findFirst()
        .orElse(certificate);

Remember to remove the workaround after September 29 2021, so you won't accidentally use other alternate certificates that may become available in the future.

PS: getAlternateCertificates() was added to the latest acme4j v2.11. If you have an older version, fear not: you just need to have a Login object, so you can bind the alternate certificate yourself. This is how it would look like in the example client:

Login login = session.login(acct.getLocation(), userKeyPair);

Certificate certificate = order.getCertificate();
certificate = certificate.getAlternates().stream()
        .map(login::bindCertificate)
        .findFirst()
        .orElse(certificate);
Little Java Regex Cookbook

Regular expressions, or short "regex", are a pattern of characters and metacharacters that can be used for matching strings. For example, the pattern "gr[ae]y" matches both the strings "gray" and "grey".

While regular expressions are an integral part of other popular languages, they have been introduced to the Java world rather late with the release of Java 1.4 in 2002. Perl, certainly the mother language of modern regexes, already turned 15 that year.

Regexes are sometimes hard to understand, but once you got the hang of them, they will soon become your weapon of choice when you have to deal with texts.

In this article, I focus on Java code patterns for common scenarios. If you have never heard of regular expressions before, the Wikipedia article and the Pattern JavaDoc are good starting points. The Regex Crossword site is a great place for working out your regex muscles.

Read this article...
Enable Synology's hibernation debugger

If you own a Synology NAS, you probably know the trouble that it frequently wakes up from hibernation without any obvious reason. Synology has added a more or less undocumented debugger for that issue. If enabled, it will log the reason for waking up from its beauty sleep, so one can take measures against it.

WARNING: This article is targeted at experienced Linux users. Even if you manage to enable the debug mode, you still have to analyze the log files, find a solution to your individual problem, and assess if it is safe to apply. If you make a mistake, you can cause a lot of damage to your system and your data. Please take this advice seriously.

In any case, make sure your data is properly backed-up. Remember that a RAID is not a backup!

Also note that the debug mechanism has changed from time to time, so it may be completely different on your NAS depending on the DSM version that is used.

Read this article...
Thunderbolt and Lightning

 The Kaminari Lightning Detector Pyramid I recently found an article about the AS3935 Franklin Lightning Sensor. As I am already recording some weather data, it immediately raised my interest.

The sensor module can be found at many online shops selling products from China. It is not really cheap, but still affordable. I decided to use an ESP8266 as microcontroller, so I can read the sensor data by WLAN. The sensor is connected to the ESP via SPI. There was also some space left for a SK6812 RGBW LED indicating the sensor status.

The result of this project can be found at GitHub. It's called Kaminari (which is Japanese for lightning), and also comes with OpenSCAD files for a 3D printed, pyramid shaped case with illuminated tip. In this article I will explain a bit about how I developed the Kaminari firmware.

The first problem was the calibration. The sensor is roughly pre-calibrated, but must be fine-tuned to 500 kHz ±3.5% via the TUN_CAP register. For this purpose, the antenna frequency can be routed to the IRQ pin and then be measured by the ESP. I chose to prescale the frequency by a ratio of 128, giving an IRQ frequency of 3,906.25 Hz. For measurement, I've set an IRQ handler that is just counting up a variable on each interrupt. I then reset the counter, wait for 1000 ms, then read the counter, and get the IRQ frequency in Hz units. It's not 100% accurate, but good enough for this purpose.

The TUN_CAP register offers 16 calibration steps. Just incrementing it until the frequency matches, would take up to 16 seconds. Instead I used an algorithm called successive approximation to find the correct calibration value in only 4 iterations, taking a quarter of the time.

 The AS3935 connected to an ESP8266 To my disappointment, it turned out that the manufacturer of my module (CJMCU) has used nonstandard components, so my module could only reach a maximum frequency of about 491 kHz. I first suspected that the ESP might be too slow for this kind of measurement, but a scope connected to the IRQ pin confirmed the frequency. Well, it is still within the required tolerance, but it gives a suboptimal tuning result and renders the TUN_CAP register useless.

The next problem is finding a good noise floor level. This is some kind of background radio noise filter. If the level is too low, the sensor cannot operate properly because of interfering background noise. If it is set too high, the lightning detection quality declines.

The noise floor level cannot be calibrated just once at the start. Radio noise sources come and go, may it by turning on an electronic device or just by a change in the weather. I did some experiments, and the most promising solution is a kind of tug-of-war. When the AS3935 detects too much noise, it triggers an interrupt, and the noise floor level is raised to the next higher step. If the last level change was 10 minutes ago, the ESP attempts to reduce the level by one step.

In order to reduce the number of level changes, I have added a counter. Each noise interrupt increments the counter, and every 10 minutes the counter is decremented. The level is raised when the counter reaches 2, and lowered when the counter reaches -2.

Sometimes I noticed a "noise level runaway", where the AS3935 triggers a lot of noise interrupts in a very short time, raising the noise floor level to its maximum value immediately. To stop that behavior, further noise interrupts are being ignored for one minute after a noise interrupt has been processed.

Now the noise floor level has settled to an average of 95 µVrms here. In the graph, one can see that the level is raised at some time, but then reduced again after a while. One can also see the frequent attempts to lower the level a bit further, immediately followed by a raise back to the average level. It seems that the AS3935 and the ESP have negotiated a good compromise. 😉

The AS3935 seems to be set up in an optimal way now, but I still get some false lightning events from time to time. There are a few registers left to experiment with, namely WDTH (watchdog threshold), SREJ (spike rejection) and MIN_NUM_LIGH (minimum number of lightning). I have raised the watchdog threshold to 2, and did not have a false lightning event since then.

Now I have to wait for some real lightnings… 😄