BouLed will be inside a plexiglas sphere, so there will be no button. The two ways of interacting with it are its orientation and a WiFi remote control, which I made with an ESP32 DevKit. It opens a access point and runs an HTTP server. You connect to it with your phone (or whichever WiFi-enabled device you like), select some parameters on a web page, and send them to the ESP32. Which in turn sends them to our main board via SPI. Naturally, there’s no noticeable latency.

However, I noticed something strange. The card doesn’t automatically boot in flash when powered on, while it should (according to Espressif) when GPIO0 is not grounded. I tried connecting it to Vcc instead of letting it floating, and it boots in flash. Same behaviour on other kevkits. Except for the brand new one soldered on our main PCB, fortunately.

## Clever mistake

When Matthias was working with the simulation, he noticed the faces weren’t ordered correctly. The top 5 faces of the icosahedron, enumerated in clockwise order, would haves indices 0 1 2 4 3 in the array of matrices giving their position, instead of 0 1 2 3 4. Yet I could do all the pretty map projections without any issue, as my implementation didn’t rely on a particular ordering of the matrices. Here’s a pseudo-code version of the function that would compute these matrices :

`mat4 face = some_correct_somputation(); mat4 rotation = some_rotation(2*pi/5);  faces.add(face);  for (int i = 0; i < 4; i++) {   faces.add(rotation * face);    rotation = rotation * rotation; } `

The purpose of this was to place one face, rotate it by 2*pi/5 around the correct axis and use this as the second face. Rotate the 2nd face by 2*pi/5 to get the 3rd one, etc… This is obviously not the behaviour of this code, as the rotation matrix is squared each time, instead of being rotated by 2*pi/5. But this actually computes the right matrices! Basic group theory in Z/5Z you’d say. Funny bug I say.

## Finishing the firmware

For the different features of bouLED, we worked on different devboard, because we can’t all work on our only STM32H7 devboard. Git merge after git merge, we’re done making it all work on the same board.

## Finishing the hardware

We soldered the LEDs on the triangular PCBs last week. That was not too painful thanks to our teachers and a pick and place machine.

We’ll now start mounting the whole thing.

## [LASMO] PCB progress

Externals Clocks

In my previous article, I talk about the STM32F7’s and the STM32F1’s clock.  However, according to the STM32CubeMX and after talked with Alexis, we will use for each controller a 8MHz external clock (for consumption questions) and rise the frequency using the PLL until 216 MHz for the STM32F7 and 72MHz for the STM32F103. According the oscillator design guide for STM32, we have

with CL the load capacity of the clock wich is 18pF here and Cs the stray capacitance of the printed circuit board and connections wich is 10pF here. So, we have the construction for each controller :

Also, we have a ESP32devKitC which don’t must to have an external clock because the ESP32 WROOM integrated has one.

XLR connection

We also work an the XLR connection but due to the phantom and the symetrisation we had some problem with the architerture, so we decided to use a jack connector. We talked about an architecture but we change again for RCA connectors which Pierre will talk about.

DAC to LASER

The drivers of the laser work with a balanced analog input ranging from 0 to 5V. Since the DAC of the MAX outputs a single-ended signal ranging from 0 to 3.3V , this is an issue we had to resolve.

We basically had to convert an analog single-ended signal to a other one, and amplify it with a 5/3.3 ratio. We achieved this by using an ADA4500-2 amplifier with two resistances, as represented below.

This circuit is composed of a non-inverting amplifier (taking the out of the MAX5105 as entry), which, with the resistances of 1kΩ and 1.96 kΩ, multiplies the signal by 1+1/1.96 = 1.51 = 5/3.3 (approximately). Then an inverting amplifier with a gain of 1, create aa signal which is going to the input of the laser

After talking with Sam, we decided to delete the DAC_OUT signals from the MAX5101  to the F103 microcontroller because their are not essential. So, we configure the HREF of the MAX5101 at 5V, and not at 3.3 V. So, we don’t need this architecture for the lasers’ inputs.

Project architecture

We also decided about the architecture of our project and about the workflow. I put the configurations files of the STM32F4 controller that we use in TP in order to begin to code with the board that we have. Let’s begin !

## [LASMO] Started PCB design

This week, I start to draw the design of the PCB.
I start to add the main components of the PCB, and decide the exact references we need :

• For the STM32F7, all references available on the ST website are suitable, so I choose the one that was already in the Xpedition PCB library, the STM32F767vit6
• For the ESP32, Luc choose the ESP32-WROOM-32: it has an embedded Wi-Fi antenna, an RMII interface for the ethernet, and an SPI interface to communicate with the STM32F7
• For the security microcontroller, I choose the STM32F103RE. This MCU has to integrate 5 ADCs, one GPIO and an SPI interface. So, a very small STM32 MCU is enough.
• For the triple 8bits-DACs, I change the MAX512 to a MAX5105 because the MAX512 don’t integrate three equal DACs. Moreover, the MAX5105 has an asynchronous MUTE input, which is convenient for the stop of the LASERs by the security MCU

Then, I work on the Ethernet connection. I add a LAN8742A and an RJ45 connector to make the physical layer. I never made design PCB, so I spent a lot of time to find and understand the different components to add to the design.

After finishing the Ethernet design, I work on the MAX5105 connections. This part was easy to make, but I’m not sure about the direct connection (cf figure 1) between the DACs’ outputs and the inputs of LASER drivers. I don’t have the LASER documentation yet, so it’s confusing for me to know how correctly connect these two parts.

This is the newest version of our main components implementation :

## [LASMO] Main components architecture

The LASER and the scanner were chosen : a LASER RGB of 1W and a scanner with a speed of 30 Kpps. They came from laboutiquelaser.fr, a French website. We are waiting for the technician’s answer for the availability of the LASER and a real documentation of each component.

The choice of these two components allow us to define the main architecture of the project :

The main controller is a STM32F7 family. On this micro-controller we will :

• Use two DAC of 12 bits to control the scanner
• Use two ADC of 12 bits to get a stereo input line ( in order to synchronize the animation with a sound beat )
• Communicate with a SD card
• Communicate with ESP32, STM32F3 and MAX512 with SPI protocol

The network controller is an ESP32. It will allow us to communicate with LASMO over Ethernet or Wi-Fi. It will integrate a HTTP server to provide us a web app in order to control LASMO.

The MAX512 is a triple 8 bits DAC. It will be able to control the LASER with 3 analog inputs (RGB). This information have to be confirmed, we don’t have yet the documentation of the LASER. In case the input is not analog, the MAX512 component will be removed.

The STM32F3 is a micro-controller whose solely role is to comply with security norms : indeed, the LASER can’t be turn on more than 25 ms on the same position. The security controller monitors the return position signal of the galvanometers and force the laser inputs signals to zero if the galvanometers don’t move enough.