Timing the flashes, the end for now

A false issue

In our previous post, Vlaya and I said that when a full rotation completion triggers an interrupt simultaneously with a flash interrupt, the order in which the HAL API IRQ Handler checks and handles each source of the interruption (both share the same IRQ line to the processor, and they set flags that the IRQ Handler must inspect to determine what happened) made it so that the rotation was handled first, delaying the flash handling.

To solve this, we decided to check the flags for the flash directly in the rotation callback, and trigger the flash before handling the rotation completion if they were set.… Read more

Timing the flashes, Act 3


  • Yesterday the latency and jitter of the SPI “FLASH”  frames was a little high: around 80µs for the jitter
  • We had originally planned to solve this by bypassing the interrupts with a DMA request, but sadly this turned out to be unfeasible.
  • Investigating ways to reduce the interruption jitter revealed two main factors:
    • The interrupt priority was too low
    • A scheduled flash and a capture at the same time would cause the flash to be handled after the capture event.
  • Fixing this reduced the jitter from 80µs to 2.5µs

Unfeasible DMA

Yesterday Vlaya and I ended our post with a plan to use a DMA request line (triggered by a comparison match on our Timer channel) to send the “FLASH” SPI frame instead of doing it by software in an interrupt.… Read more

Timing the flashes, Act 2

Since our last post on Monday, Vlaya and I have been writing code to trigger flashes when the Phyllo is at precise angular positions.

Flashing via SPI

As mentioned here, to flash the LEDs we need to send a SPI frame “FLASH” from the main board to all the led-driving PCBs signaling them to turn their LEDs on right now and for how long.

Checking the timings

On top of sending a SPI frame, we also set the Timer channel we use to trigger the flashes in output mode “Toggle”. Using a Saleae Logic analyzer to  monitor all these outputs allows us to export the precise timings of both the moment the Timer channel is toggled and the moment the SPI frame is sent.… Read more

A new angle on flash frequency

In a previous post, Vlaya and I showed how the flash frequency can lead to many nice effects.

A question of angles

After a long reflection, we realized that for many reasons the best way to describe the flashes is not by their frequency, but instead by the absolute angular position of the Phyllo when each flash occurs.

Therefore, each image description will contain the colors frames and a pre-computed absolute angle (which may be procedurally computed or included in a stored animation).

These absolute angular positions are not to be confused with the relative angular rotation of the motor between two consecutive flashes.… Read more

Spring is coming

Now that the speed control finally works, we promptly decided to test it out with a actual Phyllo.

Here’s a video of a Phyllo spinning at 11.45 RPS and then 18.54 RPS filmed with a 30 FPS phone camera.

In order to shorten the exposition time to reduce motion blur, the Phyllo needs to be as illuminated as possible. Since today was not sunny (just another day in Saclay…), we borrowed a spotlight from the design studio next door.

We really like the transition effects when changing speeds, so we’ll try to incorporate them in our panel of animations 🙂

Speed control from every angle

Since our previous post last Thursday, Sibille and I have kept working on speed control. It has taken us much longer than we originally thought, but we’re happy with the result. Now that we have a working product, we’ll go back over what all went into making it work:

As mentioned previously we use a Proportional, Integral, Derivative (PID) control scheme to regulate the throttle command given to our ESC so that the motor speed matches the desired speed.

Speed feedback and speed format

If you’ll recall, Vlaya had previously written code to capture the edges of a once-a-rotation interruption (the “period interruption”) from a Hall sensor or an optical sensor and deduce the elapsed time during the rotation, and from there the speed.… Read more

GDBug and other glitches

Executing our code from flash

Last week Sibille and I moved our bare-metal code for the processor-PCB (which so far was directly inserted in RAM by the GDB debugger) into the Flash memory proper, and wrote code that will execute from Flash to copy everything in RAM and continue execution from there.

However, we soon noticed a strange bug: the GDB debugger now ignored every breakpoint we tried to set in RAM (breakpoints to parts of the code executed in Flash before the copy to RAM still worked fine). After a lengthy debug session, Alexis determine that it‘s a bug from the GDB debugger and not from our code.… Read more

Bare-metal succes

Today, Sibille and I ran the final tests for the led-driving PCBs software using Vlaya’s SPI generation code. We wanted to make sure that if the main board sends an entire SPI frame (24 LED configuration instructions and a “TOP” command), the CPU managed to configure all the LEDs and turn them on. It does 🙂

On the nucleo devboard, we can observe 20 out of 24 timers. Have a look at the outputs we measured with the logic analyser : 

LEDs fired for two cycles (duty cycle proportional to LED ID)

Here is a link to the processor Reference manual.… Read more

Uncrossing wires

Today Sibille and I made great strides on the bare-metal code for the led-driving processors.


Yesterday we left off unable to see the PWM outputs on the processor pins. Today we started by remedying an oversight: we set about configuring the clocks. 

On top of that, it turns out that yesterday we didn’t pay enough attention when reading the documentation for the board: the documentation includes pinout information for other boards with other processors, and we were looking at the wrong processor…

We were then able to use a Saleae Logic analyser to observe the PWM output. At first, the frequency was off, and we spent much time looking at our clock configuration before realising that the timer prescaler didn’t behave in the way we expected (it turns out that frequency division ration if the prescaler value plus one, which is a neat way of avoiding a “division by zero” type of situation). … Read more

Tuning up

Motor update

Since yesterday, Sibille and I have worked on reducing the voltage threshold for motor acceleration we’ve mentioned here

After a meeting with Alexis yesterday and with the school mechanic this morning, we have two main leads.

Reflashing BLHeli ESC

The first lead is to take a look and the programmable  parameters of the ESC. We previously hadn’t given this much thought, but ESCs usually allow for the tweaking of several parameters in how they control the motor. Usually there’s a way to access these settings by playing with the PWM throttle input and using the feedback bips to identify various menus.… Read more