Avian’s Blog

Last week I attended a three day course at Aalborg university on cognitive radio. Cognitive radio research is the reason behind the development of spectrum sensing hardware for VESNA. Since I haven't encountered this field before joining the Jožef Stefan Institute I decided to go to this course to get some background and to better understand what is the state of the art in radio communications.

It turns out cognitive radio means many things to many people. In the most broad sense it's an autonomous device that can optimally use the electromagnetic spectrum for communication by being aware and capable of adapting to its environment. This idea is then developed by some to an extreme, where the radio contains strong artificial intelligence that has perfect knowledge of its surroundings and is capable of predicting future events and the wishes of the user. For instance a mobile phone that learns your daily commute and plans ahead in cooperation with base stations on how to optimally use the cells on your way to the office. The personal digital assistant idea is strongly coupled with this and sometimes cognitive radio device is even described as being capable of communicating with the user through speech and natural language.

But such visions I only see as a thought experiment, as I can see no indications that such machines will be possible anytime soon. On the other hand however there is a more pragmatic approach to cognitive radio that concerns itself mostly with how to more efficiently use the limited amount of usable frequencies and overcome the spectrum crunch. This research covers for instance new ways to dynamically allocate frequency bands beyond very static licensing regulation that is in use now, how to enable secondary use of frequencies that are unused by people that initially licensed it for exclusive use and how to decentralize frequency allocation. It is also tightly connected to software defined radio technology that enables this kind of quick reconfigurability of radio devices.

Besides lectures that covered information theory, networks, game theory, machine learning, software radio and economics we also had a practical demonstration of the ASGARD software radio platform. Guys from Aalborg university demonstrated three pairs of USRP devices that were dynamically and autonomously selecting radio channels in a shared 5 GHz ISM frequency band so that the interference between them was minimized.

The course concluded with a poster session where I also presented the spectrum sensing expansion for VESNA with the following poster (PDF version).

In a month or so, we will be deploying around 50 VESNAs to a wireless sensor network in one of Slovenian smaller cities. VESNA boards, sensors and other electronics will be mounted in white plastic boxes and fixed on top of light poles alongside public streets. It will look somewhat similar to this temporary mock-up we set up in the Jožef Stefan Institute courtyard the other day:

While these boxes are certified to be resistant to the elements and provide adequate shielding for sensitive electronics within, one question remains open. In the summer the air temperature can reach 40°C and with the boxes exposed to direct sunlight the inside could get uncomfortably warm. The ARM microprocessor on the VESNA core module only dissipates around 100 mW at worst, however my UHF spectrum sensing receiver, which is also going to be inside the box, has to shed close to 1.5 W of heat while not heating up over 120°C. If the air inside the box is at 80°C from the sun alone, this requirement might require some extra measures to meet.

Unfortunately, there are no exact specifications on how the boxes behave in this respect. To get a rough estimate of the situation I defined the following thermal resistance model of the box and performed some experiments in an attempt to determine some limiting values on the environment my electronics will have to endure.

Here, T_a is the environment air temperature, T_b is the temperature of the box itself and T_c is the temperature of the air inside the box.

First experiment was to determine the contribution of the sun (P_sun). I put a VESNA node running on batteries inside the box which was mounted in a sunny position on a south-facing balcony. VESNA was running a temperature logging application which recorded the ambient temperature every few minutes.

In the ten days the experiment was running we had 8 sunny days. If you look at the highest peak, the temperature inside the box was somewhere in the vicinity of 55°C, while the air temperature outside the box (not drawn on the graph) was around 25°C. So, in early May the sun already heated up this white object to 30 K above the ambient.

The second experiment was to determine the contribution of the UHF scanner's power dissipation on internal air temperature. I placed a ceramic resistor inside the box and set up a lab power supply so that 2 W were dissipated on the heater (P_c). This time I used two battery-powered VESNA nodes to log the air temperature inside and outside the box.

While this experiment was performed inside and in the shade, the daylight still somewhat affected the ambient temperatures by heating up the room, so the thermometer outside the box recorded a slight increase during the day. During the day I also turned on the heater (I didn't want to leave it running over the night), which resulted in around 5 K increase in the internal air temperature.

If you look at the model I pictured above, these measurements are unfortunately still inadequate to determine both thermal resistances. From the second experiment you can calculate that R_ab + R_bc is around 2.5 K/W, but to get individual resistances you would need to know the thermal input from the sun, which depends on the unknown albedo of the box.

However, at this point this detail is irrelevant. From the first experiment in know that the sun will contribute around 30 K and from the second experiment I know that internal power dissipation with add another 5 K above the ambient. If I take the worst case air temperatures outside to be 40°C, this adds up to 75°C inside the box. From this I can now calculate the maximum allowed thermal resistance between the tuner IC's silicon and the inside ambient and from that choose the appropriate cooling solution.

Spectrum sensing is a phrase that is being used a lot at my current job. I have mentioned it before in relation to the experiments in Munich back in February. Let me explain what it means and why it is important.

One possible way of enhancing radio communications in the future is making the receivers and transmitters aware of their environment and capable of adjusting the radio link accordingly. For instance, they could intelligently avoid uncontrollable interference at a specific frequency, cooperatively share a limited part of the spectrum or use frequencies that experience the least fading in the current location. This idea usually falls under the somewhat awkward umbrella of cognitive radio (which sometimes also includes gratuitous applications of strong artificial intelligence and other things not directly related to radio communications).

So broadly speaking, spectrum sensing means measuring the properties of the radio-frequency part of the electromagnetic radiation propagating in an area of interest. In the current real-life usage scenarios you are usually interested in knowing whether there are other third-party transmitters operating in the same part of the spectrum as you. This might be because you don't want them to interfere with your connection. But equally important are cases where you don't want to interfere with them. For instance, recently frequencies where formerly only big, licensed TV operators were allowed to transmit are being opened to general public and consumer devices, with the added catch that these devices must make sure their transmissions will not interfere with licensed users.

The latter use case is especially problematic. If you are only interested in the effect of any third-party transmitters on your radio link, measuring their signal strength at your own antenna is sufficient as the location of the measurement is the same as the point of interest. However electromagnetic field theory says that in general case just by doing measurements at your antenna you can't infer how your transmissions will affect a link between two distant devices in your neighborhood. Empirical rules have been developed though that work in common circumstances with high enough reliability, but they are necessarily hard to satisfy in practice as they require very sensitive spectrum sensing receivers.

How do you detect a transmission? The most simple method is called energy detection - you are simply detecting the received signal level on the antenna and declare a transmission has been detected if the level is high enough above the noise level. Energy detectors work quite similar to classical swept-tuned spectrum analyzers except that they are much simpler and cheaper. Usually an integrated silicon tuner is used. For example Texas Instruments CC2500 is a popular choice for the 2.4 GHz ISM band.

Simple energy detection has one big problem though: you can only detect signals that are significantly above the noise level. For example, in TV band white-spaces FCC requires detection threshold of -114 dBm. At this levels of sensitivity even the unavoidable thermal noise presents major problems. This can be solved though with more advanced methods of detections. For instance, repeating patterns can be still detected when the signal to noise level falls well below unity. And most real-world transmissions include some repetition, so cyclostationary detection doesn't hurt generality much.

In conclusion, to add some practice to all of this theory, here is a spectrum sensing receiver I developed at the Jožef Stefan Institute during the past months. It fits on a VESNA node and is built around the TDA18219HN silicon tuner from NXP. This single chip includes most of the radio-frequency circuitry as well as the intermediate frequency part, a lot of which can be reconfigured through an I²C interface. It's also cheap enough that many such receivers can be used in a sensor network.

The receiver can do energy detection on the VHF and UHF bands with receive bandwidths from 1.7 MHz and 9 MHz and is specifically designed for research into TV white-spaces reuse. In theory it should also be capable of cyclostationary detection using VESNA's CPU, although that has yet to be tested in practice. Here you can see a spectrogram of the UHF TV band that was recorded with it. The central Slovenian DVB-T multiplex can be clearly seen at 562 MHz.

Making this hardware was a lot of fun and I might write a bit more about it in a separate post. There is some ambiguity about the amount of information I can disclose about it though as the documentation for the tuner chip and reference implementation came with some crazy restrictive fine print. However you can already dig through the source code of VESNA spectrum sensing application and my spectrum analyzer Python script (which has been recently updated to work with a properly equipped VESNA in addition to Fun Cube Dongle).

VESNA is using STM32F1 family of ARM Cortex M3 microcontrollers from ST Microelectronics. These chips have a real-time clock peripheral built-in that can be used to keep track of time and date. In VESNA it uses an external 32.768 kHz tuning-fork quartz oscillator and is running even when the CPU has been power-down to conserve power.

The clock can be used in a number of ways: it can trigger periodic (e.g. system tick) and non-periodic (e.g. alarm) interrupts or you can simply read its value when you need a timestamp in your code. The latter use might appear to be the simplest, but can be especially problematic as the peripheral stores time in no less than 4 16-bit registers spread out over 16 bytes of address space. They can not be read atomically which can lead to subtle race condition bugs where the clock appears to be wrong for duration of one tick. I recently spent quite some time debugging such a bug and would like to share my findings (for best experience, open up reference manual at chapter 18: Real-time clock).

RTC keeps time in two internal registers: the prescaler RTC_DIV counts down periods of the RTC oscillator. Once it reaches zero it is reset and the counter RTC_CNT register gets incremented. These two registers aren't directly accessible - instead each of them has two 16-bit shadow registers on a CPU-accessible bus APB1 that get periodically updated with fresh values synchronously to the CPU bus clock. These are called RTC_DIVH, RTC_DIVL, RTC_CNTH and RTC_CNTL in the documentation.

VESNA uses what is likely the most common configuration: the prescaler is set so that it wraps around each 32768 cycles, making RTC_CNT count seconds while RTC_DIV can be used to keep fractional seconds with around 30 μs precision.

There are two important things to watch out:

• As mentioned before, you can't read the four values atomically. This means that between reading say RTC_CNTH and RTC_DIVL the values might have changed. In the best case this means you get a value off by one RTC tick. In the worst case, lower registers just overflowed into a RTC_CNTH increment and the value you read is off by 18 hours.
• RTC_CNT only gets incremented one clock tick after RTV_DIV gets reset.

First, you might be tempted to make the four bus reads atomic by synchronizing the reads with the shadow register update. There is a RTC_CRL_RSF registers synchronized flag that gets set by hardware each time the shadow registers are updated. I have tried this by thinking that if I read the values immediately after it gets set the values won't change for another RTC clock period (which should be plenty, considering RTC runs on the order of 10 kHz and the CPU on the order of 10 MHz). This however does not work reliably for some reason - the documentation only says that this works for the first update of the register anyway. Such synchronization also slows down the clock read-out function and even makes its run time unpredictable.

The second point is actually documented in the datasheet if you look carefully at the timing diagram in the real-time clock chapter. But it is easy to overlook and I wasted more than one day thinking that observing that behavior is due to some problem in my code. It also makes detecting counter overflow somewhat more complicated.

In the end, I went with code like this:

uint16_t divl1 = RTC_DIVL;
uint16_t cnth1 = RTC_CNTH;
uint16_t cntl1 = RTC_CNTL;

uint16_t divl2 = RTC_DIVL;
uint16_t cnth2 = RTC_CNTH;
uint16_t cntl2 = RTC_CNTL;

uint16_t divl, cnth, cntl;

if(cntl1 != cntl2) {
	/* overflow occurred between reads of cntl, hence it
	 * couldn't have occurred before the first read. */
	divl = divl1;
	cnth = cnth1;
	cntl = cntl1;
} else {
	/* no overflow between reads of cntl, hence the
	 * values between the reads are correct */
	divl = divl2;
	cnth = cnth2;
	cntl = cntl2;
}

/* CNT is incremented one RTCCLK tick after the DIV counter
 * gets reset to 32767, so to correct for that increment 
 * the seconds count if DIV just got reset */
uint32_t sec = (((uint32_t)cnth) << 16 | ((uint32_t)cntl));
if(divl == 32767) sec++;

/*
 *        1000000                   15625
 * usec = ------- * (32767 - div) = ----- * (32767 - div)
 *         32768                     512
 */

uint32_t usec = 15625 * (32767 - ((uint32_t)divl)) / 512;

This code makes two assumptions: that RTC_CNTH is unused (i.e. prescaler divides the oscillator frequency by less than 65536) and that the CPU is fast enough to read the four registers in less than one increment of the counter registers. Note that the latter one can be affected by interrupt service routines, so if you have a slow CPU clock, fast running RTC and/or long-running ISRs it might be necessary to disable interrupts while reading the RTC registers.

A version of this function that would work with any prescaler setting would make a nice addition to libopencm3, but I have yet to come up with one elegant enough to warrant a patch.

Note that currently both libopencm3 with rtc_get_counter_val() and rtc_get_prescale_div_val() and STM's FWLIB with RTC_GetCounter() and RTC_GetDivider() get this wrong. Also they don't support getting both values in a consistent way. There is a discussion about this issue on STM32 forums and the solution given there is functionally identical to mine (though I don't like the potential for a goto-induced infinite loop).

I promise this isn't turning to a series of math rants. But since I have been lately studying spectrum analyzers and similar machinery let me tell you about a small annoyance that has been bothering me in texts and datasheets covering this topic.

Often when discussing noise that has constant power spectral density over a range of frequencies the level of this noise is given in the logarithmic scale in units of decibels per hertz (for instance thermal noise is often said to be -174 dBm/Hz). This is wrong, as it implies that you need to multiply this value by bandwidth (in hertz) to get the power in dBm when in reality you need to add a logarithm of the bandwidth. Of course, everyone dealing with these equations just knows that. Logarithms turn multiplication into addition right? But then you end up with equations where the two sides of the equal sign have different units and that is just plain sloppy writing.

Here's how you properly convert a formula for Johnson-Nyquist noise into logarithmic units:

Apply definition of dBm:

See how the value inside the logarithm has no dimension? The value in the numerator is in units of power and that cancels with the milliwatt in the denominator. If you are doing things correctly there should never be any physical unit inside a logarithm or exponential function.

To split off the bandwidth term, multiply and divide by one hertz.

Note that you still have dimensionless values inside logarithms. There is no need to invent magic multiplication factors "because of milliwatts" or fix the units of the variables in the equation. The division by 1 Hz in the bandwidth part also nicely solves the confusion that happens when you have bandwidth defined in units other than hertz.

So how do you concisely write this value? There is no short notation that I'm aware of that conveys the proper meaning. I would simply write out that noise level is -174 dBm at 1 Hz bandwidth and leave it at that.

Now let the flames come that this is school nonsense and that real engineers with real dead-lines don't do any of this fancy dimensional analysis stuff and that back-of-the-envelope calculations just work since you just know that this here number is in watts and that there is in kilohertz.

Recently the following question has been circling the Internet and also ended up in my inbox a few times. It's yet another one of those silly exercises that ask you to continue a sequence based on a number of examples. They are a pet peeve of mine and I'll explain why I hate them here once and for all instead of replying to everyone that sent a copy my way.

The logic of this specimen is particularly broken, even putting aside the questionable statement about pre-school children being able to solve it in mere minutes. It's obvious that whoever wrote that is not familiar with the meaning of the equals sign, as 8809 isn't equal to 6. So strictly reading, this exercise gives you 21 false statements. From that it can be simply inferred that the author is looking for another false statement, so ??? can be replaced with any number not equal to 2581.

With that out of the way, let's look at what was probably meant with this notation. You are given N=21 pairs of values (x_i, y_i) such that:

And asked to find y_N for a given x_N:

From a purely mathematical standpoint, this problem has an infinite number of solutions. To demonstrate, assume that f is a function that satisfies the condition set above. In that case:

where

also satisfies this condition. Note that g is a function that can have an arbitrary value at x_N and hence this new solution will give a different value of y_N.

Just to make this a little bit more practical, here's an example of a polynomial that goes through N points:

And here is how its graph looks like if you plug in the given 21 values:

At x=2581 it gives the value of around 5.8·10⁷³.

Note that using the formula above and N=22, you can get a polynomial that goes through the required 21 points plus the 22nd that you can choose to your liking.

This is just one example. You could construct functions that meet the requirements from trigonometric or exponential functions in a similar way.

Sure, so this is probably not the solution the author of this question was looking for. You could say that I'm overcomplicating things and that the rule that pre-school children would come up with, based on the shape of the digits the author arbitrary chose to represent these numbers in, is nicer. But there is no such thing as niceness in mathematics (see interesting number paradox).

This is the big difference between mathematics and physics. Our universe has physical laws that for some reason can often be represented in certain mathematical forms. If a liter of water has a mass of one kilogram and two liters a mass of two kilograms it's quite likely that three liters will have a mass of three kilograms and so on. But this is purely based on our experience and beliefs about our environment and not on any purely mathematical basis. Such a prediction, just like the one above and many like it, when stripped of any physical context, does not make any sense.

My dad is an avid model airplane builder and he is currently building a new electrically-propelled glider of his own design. This particular airplane will have styrofoam-core wings and two weekends ago he was trying out a new way of making them.

Such wing profiles are traditionally cut out from blocks of styrofoam with a hot-wire cutter that is pulled by hand over plywood templates. However the width of the cut depends on the speed of the wire as it travels through the material and since you can't manually pull the wire at a perfectly constant speed the wings end up full of little pits and grooves. Of course, nowadays you can get computer controlled cutters that control the hot wire with servos and can cut out any shape with perfect steadiness and without the need for templates.

My dad however went for another approach: he made a purely mechanical device that pulls the wire over the templates with constant speed. The interesting bit here is that the two ends of the wire usually have to travel different lengths through the styrofoam in the same amount of time, depending on the wing taper ratio. He achieved this with an adjustable system of levers, pulleys and ropes that would make for a nice high-school mechanics class demonstration.

The whole thing is powered by gravity and an occasional nudge by hand. In fact, for perfect straight cuts just the weight of the hot-wire cutter is sufficient without additional mechanisms.

As you can see from the (long) video below, it takes one to two minutes to make one cut (and you need several per wing, depending on the number of segments), so it's not the fastest thing around. But it makes up for it with perfectly smooth cuts and if you only make a few wings per year it's perfectly sufficient.

A while ago Gašper gave me this Energycount 3000 kit from Voltcraft for logging household electrical energy usage, with a wish that he would like to access its measurements from a computer. All this time it's been mostly gathering dust on my desk, but last week I've found some time to give it a closer look and made a few discoveries that are worth reporting.

The box contains two sensors that can be connected between a wall socket and a plug and a tiny battery-powered remote control for reading out the data. The short instruction leaflet explains that the sensors broadcast their measurements through radio every 5 seconds. With a push of the SCAN button you can set the remote control into a 6 second listening mode which catches the transmission and displays it on the small LCD screen.

The remote also has some calculation functions, like predicting the next electricity bill, but is otherwise nothing more than a remote display for the sensors, which apparently do all the logging. This makes sense: the remote control is limited by its batteries and as much functionality as possible is pushed to the wall plug where there is abundant power. The radio link is also obviously unidirectional. The sensors transmit their periodic reports and the remote receives them. All user interaction with the sensor is done through a push button on the sensor itself.

To get the data from the sensor it appears that all I would have to do is to eavesdrop on the transmission. Unfortunately, the box says this device operates on the 868 MHz ISM band, meaning that my 433 MHz receiver was useless. I could get a 868 MHz receiver module for it, but I suspected that these devices use something more complicated than on-off keying, so I looked for other possibilities.

Here is how sensors and the remote look from inside:

As you can see each device has two integrated circuits under a blob of epoxy. I'm guessing one is a microcontroller and the other obviously some kind of integrated ISM band transmitter or receiver. In both the sensor and the remote control they are connected with 5 copper traces. Having recently encountered and worked with chips like the CC1101, my first guess was something like that. I figured the five traces would carry a digital bus like SPI or I²C, so I soldered some wires to the tiny traces on the remote (destroying one of the termination capacitors in the process) and hooked it up to a logic analyzer.

Unfortunately, what I saw there didn't look at all like a synchronous transmission. Out of 5 lines, 2 seem not to carry any useful signals (all I saw there were some transients that looked like glitches). The remaining 3 might act as a digital bus immediately after the microcontroller wakes up the radio chip, but otherwise look like some pulse-width modulated signals for the majority of the 6 seconds when the radio is turned on.

This was a sort of a dead-end until I came across chips like the TH81112. These are ISM band receivers that can be used to receive ASK or FSK transmissions, but are much simpler that system-on-chip products like CC1101. They merely contain a tuner, intermediate frequency and a phase detector and therefore rely on the microcontroller or some other logic to do full FSK demodulation. In hindsight, it makes sense for Energycount to use something like this. It's a relatively cheap product and an expensive general-purpose transceiver like the CC1101 would probably be far too expensive for it.

Update: Gašper found a thread that has some interesting insights, particularly regarding the communication between the radio chip and the CPU. It's possible I was looking at the signals at a completely wrong time scale.

But at this point I didn't bother to mess further with the original receiver. I started up GNU Radio and Fun Cube Dongle Pro and tried to catch the transmissions with that. It turns out fishing out the correct channel in the 868 MHz ISM band is a challenge in itself if you're only limited to the 90 kHz bandwidth of the Fun Cube Dongle. But luckily having the transmitter and receiver close by meant that I was able to see the transmission burn through even when the receiver wasn't tuned exactly to the correct frequency. So after some bisection I found the transmission at 868.388 MHz.

The double peaks in the spectrogram gave me more confidence that this is indeed frequency-keying with 20 kHz deviation and with GNU Radio's FM demodulator block the bits in the packets became clearly visible.

Actually, it's impressive how easy software defined radio makes tasks like this. Throwing blocks around in the GNU Radio Companion in a few minutes is something that would otherwise take you weeks with a soldering iron. Next time I'm doing something similar I'll most likely skip the whole logic analyzer part and just skip right to sniffing the radio waves.

To conclude, this demodulated signal is now something that can be piped to the capture process from my AM433 project and it will hopefully produce binary data. But of course, getting useful information from a binary blob is a whole new matter and that will come in a follow-up post.

Last week Eric Smith found a bug in z80dasm, the disassembler for the Zilog Z80 microprocessor I put together a few years ago when I was researching Galaksija's ROM. It turns out a corner case in relative addressing where the offset would wrap around the 16-bit address space boundary of the CPU wasn't handled correctly. For such cases the code would create labels with excessively long names which overflowed some internal fixed-length string buffers, leading to stack corruption.

Hence a new release of z80dasm after almost 4 years. You can download the source tarball from http://www.tablix.org/~avian/z80dasm/.

I also used this opportunity to move the code from my old CVS repository to git, so you can now also clone the repository with:

$ git clone http://www.tablix.org/~avian/git/z80dasm.git

As for binary packages, Eric is packaging z80dasm for Fedora. I've put together updated packages for Debian and will do my best to get them into the Debian Unstable as soon as possible (as Debian is now three releases of z80dasm behind).

One of the more unusual sights at the 28C3 last year in Berlin was a circle of hackers of all ages and genders sitting on the floor around a large flat panel monitor. They were watching a cartoon show with colorful ponies, while behind the screen you could see the dark basement with flags of various groups and hackerspaces hanging from the ceiling and a disarray of electronic devices strewn on tables. Maybe not surprisingly, this gathering also happened to be almost immediately below the no photography sign, which means that I was unable to find any evidence of it.

I have heard about this show now and then in the usual background noise of the web even before the congress. However this encounter made me somewhat curious and, having never actually overgrown watching an occasional cartoon, I decided to see what all this is about. For scientific reasons, of course.

Image by Chromamancer

I am talking about the latest remake of My Little Pony. It's an animated TV series that was created to advertise a line of Hasbro toys for girls, but in a funny turn of events actually got a sizable following of the opposite gender and in another age group. I guess something that would be unlikely to happen without the internet and the pseudo-anonymous discussions it enables.

After watching some of the show, I can say that I can understand to some degree why it has attracted such a broad audience. They say that a sign of good content for children is that it is also worth watching for adults. And in this particular example the latter certainly appears to be true.

You can often read that the show is well drawn and animated. For sure that is one part of the attraction. Remember my thoughts about the Avatar movie? I guess modern artists have become increasingly good at triggering emotional responses in their audience. The combination of human and animal visual traits in a character allows you to trigger more image recognition circuits than what is possible with only a human face. There's actually a word for that: superstimulus and it's quite amusing to see the parallels between songbirds falling for a red stick with white bands and people looking at what would be pretty deformed body shapes in nature.

Another thing that is often mentioned is the lack of cynicism in the show. Not surprisingly for a show that also carries an educational mark, the characters always find out that it's better to work for the greater good than for only your personal benefit. I can certainly see the appeal in this. It's nice to loose yourself in such fantasy after spending day after day in society that is increasingly focused on grabbing as much of the pie for yourself as possible and there isn't much space for laughter, truth, generosity and loyalty.

However, if this is one of the causes for the popularity among grown-ups, it's somewhat ironic if you consider why the show has been created in the first place: to increase profits of a multinational company that turns around billions of dollars each year. And in fact Hasbro has controlled the show from the start, making sure that it features things they can sell as toys.

But if you put these arguments aside, the creators of the show managed to paint a pretty consistent picture of a world where things are operated with hooves and mouths instead of fingers and three races divide their work to cover for each others shortcomings. This has made it possible for fans of the show to build upon it with their own original stories and, not having to stick to the original constraints, some of them are just as, if not more amusing than the original itself. So it's not all in the visual appearance either.

To sum it up, once you survive through the first view of the pink sugary overkill of the brand logo, it's an enjoyable show with memorable songs and a surprising lack of elements that could be described as fitting for a stereotypical little girl. If it makes more people think about their actions from the perspective of broader society, so much better. And if marketing departments can miss their target audience that much, I guess that's also a sign to be optimistic and might mean we have some time left before they figure out how to control our every thought.