In 2 days, we defined the architecture of our project and most notably, we establish that we’ll be using 3 microcontrollers: a main controller from the STM32F7 family, a smaller one from the STM32F3xx family, whose main purpose will be to switch off the laser when it doesn’t move to comply with security norms, and an ESP32 for the network.
It seemed then logical to try and begin learning to use FreeRTOS, as we were used to work with ChibiOS in practical courses. That’s why I copied a demo for STM32F4xx cards, which we happen to have used during the practical works. In the next week I’ll try to learn how the kernel works in order to set up a SPI interface and maybe, if I have the time, a code to access an SD card, using the STM32F4xx. The code will be eventually reused on our final STM32F7 if functional.
We chose to use the “GitHub workflow” because it’s simpler. The “Merge Request” feature of GitLab will help us apply this flow well.
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.
LASMO will need to get data from the storage devices where the animations will be stored. For that reason, we need to add to our PCB a USB connector and a SD connector, as well as identify the electrical needs of the devices once connected and active. So I looked for what kind of SD cards and USB drives were fitted for LASMO. (streaming of ILDA files). Thanks to Pierre, we know that we’ll need a debit of approximately 500 kbps.
SD cards are divided in 3 categories according to their storage capacity, and are granted a speed class among 11 possibles.
According to this table, all the speed classes on the market are fitted for the application.
As for power supply, it is kind of standardized. Indeed, accessing SD cards with an SPI bus requires a voltage of 3.3V. After looking at the cards available for example on Mouser, the typical supply current is between 30 mA and 100 mA.
Thanks to the presentation on USB we had a moment ago, we know that USB 2.0 and USB 3.0 deliver theoritical debits up to 480 Mbps and 5Gbps respectively. That is largely enough for what we need.
We had arguments over which type of connector will be the best (between USB-A and USB-C) . We finally decided to go with the most common (for the moment) USB-A.
As for the power supply, if the voltage is almost always 5V, the current does change with the version of the protocol: maximum 500 mA for USB 2.0 and maximum 900 mA for USB3.0.
The galvanometers are controlled by an analog signal input (between -5V and +5V). So, we have to use DACs in order to convert each digital coordinate. In the ILDA Format, each coordinate are code on 16 bits, but very few microcontroller embed 16 bits DAC. It’s generally DAC of 12 bits we can find on common microcontroller (like STM32 series). With 12 bits on each coordinate, the display resolution is 4096×4096, witch is bigger than the 4K resolution (3840×2160) ! 12 bits for each DAC are quite enough.
Most of DAC on STM32 can operate up to 1 Msps (megasamples per second) and it’s compatible with our 30Kpps (and so 30Ksps). Most of DAC on STM32 have an output signal voltage of approximately VDD=~3,3V. If we want an -5V/+5V range, we must use an AOP. For this king of gain (<10), most of AOP can easily operate at our speed ( 30Kpps ).
In conclusion, it will be easy to find a microprocessor with DAC requirements. The only constraint is the number of DACs: a minimum of two for the two axes but a third is required if we want use an analog LASER control (in opposite of TTL control).
For the LASER, we need to know which power we have to use, in order to know the LASER’s class. It was a difficult question which I had to think and reflect on. Actually, the class 3B is a higher level of LASER, but more dangerous. On another way, I thought that a 3R LASER couldn’t be powerful enough. Finally, after some researches, we decided to take a 3R LASER of 5mW, which would be sufficient for projecting animations. Furthermore, the LASER will be in green colour (520 nm) , thus points will be more apparent and distinguishable.
There are 2types of LASER that we can use: The LASER diode, that can be used like a simpleLED or the LASER Diode Pumped Solid Stage. We will use the first one.
With those informations, we can now specified some characteristics like the tension : 2.8 – 6.5V/ DC
We will control our LASER with the TTL modulation and not a analogic one. We can also shade the beam’s brightness with PWM mode.
Now, we also know that in order to show an animation, we need 300KB/s = 2.4 Mbits/s.
Also, 10BASE-T Ethernet can provide us 10Mbits/s which is enough. We can also take another specification of Ethernet that will be widely enough like 100BASE-T .
For the Wi-Fi, norms are differents by the range and the rate. We can use almost every norm, but we prefer to have a considerable range in order to do the LASMO’s configuration everywhere in a site. So,we will use the 802.11n norm Wi-Fi.
Now, we have to identified the micro-processor we will use
Informations on this post are taken from ILDA official website. The ILDA format is intended for frame exchange purposes only. It is not optimized for space or speed, and it is not currently concerned with display issues such as point output rate. Also, the format does not include show information such as timing of frames. Generally, the highest function the ILDA format can provide is a sequence of frames which play back to form an animation. The ILDA File can provide a 3D or 2D structure, and provide color with Indexed color in a table or True colors on 24 bytes. In order to best estimate the required useful bit-rate, we analyse the most disadvantageous case : format 4 with 3D points and “True Color”. All these numbers are for one frame and N points per frame :
a header of 32 bytes
N data records of 10 bytes :
2 bytes for X coordinate
2 bytes for Y coordinate
2 bytes for Z coordinate
1 bytes for status code
3 bytes for “True Color” ( 1 bytes red, 1 bytes green, 1 bytes blue )
With frame_rate in fps, N in points per frame and k in pps :
N = k / frame_rate
bit_rate_per_frame = 32 + 10*N
bit_rate = bit_rate_per_frame * frame_rate
For our project, we can assume that the frame rate will not exceed 60fps (and generally 25fps) and the number of points will not exceed 30Kpps (the commercial galvanometers can’t go faster). So, the bit-rate of an ILDA animation will not exceed 300KB/s.
In order to choose the components of our project, I decided to focus on the format of a LASER animation: ILDA. Indeed, the format of the animation requires us the bit-rate of our data flow, the time-precision and spatial accuracy of the galvanometers.
These informations are essential for the choice of all the components: the class of the SD card, the generation of the USB protocol, the choice of the Wi-Fi and ethernet specification, the requirements of DACs (to control galvanometer and LASER), and finally the choice of the micro-controller.
In order to collect all these informations, I created the Wiki of our project LASMO. I put the information about the ILDA Format, and the information of one of a galvanometer we will be able to use.
For our project, we need to
define the LASER type we can use. So, I did researches about the different
classes. There are 5 classes of LASER, and we can use only 3 of them without a
specific licence. However, we need to have enough energy to properly see the projection.
So, we will use a 3R LASER class, which can not be looking during more than
0.25 s. We need to program in hard a control module in order to avoid a potential
Now, we have to precisely define
the LASER’s colour, its power, its voltage, its diameter, and its control speed
required for our project
LASMO’s main objective is to display monochrome laser animations in small audience light shows, for example at the parties held by student associations in Telecom ParisTech. The displayed animations, which has to be in the standard ILDA format, could be read either from a physical storage device such as a USB key or SD card, or streamed from a connected PC. Here is an example of what LASMO will be able to display:
LASMO’s will be able to display 2D or 3D animations with these characteristics:
All animations will use the ILDA standard
16 millions colors (RGB)
Resolution of 4096×4096 points
30k points per second (kpps)
3D animations can be displayed if a point of view is specified.
LASMO will adapt the orientation of the display to the orientation of the system (for example, if it is set vertically or horizontally, the frame will still look the same and not be reversed).
LASMO will be able to synchronize animations with a beat. To do this, one will simply have to plug a stereo XLR input (2 cables) with the beat wanted. LASMO will also use the ArtNet library to be compliant with standard light show controllers via Ethernet.