The hardest choices require the strongest will

The past week I’ve been looking through datasheet after datasheet in order to find several components that would fit our project.

  • Hall effect sensor:

Looking through the different types of hall sensors, I found that a switch sensor was the best fit, since we will use it to get the motor’s speed rotation, we only need to know when the magnet will be aligned with the sensor. The constraints we had on the choice of sensor were not numerous: we need a sensor with digital output, with 3.3V in input. However, one interrogation I have is whether or not the inductive power transmission will infer with the sensor. Alexis said that it was not a problem, but I am still wondering if having a highly sensitive sensor like the one Cyled chose, the TLE4964-4M, won’t increase the risk of interfering with the power transmission. I honestly don’t think it will be a serious issue, but I prefer to be sure before I validate this sensor.

Another issue I had with the position sensor was if it would be precise enough. A solution to that could have been adding an optical sensor in order to have a second measure, but the problem was that most optical sensors use infrared, which we already use for communication. In fact, simply having several magnets on the fixed part allow us to have several measurement points per rotation.

  • Infrared sensor:

Regarding the communication from the mobile part to the static part, Alexis advised us to do some research on the IrDA protocol, which is a communication protocol using infrared transceivers. There are several communication speeds available (SIR, MIR and FIR), but since we only need to transmit speed commands to the motor, the lowest speed (SIR, which corresponds to a standard serial communication speed: 115.2 Kbps) will be sufficient. I chose to use this kit with a emitter and a receiver: TFBS4650-TR1.

  • Wifi module:

For the Wifi module, I had two main choices to make:

  • the hardware interface: I started by searching what Cyled did. However, they did not have much choice regarding the hardware interface, and had to choose a USB module. On the other hand, we have a larger SOM that gives us much more choice: USB, SPI, PCIe are the main ones. I found module for each of them, but I’m still not sure which interface would be the easiest to implement.
  • the protocol version: for the 802.11 protocol there are several versions, such as 802.11b, 802.11n or 802.11ac., 802.11ac is the most recent one and the fastest, but it also consumes more power, and most importantly, we don’t need that kind of speed, since we won’t do any streaming. Consequently I choose to stick with 802.11b/g/n compatible modules.
  • Leds:

In terms of lighting, we have the same constraints as Cyled, so we will just take the same: ASMB-KTF0-0A306.

EDIT: I didn’t publish this post right after I wrote it because at the time we were waiting for answers from Alexis, and I wanted to publish it with the answers.

After the discussion, several things changed:

We will in the use a sensorless motor, as Cyled did, so this eliminates the need for a IrDA communication with the motor. No IrDA communication means we can use an optical sensor along with the Hall sensor in order to increase to precision of the speed measurement, just like Cyled did. We will use the TCUT1600X01.

As for the Wifi module, in the end we will go with an ESP32-WROOM wifi module which will communicate in UART with the PCB.

That’s it for the choice of these components. We can now start making the PCB!

Communicating between Phyllos : Who’s Who ?

In order to display animations that flow back and forth between several Phyllo, the Phyllos need first to be able to know each other’s position. 

For now, we have reduced this problem to this : to display animations in the proper orientation relative to its neighbours, each Phyllo needs to know the direction of each neighboring Phyllo. They have no real need to know exactly how far they are from each other.

Associating detection and communication

It is not enough to merely detect Phyllos if the detection method doesn’t allow us to distinguish one Phyllo from another. We have to be able to both talk to a specific Phyllo AND know where it is physically located.

It’s the same problem as trying to find someone you’ve never met in a crowd, while you’re on the phone with them. At some point you’re going to need a sign to differentiate them from every other person around you.

So far we have discussed several ideas :

The IrDA idea

Our first idea was to place a lot of highly directional IR transceivers facing outwards all the way around the fixed part. Regularly, if a Phyllo isn’t communicating with anyone, it emits its identifier. If one of the transceivers detects an answer, the Phyllo uses this transceiver to speak with the Phyllo who answered. Like that, we communicate directly in the right direction. If three Phyllos are aligned, the middle Phyllo will hide the two others from each other, but it’s not a problem.

However, we do not know if it is feasible. One problem in particular is that, in order to use very directive IrDAs, we would need many of them to cover 360° and the processor probably won’t have enough UARTs.

The magnet sensor idea

Alexis suggested that we use magnetic sensors. It would then be possible to have hardware set ids by playing with north and south poles of magnets in each Phyllo. Alexis also lent us an evaluation board of such a sensor.

However, even with pretty strong magnets, we could not detect anything further than 5cm (which is to be compared with the 15cm diameter of a Phyllo). Moreover, it doesn’t seem easy to discriminate magnetic perturbation from each Phyllos, and even more if each of them hold several magnets. On top of that, we would need to filter out the Phyllo’s own magnets.

The rotating IR emitter idea

Our favorite idea so far is about combining Wifi and IR detection.

The Phyllos start with Wifi to list everyone present. They either already have unique identifiers, or cooperate to give each-other unique identifiers.

Then, in an agreed upon order, each Phyllo emits IR in all directions with several emitters around its fixed base to cover 360°. Each Phyllos also possesses an IR receptor on its rotating part, allowing them to determine the direction of the Phyllo who is currently emitting. Thanks to this protocol, the association between Phyllos’ ids and their location is possible.

Working anatomy of a Phyllo


Here is a diagram summarizing the architecture of a Phyllo, to allow you to have a global vision : 

Some details

This week, we spend a lot of time trying to choose the components. Here are the solutions we explored and the decisions we took.

Motor and ESC

All the animations we will display are based on two or three basic animations : aging petals, de-aging petals and possibly fixed images. Here are simulations to visualize those animations :

Aging and de-aging petals

In order to display those animations without skipping any petal (have a look at this instructable to remember the “skipping petals” part) while flashing the LEDs at 30Hz (ie 30 frames per seconds), the Phyllo has to rotate at : 

AnimationSpeed (RPS)
Aging petals11.46
De-aging petals18.54
Fixed petals30

Furthermore, we are going to use a brushless motor (less wear-and-tear, less noise) controlled by an ESC. We have chosen not to use the same motor than J. Edmark (KV135) but a motor with a higher KV, in order to consume less power. A higher KV motor has a weaker torque at the beginning, so we will have to choose a precise ESC (some of them are controlled in I2C or SPI). 

For now, we have chosen:

For the ESC, we will first test if the ESC CyLED used last year is able to start our motor. If not, we will use the VESC 6+.


The LEDs will require a lot of power, but for very short bursts: they will require less than 1W on average. The motor require at most 75W. We would like to have 1h autonomy, so the battery has to provide 80000mWh. The motor we choose requires a 6S battery. Therefore the capacity must be more than 3622mAh. We have chosen this one : Batterie Lipo 6S 4500mAh.

Power transmission

First we wanted to have a wireless transmission to avoid the ugly effect of having a metal bar coming out of the top of the Phyllo, as CyLED did last year. After extensive research, we found that this type of energy transmission is currently used almost exclusively for mobile phone charging. Therefore, output power is usually far lower than our needs (20W against 120W). The few products with better output power are essentially coming out of China without any documentation.

We also considered the possibility of building our own wireless transmission to get an appropriate output power. However, it is too hard to get a satisfactory calibration and we do not have the time required.

The following idea was the slip ring. However it has a big flaw: it wears down quickly. We imagined to have one connection on the ball bearer of the motor. Then, we thought that we could put a second one as a ring on the axis of the motor to completely get rid of the slip ring.

This ball bearer has no other use than electricity transmission. Here the insulating layer enables the ball bearer to stick to the axis. It is also necessary since the axis already bears the current from the ball bearer of the motor.


We will need at least a 3.3V regulator and a 5V regulator, to regulate the output voltage of the battery and of the power transmission device. We have considered 2 switching regulators : LT1765 and LM2678.

LEDs and light pipes

We haven’t received all the components yet… While we were working on the components choices, Vlaya has started to design some tests for the LEDs.

LED Drivers

We plan to use a LED driver for each spiral arms. The drivers need to have enough output channels to drive all the RGB LEDs of the spiral without multiplexing. A Phyllo has a different number of clockwise and anticlockwise spirals, so we can take as many drivers as the smaller spiral number, in which case they need to have more channels, or as many drivers as the bigger number, and they can have fewer output channels.

The drivers cannot be interrupted in the middle of a PWM cycle, therefore the clock of the internal PWM of the drivers needs to be fast enough that a PWM cycle is shorter than approximately 100µs. That is the time the LEDs can be flashed, if they stay on for longer periods the image will blur due to the Phyllo’s rotation.

Moreover we need to be able to communicate fast enough with the drivers to send the color values of each LED to the drivers in the time between each frame (1/30 of a second). And we need to be able to simultaneously enable and disable all the drivers.

Finally the output current must be high enough to power our LEDs with an acceptable brightness.

We have chosen these LED drivers : THL3502

  • 24 channels, allowing up to 8 RGB LEDs per driver
  • PWM 10 MHz and 8-bit brightness control, making for 25.6 µs PWM cycles
  • 10 Mbps I2C serial input, allowing us to send colors for 150 RGB LEDs in 240 µs
  • Output current : 100 mA

With the I2C interface, we cannot simultaneously fire and disable all the drivers. If the delay gets too big, a solution could be to separately control the current output to the LEDs with transistors.


We will need Wifi to communicate with a Phyllo from a computer, and probably to communicate between Phyllos. At first, we wanted to use an ESP32 because it’s simple to use and easy to find help online. But after discussion with Alexis, we will use a AMW006.


We would like to be able to upload complex animations frames on a Phyllo and maybe allow users to do the same. To provide the necessary storage space, we will use an SD card : JAE_ST1W008S4ER1500.

Angular position sensor

To be able to display neat and clear animations in a precise direction, we must be able to detect the alignment of the motor with its original position with an accuracy of less than half a degree (to have distinct images like J. Edmark). To do so, we will use a Hall effect sensor (TLE4964) and we planned an optical sensor (the same than Cyled : TCUT1600X01) just in case, even if theoretically, the Hall sensor is precise enough. The idea is to get a pulse every rotation and use these to deduce motor speed, and then integrate the speed, coupled with the once-a-rotation pulse, to deduce the angular position.


To communicate inside a Phyllo between the fixed part and the rotating one, we will use IrDA. We have chosen these transceivers : TFDU4101-TT3.

The IrDA Design Guide requires a transmission distance of 0cm to at least 1m and an emission angle of at least 30 °. Thus, if we place the transceivers close to the axis of rotation, they will be able to communicate during most of a turn, so no worries about the transmission speed.

If we can not place them close enough to the axis of rotation (because of the wide motor diameter), we can reduce their directivity by putting a diffuser so that the LED illuminates the entire interior of the phyllo (or at least most of it) and the two transceivers can communicate all the time. It will not be necessary that it affects the communication of the other Phyllos.

If we cannot place them close to the axis of rotation nor diffuse enough light, and we are obliged to place one at the periphery of the PCB: we place one near the center facing outwards, the other on the periphery oriented towards the center. They will be able to communicate during 2.7ms minimum. In this case, we must take elbow transceivers like TFDU4101-TR3, probably faster ones…

To be continued…

The following post will detail our ideas about detection of other Phyllos and communication between them. And Monday, we have a meeting with Alexis to decide on a solution. We will keep you updated 🙂

Architecture: “The more it’s simple, the more it’s simple”

First, the work of some students

We spend a whole week working with just a few responses from Alexis, so we try on our own to find out how to make our architecture. This is what it would look like

We spend a lot of time exploring the best components, as you may have seen it in our previous posts.

We would have to make a lot of FPGA programming for the I/O expander, but we thought it was our unique solution.

We spend some times looking for a sensitive captor touch with only one key and the way to use it because we wanted to use the sensitive captor touch of an ESP32-WROOM-32D.

Then, destroy everything with a single Alexis and build again

We had a meeting with Alexis yesterday. He explained to us that the sensitive captor touch of the ESP32 wouldn’t do the job through the wood. One component to change. Fortunately, we already found a 3-key sensitive captor touch, we just have to make sure it will have enough strength to work through the wood.

Then, we spoke about the price and the length of the device. With 64 I/O expanders, Touch would be too expensive for funding it, that’s why we choose to make only a 16×16 grid of marbles.

The next step was the I/O expander: we cannot use them for our hall effect sensor because they are analogic and not numeric. We thought to change for numeric ones but we will come back to them later

We still need a lot of I/O expander, that’s why we need to find a better architecture for our H-bridge. Alexis first thought to make something similar to the architecture of a digicode. One half H-bridge by line, and one by column. If we want to activate the third coil of the fourth line, we would put VCC on the third half H-bridge and the ground for the fourth half H-bridge.

Finally, taking a look at our H-bridge gave us the best solution. This H-bridge can be controlled by an I2C bus, and we can give each of them a special address, so they can be on the same bus: instead of 32 pins, we just need to use three pins. Two for the I2C bus and one for the address, that we will link to some shift registers to control their address.

Now, are we happy? Not exactly, we still need to find how to control our hall effect sensors. A brief look at component gives us our last solution. We would use some analog multiplexers. So, here is our new architecture.

And now?

We are waiting for some coils and Hall effect sensors, and we will begin our tests.

Going back and forth the H-Bridge

We need to be able to drive our little magnet marbles and flip them according to a magnetic field direction or the opposite one. To do so current must be able to flow both ways through our self-inductances. Moreover we’re going to need current’s intensity of a much higher value than what is able to flow out of or flow in the GPIO.

One way to do so, is to use a H-Bridge as we can see on this site that we’ve already mentionned in an earlier post.

What’s an H-Bridge

Basically an H-Bridge is a electronic circuit built with drivable switches in a way that allows us to flip the voltage on a load and thus allows us to flip current polarity.

H-Bridge circuitry in red | Source :

There are two important configuration for us :

  • the configuration where S1 S4 are closed and S2 S3 are open and
  • the opposite configuration

By switching from one mode to we are able to revert current polarity by changing which voltage source terminal is connected to which load terminal.

FET transistors are usually used as switches to drive the load. Below we can see a typical implementation with NMOS and PMOS.

H-Bridge implementation with MOSFETs | Source :

How we plan to implement the H-Bridge

There’s two ways to implement H-Bridge circuit. Either we do it ourselves hand picking the transistors and doing the circuitry ourselves or we pick a H-Bridge driver integrated circuit. We choose the later solution as implementing the H-Bridge by hand can be tricky and unnecessarily complicated for our project.

Moreover, H-Bridge drivers are more advantageous as they have protections against over-voltage, under-voltage, overcurrent etc.

How we choose the driver

There’s two ways to implement H-Bridge circuit. Either we do it yourself hand picking the transistors and doing the circuitry yourself or we pick a H-Bridge driver integrated circuit. We choose the later solution as implementing the H-Bridge by hand can be tricky and unnecessarily complicated for our project.

Moreover, H-Bridge drivers are more advantageous as they have protections against over-voltage, under-voltage, overcurrent etc.

How to choose the driver

There are many criterias that we considered to choose the driver.

First of all, one criteria that seems obvious but we didn’t know about before talking with our professor in charge, is that the driver must be designed to be used with inductive loads. This is not always the case as we can find H-Bridge drivers for capacitive loads.

Initially we’d like to have a 32×32 marble matrix and if not possible a 20×20 matrix at least. It is consequently obvious that price is a critical criteria. As each of our marbles needs to be individually drivable, we often need for one component to order as many as we have marbles.

One way to reduce the number of H-Bridge drivers we’ll need, is to look for drivers designed for multiple loads. This is an important criteria as it possibly allows us to reduce the final cost for this component but also because it may also allows us to gain space on our PCB.

Likewise, driver package size is equally important as we’ll need for each marble a set of components (self-inductance, Hall effect sensors, H-Bridge drivers). It’d be too bad to have to space out the marbles because we don’t have enough space under them to fit all components.

Last but not least are the voltage of the power source and the maximum current that can drives through. We estimated that we won’t use currents higher than 1A to generates the magnetic fields so we looked for drivers in this range. As for the power source, we thought that 7V should be more than enough.

Giving all these criterias we looked for a good compromise and we ordered these two drivers for testing :