Projects Kajus' projects en-us Picoballoon 2020

As in 2019 the Brno Observatory and Planetarium organised a Picoballoon Channelnge in 2020. It's a competition of high altitude ballon probes, the one that sends it's altitude as the last one wins. Each probe must weight under 20 g and share at leas an approximate altitude in the telemetry messages. These probes will be launched on helium filled balloons to altitudes around 5 to 10 kilometers, that means the probe must whistand temperatures below -40 degrees Celsius an rough weather and at the same time, it must be able to send the telemetry data from any point in space. The previous probe I made for the 2019 competition wasn't very successful, a communication with the TTN didn't work as expected as I was only able to receive the join requests, but no payload. Due to the very limited amount of time I had when I started the project, I didn't have a change to properly test the power supply design, it worked, but it's efficiency was miles from perfect. So, a new year is here, let's do it better! Oh, crap, only two months to launch again...


Let's start with a way the probe could be powered. We are limited by 20 g total take-of weight severly, therefore only battery and solar power comes into comparsion. Batteries are heavy, will die eventually, but can provide power all the time until fully discharged. Last time all the probes were killed during night in storm, the last probe alive was running from batteries, therefore could send the telemetry during night and win the competition.

Second option are solar cells, they won't run out of charge, but the probe operation is possible only during the day. Aditionally small solar cells won't generate much power therefore some kind of energy storage (e.g. supercap) is needed. Solar cells are also fragile and can be easily damaged during a transportation or by strong wind gusts (not mentioning hitting a tree during the launch which happened to one team last year). Let's go with the solar way, optionally the solar cells could be replaced by a battery without changing the board.

The solar cells are charging a supercap that can power the probe for dozen of seconds. Last year I was simply charging the supercap through a low drop diode. It worked well, but it can definitely be done better. There are many energy harvesting ICs (LTC3105 for example), but they tend to be expensive, complicated to setup properly and based on few internet discussions also operate poorly on very low level light conditions as these circuits are usually designed for higher power usages than for the 20 g balloon probe. The low light conditions are the main reason why I would use the harvesting IC! Ok, this is not the way. So I kept the diode to charge the supercap directly. When the output voltage of the solar cells is high enough (around 0,6 V) the boost regulator starts to operate boosting it to...

STM32,GPS,low-power,RF,solar,probe Mon, 02 Mar 2020 22:35:41 +0100

For some time I was looking for a GPS tracking solution that would run from a single battery for several days. Smartphones are too power hungry, all GPS loggers I found are designed to track animals, cars, etc. by sending positon on request over GSM, but there are no loggers that would just save GPS position every few seconds and lasted several days on small battery. This fact forced me to design my very own solution.


This project is still in progress, most of the fw had been tested by unit tests, hw design is currently in the manufacturing house.


  • Run on a small battery for at least a week (with logging period equal or shortan than 1 minute)
  • Ability to store at least one month of tracking data
  • Show distance travelled and altitude ascended/descended
  • Download data to PC in common GPX format


As the device is supposed to be running on a small battery for extended periods of time, the desing itself must be as low power as possible. There are four main power hungry blocks: MCU, data storage, GPS receiver and power supply.

Few years back I would go with the Atmega or Attiny MCU, but stm32 + jlink + atollic for debugging makes me too lazy to do the old style printf debugging. STM32F070 comes with integrated USB peripheral and tons of flash storage for under 3 bucks in single quantities, so this is the easiest way to go. Also the huge flash memory can be used for storing two firmware images (valid and backup). The power consumption can be reduced heavily by switching to sleep mode as often as possible.

SD cards are a perfect storage solution, except for the power requirement, current during writing can reach more than 100 mA, standby current is bit smaller than 1 mA. That's awful. SPI Flash memories can run at few uA when not used and won't take much space on PCB. The capacity is much lower, but with a reasonable data format, this shouldn't be an issue.

It's hard to find a different GPS receiver than U-Blocks modules. I've worked with these before, they are nice, but the price tag in single quantities is around half of the planned device cost. That's too much. After some search I found a SIM28ML module which has same footprint as MAX-M8Q from U-Blocks. It comes with integrated LNA and SAW filter, everything bundled in a tiny package. The power consumption is similar to U-Blox modules. Unfortunately, the GPS module is the most power hungry device in the design. To reduce it to the minimum, it will work only once a minute and will be switched off after getting a fix, shorter logging period = higher power consumption (not necessarily linear dependence).

Currents drawn from the battery will be in order of dozens of mA, it doesn't really make sense to use a switching power supply here, a LDO is a good solution here. BUT, the power consumption is a...

STM32,GPS,graphic,low-power Mon, 30 Sep 2019 18:38:38 +0200
Picoballoon 2019

In 2019 Brno Observatory and Planetarium together with Slovak Organisation for Space Activities organised a competition of high altitude balloon probes. The rules were simple, build a probe that weights below 20 grams. It should be able to send it's own position. They will launch it on a small balloon up to stratosphere (well, the final altitude depends on probe weight, could be between about 2 km and 15 km) and the last probe alive wins. The deadline for registration was quite close and almost all my free time was gone because I was working on my master thesis back than. Anyway, launching my own probe into the space (almost)? Yeah, let's postpone the thesis a bit.


Question number one, how to power the probe? The power source must be light and must survive in freezing cold temperature (around -50 degrees Celsius). Some teams used batteries expecting the probe to work for day or two. Most people decided to use solar cells. As the competition goal was to send position for as long as possible, batteries were no-go for very limited lifetime. I had few solar panels lying in my mess box, quite bulky and heavy (around 4 grams), I've ordered box of solar cells from China, but shipping took too long and the parcel arrived a week after probe launch, so I had to use the heavy panel from the mess box.

As the radio link requires quire a lot of power (it takes dozens of mA during data sending) I needed some kind of a power storage in addition to solar cell. The 3.3 F/3V supercap I bought some time ago out of curiosity was the choice. So, solar panel charges the supercap, supercap powers the probe. There's one catch though, I need stable 3.3 V to power the MCU, GPS and RF modules. Therefore the supercap voltage is increased by boost switching power supply (MCP1640) to 3.3 V.

The power supply can't run all the time, imagine a simple situation - sunlight hits the solar panel, voltage on supercap starts rising from almost zero to around 800 mV where the boost regulator starts to operate, MCU and GPS wakes up, current consumption jumps to several mA, solar panel is not able to supply enough current, supercap discharges and boost regulator dies before any data were sent to ground. I tried to design a simple latching circuit from two transistors and few passive parts. The principle is simple.

  • Vcc is slowly rising, D2 is closed, no current is flowing through R1 and R3, voltage on Q2 base is same as on the emitter, Q2 is therefore closed.
  • Once Vcc is higher then zener voltage of the D2, D2 opens, voltage on Q2 base is same as D2 zener voltage, once Vcc gets over D2 voltage + 0.6 V, Q2 opens.
  • Current flowing through Q2 causes voltage on R5 to rise, therefore enabling the buck power regulator.
  • Voltage on R5 opens Q1 which holds Q2 opened until Vcc...
STM32,RF,solar,probe Sun, 25 Aug 2019 09:40:50 +0200
Darkstar MK.II

The original headlamp Darkstar was working well for me and for few of my friends, but the light output was not that high, there were few details I would make different today, etc. Therefore I decided to build another version as my balchelor thesis topic. This time I wanted to get as close as possible to professional lights. So, let's get to the design itself.


Driver schematics

The lamp is using my own design of switching buck current source. The operational principle is similar to one used in previous lamp model.

  • Assume Q3 is opened. Current flows through the coil, LED and R14.
  • When Q3 is closed, current continues to flow through the D4, coil, LED and R14, dropping as the magnetic field around coil collapses.
  • Current flowing through LED is measured by R14, voltage across this resistor (therefore referenced to ground!) is proportional to the current. This voltage is amplified by the opamp U3B (non-inverting amplifier).
  • Amplified voltage is compared with LED1_REF voltage on comparator U4A. R20 and R22 configure the comparator hysteresis. Output of comparator is configured through gate driver back to Q3 gate forming closed loop.
  • Frequency of the loop depends mainly on Vcc, coil impedance and comparator hystersis.

The left image show current through the LED. First the current is slowly rising as the magnetic field builds up, once the threshold is reached, Q3 is closed and current starts to drop. Upon reaching lower limit, the Q3 is opened and cycle repeats. The efficiency of such driver depends on difference between Vcc and forward LED voltage (therefore mainly on switching frequency, which is changing severely with this voltage difference). Lower difference, higher efficiency. Efficiency is low for low LED currents because the MCU and other components consumption is the same magnitude as the LED current. LED forward is not stable, it slowly rises with rising current, reducing the difference between VCC and LED, therefore increasing efficiency. The resistive losses counteract this increase causing slow drop of the efficiency in higher currents region.

I've also measured heating of the drive components and lamp body using FLIR thermal camera (set to maximum current - around 2 Amps per LED, ambient temperature around 25 degrees C). As you can see from the photos, highest temperature on driver board is 67 degrees. As the driver's schottky diode is in small SOD-323 package, it's heating considerably. Second significant heat source is the MOSFET. Some heat is also produced by the coil and current measuring resistor, but it's able to dissipate without any problem.

Most of the heat in the lamp is produced by LEDs. As you can see on the second image, LED temperature reached over 90 degrees C and the body (heatsink) was heated to 60 degrees. LEDs are soldered to aluminium star heatsink, which works well, but could be better. I was experimenting with soldering LEDs directly to the piece of cooper, it worked, but I overheated one of the LEDs in the process and it started to heat much...

caving,LED,atmel Sun, 25 Aug 2019 09:35:32 +0200

Few years ago I was facing simple question. Should I invest a huge amount of money to one of the top headlamps like Scurion or am I able to build my own with similar parameters? Well, buying stuff is easy and boring, building my own is a great way to learn and save some money (in theory).

After brief comparison of various headlamps, I've came with following requirements:

  • Separated battery box for two or more Li-ion 18650
  • Two LEDs, flood and spot (preferably latest Cree technology, at the time of building the lamp Cree XP-L2), with separated control
  • Aluminium body (heatsink, durable)
  • Water and mud proof design


The headlamp is just a current source for a LED module, right? Maybe with some additional crap like modes control, but the current control is the most vital part. High power LEDs can draw around 3 Amps at 3 volts. Li-Ion battery has nominal voltage 4.2 Volts, higher than LED nominal voltage. This simplifies the design. So, how can we control the current trough LED?

  • Linear supply - Resistor/Diode/LDO in series with LED, ineffective (4.2 - 3)V * 3A = 3.6 Watts lost as heat, hard to control power output (multiple switchable resistors)
  • Direct PWM - limit current by resistor, control brightness by PWM - ineffective same way as above
  • Switched current source - best possible efficiency, current through LED is precisely controlled, switched supplies have efficiency above 90 %.

So, switched current source is the best, right? But how do I get one? And how to stuff it inside tiny headlamp? Fortunately, I found interesting application note from Microchip. PIC MCUs contain reasonably fast comparators inside. These can be used in simple, but working buck regulator. The principle is simple:

  • High side switch opens, current flows through coil in series with the LED and current measurement resistor
  • Current through the coil cannot change immediately, it's rising, voltage across measuring resistor is rising therefore too
  • Once voltage on resistor reaches configured value, high side switch is closed, coil becomes current source and current flows now through diode connected to ground.
  • Once voltage on resistor falls below configured value, high side switch opens and cycle starts again.

These magical configured values when high side switch changes its state are derived from one reference voltage (generated by MCU, more below) and hysteresis of the comparator. Equations to control exact values can be found in the Microchips application note mentioned before.

Now I need to generate the reference voltage. Cheap PIC MCUs don't have DAC, so what now? Just run PWM of reasonably high frequency through simple low pass RC filter, it removes the higher frequency parts of the signal and what remains is a DC value (with some small ripple, no filter is perfect, especially single stage RC is quire horrible filter to use, but it requires only two components!). Cut off frequency of the RC filter is \(F = \frac{1}{2\pi RC}\). We need to get as low as possible - it means...

caving,LED,microchip Sun, 25 Aug 2019 09:32:08 +0200
BUT Pneumobil

In 2017 I became a member of Pneumobil Racing Team Brno, a group of students designing and building pneumatically powered racing cars for the Aventics Pneumobile competition. My task was to design and build electronic control and telemetry system. The first iteration was far from perfect. The pneumatic circuit was controlled by atmega MCU, logs were collected by the well known bluepill STM32 board. As the budget was severely limited I used cheap connectors that were far from perfect. During the arcade race one of the connectors failed and we lost the race. For season 2018/2019 I started from scratch (and made this project my masters thesis).

System design

The control system has several tasks:

  • Pneumatic control = pneumatic valves timing, race modes, optimizations for top speed or air consumption,...
  • Source of informations for driver = Car speed, selected race mode, air pressures,...
  • Logging and telemetry = saving car data to SD card and sending most important stuff to the pc

To increase reliability and maintainability I split the system into 4 separate parts that are interconnected by the automotive CAN bus. This way I can completely change the pneumatic control board for new car next year and keep remaining boards unchanged, etc. The general layout is below:


The Engine Control Unit is the most critical one. It does:

  • Valves control - 4 valves control air flow in the propulsion system, timing and the valves opening/closing scheme determine motor characteristics, top speed, air consumption, etc.
  • Reading user inputs - brake, throttle, horn,...
  • Measuring car speed, gear shifted,...
  • Measuring pressures in the pneumatic circuit
  • There are few spare inputs and outputs for e.g. electronic shifting (the gearbox is controlled manually be lever for now),...

As I mentioned there were few issues with the connectors last year, so for this season I used connectors with proper mechanical locks and grouped similar functions to one big common connector. It minimizes a risk of connecting a cable to an incorrect connector and increases rigidity of the car cabling.


The Human Machine Interfaces serves primary as a source of informations for driver. Additionally it provides a debug interface and there's a SD card for storing race logs and a RF module to send data to PC during the race.

The main part is a 5 inch touchscreen which is used to display several screens:

  • Race screen - shows speed, average speed, distance travelled, pressures in various points of the pneumatic circuit, allows driver to switch between several race modes and restart data logging system
  • Status screen - shows all important values from the car - battery voltages, currents, inputs state, piston position,...
  • Setup screen - interface to set system time and race modes parameters
  • Debug screen - simple interface for engine control - manual valves control, etc.
  • Console screen - System messages are printed here

Also there's a slot for SD card where system log (simple .txt) and race log (to .csv file at 100 Hz) are stored. Additionally most important...

STM32,RF,CAN,graphic Sun, 25 Aug 2019 09:27:50 +0200