Web interfaces


Some of the electronic devices I build require some sort of display and buttons for user interaction. This usually leads to a lot of work to design and build a front panel which ends up having a tiny character of graphic display. While in some cases it would be mandatory to have the interface on the device itself, this is not always the case. The simplest alternative is to have the device controlled through the serial port via console and growing more advanced means designing some sort of GUI for your pc. The next step is to have your device be a web server as well and provide control through a web page which in todays world means access is opened to anything that can browse the internet, the PC, tablet, phone. So far, my chioce of HW interface was Ethernet through the ENC28J60. Lately I decided to give something else a chance: routers.

Why routers

Simply because, depending on the goal, a router is able to provide with the following: a power supply with something left for the project, a case for the project, wireless and wired network connectivity, web server and interface, USB port, ample processing power and memory(vs a micro), huge list of bash commands, rather low power consumption etc. Many low cost models ca go below 20 euros and quite a lot of routers have been used for internet connectivity in projects. The down side is that they cannot replace the micro in the project due to limited amount of pins available and lack of ADC. It is worth noting that the price of a low cost version is comparable to purchasing Ethernet PHY, power supply and case, if the project can use those of the router. Alternatives of course exist, there are different tiny boards, my favorite would be the carambola 2 and there are new low power WiFi modules that could serve more power constrained devices like TI’s CC3300 but they are quite needy, requiring a lot around them.

My first experience was with an Asus 500gP which brought remote control to a few things around. Today I am looking at 4 other models. The TL-WR741N(D)  is available as low as 15 Euro, though it will probably be replaced soon. I have successfully used it as IP to serial bridge to replace a “normal” IP-serial bridge. But for more compact designs I would prefer the WR710N European version which I will use in this test. It’s a more compact version of the very popular 703N which has a separate supply and takes a while to be delivered. Have a look at some great pictures of the 710 here. The third option is DIR505 which has a great advantage of splitting in two giving you a nice and compact wireless board and a few extra GPIOs used for the switch. Now if only router manufacturers would do something nice for the hackers out there and bring out some of the unused GPIOs on a header….

A test

I decided to give it a try and found a candidate project: the heatsink tester. I am testing it with a TL-WR710N router, European version which comes with 32MB RAM and 8MB flash (3.5MB available after openwrt install). I took some shortcuts: I used a USB-serial adapter instead of the built in serial port to allow me to work with the console while developing the project, and try to modify the original heatsink tester as little as possible. This is not needed in a final design. Of course, the micro I used has USB port and could be loaded with usb-serial software, leaving the console free. If I am satisfied with the overall feeling I will buy a dedicated router for my heatsink tester and give it a proper „house”.

The web interface

I created a web page for the heatsink tester with the help of jqwidgets which are free for personal non commercial use. It took a while because I have no experience with javascript or html, but as I will be able to reuse parts of it for next projects it should go a lot faster next time.

The webpage has three parts: creating the widgets which includes all their designs, putting them on the page and the scripts for the data. The data flow is insured through two functions: one fetches the data from the router, the other sends data to it, both are called periodically.

Here’s a quick look. router web interface

Router software

The router stands between the microcontroller and the web browsers. The microcontroller sends all parameters required on the web interface through the serial port. A script on the router saves the last entry in a file in RAM. When the web page is opened it calls a cgi script which fetches the data in that file. Any interaction on a web page calls another script which sends some data to the serial port, to the microcontroller. The „middleware” on the router is meant to be universal, independent of the project. This will allow me to create a single image for all routers and use that one for an instant functioning router. For the moment the „history” is implemented on the webpage, not the router.


Response of the router seems to be very pleasant. The browsers show around 25ms response time, with both devices connected over WiFi. I tried opening the page from 3 devices and set the data refresh rate to 10/second and the router had no trouble handling it, there is plenty of power to spare. It is definitely faster than what you get from microcontroller based web servers, while the page is more complex.

While the design of the control panel and display may not be very artistic, it totally achieves the functionality I desired. I have displayed the important status parameters with gauges and text, which gives the user both precise and a fast display of status. A plot shows the evolution of parameters over time, providing a nice history.

Heatsink tester 2.0

My intention was to modify the original project as little as possible, jut to test the overhead of making such a web interface once the console is done.

I have changed the way data is send through the serial port to be comma separated, as this makes it very easy to parse. I have added some other status parameters, like if the heater is on, what is the maximum set power etc. I made minor improvements to the functionality as well: I added temperature limiting, if the temperature threshold is crossed, the available power will be limited. The loop is implemented in a simple way and is not very stable, but I don’t intend to spend time fixing it as it is meant only as a simple safety measure.

The second thing to add was a safety measure: periodically(every 5 seconds) the webpage pings the microcontroller. If no ping is received, after 12 seconds the microcontroller will stop the test and stop heating the heatsink. This means that the heater cannot remain on if there isn’t at least one web page open.

Here’s a quick measurement of a heatsink

heatsink tester connected to routertest with heatsink tester and web interface

Future plans

For the moment the plot is made by every webpage, so a device connecting later does not have access to the history. I will expand the script on the router to achieve this.

As it seems that one single router can handle lots of things, for some projects it might make sense to use a router as a gateway for multiple projects. Data can be sent to the router with simple radio modules, like RFM12 or NRF24L01. This will make each project smaller and possibly battery operated.

Disclaimer and thoughts

This is not meant to be a complete project, just a test of feasibility. So there are no files available or detailed instructions how to achieve this. I will post all details with the first complete project that will have a web interface. I have had troubles getting stable results over the serial port. After many tries I decided to re-install openwrt after which everything worked fine. The webserver on the router comes by default with a very low number of maximum connections which causes frustration and failure to load pages, slow interface etc. So I increased it.

I have been unsuccessful at making it visible as network devices through network discovery, it would work out great if its properties could point to its webpage. Drop me a comment if you know how to.

The power supply should be able to provide the full current of a single USB port, 500mA but I suspect the total available to be more like 0.8A. My sensitive power meter shows the router draws about 1.2W from the mains while connected to the WiFI, while also powering the microcontroller and the CP2102 USB-serial adapter. The router itself needs only 1W of power.

WS2812 level translator

WS2812 LEDs are one of my favourite toys. Apart from all the things that you can do with them in terms of lighting, displays or even light painting you can also use them for your projects as indicator lights.

The great advantage comes from the fact that you can use a single pin to drive so many of them and it takes just 3 wires ran across the whole box for practically any number. This in turn comes with the disadvantage of more complex control and problems driving them(5V devices) from a 3.3V microcontroller.

Although the data sheet states that you would need at least 3.5V for them to recognize as HIGH level(70% of 5V), many seem to have no problem being driven from a 3.3V micro. With the signal regeneration that each does, it is only a problem for the first one in the chain. But, as I found out, some LEDs simply don’t work as the first device, and to be safe it is best to use a level translator. Unless you completely forget about it and find yourself in need of driving a display with WS2812 which does not like 3.3V signals.


Luckily there is a simple solution with parts that you have available: just another WS2812 LED (or two) and a diode. The trick is to power the first LED in the chain from 5V via a diode dropping its supply to 4.3V*. At this level the 3.3V signal from the microcontroller is within specifications to be recognized as a high level. As each LED does signal regeneration the output of the first LED will be at a 4.3V level which is in specification for the next LED powered at 5V. If you need a longer cable between the microcontroler board and the LEDs, a second one may be included in on the board which will be supplied by 5V in turn regenerating the control levels to 5V.

 Below you can see the original 3.3V signal and the 4.3V signal after the first LED. Also notice there is stronger ringing on the 3.3V control signal due to longer wire from the microcontroller.3v3_to_4v3

And now the original 3.3V signal and the 5V signal after the second LED:3v3_to_5v

*Datasheet doesn’t specifically say what is the normal supply range for these LEDs, although many specs are provided for 4.5 to 5.5V supply. I found no problem with them at 4.3V in normal ambient conditions.

Heatsink Tester


It’s quite a common problem when building electronics that some components need cooling which is usually done through some sort of heatsink and optional fans. Choosing the right cooling solution can be a difficult task because the real life behavior of the system is hard to predict or model. In my case I have faced the simple question quite a few times: how much heat can a cooling system dissipate? The thermal resistance of a particular heatsink may vary quite a lot depending on the surroundings or it can simply be unknown to start with. The aluminum side wall of an enclosure made me build this thing.


This is why I have made this little device: a thermometer, a transistor and a microcontroller with a simple command line interface. I could have answered my questions in quite a lot of simpler ways, but since I made a simple thermometer not much else is needed to control the transistor when a DAC is available in the microcontroller.

The device works in a simple way: a specific power is dissipated on a transistor while a DS18s20 temperature sensor measures the temperature on the heatsink as close as possible to the transistor. The circuit uses a serial connection and is controlled via the terminal. A few preset values are available for the power to be dissipated.

The micro at the center of the project is an ATXMEGA32A4U and I am using a small board I designed for another project and another proto board which contains a current sensing resistor and a voltage divider to measure the supply. A TL431 is used as a 2.5V reference. The circuit uses two supplies, one for the micro which also contains a 3.3V LDO and one for the dissipating transistor. The schematic is shown below:


The reason for leaving the supplies separate was to be able to use a wide range of supplies for the dissipating transistor; the circuit is designed to measure up to 52V input. Such a supply is too high for a normal regulator for the micro. If the allowed maximum is lowered, a regulator can power the micro as well. In practice it turned out the low power levels (0.5 – 5W) are regulated better when a low voltage supply is used for the transistor (3V). For higher output power (5W to 50W) a 19V laptop power supply worked just fine. The limit simply comes from the ADC precision and the value of the current sensing resistor.

An IRL540 transistor is chosen as the dissipating element due to its low threshold value. This is necessary to allow driving from a 3.3V DAC, considering the voltage drop on the current sensing resistor as well. This was chosen as 0.1 ohm, which corresponds to about 0.25V of drop while dissipating 50W from a 19V supply.


Due to the high thermal inertia of the system, a very simple regulating method was chosen: if the dissipated power is too low, the DAC output is increased, otherwise it is decreased. This produces some oscillations around the set value, but if the power is averaged over one second a very stable value is obtained. The control loop runs a few hundred times a second, data averaging and display is controlled by the RTC.

The microcontroller calculates the thermal resistance of the heatsink assuming that the start of the experiment is at ambient temperature. The circuit needs to run until the temperature of the heatsink stabilizes to the new value. The time required depends on the system, but in practice I found 1h to be sufficient.

The software allows for very simple functions, but I found it to be sufficient: choose the power to be dissipated and start and stop the experiment. The software is available for personal use. Data is sent out through the serial port and can be viewed in a terminal, the supply voltage, current, calculated power, DAC set, temperature and calculated thermal resistance are sent out.

NOTE: there is no protection for the overheating of the transistor, since its temperature is not measured directly. It is up to the user to make sure the dissipated power is chosen appropriately for the heatsink size. When mounting the temperature sensor it is important to have it thermally coupled to the heatsink and insulated from the ambient. 

Experiment 1

A small heatsink is placed in a small box and 5W are dissipated. Other components are added around to mimic airflow restrictions. After half an hour the temperature stabilizes around 72°C indicating a thermal resistance close to 10K/W. This is pretty good, considering that the manufacturer rates it at 14K/W.




Experiment 2

This experiment is actually the real value I was interested into. The side of the enclosure is made of aluminum and it allows for transistors to be easily mounted. But neither the seller nor the producer were able to say anything about the dissipating capabilities.  By dissipating 20W the final temperature reaches 52°C which indicates about 1.3K/W thermal resistance. In practice such a high temperature is uncomfortable to the touch but does not burn, so a circuit should dissipate lower, depending on the application. Plotting the data gives out a nice curve with the temperature variation. The output log is available here. 




Future work

The whole thing is build as fast as possible using a PCB I already had. A next iteration would include a dedicated PCB, with its own LCD and with a nice PC application. A case would also improve the project.