[SpiROSE] FPGA, the end is near

Hello everyone, I hadn’t posted since Christmas, so here I go ! Since the expedition (no pun intended) of the PCBs to the manufacturer, I kept mainly focused on FPGA development including source code and tests for various modules, which allowed us to correct many bugs we hadn’t seen so far. I will detail some features later on.

SPI slave

The SPI slave implementation is complete. The protocol for sending commands from the SBC to the FPGA is simple, we have a header command byte, followed by as many bytes of data as needed. Let’s have a quick summary of the different possible commands.

  • Enable/Disable the RGB module: we need to tell the RGB module, the one that writes into RAM the data the FPGA receives from the parallel RGB, to start or stop writing in RAM, since we only want to display relevant data. As the RGB module is the first module in the chain, this command starts everything.
  • Configuration command: change the configuration of the drivers. The command may be issued at every moment, the driver controller module can handle the reconfiguration even when it was streaming data to the drivers.
  • Request rotation information: The FPGA should be able to send its the rotation position (the slice we are at), as well as the speed of the motor.

But how can we get the position of the rotating part ? Let’s look at the Hall effect sensors !

Hall effect sensors

Since we finally use Hall effect sensors instead of the rotary encoder that was originally wanted, I did the module that tells the driver controller and the framebuffer when we enter a new slice, to begin displaying for the current slice.

The issue is that we have only two Hall sensors that are opposite one to another and 256 slices per turn. So we need to infer the slice we are at given only 2 positions, over the 256 for a turn, that we are absolutely sure of. Ideally, the synchronization signal is generated without knowing in advance the motor speed, so it must adapt in “real time” to it. An idea, since we have 128 slices per turn, is to estimate the slice positions of the current half-turn given the number of cycles that it took to make the previous half-turn. In a word, we constantly correct the duration of a half-turn to fit the speed variations of the motor.

The Hall effect sensors we chose are hysteresis sensors which, in their case, means that the output of the sensors is set low when the magnetic flux is beyond a certain threshold and is kept low until the flux reaches a second threshold that is lower than the first one. This provides an integrated anti-bounce mechanism. We thus only need to detect the negative edge of the sensor output to have a “top” to synchronize onto. Between the 2 tops of the opposite sensors, we count the number of cycles and we compute (right shift)  the duration for each slice for the following half-turn, sending the synchronization signal accordingly. To give a few figures, if we have 15 rotations per seconds, around 15600 clock cycles are elapsed between 2 slices.


For the upcoming week, while we are waiting for the components to be shipped and since all FPGA modules are complete, we will build end-to-end tests with all of them, hoping that all the tests we have implemented for each modules were thorough enough to spot all possible bugs, for it to be ready for a quick deployment on the actual board.

See you soon !

[SpiROSE] Placing and routing in restrictive environment

Hello everybody !

Recently, I have worked on the PCB of the LED panels. It needs to be finished really soon in order to work on it shortly. For a brief recap, a LED panel has in its centre a 1920 LED matrix which is surrounded by 15 LED drivers, 5 of which are beneath the matrix and the remaining 10 above. Now we had to add the MOSFETs for the multiplexing as well as the clock buffers (2 buffers for SCLK, GCLK and LAT, for a total of 6 buffers). Since the drivers and the matrix had already been placed and routed, we tried to figure out what the optimal placing location for the MOSFETs, in order no to mess up the PCB too much.


Some MOSFETs with their multiplexing lines

Under each LED column, there is a plane for its corresponding multiplexing signal (the filled purple vertical plane). Since we have one MOSFET for each LED column, we chose to place the MOSFETs right where this plane ends, beneath the LED matrix. Yet, there is very little place: we indeed have vertical traces (the blue ones, layer 1) between all LEDS, which restrain the MOSFET place. With Unidan, I did run placing and routing tests to determine whether placing MOSFETs vertically or horizontally would make the routing more convenient. It appeared that the horizontal one gave best results, so I placed then routed this pattern. The MOSFET area is filled with a thin 4V plane.

Routing everything

Lower part of the LED panel, showing some MOSFETs, 2 LED drivers and 1 clock buffer (blue=top, red=bottom)

After that the struggle began, welcome to the trace jungle. Between the 5 bottom drivers are now placed 6 clock buffers, all aligned in a tiny place. The challenge was to route the output signals of the clock buffers up to the 10 upper drivers as well as routing the signals that will be transmitted from the rotary motherboard. The big issue is that we should only use 2 layers to do so, ie route all buffer/upper-driver, buffer/lower-driver, driver/matrix, MOSFET/MOSFET and MOSFET/multiplexing connections in the 2 external layers, since the 2 inner layers are used for Vcc and ground. I tried not to use the inner layers at all, but it was not entirely possible, so instead, I tried to minimize the length and the number of traces that occupied the aforementioned layers. By the way, using many custom colours for the different nets/traces/planes really helped a lot.

I have almost finished routing all nets, some still require a consequent length in inner layers and thus need to be improved. But is is not over, we still need to add the MOSFETs drivers as well as the board-to-board connector. This task is now our priority and will be carried out in the beginning of the upcoming week.

[SpiROSE] Fixed Base and LCD screen

This week, I have worked on the fixed base, which is basically the ST STM32F746G-Discovery DevKit. Its role is to be the interface between users and SpiROSE since it will eventually be able to start/stop the device, to let the user choose what demonstration he wants to be displayed on the 3D screen, to drive the ESC and to handle safety issues. The DevKit comes with an integrated LCD 480×272 touch capacitive screen, which, we hope, will enhance user-friendliness.

To drive it properly, we decided to use a GUI library called µGFX. We thus had to integrate it along with the ST HAL drivers, the GNU Arm Embedded Toolchain as well as OpenOCD to debug the board. Once that was completed with no error whatsoever, we were able to dive in the API to get going. As regards Continuous Integration, to go beyond linting, I will have to find a way to test the program relatively to what is it supposed to display or what is it supposed to do when a given input occurs on the touchscreen.

I also worked on the IMU part. We already had a NXP FRDM-KW41Z board with an integrated SPI/I2C compatible accelerometer/magnetometer NXP FXOS8700CQ that could be bound to the DevKit with its Arduino connectors, so we didn’t bother finding another option. Since only the accelerometer is of any use for the project, I just had to flash on the NXP board a simple program that would set the right pad multiplexing so as to have SDA and SCL (I2C Data and Clock) driven properly from one board to another. I didn’t bother building an entire project based on the GNU Toolchain, but used instead NXP online tools. The accelerometer is capable of outputing data at 800 Hz, but there is no use for such speeds. One measurement every tenth of a second should be enough to detect a random displacement of the structure and to shut the motor down, in case of emergency. There again, I will have to determine the tests to be applied for the I2C communication between the two boards. For now I am able to display on the screen the IMU data along three othogonal axes. The data remain to be processed to know whether at a given moment, the accelerations measured are within acceptable range, this can only be implemented after tests on the actual structure, since we have to filter the accelerations due to vibrations.

As regards the interface, it is not looking fancy yet, but for now, three menus are implemented, one control menu for the user to start/stop SpiROSE, another to choose the demonstrations to be displayed and finally one console-style menu meant to display ERR/OK messages after virtually every component initialization or change (typically the configuration of the accelerometer with specific writes over the I2C bus). It will also ease debugging during the remaining development phase.

What’s next for the fixed base ? Once the potentiometer is received, it will be integrated. It is not important for now, but a lifting of the interface will be needed later.


First version of the interface, displaying the IMU values and a slider simulating a potentiometer

[SpiROSE] Reducing the costs

As SpiROSE had slightly shifted towards a rotating plate design, we had to list of the upcoming purchases that will be needed for the project. Yet, it quickly turned out that the costs were consequent after the first dimensions of the project were discussed.

Since we wanted – and still strongly desire ! – to have an excellent resolution for our screen, and given the maximum physical dimensions of the rotating plate stated by the mechanic, we ended up with a staggering number of almost 9000 LEDs, which represented a third of the total costs ! Other configurations were simulated, where the LED amount was decreased, significantly decreasing the costs. Having fewer LEDs implies that, if the size of the plate remains the same, we lose some resolution (but it also means that we have fewer traces to route and fewer components to solder). As regards the LED drivers, as Adrien explained, the multiplexing capability of the drivers allows to significantly shrink their numbers, allowing huge savings.

We then have to optimize each component with regard to its cost.

  • For some electronic components, we can benefit from the free sample policy from many electronic distributors, the LED drivers are planned to be bought this way.
  • The cost of SpiROSE structure can be alleviated by diminishing the thickness of the metal plates and bars needed to build it. The least stressed parts of the structure can be thinner, and since we buy a certain volume of metal, we can again reduce the costs, without endangering the integrity of the SpiROSE.
  • PCBs are a consequent part in the final costs of the project, so the smaller the cheaper. If we manage to shrink its sizes, with regard to the rotary base and the fixed base ones, we again shrink the costs. Another way for the LED PCB would be to buy small PCBs and assemble them together, since it is often cheaper to buy many small ones than a large ones, if they have the same total area. But finding an easy and solid way to perform it is not easy task. In our cheapest simulation, we still have to solder more than 2000 LEDs, which can be performed by the PCB manufacturer, but it has a price. We are discussing whether or not it might be feasible and reliable.
  • Being also expensive, the motor will be chosen carefully. It requires sufficient torque to have the rotation initiated and to counterbalance the air friction , as well as to withstand the speeds we are aiming to reach for the rotary panel.
  • Finally, we can change the model of the SBC and/or the FPGA to choose the one that fits exactly our needs. But it is risky to do it now, if ever we underestimated our needs , then this optimization would be pointless.

The exact dimensions of SpiROSE will be fixed early this week. The upcoming week, we will be working on the LCD screen, the tests with the LEDs and hopefully begin designing the electrical components 🙂



SpiROSE: Security and interactivity

As we discussed the plans of the project, we quickly realised that allowing rather large devices to rotate at around 2,000 RPM was not inconsequential to anyone using SpiROSE with regards to safety. A first mandatory step is to use a large transparent cylinder to prevent any moving part from flying away with high energy, should the implemented fixation fail at any moment. But this is not enough. We must make sure that no one tries to move SpiROSE while it is working – you do not want to destabilise a device with blades that have a terminal speed sufficient to race with a car on German highways !

Therefore, an Inertial Measurement Unit (IMU) is planned to be placed in the fixed part of SpiROSE to monitor any movement of the device – except the vibrations caused by the rotation – in order to know whether it is safe for SpiROSE to be working. First of all, before the system is even started, it checks if it’s completely still and horizontal. Then, while it is spinning, SpiROSE is able to detect any extern action and to perform an emergency brake on the moving parts. We were thinking about mechanical brakes to quickly and significantly reduce the angular speed, but it has to be calibrated not to have a massive deceleration that could weaken or destroy parts.

Let’s jump to another feature of SpiROSE, its interactivity. We do not just want a 3D display, but a 3D display that can be, as much as possible, controlled by the user. We decided to use an LCD display for the human-computer interaction. It is attached to the fixed base. It will for instance display information from the IMU or some useful other from the SBC sent through CAN/FlexRay/IrDA/BLE. The interface will allow a user to adjust some parameters – we have not decided of all of them yet – on the 3D display. A clickable rotary encoder or an endless potentiometer allows us to navigate through the interface and set adjustments, for instance we could rotate a steady 3D image. Isn’t it pleasant to touch a knob rather than to move to the other side of SpiROSE to see the face of your favorite character displayed in 3D ?

The exact features available on the LCD display will become more and more accurate as the project keeps going. Yet we have to focus on more basic features for SpiROSE by the end of the upcoming week, such as the exact dimensions of the device thanks to the mechanic, so that we can really begin working on something that we know is feasible !