Archive for the ‘Uncategorized’ Category

On GreatScott’s Arduino vs common IC’s comparison

August 23, 2016

I’m writing this after having read this Hack A Day post. The post is about a Youtuber named GreatScott! (which I already knew for its well made electronics videos) attempting a second build of a coilgun driving circuit, this time using logic integrated circuits instead of an Arduino. The video I’m referring to is this one.

Up until now everything seemed fine. It’s actually cool to show that “there’s more than one way to do it” in electronics. However, after watching the video, I was quite disappointed. The video seems – to me, at least – more like a way to prove the point that using an Arduino was a good idea in the first place, rather than an attempt at giving a fair comparison between logic design and microcontrollers. Why, you may ask? Because the author made no attempt at actually optimizing the circuit! Not putting any effort in optimization, unsurprisingly, leads to an overcomplicated design.

Here’s a list of the missed optimization points (which might make sense to you only after you watch the video):
1) Use of inverters to match the pushbutton to the flip-flop. A pushbutton can close to the positive rail and have a pulldown resistor, or close to the negative rail and have a pullup resistor. When using a microcontroller, the choice of pushbutton configuration gives you no advantage (unless you want to use the microcontroller’s internal pullups), but when using logic you can take advantage of this to avoid needless inverters.
2) Unnecessary use of opamps. The use of RC circuits to provide timing in logic is well known, but so is the fact that CMOS logic happily accepts the slowly rising voltage of a capacitor without the need for an opamp used as a comparator. Schoolbook examples such as the NOR monostable prove this. Even in tricky situations, the availability of CMOS gates with schmitt triggered inputs means you can get away without opamps.
3) Use of discrete gates where wired logic is sufficient. Wired logic is a common way to optimize a design, eliminating the need for discrete gates. The infrared sensors he used (CNY70) are even natively open collector, which simplifies the schematic even further.
4) Missed opportunity for simplification of the original schematic. The original design using an Arduino requires IRS2001 MOSFET driving ICs because an Arduino works at 5V or 3.3V, and that voltage may not be high enough to drive a high power MOSFET. However, CMOS ICs happily operate at up to 15V, so they can be operated at the same voltage used for the coils, and drive the MOSFETS directly, actually reducing the IC count compared to the Arduino schematic!

As I don’t think it would be fair to state all this without proving it at least with a schematic, here’s my solution to the coilgun driving problem using logic (download it in Eagle format here).


We’ll start describing the schematic from the top left. The button is used to fire the device. It closes to ground, so no inverter is needed. The use of C1 and R2 is to prevent the first coil from being permanently energized if the user keeps the button pressed, an issue that the author stated the Arduino version does, but his logic solution doesn’t do. A CD4093 4 NAND gates with schmitt trigger inputs is the only IC in the circuit. Half of it is used to make the first flip-flop. R4 and C2 provide the safety timeout circuit to de-energize the coil if something goes wrong. D1 quickly discharges the capacitor. The light sensor, and the RC circuit are wire ANDed together to reset the first flip-flop and start the next one. The bottom circuit is just a simple repetition of the first one, which incidentally makes extending the circuit to a coilgun with more than two stages very easy.

The component count is just one IC, a CD4093, two transistors and two MOSFETS. Compared to three ICs and two MOSFETS in the Arduino version, the solution is simpler and cheaper. But this does not mean that it couldn’t be optimized even further. The schematic I’m proposing is just the first option that occurred to me, and is using common logic gates such as NANDs. After designing the schematic I realized that maybe replacing the CD4093 with a dedicated double monostable chip such as a CD4098 with the light sensor connected to the monostable reset lines could remove even the need for the two transistors.

However, to be honest, I still think my post is a bit unfair. That’s because the author of the video actually built the circuit, while I’m only providing an untested schematic without component values. The issue is, I’m on holiday (yes, I follow Hack A Day even while on holiday), so unfortunately I can’t build the circuit to test it. I hope I haven’t made any major mistake 😀

To end this post, I’ll add just a small note. Even though I am not exactly a fan of Arduino (which I like to think of as a good learning tool an engineer should grow out of at some point), I am definitely not against the use of microcontrollers in general. I even wrote an operating system for microcontrollers, Miosix. There are good reasons for using a microcontroller: data logging, a menu based user interface, PC interfacing come to mind. Even too complex application logic is a good reason for using a microcontroller. It’s just that I recognize that certain tasks are still better solved using logic, and two flip-flop with a timeout definitely falls in this category.


Atten 858D+, the D stands for defective

June 26, 2016

A couple of years ago, I was looking for an inexpensive hot air soldering station to solder SMD components. It wasn’t the kind of tool I expected to use everyday, so the price point was an important factor for me. After a bit of research on the Internet I found this EEvblog video about the Atten 858D+. It looked good enough, and the price seemed right, so I bought it.


As you may have guessed from the title, I’m writing this post because it broke. After only a couple of years of occasional use. Yesterday I was soldering some components and it suddenly stopped melting solder. Looking at the display I saw the temperature slowly decreasing, and after a while the letters “H-E” appeared on the display, which I guess means “heater error” or something like that.

Left with a broken soldering station, I decided to open it to see what happened. The heat gun is relatively easy to open, just unscrew the plastic part covering the back of the metal tube, and undo two screws. Inside there is a small PCB with no components, used as a wiring board. Two contacts are marked “heater”, and unsurprisingly they measured open circuit. Disassembling the heating element was a little bit more difficult, as the metal tube is glued to the case, and the heating element is wrapped in mica paper and is a tight fit in the metal tube. After unwrapping the mica paper, I found a coil on wire, probably nichrome and a thermocouple towards the tip.

Actually, there was also something else. Two small pieces of wire stuck in the middle of the resistor coil, shorting some of the turns. And at one point, coincidentally exactly where one of the two extraneous metal wires was shorting the coil, the coil was melted, resulting in an open circuit.


In the picture above you can see in the red square the point where the heating element was broken, and in the yellow square the two pieces of extraneous metal wire that I removed from the heater coil.

The next question is: did those two pieces of wire end up there as a mistake, or were they put there on purpose to cause hot spots in the heater so as to make it fail prematurely? Is this a case of planned obsolescence? In any case I’m not going to buy Atten branded stuff again.

Thermopiles and tunnel diodes: a candle powered LED

March 25, 2016

This is just a small project that I’ve been doing to explore some not so well known technologies. The goal is simple: use the heat of a candle to turn on an LED. Actually making a device that does this function turned out to be not that simple, though.

Part 1: The Thermopile

To generate electricity out of a candle flame, I decided not to go the obvious route of buying a TEG, but instead to try building its ancestor, the thermopile.
A TEG, or thermoelectric generator is a device made of a number of semiconductor junctions in series that generate a small voltage when a temperature difference is applied to them. They are essentially the same in construction as the more common TEC, or thermoelectric cooler, that can be found easily on ebay.
The main reason why I have decided not to use them, is that TECs/TEGs get damaged at temperatures above 150°C or so. Since the flame of a candle is well above that temperature, I would need to come up with a way to reduce the flame temperature to a usable value.
A thermopile is a series arrangement of thermocouples. It works in the same way as a TEG, but uses metal junctions instead of semiconductor ones. Thus, it is more rugged and can easily withstand higher temperatures.
At first, I tried making a thermocouple out of materials I had at home, namely copper wire and nichrome wire, but the results were very poor, as I could only get a few millivolts out of it when exposed to a flame. So, I ordered a K thermocouple to cut its wires into pieces and experiment with thermopiles.


This is what remains of the thermocouple after the experiments. I’m sure it still works if I solder back the wires to the connector.


This is my first thermopile. It was built by cutting two 4cm pieces of thermocouple cable, straightening the wires -as they were twisted together- stripping the insulation and twisting the chromel and alumel in order to make the hot junction. I would have tried welding them together, but I lack the necessary equipment. The cold junction between the two thermocouples can simply be soldered, as it doesn’t have to withstand hundred of degrees.
When exposing both hot junctions to a candle flame, I got around 65mV, that’s promising.


This is my second attempt at making a thermopile. I used mica sheets above and below to provide some mechanical strength and try protecting the twisted hot junctions from the flame. My fear was that since the metal is just twisted and not welded, if it oxidizes due to the heat, it may no longer form an electrical connection.
This design turned out to be a bad idea, though. Despite having three thermocouples in series, I could not get more than 50mV out of it. The main reason is most likely that the mica introduces a thermal resistance between the flame and the junctions, so the temperature they reach is lower.


After the failed attempt, it was clear that to work well a thermopile requires the metal to be exposed to the flame. Having learned that, the next step was to make a working device and not just a test. I wanted to get around 200mV out of it (see the next part for the reason), so that means 6 thermocouples in series. After spending some time thinking how I could make a design with 6 thermocouples close together enough to be heated directly by a single candle flame, this is what came out. I used four mica spacers to prevent shorting, and epoxy on the outer spacers to provide some mechanical robustness to the design.

I also tried to do some computations to figure out what could be expected out of such a device. The expected voltage is three times the one I got out of the first test, about 200mV. That means around 33mV per thermocouple.
Estimating the current is a little bit more difficult. The seebeck effect theory seems to focus on a voltage difference being generated, but does not mention current. So I guessed that what limits the current flow is just the resistance of the wires. Looking up the resistivity of chromel and alumel resulted in those formulas:
chromel 0.706uohm/m (1+0.00032*T)
alumel  0.294uohm/m (1+0.00239*T)
The resistance depends on temperature, and given that the hot junction reaches hundred of degrees, it likely can’t be neglected.
According to the K thermocouple curves, a 33mV voltage means around 700°C of temperature difference. As the cold junction does get a little bit hot as well, an educated guess may be 750°C for the hot junction, and 50°C for the cold one. To simplify computations, I assumed that temperature varies linearly along the wire, leading to an average temperature of 400°C. Considering that the wires have a 0.3mm diameter, and are 4.5cm long, a single thermocouple has an estimated resistance of 0.9ohm, and the entire arrangement 5.4ohm.
This means a 37mA short circuit current. The maximum power that can be expected out of this device is thus half of the open circuit voltage times the short circuit current, or around 3.7mW.


Measuring the short circuit current of a device outputting such a low voltage is not easy. A simple multimeter has a burden voltage in the same order of magnitude as the open circuit voltage (~200mV), introducing a significant error in the measure. As I don’t have a uCurrent, I settled for using a short loop of 26AWG copper wire as a low value shunt resistance, and using a millivoltmeter with 0.1mV resolution. Since the resistance of the shunt is unknown, it was first measured using a known current, and resulted to be 0.035ohm.
In the picture above we can see the reading, which is 1.7mV (the millivoltmeter lacks a decimal point). The short circuit current is 48mA, nearly 10mA higher then predicted. This was due to the wire having a lower resistance than the one computed before.


An open circuit test showed I got 178mV out of it. Not quite 200mV as I hoped, but close enough. In the picture you can also see the wire loop used as low value shunt resistor. So, with ~180mV open circuit and ~48mA short circuit, assuming the best power transfer to the load, this thermopile would produce around 4.3mW.

Part 2: DC-DC converter

Up until know I had fun building a working thermopile, but how to turn on an LED with it? LEDs need different voltages to turn on, with red ones requiring just 1.8V, and blue ones going as high as 3.6V. Thus, at least 55 thermocouples in series are required to directly power an LED. A different approach is apparently required.

The issue is, there aren’t many ways to build a DC-DC converter that works with just a few hundred millivolts. A blocking oscillator, also commonly known as joule thief can be designed to operate at just 200mV, if using a transistor with a low enough VCE|sat, but still requires 700mV to bias the base when first powered up. MOSFETS are even worse, even the best ones require more than 1V to their gate before thay do anything.

Although there are energy harvesting ICs nowadays that are designed to step up very low voltages, I didn’t want to go the IC route. Given the experimental nature of this project, I wanted to stay close to physics rather than using a black box IC that does what I need but leaves me with little knowledge of what’s going on inside. Also, I didn’t happen to have any energy harvesting IC lying around, but I had something else that would do the trick.

A while ago I watched a video about tunnel diodes. They are quite unlike conventional diodes, as for voltages between around 0.18V and 0.8V they have a negative resistance region, where current decreases as voltage increases. This means that an oscillator can be made with them, operating at just 180mV. From there, a transformer can be used to step up the voltage. An inverter circuit can thus be made with just two components: a tunnel diode and a transformer. Such a circuit appears to be little known, but is very old. I found it at page 104 in this RCA book from 1963.


The tunnel diodes I have are АИ301Г, rated at 10mA peak current. For the transformer, I repurposed a toroidal core out of a broken CFL neon lamp. I measured the inductance factor in order to get predictable inductance values, and it is AL=700nH. I wanted the device to oscillate at just a few tens of kilohertz, so the primary was chosen to have a rather high 500uH inductance. Doing the math, 27 turns are needed. I used 30AWG wire. The secondary was made out of 95 turns of AWG36 wire.


This is the output of the secondary. 4.5V peaks at 15KHz.


Yes, it does turn on a high brightness LED. Success.


To characterize a bit more the output, I rectified the secondary of the transformer with a BAT42 diode and a 1uF capacitor. Applying different load resistors, here are the curves of the output. The maximum power point is 180uA at 1.8V, or 324uW. Quite a bit lower than expected. This is most likely because the thermopile voltage is only 180mV, which is the same as the tunnel diode peak voltage. So, the oscillator barely turns on. With 250 to 300mV the power output would probably be higher. Also, a disadvantage of the tunnel diode oscillator is that the maximum output power is limited by the diode peak current, which is just 10mA. To get more power, you need a bigger diode.

Here’s a video of the thermopile working.

The experiment was a success. Maybe someday I’ll try to improve the efficiency by making a 8 element thermopile, but still I’ll be limited by the tunnel diode peak current. Despite the RCA book mentions 1, 10 and even 100A tunnel diodes, those 10mA diodes were the best I could find. Maybe I could try a push-pull configuration with two tunnel diodes, or use the tunnel diode to kickstart a joule thief, who knows.

Broken mac power supply

September 1, 2013

One of my computers, the one I use for web browsing is a Mac. Despite that, I’ve installed Linux on it and use it instead of Mac OS almost all the time, but this is another story.

Anyway, a few days ago, my Mac simply stopped charging. I was on holiday, so I had to wait until I got back home to troubleshoot what happened. Measuring the output voltage resulted in a zero volt reading, so I opened it up.


Inside I found a burnt resistor, and a blown fuse. The resistor appears to be the bleeder resistor in parallel with the input capacitor. It has likely failed resulting in a short circuit, and the fuse blew.

Now, Apple chargers are usually touted for their high quality compared to cheap chinese clones, however I wonder who thought that putting a tiny 0805 resistor in parallel on a high voltage line was a good idea…

Sure, the charger worked reliably for five years (I bought the Mac in 2008), and failed in a rather safe way (mainly thanks to the fuse) but still I think this failure mode could have been somehow forecasted, also considering that this is not the first time I see it. The other time was in an inverter, a device that produces a 230VAC output given a 12VDC input. The step-up circuit had a diode bridge rectifier, a capacitor, and a tiny 1/10W resistor (it was entirely through-hole, no SMD). One day I turned the inverter on, and heard a loud pop and a flash of light through the heat vents.

In the meantime I had to find a way to somehow power the Mac again. I cut the power cable and connected it to the only device I had lying around that could produce 16.5V at 4.6A… a cheap chinese power supply. That’s ironic, to say the least…


Synchronization primitives in Miosix

October 6, 2012

A small and backwards compatible change in Miosix 1.61 made me think about low-level synchronization primitives, and the fact that doumentation on how to use them was lacking. So, here’s a page dedicated to this topic.

Serial port classes moved to Gitorious

July 11, 2011

When I first published this article about using serial port with C++ I didn’t expect it to become one of the main reasons people visit my website. Over time, thanks to many comments, bug reports and suggestion, the serial port classes have been modified significantly, to the point that releasing them in a .tar.gz file is no longer a good idea. I’ve therefore decided to create a git repository at where you can get the latest version of my serial port classes.

Improving battery lifetime of Le Dominoux

April 26, 2011

Some time ago I saw on Hack a Day this post about Le Dominoux, an electronic based version of dominoes. At first it didn’t seem much fun, but watching the video I quickly changed my opinion.

In the end, the author also measures the power consumption of the device when the led is not lit, showing it’s around 100uA, and it’s from there that I thought this little device might be improved a bit.

Now, since this device was designed for a 555 contest, the author had to use a 555 IC, and given this constraint I think he has done a good job in optimizing it for low power, using a CMOS variant of the 555 and high brightness leds.

But set aside that constraint, it would be easy to optimize it event further. First of all let’s check the battery lifetime of the original device. Since the power cosumption when the led is lit (probably 5 to 10mA) differs greatly from the standby value of 100uA, battery lifetime largely depends on how much you play with it, but an upper bound is easy to calculate, and it’s 200mAh (CR2032 battery capacity) / 100uA = 2000h / 24 = 83 days. This isn’t very good since even if you almost never play with it, after ~80 days the battery is dead.

One possibility to improve it is to use standard 40xx CMOS logic gates to design the one shot timer, like this:

The fun of CMOS gates is that other than being very versatile, they draw next to zero current when they’re not switching. I built this circuit to measure the power consumption, ant that’s the result:

As you can see, it is drawing just 4uA. The actual standby current depends on how much light is shining on the phototransistor. For example in the dark it draws just 1uA, while if a bright light is pointed at the phototransistor it draws up to 300uA, which is 3V(battery voltage) /10K(R3). This happens also in the original author’s schematic, since the input stage with the phototransistor and the 10K resistor is the same, so that’s no worse than the original circuit. Anyway, in normal ambient light conditions very few light reaches the phototransistor, and the current is very low, around 5uA.

This gives an upper bound to the battery lifetime of 200mAh / 5uA = 40000h / 24 / 365 = 4.5 years!

Last notes about this circuit:

  • it uses the same number of components as the original one, just replaces the 555 with a 4011.
  • you have to connect pin 7 of the 4011 to ground, and pin 14 to Vcc, even if in the schematic these connections are omitted.

Fail over fail

January 7, 2011

Even more rant this time.

To go on programming microcontrollers as I’ve always done I have to disable two programs, gpsd and modem-manager (see my previous post) because hardware manufacturers fail. The first one, gpsd is done. To fix the second one without killing/removing NetworkManager I have to contact ModemManager developers. To do so I have to register to launchpad. To do so I have to get an OpenId. To do so I have to… find a way to avoid another fail:

See on the bottom of that webpage? “Type the two words into the field below”. I’d be glad to do that if there were two words, and one field. The HTML source of the page seems to indicate that a sort of captcha is supposed to be there, bu there isn’t… and without it I can’t complete the registration…

But wait, there’s more fail:

A quick look at and I found out that since I have a wordpress blog I already have an OpenId. I tried to log in with that, but it failed. A look at the FAQs for launchpad and:

Can I log into Launchpad with my existing OpenID?

Not at this time. Launchpad is currently an OpenID Provider (OP) and not a consumer (RP).”

And that, in my opinion, is fail.

Linux today: too much plug and play

January 7, 2011

This title is probably not what you’d expect. Usually people complain for the opposite reason: they buy some hardware, connect it to Linux and it does nothing, so they have to spend time in forums to see what can be done even if manufacturers don’t officially support Linux.

In my case, it’s the plug and play system itself that is causing me problems, because it incorrectly identifies a device as another type of device…

But let’s start from the beginning. I’m an embedded developer, and therefore I deal with microcontrollers. Often, the easiest way to debug, program, and communicate with a microcontroller is a serial port. Given that serial ports disappeared from computers long ago, USB to serial adapters have been introduced to solve this problem. These are all tiny chips like the FT232 or PL2303 that connect upstream as USB and downstream as serial ports.

These chips can be used either as standalone products, like the blue dongle at the left of this picture which is PL2303 based

or directly embedded into the device. For example, the Miosix board that I designed has an FT232 on board. It’s the chip at the bottom right, next to the USB connector

Now, both these devices identify as serial ports, using the default VID and PID (which are the identifiers of the USB protocol) of the manufacturer. They do so because they are serial ports, the first one is obvious to see, but also the second, since I don’t need any program to automatically start when I plug one of those, just to sit there and wait till I open screen or minicom to watch debug messages and the like.

Now, I’ve recently upgraded my computer to Fedora 14. It works very well, except for serial ports. At first I noticed that immediately after connecting a USB/serial device, trying to talk to it resulted in errors. “Device ore resource busy”, it said. Retrying after a couple of seconds fixed this, but then it looks like the bootloader of the microcontroller (the first program that starts) has been upset by something, so the first programming cycle failed, the next one went well, and all the subsequent too. At least until the USB/serial adapter is disconnected and reattached, in this case the issue presents again.

What could it be?, I thought. Maybe a bug in the kernel driver for serial ports? It turned out to be something entirely different.

To understand what was happening, first we have to talk about crappy GPS mice and GSM usb sticks. Both have someting in common: those who manufacture the GSM/GPS module are different from people who design the final product. The GSM/GPS modules, for convenience, spit out their data through a serial port. But given that PCs have USB ports only, final product designers add an USB/serial converter into the device. Now, the issue is, that they don’t care about changing the default VID and PID of the USB/serial adapter. Therefore when plugged to a PC they appear as serial ports despite their products are not serial ports. A GPS can only understand NMEA sentences (plus some weird binary protocol), while a GSM “internet key” can only understand AT commands. And what’s worse, they require plug and play, they require a program that attaches to these devices as soon as they’re plugged in.

Linux on the other side, is growing fast even as a desktop operating system. So it’s natural that it is starting to support more and more hardware, in the easiest possible way. But how can it cope with GSM/GPS USB sticks?

Simple: for GPSes there’s a program, gpsd, that when a new device is connected, its VID and PID are checked against a list of devices, and if matches it tries to send NMEA sentences. If it responds, ok, otherwise the device is discarded. The same happens for GSM devices, there’s another program: ModemManager that does the same thing with AT commands.

But given that most devices appear as a PL2303 serial port, how can these programs know if after the PL2303 there’s a GPS unit, a GSM “internet key”, or none of these? Simple, they don’t. They try for a while to talk and if the device on the other side doesn’t seem to be what they expect, they give up.

This explains why trying to connect my USB/serial adapter to the PC and immedately open screen or minicom resulted in “device or resource busy”, while retrying a couple of seconds later worked.

The issue I’m having with the bootloader, is instead caused by the fact that these little program don’t just open the serial port and listen, they open the port and talk! The bootloader of my board probably gets upset by AT commands, or NMEA sentences or both.

But then I wonder, does a GPS unit like AT commands, or conversely, does a GSM internet key like NMEA sentences? This is trouble waiting to happen. Also on Windows, I suppose. Assume one buys a cheap GSM unit that identifies as a PL2303, and a cheap internet key that identifies too as PL2303, what does the official Windows drivers that come with them do? Conflict, I guess.

The first attempt to fix my issue has been to uninstall gpsd and modem-manager. Unfortunately, on Fedora, the whole KDE depends on gpsd, so it can’t be unistalled. I therefore contacted the gpsd developers on the mailing list. They have been very helpful in finding a workaround (they even blogged about it as I’m doing now, here), which is to download the gpsd sources and issue these commands:

make udev-uninstall

which leaves gpsd installed, but removes udev rules that cause the plug and play. It’s also interesting that if I ever buy a GPS unit I can still start gpsd manually. Nice.

The fun thing is that gpsd developers were not aware that some other opensource project, ModemManager, was lurking for the same USB VID and PIDs…

I still haven’t found a way to disable modem-manager. It is a daemon, but it auto-respawns when killed, there’s no “service modem-manager stop” and trying to uninstall it would also get rid of NetworkManager.

Ofcouse, the only way to fix the whole problem is that hardware manufacturers should change the VID and PID so that a GPS, a GSM modem and a serial port can be uniquely identified…


I found a way to disable modem-manager while leaving NetworkManager:

sudo service NetworkManager stop
sudo killall modem-manager
cd /usr/sbin
sudo rm modem-manager
sudo service NetworkManager start

Ofcourse any GSM internet key would probably stop working, but for now It’s enough. I can finally connect an USB/serial adapter and nothing is trying to speak with it by default. Finally.

Handling PNG images in C++

October 5, 2010

This blog post is about png++, one of my favourite C++ libraries.

It’s a wrapper of libpng in C++ that allows to handle PNG images so easily that you’ll never want to use bare libpng again.

All you need to start is to add these two lines in you source files:

#include "png++/png.hpp"
using namespace png;

This is the code to open an existing image:

image img("image.png");

The code to make a new image from scratch differs only in the parameter passed to image’s constructor:

image img(1024,768);

The image class has the get_pixel() and set_pixel() memeber functions to access the individual pixels:

rgb_pixel pixel=img.get_pixel(0,0);,; //Increase red color of pixel

The image height and width can be obtained with intuitive get_height() and get_width() memeber functions:

for(int i=0;i<img.get_width();i++)
    for(int j=0;j<img.get_height();j++)
        //Do something

The image can be written to file with the write() memebr function:


Also, this library is header-only. What does it means? That you do not have to compile the library to start playing with it, just exptract the library in the folder where you have your source code, and include the header file “png.hpp”, just that.

Lastly, here is an example code including CMake scripts to show the capabilities of the library. png++.tar.gz