Sunday, January 14, 2018

Inside stuff - Siemens Dressman shirt ironing robot

I recently got access to a broken Siemens Dressman TJ10500. It's a pro-sumer device that helps you straighten shirts without the tedious ironing. It looks like this:

The unit was described as "not heating" or "cooling rapidly". The front panel and every other feature seemed to be functioning just fine.

I will describe how to tear down the unit, what can go wrong, what I did to repair mine and how well it works.


To get inside the unit, there are many screws that need to be undone: around 5 at the back of the unit (except the air filter ones), two below (left side with the unit facing you). Then you need to carefully lift up the plastic trim that surrounds the LCD and controls, all around, you will have two more screws just next to the airbag.
Most of the screws are Torx T20, some of them are Phillips (PH2 I think).

With those undone, you can remove the left [metal sheet] panel, that gets you access to everything inside the unit.

The main board and folding switch rest near the front-top side.

In this case, the main board was hanging by some threads and the folding switch had an ugly fix. I suspect the unit was moved with the 'mannequin' in the raised position, which places stress on all the components and can bend the very thin metal frame.

Sunday, November 19, 2017

Non-genuine battery in Lenovo X230

I wanted to refresh the battery in my travel laptop and decided that 70€+ might be a bit too much. So I've settled onto a 20€ battery, +1€ shipping, from Amazon. Here's the affiliate link: - but read before you decide to buy it.
If you are ordering from outside Germany, returns will be difficult, as LiPo batteries fall under a special shipping clause.
Second, the battery is suited for an X220 model, not X230.
Third - and most importantly - the battery is a fake, with less than the advertised capacity.

If you still decide to continue, then read on. Some nice people have managed to decrypt the EC firmware inside the Lenovo laptops and allow for a way to rewrite it:

You can go through all the trouble of compiling it, but, to save you 5 minutes, here's the ready-built image that I've used myself:

The patched.x230.img file needs to be written to a USB drive (or SD card with reader). If you are using Linux you might be already familiar with dd. Under Windows, you can use Win32DiskImager, the same tool that's used for writing Raspberry PI cards.
To boot it, you need to go into BIOS settings and disable EFI, enable "Legacy boot". Then you can start the flash process. While this has worked for me, I take no responsibility if anything happens to your laptop.

If you don't flash the image, the laptop will not charge the battery (as it's designed for X220) and will report "The battery installed is not supported and will not charge" and "Genuine Lenovo Battery Not Attached. The battery installed is not supported by the system and will not charge".

Anyway, after flashing the EC (embedded controller) firmware the laptop will now recognize the X220 battery and will charge it as well.

After inspection with BatteryInfoView the reported capacity is not 6600mAh but ~5700 instead:

At the end of a discharge cycle, the designed capacity is reported as 6900mAh, full charged capacity as 6800mAh, it looks great! But unfortunately, after another recharge, the designed capacity is back to 5700mAh, full capacity to 5400mAh.

To summarize, with this battery, both the designed capacity and the cycle count are faked.

I could return the battery, but I guess a doubling of battery life is worth 21 EUR (to me). The previous battery, "44++", had a designed capacity of 5200mAh and reaches only 2800mAh at this time.

For reference, I get around 7Wh consumption under Windows 10, "reading mode" and around 5Wh under Ubuntu 17, same conditions. I set a threshold for charging ("Lenovo Power Manager" / "Lenovo Companion") at 90-95%. This drastically increases cell longevity and allows me to achieve a theoretical 9.58h under Windows 10 and 13.42h under Ubuntu.

The 9-cell battery is ugly and heavy, but I guess for "vintage" Lenovo users this does not matter too much. Still, a 9h+ battery life is a sweet deal.

Sunday, November 12, 2017

Inside stuff: battery-powered glue gun

I use a glue gun from time to time and was getting annoyed with the cable, finding a free power socket, was always in the way, ...

So I bought a cheap battery-powered glue gun. It takes 7mm sticks instead of my old one - which takes 11mm ones.

It also takes a little less space and has a better stand. The old one is rated at 15W while the yellow toy has 8W written on its label.

No surprise in finding a standard 18650 cell in there. The glue stick feeds through a rubber o-ring. The only electronic intelligence can be found in the board at the bottom of the unit.

The bottom of the board features a standard (90 degree) micro-USB socket and three LEDs. The LED diffuser is pictured bottom-left, while the hand-soldered "ON" switch is center.

The bottom of the board has a TP4056 battery charger IC. It can supply up to 1A of charging current (and it does) and is produced by the NanJing Top Power Corp. While it looks like the same part number and provides similar functionality it is completely different than the LTC4056.

The Linear part datasheet contains an application note where the same chip is used for charging NiMH and NiCd batteries. This hack can also be performed with this chip, if the Vbat pin is set to a voltage between 2.9 and 4.2V. But nobody wants to go back in time...

The heating element has a rubber-like surround, probably to keep the stick pushing toward the front. That's all I know.

The heating current is drawn directly from the battery, so the gun can theoretically be used while charging. However, theoretically, if the battery voltage drops under 2.8V, the IC will enter trickle-charge mode (for recovery) which will render the gun useless. In this case, you want to make sure that the battery is at least halfway-charged before using it.

I haven't traced the board, but it seems the switch directly connects the heater to the battery, with a blue LED in parallel. This is why, when charging, both the red and green ones will light up.

Out of the box, battery life seems decent. The gun stayed on for more than 60 minutes, even without a full charge. Once the battery voltage gets really low, the blue LED will start getting dimmer until it eventually shuts off. The green led will light up when the unit is fully charged.

It doesn't seem like there is any low-voltage protection, so forgetting to turn off the gun will probably kill the battery.

The charger resistor (R4) is marked 1201, that's 1.2kOhms, which means the charge current is set to 1A through the PROG pin.

If deeply discharged, the battery will start charging at 100mA, after 2.8V it will switch to 1000mA.

Unfortunately I haven't taken the battery out of the plastic wrap to check the markings and I haven't measured the heating element resistance or temperature behavior. Might do that when I will get really bored.

Measured through a USB power meter, the battery takes 3.5 hours and 2000 mAh for a full charge. Some of that energy will go into heating the charger IC (0.5~1W in constant-current mode) so the battery is likely around 1800mAh.

Heating time, with a fully-charged battery, is around 5 minutes, comparable with my old 220V unit.
In use, the gun works just fine, when left unused it drips only slightly. More than adequate for light uses, probably inadequate for large quantities in a short time. But that's the usual tradeoff with any 7mm glue gun.
The kickstand is a joy and the gun has a nice design detail: protrusions next to the glue stick, on which, those with large hands, can rest their thumb.

Anyway, if you want to purchase one through an affiliate-link, here it is: It's currently priced at 18.99€.

CTC / MightyBoard wireless conversion attempt

This is not a "howto" as I couldn't get it to work. But if you want to know why, read on.

I've been using MatterControl instead of MakerBot for my CTC Bizer (Dual) for a while know and have been really satisfied with it. However, the best results (and control) I got with a direct USB connection.

Having a 2m-long USB cable dangling is not my style so I've searched for a solution.

TCP-Serial bridge

There are several options here, but I've settled on ESP8266 (NodeMCU) and one of these projects:

So basically the ESP8266 acts as a server which then forwards everything to and from the hardware serial connection.

The first two projects work (probably) fine, but MatterControl has currently (Nov 2017) an issue with virtual serial ports. I've tried both com0com and VSPE. It runs fine for a few commands (2-5) and then it fails.
ESP3D does not support s3g/x3g printers.


OctoPI bundles everything in a neat package. Just stick a Raspberry PI, maybe with a webcam, and upload files directly to it. It takes care of slicing, monitoring, control, ...
However, it's excruciatingly slow (on rPI B+ and B2), printer profile is not correct (even when manually input), the slicer (Slic3r) outputs wrong commands. For example, the wrong extruder heater turns on.
If you cancel a print, you have to restart OctoPrint, which takes minutes.
I love tinkering, but this is just too much, I've sunk too many hours into it.

Raspberry PI bridge

Same as the above TCP bridge, this time the bridge was set with netcat, stty and other magic commands. It did not work, for the same reasons as above.

Quick conclusion

I want to jump to this and just say not to try it. Unless MatterControl fixes their protocol (seems improbable) just stick a cable inside your computer or export to SD.

Upgrading the motherboard seems like a nice proposition, but the thermal sensors need to be exchanged as well, no easy task.
I'd say you are better off keeping this printer USB-bound and hunting for a cheap G-code one to convert to wireless. At this point (Nov 2017) the 3D printers have gone down quite a lot in price, can be found for 100$ sometimes.

Floureon BYC17.GH3 thermostat teardown and impression

I recently bought a Floureon thermostat for my electrical floor heating. and. took it apart. for your appreciation.

Later edit: a lot of the users are complaining about the clock advancing a few minutes per day. You need to decide if you can live with that or ask the seller to provide details. I couldn't test this, as my unit runs from an intermittent supply.

The thermostat can switch both heating and cooling loads, but the product page does not list any instructions. Fortunately, I have a cell photo of those:


In the box, the thermostat comes with the leaflet above, the unit, two drywall(?) screws and an external sensor.

The pinout is listed on the back and this is where you should pay attention:

Sunday, October 29, 2017

CTC / Mightyboard serial Wifi conversion fail

This is just a quick post while I'm working on something bigger.
I've tried to get a NodeMCU module to interface to the serial port on my CTC Dual/Bizer printer, which uses a Rev G(?) Mightboard motherboard. Unfortunately, the main serial port is not exposed, just UART1.

The easiest way I've found to get to the TX/RX lines was to piggyback on the resistors just before the ATMega8U chip:

The 8U is used as a serial to USB converter.

5V and ground can be picked up from the exposed UART header, pictured bottom middle:

I tried to use the ESP3D firmware but it only works with boards that support G-Code, not X3G. So I abandoned the project due to lack of time.

The pictures above are from a few weeks ago but just yesterday I managed to put a hole in my 8U chip, no idea how that happened:

So now I was forced to use my makeshift serial connection. I tried both possible solutions:

Unfortunately neither of them worked, the data gets corrupted after a few commands sent to the printer and the printer does not respond to serial input anymore.

However, using a standard CH430 USB converter does the job, with the jumper set to 5V.

I could probably get the ESP8266 working, but need to check whether it needs some voltage converter (UART on ESP8266 is 3.3V, on Mightyboard it's 5V) or some resistors.

In case you decide to try it yourself, to set up a transparent serial-TCP bridge on Windows, I've used com0com with the following batch file:

com2tcp.exe --baud 115200 --ignore-dsr --telnet \\.\CNCB0 23pause

Not sure if the ignore-dsr option is needed or if it does more harm than good, haven't experimented too much.

Wednesday, October 11, 2017

Voyager Golden Record images - processing considerations

As you may have seen in my previous post, decoding the images on the "Golden Record" is not very difficult. The problems arise in timing and amplitude issues.

I've talked about timing in my previous post: there "sample rate" varies throughout the record (slowly increasing speed) and it also "flutters" throughout a frame.

The amplitude issues are caused by feeding digital signal into an unconditioned/untuned analog system (probably a recording needle).

Let's analyze the circle image:

I will use the [vertical] scanline represented by the red dot as illustration for how a uniform background (constant color) should look.

The blue trace is the actual waveform. My red line underlines the non-linearity of the recording. The yellow line signifies my expected value. So we have an inverse exponential gain that needs to be applied with respect to time, as well as a linear gain. The could be mixed into a single formula.

For reference, the actual image on the record should be this one:

Remember that the signals are inverted, so white would actually be a very low signal, close to the minimum. Hence my interpretation on where the yellow line should sit.

Back to the first image, analyzing the scanline next to the blue circle:

Highlighted in red are the level differences: after meeting a peak, the signal recovers to a lower level than the background one. Lower level = lighter pixels.

The opposite happens after a white portion (low signal level), exemplified in the following image:

The portion below ("after", in time) the white text is darkened. Picking out a random scanline from the waveform:

It's pretty hard to determine what difference is caused by the non-linear time-dependent gain distortion and what is caused by the peak/dip recovery.

Another non-linear distortion, perhaps related to all of the above, can be seen in the lead-out (postamble) of the frame:

After a wide peak (odd lines), the dip is more pronounced - longer recovery time with overshoot. After a narrow peak (even lines) the signal is more linear and with little overshoot.
The analog recording system can be characterized using the data and a "reverse" system can be designed, which corrects for at least some errors.

I can only speculate what the causes for those errors are: output vs input impedance (capacitance), needle bouncing, slow and non-linear amplifiers (remember this was the mid-70s). Whatever the cause should be, I have confidence that the engineers at that time did their best to create a signal as clean as possible. We also have to take into account that the digitization process might not have been perfect, it never is.

That's as far as I will go with this today. As a "cookbook", in order to decode better images one needs to:

  • apply a multiplier to the grayscale signal, like: signal *= a^time + time/b - where a is between 0.5 and 0.999 and b < 0
  • apply some sort of reverse impulse recovery: design a FIR filter that based on the slope of a positive/negative impulse it applies a proportional feedback. That is, a high-slope positive signal should provide positive feedback
  • take into consideration whether decoding an odd or even scanline
Unfortunately the extent of my digital signal processing skills stops well ahead of a proper implementation.

On an unrelated note, it would be interesting to find out if the encoded images carry some metadata: whether they are part of a color image, which channel, whether they are in portrait or landscape orientation, if they have an ID.

Decoding Voyager Golden Record images - in Java

My inspiration started when I first saw the associated video for this article:

Without studying much further, I decided to download the sound files and try my hand at decoding the images - more as a programming exercise.

I haven't studied the original article too much as I didn't want any spoilers. After struggling a bit with the data, I found that the article could not help anyway with the problems I was having. So there's the "cheater" disclaimer.

Watch the end of this post for updates.

Data preparation

Load the sound file into Audacity, perform a normalization (Effect -> Normalize) to 0dB.
Then click the black triangle above the track name and do "Split Stereo to Mono".
Select one channel (entire width), File -> Export Selected Audio. I used WAV 16-bit PCM as I couldn't get MP3 to work properly in Java.

That's how the waveform should look. Get familiar with navigating around it (Ctrl+Wheel to zoom) and measuring milliseconds or sample duration. The switch can be done by clicking the small dropdowns where the selection start/end/length is listed.

I will be using "Track 1" throughout this article (left channel) only, but the other channel can be analyzed in an identical way.

I will use samples, milliseconds and seconds interchangeably. Since the data is sampled at 48000Hz: 0.001s = 1.0 ms = 48 samples = 1000Hz.

Cold analysis

The sound file start off with a 33.63 seconds of silence, followed by what seems to be a square wave gone through a low-pass-filter. This lasts another 33s. Each square wave measures 399-400 samples in width, so the audible sound would be ~120Hz

This is followed by 4.7 seconds of an almost pure square wave, with a width of 40 samples, so a frequency of 1920Hz

The above data is a preamble for the whole disc (platter?), as we shall see. It allows the "aliens" to tune in on our frequencies and perhaps test the stability of their "vinyl player".

The first frame of data

I - doesn't seem like something significant, it's just a burst of 40 samples followed by a repetition of a 400 sample signal.

What's interesting is that the peaks at those 400 sample intervals vary in width: ~19 samples for each even peak, ~6 samples for each odd peak. This will be a recurring theme.

II - a train of squarewaves, each 25 samples wide. They seem to be grouped into 16 "bits", with the last bit being higher in amplitude.

In total there seem to be about 21x16 bits, but it's hard to recover more information from the audio sample I have access to. I will refer to this as the frame preamble.

III - frame data, will detail later

IV - frame postamble

V - start of next frame

The frame data is split into lines, I call them "scanlines", each 399-400 samples wide, so around 8.315ms.

Each scanline represents analog video intensity, from the lowest point (trough) up to the highest point (peak) into the waveform.
Analyzing the peaks we can see that they follow the same pattern: each odd line has a 6-sample-wide trailing peak, each even line has a 19-sample-wide one.

While it's easy to determine where each frame starts and ends using our eyes, getting a computer to do that for us is a bit more difficult. Intuitively, the frame should start at the lowest value. However, this gets a bit complicated with images that have a  high contrast:

The number of scanlines seems to be pretty constant, around 500 for each frame, however the postamble (IV-V above) varies quite a bit. It might contain some extra information. It follows the same layout and spacing as the scanline and is ~665 lines in some frames and even 807 lines in others

Friday, October 6, 2017

Zoom 9002 hardcore repair - basket case

Many years ago (circa 2004) I bought a used Zoom 9002. This worked fine for a while until the output became weaker and weaker. At some point it stopped amplifying completely. I looked online, there was at least one blog post mentioning that some electrolytic caps and the ICL7660 need to be replaced. I did that, nothing improved. I think the display also started failing.

"Smart" as I was at the time, I decided that perhaps the board needed some reflowing, so I stuck it in an oven for a few minutes. Packed it good. Fast forward 10 years later:

Initial condition

This was literally a "basket case" - all the parts were in a basket, with no ideea what goes where.

Thursday, September 21, 2017

Blackview A7 quick review

This a departure from my normal topics as there seems to be little information online about the phone. Paid ~32€ (38 USD)  for a shipped unit, so try to keep the price in mind. A unit with similar features would cost today at least 55€.

In the box

Phone, TPU shell, charger, cable, small leaflet.
No earphones, no extra screen protectors.

Compared to a Motorola Razr XT910, it looks like a monster.


Tuesday, August 15, 2017

A look inside the Samsung S7 camera implementation

This post is less of a guide and more of a collection of thoughts. It assumes some Java and camera operation knowledge.

My S7 has become my main camera since it handles low-light, uploading, water and time zones very well. It does have a few big weakness though, oversharpening being one of them and over-confidence the other. By over-confidence I mean it will gladly lower the shutter speed to 1/4s, thinking OIS will take care of the shake. It can't.

The Samsung camera app on Android Nougat has shed a lot of features in exchange of user-friendliness. Gone are the sharpness controls, OIS cannot be disabled, RAW mode is available only in the "Pro" camera mode. Quite a lot of artificial limitations which third-party apps don't seem to bring back.


To analyze the application we need to take a look at some binaries: SamsungCamera6.apk, semcamera.jar and seccamera.jar. There are some other binaries but they are written in native C ( or even for FPGA (e.g. fimc_is_fw2_2l1.bin).

For taking a look inside the jars I'm using dex-tools 2.1, jd-gui 1.4.0 and Eclipse. The classes.dex file is extracted from each app, sent to dex2jar, imported into jd-gui and saved as a zip collection of .java files, then imported into an Eclipse project. There's probably a better workflow for this.

From those various jar files a structure emerges: SemCamera is the bridge between the native camera binary and Android/Java.
FaceAreaManager seems to take care of face detection, HRMSensorFusion enables use of the HR sensor to take selfies.

The camera modes are defined inside the application, even though they need to be downloaded in order to be used:

Interestingly enough, there are a few camera modes which do not have an equivalent app in the Samsung App Store: Antifog, BurstPanorama, Night / NightScene, ProductSearch, ProLite, RichTone, TagShot.

Antifog might be targeted towards the Asian market, as a mode that reduces smog smear. Night might be a sub-mode for the Auto. ProLite might be a Pro implementation for phones with less features (Samsung A7). RichTone might be a sub-mode for Auto+HDR.

I find it both curious and disturbing that features are being hidden from the user at the cost of a "purchase". Not sure if the idea was to monetize camera modes or to simplify camera usage. A simple checkbox list would've sufficed.

Saturday, August 5, 2017

Failed project - WiFi to InfraRed to Coffee

In one of my most-viewed articles, from quite a few years ago, I've teared down a Saeco Talea Coffee machine and noticed a strange protrusion on top. I assumed it was an IrDa transceiver, then thought that maybe it was a coffee cup detector.

It indeed turned out to be an infrared port.

Armed with this knowledge - and some time to kill - I've decided to try and talk to the machine, wirelessly.
While it might sound easy, there are many steps involved: get hold of the service tool application, reverse engineer (RE) it, RE the service dongle, RE the machine protocol, write an IrDa implementation for Arduino, write the web app to serve the page - and coffee.

Step 1 - .NET reverse engineering

Ever since I've discovered JetBrains' DotPeek, my life has been changed. I don't know C#, in fact I barely know C, but I can pretend to be a .NET developer.
After getting hold of the SSC2 application (that's another topic in itself) we can try to see how it can talk to the machine.

The baud rate for talking to the serial tool is 19200, for my machine. Since the baud rate is different for other machines, I could make an educated guess and assume that the serial tool is just a transparent proxy between a USB to serial converter and either IR or RS232.
The serial protocol is 8N1 - 8 bits, no parity, 1 start and 1 stop bit - pretty standard.

Let's see what we can speak:

The program sends the "(MA)\r\n" command on a button press.
Let's see where Button17 is declared.

That button has a text called "BU up", which in slang means "Move brew unit to the upper position".

Similarly, we can find a pretty long list of commands that can be sent.

For convenience, here's a shortened version: (COMM), (MA), (MB), (GA), (TEST), (CONF), ERASE, S0, S1, (GB), (PA), (TA), (TB), (TC), (TD), (EXIT), (TEST).

Here's a interesting one
      this.Button4.TabIndex = 11;
      this.Button4.Text = "make Espresso";
      this.Button4.UseVisualStyleBackColor = true;
It just sends "(EXIT)" :)