Almost a year later, how is V doing?

Last year in February V was announced. The language was designed by Alexander Medvednikov, who needed it for the development of Volt, a desktop client for chat applications. The writing of Volt, happened in Vid, a self-written text editor, also written in V.

V has quite a few interesting characteristics. Perhaps the most interesting, is the fact that V is written within itself. A first version was written in C, and after that it was developed further. The C version can also be found on Github.

On the website, V is described as follows:

Simple, fast, safe, compiled language for developing maintainable software.

As in most languages today, you can work in a modular way. V supports the development of modules very well, which makes it easy to develop packages, as we know them from npm and pip. Managing packages can be done with vpm, the package manager for V.

Something else the website claims is the following:

Compiles themselves in <1s with zero dependencies.

The question is of course: is this true? Much has been checked and said about this statement, but this is the piece of terminal output Alexander posted:

unzip &&amp; cd v
./v -o ./v2 v.v # warm up
time ./v -fast -o ./v2 v.v
0.06s user 0.03s system 97% cpu 0.094 total
./v2 -o v3 v.v # make sure that V can still build itself

He also promises:

By January 2020 it should drop to 0.06 seconds.

What he’s basing this on is as yet unclear. He does not always respond in detail to substantive questions, nor does he always achieve the goals he sets for himself.

For example, the first stable version was due to be released in December 2019, but in the meantime both the website and Github have been updated to January 2020. Although that’s not too bad, it’s not the first time either.

The language itself has a lot of problems. For example, this is what the website has to say about memory usage:

There’s no garbage collection or reference counting. V cleans everything up during compilation. If your V program compiles, it’s guaranteed that it’s going to be leak free.

Next, on September 3, an issue is created because the example that V himself gives is leaking memory. There Alexander says he will solve the problem within a week. Even though the original author requested on an update two weeks later, this issue was never addressed. I’ve tested this problem, and it’s still in effect.

Furthermore, at the time of writing, the playground is not working (again). Earlier it was taken offline, because it was hacked.

There are also a lot of things that work well, you know. For example, hot code reloading works well in principle and translating C to V also seems to work reasonably well, if we look at the example provided.

However, the question is whether the language is currently good enough to justify Alexander earning $915 a month with it.

The beauty of creative problem solving

I read about a question that was given to a programmer in an Oracle Interview. I hope he did not get the job, because he simply posted his question on Stack Overflow, but the question itself, looked like a very interesting one.

How would you divide a number by 3 without using *, /, +, -, %, operators?

The question, as given on Stack Overflow.

Think about this question for a while. Perhaps your favourite programming language has a built in solution. Well, C does, so that would make the job as easy as using div:

The div() function computes the value numerator/denominator and returns the quotient and remainder in a structure named div_t that contains two integer members (in unspecified order) named quot and rem.

man page of div

This is, of course, the simplest solution available. If your interviewer is trying to look at your knowledge of the language, this would be a fit solution too. I do hope however, that you won’t meet many interviewers who are looking for solutions like these.

It is more interesting to see what you actually know about algorithms and creative problem solving. That’s why someone else responded with this piece of brilliant code:

#include <stdio.h>
#include <stdlib.h>

int main()
    FILE * fp=fopen("temp.dat","w+b");
    int number=12346;
    int divisor=3;
    char * buf = calloc(number,1);
    int result=fread(buf,divisor,number,fp);
    printf("%d / %d = %d", number, divisor, result);
    return 0;

This actually writes 123456 bytes to a file, which can be of course, any number you are trying to check. After that, it reads chunks of 3 bytes each, and returns the amount of times it was able to read a chunk. Therefore, it divides the original number by 3.

Of course, this is a horrible solution, but that’s fine, according to the one who posted the code, because it fits the question.

Let’s look at another creative piece of code:

#include <stdio.h>

int main() {
  int dividend = -42, divisor = 5, quotient, remainder;

  __asm__ ( "cdq; idivl %%ebx;"
          : "=a" (quotient), "=d" (remainder)
          : "a"  (dividend), "b"  (divisor)
          : );

  printf("%i / %i = %i, remainder: %i\n", dividend, divisor, quotient, remainder);
  return 0;

This one is creative enough to use another language into C. He decided to use assembly to solve this problem, because even assembly has division instructions built in.

An even better solution came from someone who suggested to use the Setun computer. This was a computer from Moscow that used a ternary system instead of a binary one. This allows you to do one right shift to divide a number by 3.

Obviously, the answer would be to use left and right bit shifting to replace the + and - operators, of course:

// replaces the + operator
int add(int x, int y)
    while (x) {
        int t = (x & y) << 1;
        y ^= x;
        x = t;
    return y;

int divideby3(int num)
    int sum = 0;
    while (num > 3) {
        sum = add(num >> 2, sum);
        num = add(num >> 2, num & 3);
    if (num == 3)
        sum = add(sum, 1);
    return sum; 

But if that is too complicated for you, and you only need a demo, you can always try this:

if (number == 0) return 0;
if (number == 1) return 0;
if (number == 2) return 0;
if (number == 3) return 1;
if (number == 4) return 1;
if (number == 5) return 1;
if (number == 6) return 2;

Syntactic sugar in C: accessing arrays

Arrays in C are very easy to use, and that’s mostly because of the implementation behind the scenes. One of the things that makes this extremely clear, is the following line of code:

a[10] == 10[a]

This is always true, because C uses what is called syntactic sugar. This isn’t a real concept, but rather a name for syntax that makes a programming language sweeter to humans. This expression was coined for the first time by the computer scientist Peter John Landin, to express easy syntax to make programming easier.

Not everyone likes the term syntactic sugar. One of them is Jen Chan, who wrote a shitpost about it, calling almost everything in a programming language sugar. Perhaps he is right about that, but there are a few things that clearly are sweeter than others.

The best example in C is without a doubt a[10] == 10[a]. This can be tested with simple code like this:

int a[20];
if (a[10] == 10[a])
	printf("These are equal!\n");

This will print These are equal!. The reason for this is fairly simple: this syntax is only meant to hide the real syntax for accessing:

a[10] = *(a + 10)

Sadly, all good things must have a downside. The downside of this sugar, is that the compiler is unable to validate the left hand side of this expression. Because of this, this is also an option:

10[a] = *(10 + a)

Thankfully, that does not matter, because the operation is commutative. That means that the order of addition is not relevant to the output.

C, what the fuck??!

What do you think that the value of a will be here?

int a = 0;
// What will be the value of a????/

You probably know that it won’t be 1, but there is a big chance that you only know that because I asked this question this way.

a will actually not change, and that is because a++; will never be run. This is because of the comment above. There is something special about this line. Before we jump into that, let’s look at another example:

!didIMakeAMistake() ??!??! CIsWrongHere();

This actually compiles, which is already impressive on its own. The question is, however, what the fuck does this do?

To understand this, I have to admit one thing: I have to pass -trigraphs to a modern version of gcc before this actually works. Trigraphs are special combinations of characters that were invented because of a problem in C: it uses 9 characters that are not in the ISO/IEC 646 Invariant character set. That are these characters:

Image: Wikipedia

Who uses C on a regular basis, should be able to figure out which 9 characters are missing from here. Those are the following:

 # \ ^ [ ] | { } ~

The table in the image above is meant to be clarifying, but we discover that this table might be confusing. That is because the characters that are missing, can all be found in the table above. You should note however, that they are all grayed out. That is because they are national code points, and therefore not an international rule.

This could become very interesting. Let’s look at this simple line for example:

{ a[i] = '\n'; }

This would be written like this by a Swedish programmer:

ä aÄiÜ = 'Ön'; ü

This is because they would use different characters for the national code points, than an American programmer would use for example.

The ANSI C committee of course recognized this problem and therefore, they decided to introduce the trigraphs. That are nine combinations of characters that were meant to replace the non-standard characters.

Image: Wikipedia

Of course, this isn’t a beautiful solution, but it should do the trick.

Now, with this knowledge, let’s look at the lines that we started with. The latter is the easier one:

!didIMakeAMistake() ??!??! CIsWrongHere();

If we look at the table above, we see that ??! should be replaced with |. Therefore, this line actually says:

!didIMakeAMistake() || CIsWrongHere();

If you understand how short-circuit evaluation works, you can understand that this will result in the following:

if (didIMakeAMistake()) 

The other example is actually more interesting, and a good reason to be cautious with trigraphs:

int a = 0;
// What will be the value of a????/

Earlier, I already explained that a will be 0, because a++; is never executed.

A trigraph is only a trigraph when the ??s are followed by one of the nine string literals. So in this case, the C preprocessor will replace the code above with the following:

int a = 0;
// What will be the value of a??\

This \ actually escapes the newline, which eventually results in the following:

int a = 0;
// What will be the value of a??a++;

And this is why a++; was never executed.

I would like to end with a note from the committee itself:

The Committee makes no claims that a program written using trigraphs looks attractive. As a matter of style, it may be wise to surround trigraphs with white space, so that they stand out better in program text. Some users may wish to define preprocessing macros for some or all of the trigraph sequences.

Rationale for International Standard Programming Languages C (

A function to sleep a 1000 years: explained

I encountered a code challenge that asked for a sleep function that sleeps a 1000 years. The current functions use an integer to declare the amount of seconds, but 232 is only around a 100 years long.

A smart guy posted this interesting line of C code:


This works fairly correctly, surprisingly. Let’s look further into it!

First, we’ll dissect the code into more readable code:

f() {
	--i && f(sleep(7));

The first line creates a signed integer, called i. According to the C99 standard, section, it will be initialized as 0:

If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate. If an object that has static storage duration is not initialized explicitly, then:

— if it has pointer type, it is initialized to a null pointer;
— if it has arithmetic type, it is initialized to (positive or unsigned) zero;
— if it is an aggregate, every member is initialized (recursively) according to these rules;
— if it is a union, the first named member is initialized (recursively) according to these rules.

Section tells us that we have to define a declaration specifier. Therefore, i would have to become int i. However, in C89, this was not yet a rule. This is what the rationale of C99 tells us about that:

A new feature of C99: In C89, all type specifiers could be omitted from the declaration specifiers in a declaration. In such a case int was implied. The Committee decided that the inherent danger of this feature outweighed its convenience, and so it was removed. The effect is to guarantee the production of a diagnostic that will catch an additional category of programming errors. After issuing the diagnostic, an implementation may choose to assume an implicit int and continue to translate the program in order to support existing source code that exploits this feature.

Now, we know that i would have been an int, if we use C89 rules. gcc will not give us an error if we try to do this, but just give us a warning:

warning: type defaults to ‘int’ in declaration of ‘i’ [-Wimplicit-int]

According to section, integers are arithmetic types. This, in combination with the second rule, makes that i will now be 0.

Then, the function f() is declared. This function takes no parameters and gets the default return type. This is also an int, because of the exact same rule as quoted above.

So, now we have an int called i and a function with return type int called f(). Let’s look at the contents of f()!

--i && f(sleep(7));

You have to understand that --i means that 1 will be substracted from i, before it is being evaluated. This means that we start with -1 in i.

The second part is actually more interesting. f() is called recursively, but with a parameter! Let’s look at another example that I wrote:

#include <stdio.h>

f() {
	printf("Bye world!\n");

int main(int argc, char const *argv[])
	f(printf("Hello world!\n"));
	return 0;

This actually outputs the following:

Hello world!
Bye world!

Apparently, we can still pass things to our function. They will be executed. If you want to avoid this, you will have to give void as the parameter type. So the following would not have worked:

f(void) {
	printf("Bye world!\n");

Now, we know why the recursive function works. So, when does it stop? According to the author, it stops at approximately a thousand years. He tells us it will run for around 952.69 years.

Let’s look at when the function technically stops. To start with this, you have to know that every number but 0, is true. Just looking at the function does not help a lot. There is not even a return value! For this, you have to be familiar with short-circuit operators. The following means that f(sleep(7))will only be executed, if --iis true. This is always the case, except for i == 0. This means that f(sleep(7)) will be run until i is 0:

--i && f(sleep(7));

So, when will i be 0? Well, i is a signed integer, which has a size of 32 bits. That means that i has a minimum value of -(2^31), which is -2147483648, and a maximum value of 2^31, thus 2147483648. We will go from -1 to -2147483648 and then we will flip to 2147483648. We will see 2^32 = 4294967296 values for i. -1though, because 0 is not an option. 0 would mean that f(sleep(7)) would not be run, and that’s the end of our f().

So, sleep(7) will be executed 4294967295 times. Let’s calculate the amount of years that this will run.

The amount of seconds: 4294967295 * 7 = 30064771065
The amount of hours: 30064771065 / 3600 = 8351325.3
The amount of days: 8351325.3 / 24 = 347971.9
The amount of years: 347971.9 / 365.25 = 952.7

So this code will indeed run for a thousand years, with a margin of ten percent.

With this, we have proven that this beautiful line of code is correct!

The right tool for the job: designing schematics

Word in advance: I have made a few mistakes in the designs you are about to see. Some are intentional, some are not. Always check the datasheet before wiring up something and use some common sense.

If you develop prototypes from time to time, you may have designed schematics. A lot of people start with Fritzing, because it’s very easy to start with Fritzing.

My opinion about Fritzing’s earnings model is known thanks to my previous post, but also the technique of Fritzing is not ideal. This is not so much because Fritzing doesn’t work well, because it does, but because it doesn’t teach you the right techniques.

Getting started with our prototype in Fritzing

This is how the default starts in breadboard mode. This allows you to design with visual elements, schematics, as if you were looking at your prototype. That looks like this, for example:

Image: Our original design in Fritzing on a breadboard

This is still relatively easy to use. It doesn’t look very neat, but it’s easy to build on this drawing. However, the problem is already becoming visible. Imagine if we were to add five more motors to our robot:

Image: Version 2 of our schematics

This way of drawing clearly doesn’t work. The large parts take up far too much space and the connections have to be drawn far too close to each other. As a result, the whole thing becomes very messy and unreadable. The result is that you quickly make mistakes when reproducing these schematics.

This is still a very simple prototype: an Arduino that controls six engines via Bluetooth. There are no sensors, resistors, capacitors, LEDs, buzzers, converters, et cetera.

Designing schematics based on breadboard design

Therefore we stop with the “breadboard view” and switch to the second option within Fritzing, namely “schematics”. This of course sounds much more like what we want to make.

Image: Schematics view of our current project

This also looks disastrous. That is logical, as we have not yet started to connect and clean up parts. Fortunately, Fritzing has a tool for us! Before we can use it, we place the parts the way we want them.

Image: Schematics view after replacing the parts

Now we can use Fritzing’s famous tool: autoroute. This tries to automatically make the connections of the components (based on our breadboard design), so that we have a good schematics view. The result is as follows:

Autorouting our schematics

Image: Useless autorouting

As you can see, only five of the twelve connections are actually connected. The other connections were not made, because Fritzing didn’t succeed in doing so within a hundred attempts.

Originally I thought this was the case because Fritzing doesn’t want to draw lines through other lines, but this scheme is also proof that this is not the case.

I also noticed that in the breadboard view I accidentally connected the GND directly to the VCC. Such a mistake was relatively easy to make in the breadboard view, while in the schematics this would not happen very quickly. Of course I solved this immediately, after which I ran the autoroute again. At that moment everything is done again, and this work of art is created:

Image: A horrible result of autorouting

Excuse my words, but: What the fuck is going on here? I clicked on the autoroute a thousand more times out of amazement and it never happened again, so I assume this was a bug.

I was actually secretly pleased to see that there were more connections now than before, but every autoroute after this bug gave the same disappointing result:

Image: The result after autorouting again

Unfortunately. We haven’t made any progress yet. If we try to solve this neatly by hand, we end up with something like this:

Image: The result after routing by hand

After I first had to remove dozens of ratsnest lines, because there was such a line between each VCC and GND, I drew the lines myself. Of course this doesn’t work very well, because a lot of lines have to be drawn over each other and this makes it very difficult to get a clear overview.

It is clear that we need another solution. It doesn’t seem like it’s possible to make everything clear in one drawing. Maybe we should split it up into several drawings.

PCB design

Unfortunately, Fritzing doesn’t have the support to do that in a good way. Before I switch to KiCad to show how to do it, I want to show what Fritzing does with PCB’s: the most important part. In the end, you want to be able to convert any good prototype into a PCB.

Image: The PCB of our project

After I open the PCB view and manually place everything in a convenient place on my board, I click on autoroute. I expect Fritzing to try to use as few layers as possible and make sure a working PCB comes out.

Unfortunately, only the latter turns out to be true. Fritzing knows how to successfully connect everything, but that’s all there is to it. It doesn’t matter if it doesn’t work, but don’t offer it then.

A better alternative

Let’s move on to a solution that will hopefully work better. We’re going to split our design into several parts, each of which will be explained separately. This will keep the whole thing clear to work with.

We’ll get on with KiCad. This is an open source EDA that actually does work well. (KiCad, if you are reading this: your SSL certificate is not set correctly)

Create your first schematics

Let’s start all over again. Let’s learn from what we did wrong with the design in Fritzing. There, we tried to map out the whole system at once, and we saw that it didn’t even work with these small applications. We start by bringing our parts all into our project.

Image: All of our parts in one schematics

For some reason, this is already looking better, even though we haven’t done anything yet. In my opinion, KiCad feels much more professional than Fritzing.

Please note that I replaced the HC-05 here with a more serious Bluetooth module. The HC-05 is very nice when you are experimenting, but you don’t want to use it in your final product. So, in the prototyping process, start working with the module you want to use, so that you know if it works with your application.

Let’s make some standard connections, and indicate the connections between the elements with labels. KiCad natively supports this and this makes working with these schematics much clearer.

Image: All of our parts with connections on one page

Now all our parts are on one page, together with the connections between all the parts. If we now want to expand or clarify parts, it can be done relatively easily. For example, we can add an LED to make it clear when the Bluetooth module is activated and we can make the current in the circuit clear. So I want this to work on a 12V battery and I want to give the motors 6V of that as well.

Image: Schematics with added information

This is still far from enough to make a good PCB, but it gives a good picture of the difference in readability between Fritzing and KiCad. This is still far from enough to make a good PCB, but it gives a good picture of the difference in readability between Fritzing and KiCad.

On making PCBs in KiCad, I’ll go into it later. I do hope that you have gotten a picture of designing in KiCad and I would strongly advise you to take a look at it. Once you’ve started, you’ll never want to go back to Fritzing.

How Fritzing is killing itself

It is logical that Open Source organizations also like to earn money. Free software does not mean that there is no money to be made with it. After all, these developers must also be able to feed their families.

Strange methods of making money from open source software have been seen before. For example, OpenCollective is a collective that tries to support open source. One way is to persuade users to advertise by means of a message in the terminal.

Image: ZDNet

This is an innocent way, of course. Funding had another approach. A developer named Feross Aboukhadijeh said that he had already spent 3,000 unpaid hours developing open source software and he wanted to see something in return. An understandable point of view.

To achieve this, he started with Funding, an experiment in which he placed advertisements in the terminals of the users of his software.

Image: William Hilton

Of course, this caused a lot of commotion in the open source software world. A developer even went so far as to build an adblocker for the terminal. The turmoil was of course exactly what he wanted. He raised an important issue: how can we support the developers of the open source software?

After a few days Feross thought it was enough and he stopped the project. You can read his explanation on his blog.

Donations are still the best accepted way to make money from open source software. Unfortunately, donations are not made just like that, which is why creative ways need to be devised. For example, you can use donations to obtain extra content, “buy someone a coffee”, etc.

Many companies try to encourage you to donate, either by clearly displaying the button or by initiatives such as those of OpenCollective. One of the companies that strongly encourages donations is Fritzing, but they do so very misleadingly.

If you click on “Download”, you will not receive the download file, but will be automatically redirected to Paypal. You could then cancel the payment via Paypal to be sent back to the page, but then the Fritzing download still doesn’t load.

If you dive into the code, you’ll soon find out why. Fritzing has deliberately made sure that users who pay in this confusion, will see a different page than other users. This is the code of this form:

As you can see, the parameters “return” and “cancel_return” have two different values. This nonsense from Fritzing makes it very difficult to download this software in a normal way.

As a result, there will undoubtedly be more people looking at the alternatives to Fritzing. As the alternatives are very good, the number of users will gradually decrease. Furthermore, this will clearly reduce sympathy for the developers, which will undoubtedly reduce the number of donations in the long term.

Are you annoyed about this behaviour, but do you need software to draw your schematics? Take a look at one of the more than 50 alternatives.

Why Arduinos are not suited for professional education

At our university, we teach students the basics of microcontrollers by working with Arduinos. These are extremely easy to use, and therefore offer a simple introduction to the use of microcontrollers. You can start setting up your project and writing code within minutes. This is why working with an Arduino gives you a lot of satisfaction.

However, this advantage has a number of major drawbacks.

The biggest disadvantage is that you don’t learn to work with individual parts. If you don’t work with product development, that’s okay. However, we do this in computer science and engineering, and that’s why it’s important that you learn that.

If we look at the datasheet of the Arduino Uno, we see how complex it works under the hood.

Image: The datasheet of the Arduino UNO. This can be found here.

If you have worked with the Arduino Uno before, then it is recommended to have a detailed look at this datasheet. (Although this one is actually a mess. It might be easier to look at this datasheet of the Arduino Due).

You can use the Arduino without knowing how an AD converter works, or without knowing how the SPI communication to the ADC works. One risk of this, is underestimating how difficult this can be.

When you finally start developing your own product, you’ll notice that it’s usually not that easy to connect these kinds of things yourself.

Image: This is a photo that I made during the debugging of the SPI communication with an AD converter. As you can see, the communication failed due to a wrong timing.

If you’ve only worked with an Arduino, this is a pretty complicated experience. However, this is the truth for all students who have only worked with Arduinos at university. When I started this project, I only had experience with Arduinos. For me this was much more instructive than anything I had ever done with an Arduino.

If you really want to be able to design products on this scale in the end, it’s better to ignore the Arduino and just start developing with real parts. Otherwise, you’ll have to learn to rebuild after your prototype. If you are just a hobbyist and want to develop small prototypes, I would definitely stay with Arduinos.

Let’s blow it up!

This project has been cancelled, due to a lack of interest from the students.

Hot-air balloons are a magical phenomenon to see. They achieve a deep human fantasy and they usually have beautiful colors. But really nice about these balloons, is the way they fly. They don’t use a motor and they fly very quietly. The only thing that’s unfortunate about a hot air balloon is that they need fuel to fly.

In June 2013, Google started testing the first thirty balloons of Project Loon. These balloons fly at an altitude of about 20 kilometres and are therefore almost unaffected by weather conditions or turbulence. They are used to deliver internet to countries that currently have poor or no coverage.

These balloons fly through helium. Each balloon is equipped with 12 helium tanks, which can be used to determine how fast a balloon has to descend or rise. The disadvantage of this is that the balloon has to be lowered when the tanks are empty.

If you don’t let the helium escape, the balloons don’t have to be brought to the ground anymore. This is only necessary if there is a problem with the balloon.

That’s why we’re going to build a new balloon that can do this. We do this by not adjusting the amount of helium, but the amount of air in the balloon. This changes the total density of the balloon and allows us to go up and down.


There are many purposes that you can think of for a balloon flying at 20 kilometers above your head. That’s why we want to open the balloon for research. We want to make it possible for researchers, students and companies to use the balloon themselves.

There is, however, a purpose that I would like to investigate myself. That’s use for real time communication. We can use this to control robots at relatively large bandwidths over long distances, for example.

Technical challenges

There are several technical challenges that we expect to encounter. However, this is a small part of the challenges that we are really going to face. In practice, there will be many more problems that we cannot yet predict.

Ascending and descending

One of these problems is that the airtightness of the air around the balloon is as high as that of the balloon itself. This means that leaving extra air in the balloon does not increase the density of the balloon. The result is that we can’t lower the balloon.

That’s why we need to build a small compressor that we can use to compress the air. This increases the total density of the balloon and allows us to descend.

Of course, ascending is a lot easier. To do this, we simply let the air run out of the balloon again, so that the density decreases.

Ground communication

The balloon must be able to communicate with the people on the ground. This allows us to control the balloon, the balloon can get information (e.g. about the weather forecasts) and people can use the balloon for research.

However, communicating over these long distances is extremely challenging. We know it can be done, otherwise satellites wouldn’t be a thing, but that doesn’t suddenly make it very easy. We do have the advantage that we have almost no obstacles, as opposed to a situation in a densely populated city.

Techniques such as LoRa already achieve this kind of distances, so they should be relatively easy to implement. However, we want more bandwidth, so we need to explore other possibilities as well.


Another challenge facing us is that of power supply. We use equipment that must not fall out. We can use wind energy for this, but the wind power is very low at that altitude. An advantage we do have is that the balloon is above the clouds, and therefore has all day sun power. Looking at project Loon, this should be enough.

However, we still need to test and investigate this properly before we can use it. We use more energy than Google’s project, because we will probably have to use a compressor.


We should also be able to steer the balloon. A normal hot air balloon can’t be steered just like that, but this balloon has information about the air currents and can descend and ascend for miles and use those currents in that way.

This means that the balloon always has to have accurate information and that it has to start the rise and descend on time. The steering can then be used to change the location, or to maintain a fixed location.


The balloon must be as light as possible in order to reach great heights. However, it must be equipped with equipment. This means that a lot of profit can be made based on the choice of materials.

With an area of about four thousand square meters, enormous savings can be made. If we made this balloon out of paper, it would weigh 320 kilograms.

Another problem is that there is hardly any protection against UV in the atmosphere and that there are enormous temperature fluctuations there. It can be as low as -90 degrees there.

The choice of material must take into account the conditions in the atmosphere and the intended weight targets.

How we are going to get there

This project will be carried out in full with students from the Rotterdam University of Applied Sciences. We will plan the balloon ourselves, execute it ourselves and manage it ourselves. We will do this with multidisciplinary teams, consisting of students from all study programmes. These are students who are looking for extra challenges.

In order to obtain funding, we are going to look for companies and institutions involved in research in the fields of aeronautics, telecommunications and robots.