Highway Star

After trying to fix a pretty bad bug with Nathan on the integration of the voxelization algorithm to LitSimulate, I started working on routing the highway PCB.

First order of business was the fanouts on the GND pins of the connectors. That worked for some connectors but not every one. Apparently, Mentor does not appreciate having werid angles on its SMD components and kept spitting out SMD violation errors.
I found a workaround but intend to check with Alexis to see wether this could be fixed as it would make having multiple routing attempts much easier.

I used the autoroute feature to see what it would give us since the sheer number of lanes needed makes it almost impossible to route manually.… Read more

IR Update

Today Sibille and I made some additional tests with the IR receptors, like we talked about in this recent post.

We used the AGC2 TSOP4856 receptor, as well as a LTE-R38381S-ZF-U emitter, with the same circuit setup for our previous tests described in this post.

The first thing we tested was whether we could overwhelm the receptor’s AGC by exposing it to an IR burst longer than the maximum burst length, which is 1.8ms for our receptor. 

With bursts of 3ms (on) and 100ms gaps (off), the receptor tended to be 10 or 20ms late in reacting to the end of the burst.… Read more

Time to synchronize stuff

Today I started working on our synchronization module. This module is supposed to take in input the result of the speed measurement provided by the sensors and then infer the current angle position as well as others signals needed by both the led band controller and the led drivers: LAT, SCLK, GCLK and MULT. But before writing any code, I need to make a timing diagram as precise as possible. This is my first objective. So today I spent most of the day diving back into the driver documentation and the FPGA architecture described by Romain and Nathan in order to make a first draft.… Read more

V1: Led Band Controller

First organization

I implemented the first version of the led band controller. We divide this controller into 4 submodules:

  • FC Setter: This submodule is used to set the driver FC register
  • Mux: This submodule takes the current led, color, angle, and multiplexing and returns the corresponding address
  • Memory: This submodule represents the double buffer of the controller
  • GS controller: This submodule is used to set the SOUT signal


We have to test this first implementation thanks to a testbench. Firstly, we will test each submodule independently. The FC Setter has been already successfully tested.

Integration Schrödinghurts

Major headache with Guillaume today.

We plan on integrating the voxelizer, the 3D simulation and the remote control of LitSpin in one program, LitControl.

While trying to integrate the voxelizer in the 3D simulation, we encountered a nasty bug. Only on some computers, and only when not debugging, the result of the voxelizer is wrong. A nice Heisenbug.

To add to the list of issues, we use opencv in order to extract the frames of an animation and it turns out that the packets are a mess between the different linux distribution (namely arch and ubuntu). Therefore we will probably include opencv as a submodule.… Read more

Some tests before the prototype: Let’s PCB

A Test PCB

Before making our first device, we aimed at having a smaller one to test some components we do not have time to test: h-bridge, multiplexer, etc.

So, I had to complete a Test PCB that Alexis began. We already have chosen the components, and he chose the step-down converter, which we would use for our circuit.

I spend two days for placing and routing this PCB. We had two constraints: to put our coils at a precise place and the hall sensor just under them and to add the other component where there was still someplace. We choose to try to not add a battery since a phone charger can give us a 5V voltage with 1,5A current.… Read more

A new shell fresh from the oven

You might remember we printed a Phyllo shell with success a week ago. The material we used for this shell however was not meant to be translucid, but actually phosphorescent. This meant our shell was not as translucid as it could be, and it’s phosphorescence was also problematic since we want a high contrast between the phyllo when lit with inner LEDs, and when not lit by any light source.

We therefore ordered a more suitable 3D filament. This time the result for the shell printed with this new filament was not as successful:

The deformation on the first picture was probably caused by the temperature of the nozzle (from which the filament goes out) being too low, which caused the printed raft below the shell to detach itself from the platform.… Read more

Lots of IRons on the fire

Since Friday, Xavier and I have worked on the placement and routing of the main rotating PCB. We have a lot of constraints to place the components of this PCB, notably for the IR which is used for the detection of other Phyllos and the reception of the common time reference, and the IrDA, used to communicate between the fixed and mobile parts.


The IrDA would be used to send speed commands from the rotating part to the fixed PCB below, which controls the motor. This fixed PCB will handle the feedback control of the motor, so we really only need to send it a target speed with the IRdA.… Read more

Figuring out the right WiFi protocol

Since thursday I’ve looked into how to implement the wifi communication we need between our phyllos (see Ruling the colony of Phyllos ).
We need a way for multiple Phyllos next together to broadcast data between themselves, and a way to communicate with the Phyllos from a smartphone or computer (for instance), and we will be using a ESP32 dev kit C integrated in our Phyllos.

Data exchange between Phyllos

The rate at which the phyllo need to exchange data doesn’t have to be very high at all: we just want to exchange small messages such as “Here is my ID: xxxx” , or “Start animation X at time T”.… Read more

A few bits about motors and ESCs


Last Friday we received new motors : the EP4108 320KV with built-in ESC.

We’re particularly interested in those because they have a reflashable integrated BLHeli ESC. It turns out that, starting with BLHeli_S v16.5, which is an open source ESC firmware, a new protocol is supported to replace the old PWM control method : DShot. It’s a serial protocol where speed information is encoded in 16-bit frames, instead of analogically in the duty cycle of a PWM signal.

There are three generations of BLHeli firwmare : BLHeli, BLHeli_S, and BLHeli32 (wich is no longer open source), each with several versions.… Read more