Peltier Lamp – “fixed” – not really

Quite some time ago I built two Peltier lamps as shown in Make issue 06 in 2015 ( This was more or less my first real make project.

Peltier lamp. Back then still working.

Unfortunately one of the two lamps stopped working after a short time. It’s time to fix this mistake. Question is, what’s the problem. I speculate on the Peltier element itself. Maybe it just got too warm and got destroyed. The Make manual says they tested several elements and had no problem with any of them. Therefore, at the end they went for the cheap TEC1-12706 which I also used for my lamps.

Although I found some high temperature Peltier elements here. At this point I rather check if the problem can be found somewhere else. Why? The TEG1-12610-4.3 which look good for my application cost 28USD each plus 50USD shipping costs. I would spend the money if I was sure that’s the problem. But the other lamp with the “normal” Peltier element works just fine, so in principle the high tempereature elements seem to be not neccessary.

The installation instructions on the TEC site point out, there is a hot and a cold side of the Peltier element. When both wires point in your direction, the hot side is up when the black wire is on the right hand side. The Make instructions say, it doesn’t mater which side is up and which is down. No matter if there is an asymmetry or not, the Peltier element in the working lamp has the same orientation than the elemet in the defect lamp. That’s not the problem.

I am not sure if the connection to the step up converter is the error source, as it doesn’t feature a reverse polarity protection. I definitely have to check that. On the other hand, tha lamp worked for a short time. In case I mixed up the connection, I would have expected the lamp to not work from the start.

The distance between the flame and the Peltier element also plays an important role. The Make instructions point out for distances greater 23mm everything was fine. As every candle, or better, flame, might reach a different hight, it could well be that I boiled this particular Peltier element.

Last thing I can think of is the heat conversion tape I used to conect the Peltier element to the heat spreaders. Honestly, I think it’s unlikely this is the error source. Anyway, I will see if there are buubles or something like that after dissasembly. A possible upgrade would be carbon heat conversion tape.

Enough for today. Next time I will dissasemble the lamp and replace the Peltier element.

Update – It’s “fixed”

So I removed the upper wooden part including the step up modul from the wooden base plate. Unfortunately, I fixed both using hot glue instead of screws back when I put the lamp together for the first time. Because, what could possibly go wrong. The current separation lead to some damaging of the wood on both parts.

At first I tested the Peltier element itself. I lit up a candle below the power block and measured the output voltage via multimeter. Voltage increases slowly to some ten millivolts above 600mV and then finds its equilibrium at around 600mV.

Next up is the step up converter. This I connected to a sourcemeter and, voilà, it’s power LED and the USB lamp connected to the step up converter both turn on at approximately 600mV.

In conlusion, every single component seems to be just working fine. So I put everything back together and gave it a shot. In wise foresight, I did NOT glue the parts together, but tested everything lying around loosely.

First you tear the lamp apart. Then it tests ok.

Why so suspicious? It works. After soldering the wires from the Peltier elemet to the step up converter, the test failed. Disconnect. Works. Soldering again. Works. Hot gluing in the step up modul. Fails. Back out. Works. Back in. Works. Gluing everything together. It fails!

Long story short, the whole thing seems to be right on the edge of functioning. Sometimes it overcomes the initial switch on and sometimes it doesn’t. When switching the lamp on using the sourcemeter it was visible that for a moment when switching the lamp (or the step up module) on it requries a higher amount of current in the range of 100mA befor going back to lower values of around 10mA. How to boost Peltier element output for a short period of time? Just blow on the cold side for some seconds. Guess what? It really works.

Once the LED is on, it runs more or less stable. You should avoid under any circumstances air movement that might cool down the hot side of the power block. I also think the higher the room temperature the smaller gets the temperature difference between hot and cold side. Which again decreases output voltage of the Peltier module.

In summary, the lamp works but it barely works. Often only with a little help at the start. At the end I reconsider buying a better Peltier element with more power at the same temperature difference. In principal stacking two elements on top and connecting them in a row should also deliver considerable more output voltage and make the whole operation of the lamp much more stable.

But before those optimisations, some better woodworking tools and a better fixture of the power block, maybe even height adjustable, would be nice.

Update – not really

As it turns out, the lamp was working for one complete tealight. The next time it became even harder to get it to run and the intensity of the LED lamp was super low. Third time I tried I couldn’t even start the lamp. The same thing seems to happen with my second build lamp. I guess it’s the cheap TEC1-12706 that degrade over time when exposed to high temperatures. Therefore, I ordered SP1848-27145 type Peltier elements. Let’s see how this turns out.

Camera Slider 0.1

Used and Abused

Exploiting the old printers brought up some useful stuff. First of all, of course some functioning stepper motors like this little buddy here:

It’s a Mitsumi M35SP-11NK LF stepper motor (link to specification sheet of the manufacturer) from an old printer/scanner.

As we have two of the all-in-one printers, we decided to use the second one with the stepper motor attached to the scanners linear slider for a first prototype.

Linear slider from scanner unit
Linear slider from scanner unit

The motor is driven by an Electrely L298N dual H-bridge board (Amazon link). Everything works. Thanks. Bye.

Fast Forward and Rewind

Everything worked. Probably a year ago. If you read the last blog post regarding the RaspiBlitz you will notice some similarities. Anyway, let’s start from scratch. Make photos. Search the specifications of the stepper motor and the L298N driver board. Build the manual triggers at the breadboard and the code for the Arduino. But this time with proper documentation (Just wait for next years blog post).

How to document stuff? This site should be just fine. In addition, I noticed quite a few maker use Fritzing, an open source tool to make hardware projects more accessible (see their website: Let’s give it a try.


I started with the triggers for later back and forth movement of the slider. The result looks like this: Fritzing schematics on the left, photo of the triggers on the right and code below. The Fritzing project including description, schematics and code can be found here.

Arduino Code:

int TrigRght =3;
int LightLft =12;
int LightRght=13;

void setup() {
  // put your setup code here, to run once:
pinMode (TrigLft, INPUT);
pinMode (TrigRght, INPUT);
pinMode (LightLft, OUTPUT);
pinMode (LightRght, OUTPUT);

void loop() {
  // put your main code here, to run repeatedly:

  if (digitalRead(TrigLft)==HIGH)
      digitalWrite(LightLft, HIGH);
  if (digitalRead(TrigRght)==HIGH)
      digitalWrite(LightRght, HIGH);

  if (digitalRead(TrigLft)==LOW)
      digitalWrite(LightLft, LOW);
  if (digitalRead(TrigRght)==LOW)
      digitalWrite(LightRght, LOW);

Wow! feelsgoodman.jpg. Everything in one place. Let’s move on (pun intended).

Is this a slider?

The motor driver and the stepper motor itself have to be connected next. Connections for both can be googled. A comprehensive explanation of the L298N can be found here.

In principle it is also possible to distinct between the two coils of the stepper motor by yourself. Just shortcut two of the four connectors until you find a combination that makes it harder to move the motor by hand. These two connections belong to the same coil. The other two belong to the second coil. Coil one is connected to OUT1 and OUT2 of the L298N board; coil two to OUT3 and OUT4. The colors of the wires in the schematics below connecting the stepper motor are chosen to match the actual stepper motor cable colors.

Anyway, the result looks like this:

As the Mitsumi motor requires up to 24V, an additional DC power supply is required. As you noticed, the 5V input of the L298N board is not connected. Reason is we kept the 5V enable jumper in place, and therefore, used the L298N internal voltage regulator to generate the 5V necessary to drive the logic circuitry.

The complete Fritzing project including the Arduino code can be found here. In real life it looks a little messier… BUT … it works.

Driving the slider with the manual triggers

By the way, this is maximum speed and it required 0.3A at 24V from the DC power supply to run the stepper motor. Driving the motor at these settings for as long as seen in the video results in a blistering hot motor.


However, this thing might certainly be a very, very basic slider, despite the fact that there is so much room for improvement (I tried to collect some of the improvement potential somewhere below.).

Agile project development

The original plan was to build a working end point detection at the start and end of the slider route next. With this one could image the program finding the slider limits first in some sort of initialization process defining the maximum number of possible steps for the motor. That would also help calculating the amount of steps per image in the later timelapse and, last but not least, allows the implementation of some sort of safety mechanism, preventing the slider to push further and further into the limits.

Without the end point detection the maximum range had to be measured manually. It is 64 revolutions with each revolution consisting of 96 steps. That’s 6144 steps for the whole slider range.

Make some videos

However, the curiosity was just too big. So I gently put my camera on the slider and moved it around manually a bit. The camera is super unstable without any mount (–> to do list) but hey, who cares.

As speed is not key in our application, the tests were carried out at low stepper motor speeds requiring only 5V DC and 0.2A. I decided to go for a two hour time lapse with images obtained every thirty seconds. That’s 240 images in total and the same amount of stepper movements in between. Our total slider range of 6144 steps divided through 240 stepper movements results in 25 steps of the motor per stepper movement. All the variables can be found in the code section of the Fritzing file.

Finally, I started the cameras time laps program and approximately fifteen seconds later the slider by pressing the right manual button. And here it is, the first video of our test slider:

Do you see the movement?

I have to admit, the actual slider motion is hard to observe. But if you look closely for example at the left edge of the video it’s very faint to see. This can be done better. Below you can see the second test. It is basically the same view but this time with some objects in the foreground and some blurry stars in the background. Next time the focus has to be also on the actual camera settings.


One problem came up during the test. It looks like the clocks of the camera and the Arduino are running quite differently. After one hour the time difference of approximately 15 seconds between the Arduino and the camera was completely used up. I do not know which one was faster, but this calls for synchronization (–> to do).


So far, so good. That’s it. The slider slides. It’s the best slider 0.1 that we could build. Let’s see if there will be a version 0.2. Maybe it will implement some of the following slider improvements proposals (SIPs):

  • end point detection
  • camera mount
  • overall stability
  • synchronization of slider movement and camera shutter release
  • automated calculation of steps per image as function of time lapse overall time and length of the slider route
  • longer slider route
  • more compact design
  • more axes for camera motion

RaspiBlitz reloaded

"The two most powerful warriors are patience and time"
Jar Jar Binks

The Dissapointening

It’s 2019. End of April, beginning of May. Setting up the RaspiBlitz took like forever, mostly because of a nasty coincidence. It turned out, my desktops hard disk drive was dying and the raspiblitz image was corrupted. At the beginning, we did not notice the actual problem, but downloaded an image via laptop instead. So the RaspiBlitz started and everything went well until the blitz had to be filled with the Bitcoin blockchain. As I had no other full node available at that time, we decided to trust rootzoll and download the chain via torrent. Of course, the torrent file lacks the blocks of the last few days. In combination with the very limited processing power of the raspi (3b+) this lead to some additional days of synching with the blockchain. Thinking I was super clever, I setup a Bitcoin Core node at my desktop PC (still running the dying HDD) to speed up things. So I started the RaspiBlitz setup again from scratch, this time copying the blockchain data validated by myself from my desktop pc to the raspiblitz hard drive via USB. After some funds were transferred to the node and a few channels were opened everything went straight downhill. The Blitz reported a corruption of the blockchain and suggested a download of the data once again. Thanks! No! At this point I have had enough for the moment. In hindsight, I have to admit most of my experience was based on bad luck. The very last thing I did was taking a backup of all the lightning channels. Then it got quite…..

Temple Of Retribution

Fast forward. January 2020. Finally, the second attempt. This time wih a fresh and fully functional desktop hdd and bitcoin core running at the desktop. The setup went nearly flawless, only I was not able to copy the blockchain data as described in rootzolls manual via SCP command over the network. However, lil’b recommended using WinSCP, and et voila, after five hours the file transfer of the roughly 270GB was finished. Some more hours of synching and the main menu was accessible. Now I loaded the eight months old channel backup file and, surprise, surprise, one of the channels was still active showing the correct balance and transactions. The other two were inactive and didn’t go active within the next week, so I closed them. Closing channels hurts because it costs a lot of sats. Maybe I do something wrong, but every forced channel close cost me something around 65000 sats. Anyway, even though our node has only one open channel, the few transactions I started, all went through in about ten seconds. It works.

Next Level Shit

The 2019 me accessed the RaspiBlitz using Zeus via mobile. But only within the home network. 2020 me read the Zeus manual more carefully (Or maybe this section was new. Who knows.) and was guided to another manual from openoms, who explains how to connect Zeus app via Tor to the Raspiblitz. I CAN ACCESS MY LIGHTNING NODE FROM EVERYWHERE VIA MOBILE PHONE. That’s cool. Moreover, as the CombinatLN is intended to be a shared node of the combinat, both, @pntmg and @gegenlicht connected via ZeusLN to the node and we both can receive and send funds. Feels like a company account.


Use the manuals and read them properly.

RaspiBlitz manual should be fairly self-explanatory. It is to set up your own RaspiBlitz. Zeus is the mobile app to access your RaspiBlitz. And finally, openoms manual explains how to connect Zeus via Tor to the RaspiBlitz.

Have some up-to-date blockchain available to be copied onto the RaspiBlitz. The other options take really, really long.

WinSCP is a great tool for transferring data within the same local network. Works excellent between Windows and Linux based OS.

If you have to start from scratch, formatting the SD card is not enough: wipe the whole thing using diskpart.

Give dem Raspis their power. Not joking. Get 5V/3A power supplies. Some of the failures I experienced probably originated from not enough power for either the Raspi or the attached hard disk drive.

Big lightning nodes are not that bad. The [lnd-25] node was the only one still present after eight months inactivity from my side. All other channels I had to close manually to free the locked up funds.

Opening and closing channels is not negligible. My funds depleted quite quickly when playing around with opening and closing channels…

Nobody needs fancy cases and TFT screens. At the beginning it’s really nice to look at. At the latest after a week you stop thinking about it. I removed the screen and the case and the temperature of the raspiblitz dropped from ~70°C approximately 10°C to ~60°C. Putting the Raspi behind my NAS fan reduced temperature even further to round about 45°C. That’s cool. Almost as cool as the perhaps cheapest “case” for the RaspiBlitz ever. Made of popsicles and hot glue.

Not nice but cool. The air outlet of the NAS keeps the RaspiBlitz (without TFT display and case) at chill 45°C.

Addendum – Update from v1.3 to v1.4

Ofcourse I had problems with the update. First of all, my desktop PC does not have an “inbuilt” SD card slot. So I used a USB card reader. This fucking thing managed to write the images with errors. Every single time. At least the Balena etcher reported after writing the image a difference of the hash of the image in comparison to the expectation. The laptop card reader did a better job finally.

It also makes sense to re-connect the display when starting the RaspiBlitz with the new version 1.4 SD card for the first time, because your password A was set to default. This default is displayed at the TFT display. Without the default password you cannot conect via SSH.

Now I am curious to check out the new features.

Bitcoin + Lightning

tl;dr: if you want to throw some Satoshis around, open up a channel to our very own lightning node (CombinatLN) or send us a tip via

CombinatLN lightning node public key: 025b4f75edbad4b02468af6a7d39c1c10280a764756819cb8fc367283d945a5e49

CombinatLN public address: 025b4f75edbad4b02468af6a7d39c1c10280a764756819cb8fc367283d945a5e49@jn2hxf45fgeksudd.onion:9735

Good news everyone

Combinat now runs its own bitcoin full node with lightning on top. As we are enthusiastic about all the potential applications and use cases that could be enabled by distributet ledger technologies (DLT), we had to start with having a look at the king first: Bitcoin.

Despite just buying some Satoshis and watching prices at coinmarketcap, our goal is to get some experience with the technology behind; especially with regard to its application for micro transactions and controlling transactions. I dare to use the phrase “Smart Contracts” as it might sound way cooler than what we might be able to do.

There is an upcoming blog post planned that goes more into detail on what kind of projects we have on our to do list and what drives us. There will be a more general motivation given for the whole Bitcoin/Blockchain/DLT stuff.

So what has been actually done?

At first we set up a RaspiBlitz. The RaspiBlitz combines both, a Bitcoin full node and a Lightning node.

A whole list of parts neccessary to build the RaspiBlitz from scratch is included in the readme. It consists of the Raspberry Pi itself, an SD card for the operating system, an extra hard drive to store the bitcoin blockchain and lightning information, some cables and power supply a case and an LCD display. The overall costs were approximately 140€ per node.

When putting all the parts together, we noticed that the LCD is a little too big for the case, so the upper part of the case had to be left off , which is not a big problem.

There is an image available at the raspiblitz github site that has to be flashed onto the SD card. We used Balenaetcher for flashing. We ran into some trouble, when we had to start over again and could not flash the same card a second time. At some point we figured out that before flashing the card again, all volumes created at the SD card had to be deleted and combined again.

Following the installation instructions, severeal passwords have to be created followed by receiving the complete blockchain; approximately 210GB at the time. Unfortunately, back then my deskop computer’s hard drive started to fail. As a result, the plan to validate the complete bitcoin blockchain from the beginning via the bitcoin core node has been thwarted. Several attemps to copy the blockchain data failed. Therefore, the alternative option of downloading the pre-prepared blockchain via torrent was used. The final synchronization took the Raspberry Pi several days and ended in some error message. Some well known bug in RaspiBlitz v1.0.

Having said this, the RaspiBlitz project and the whole efforts of adding Lightning as a second layer on top of Bitcoin are under heavy development. So the instructions we used to build our node are most probably already outdatet; just like the problems we encountered. Meanwhile there is even the possibility to directly buy a ready-2-go RaspiBlitz right away.

Preliminary result

Fast forward. Some time went by, and when continuing with the RaspiBlitz there was an update to version 1.2 avalable. Switch off the RaspiBlitz. Flash the SD card with the new image and on we go.

Load up some funds worth 25€. Enable Tor. Switch on Lightning Autopilot. Interestingly, there were quite some problems adding other nodes as peers or, even worse, opening channels to other peers without the Autopilot. But sure this is a problem of us having no idea what exactly we are doing here.

However, our node has two lightning channels open at the moment of writing and we just made the first successfull micro transaction via lightning. The two Satoshis safely arrived within approximately 10 seconds, alhough there was no direct channel to the node.

Ride the lightning web interface for RaspiBlitz
The two Satoshis safely arrived at our account

Tippin tweets

Tippin what? Some while ago we heard of a cool plugin for twitter that let’s you tip tiny amounts of Bitcoins as a response to tweets you like. As the one who wants to recieve the tips, you just sign up with your twitter credentials at Unfortunately, it is more complicated to actually send tips. First of all, because you need a funded lightnig wallet. Furthermore, you cannot use the tippin function within the android, iOS or whatever twitter app, but you need a browser plug in (Chrome or Firefox). Once you installed the plugin and view your twitter feed in the browser, there is an additional symbol below each tweet; a small lightning bolt.

Press the button, scan or copy the request. Pay via Lightning. As easy as that. By the way, as you can see in the image of the RTL interface above, this is an empty invoice you get from You can put in the amount by yourself. Makes definitly sense.

What a piece of art


There is one more thing we checked out during our run through Lightning land. The Zeus mobile app was installed to one of our android phones. As its description says it’s a mobile Bitcoin app for Lightning Network Daemon (lnd) node operators. As we are now Lightning Node Daemon node operators, Zeus is what we need. To connect to your node, phone and node need to be in the same LAN. The RaspiBlitz offers the possibility to show a QR code including all the neccessary information. This code is scanned within the Zeus app and thats it.

Brave new world

Isn’t it? The whole lightning experience is kinda cool when it finally works. During our journey, we painfully noted how little we know. Starting with the Raspberry Pi to the functionality of the Lightning Network itself.

Of course you don’t need to setup your own node and if you decide to do so, you could go for a, I guess, more user friendly solution like NODL. But hey, as it is not completely unlikely, that we need the Raspi also for other projects, it was a good starting point.

We have to admit, at one point there was this “This whole Lightning thing is not going to work out” thought. But I guess, this is due to the beta status of Lightning itself and, again, us beeing absolute beginners. It’s funny to google some problem and finally find an answer from Bitcoin core developer Pieter Wuille, just to find out you have no idea what this answer actually means.

Furthermore, it’s hard to realize what it means that channel creation and closing are on chain transactions. First off all it takes some time and second of all everything costs you some fees. After opening and closing like 4 channels there was only half of our funds left. Yes, of course also because we have deposited very little.

Most channels have a lower funding limit and once a channel is open, these funds are locked. You have to use your remaining funds to open further channels.

And last but not least there is the infamous inbound liquidity. In case you open a channel to a peer, you fund the channel and these funds are local. Your peer cannot send you Bitcoin via this channel as there is no liquidity at her side. How to get this remote funding? You could send some of your local funds through the channel to your peer. Or she could open another channel to you (, I hink). This is not a problem if somebody wants to do a specific payment to you. She opens a channel to you with enough funding, sends the amount of Bitcoin she wants and closes the channel (optional) again. Inbound liquidity becomes a problem if you want to be part of the Lightning Network routing. As long as you don’t have an open channel with inbound liquidity (remote funds), other payments are not going to be routed via your node.


All the remaining problems aside, having its own node with its own wallet and beeing able to send funds within seconds around the globe in a censorship resistant way is just a very good thing. Of course there is room for improvement, most of all on our side.

First of all, we want to enable the DynDNS feature of the RaspiBlitz to be able to connect Zeus not only within our local LAN to the node, but from everywhere. Furthermore, it would be super cool to see some payments beeing routed via our node. Maybe we have to increase the funding and open some more channels. Right now, we don’t know how to solve the inbound liquidity issue for our node. Feel free to open a channel to the CombinatLN node.

Last but not least, it would be awesome to build some application that makes use of our lightning node; maybe even something that runs in parallel at the Raspi. This would be the controlling transaction mentioned at the begining of this post.

Safety, Organization and Bottlecutting


Today we fixed our shelfes to the wall. Safety first.


The tool side walls were filled to some extend, too.


….and we continued with bottlecutting. Partially not completely successful.

View this post on Instagram

There is so much room for improvement. #outtakes

A post shared by combinat (@combinat.hq) on

…partially promising. At least the last one worked out well.


Our first project. Deadline: June, 15th ; start of the Bunte Republik Neustadt.


No, we did not invent this thing. You can find the definition and history of harmonographs here:

Even better, there are super cool and detailed instructions for building a harmonograph available:

And here we go. It works. This is the first 2D test oscillation.