This is an update on Nathan’s previous post about a pretty nasty Heisenbug. The symptoms were that the static voxelizing function was not working in specific conditions. More specifically, it would work when used in the main function but would not work when used in a Qt Widget function. However, that was on my own computer and when not using a debugging tool. When using Qt Creator’s debugging interface (based on gdb), the program would run just fine. It would also run as expected on Nathan’s computer.
Nathan worked yesterday on making the program run independently from the Linux distribution used as there was an issue with Opencv versions and packages contents between Ubuntu (that Salomé and I use) and Archlinux that Nathan uses.… Read more
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
After much thinking and looking at documentations, power transmission from static to rotating assembly will be done through ball bearings. Alexis told us he had used it before on other projects and that it would be suitable for our needs. We would transfer 12V power through one bearing and GND through another.
That meant that we needed one 12V->5V and one 12V->3.3V power supply rails. We also need 1.8V for the USB controller but we will use a basic 3.3V to 1.8V regulator.
How much ?!
Now that we know what voltages will be required, we need to find out how much current will be drawn on each rail.… Read more
In order to communicate with the user on the desktop app, we need to have wireless networking on LitSpin. We looked at several options in the beginning and landed on an ESP32. We put it aside for a while working on chosing other components and working on other sides of the electronics. The subject came back while working on the mainboard.
Since CyL3D (last year’s POV display project) had a USB wi-fi dongle, Alexis suggested that we use the same method in order to be able to work on making LitSpin work and use make the ESP32 work in the meantime.… Read more
Update on the choices in components for Litspin. All of the main components have been chosen. Here are the ones we landed on :
System on Module
After looking at the schematics for CyL3D, we saw that they used around 40 pins on the FPGA IO. This meant that we could use the same Aries Embedded SoM based on a Cyclone V combined with two ARM cores.
For our LED drivers, we’ve chosen the Texas Instruments TLC5957. They give us a high enough input data rate and PWM reference frequency as well as enough channels to drive our LEDs.… Read more
When you try to rotate at a relatively high speed, centrifugal force comes with the territory. The issue is that PCBs are not the most robust pieces in a mechanical system. We need to find a way to make them stronger to hold them in place so they don’t fly away and/or break and find their way into a bystander’s face.
We tried to figure out how much the PCBs would flex. Thankfully, Wikipedia exists and our problem is a classic strength of material case. We have an issue similar to beam theory’s cantilever beam case with a spread out force.… Read more
As referenced in a previous post we need a way to wirelessly transfer power from the static part to the rotating part of our system. We found a 200W dev kit from Würth Elektronik but it seemed over-powered for our needs. Another integrated solution exists but is only good for 60W. Therefore we needed to estimate how much power our rotating system would need.
The bulk of our needs is in the LEDs. Considering 1280 LEDs and a multiplexing factor of 1:4, we would consume at most the power of 320 LEDs at a time. According to the specifications, an LED could use 60mA@3.3V… Read more
In order to better understand how to make LitSpin a coherent and functionnal device, we created a diagram of its architecture .
The following represents how the different modules will communicate and work together. Technical details will come later as choices in components and communication buses are made. This is not supposed to be a drawing so it is not representative of how LitSpin will look but it should give an idea of how it will work.
Basically, there will be two main systems. A static system that will have an electric motor and what is needed to control it : a control board that will communicate with an Electronic Speed Controller, the accompanying BLDC motor, an IR receiver that will get information from the rotating system and the induction power transmitter.… Read more
One of the issues that LitSpin raises is power transmission between moving and static parts. One idea that came to mind was induction but we didn’t know whether integrated solutions existed and if they did, would they work with our power requirements. Würth Elektronik offers a plug and play development kit that allows for 200W of output power which solves our power transmission issues.
Since the coils work using resonent induction, W.E. integrated frequency modulation in order to allow I²C data transmission. This could allows us to put the wifi module on a static PCB and get rid of the signal drops that were present on previous projects with spinning wifi modules.… Read more