Hichem got the MARG working last week-end, so we tested it with our simulation (see his post) and confirmed this model would suit us and go on our central PCB. With this and the voltage regulators chosen, we have almost all we need to design the PCBs. The triangular ones may be simpler to design, but before we want to know precisely the physical structure of bouLED.
For ease of conception and of battery management, it should be possible to open the icosahedron. One way to do it is to make five faces removable, as shown on this simple model.
The inner armature would support the electronics and the LiPos, ideally keeping the MARG in the center of the icosahedron. Thus the stick supporting the removable part should be moved, and probably replaced with something stronger. The faces would be connected to the central part with JST-like connectors, easy to plug and unplug.
We want to chain the triangles without using too long wires, and we want a removable part. This will dictate how we’ll position each face and how we’ll place the connectors on it, while keeping all triangular PCBs identical. The LED repartition we think we’ll use surely is even enough not to be considered when choosing the face’s orientations.
I’ve almost completed the schematics of all the LED panels. Once done, I will start placing and routing it.
I tried routing a small number of LEDs to check the estimations I made in the previous post. I forgot to take the soldering pad into account, so I only managed to place a LED each 3.2mm.
Anyway, this distance is too small and we risk soldering issues. Based on the vertical distance between last year’s SPIROSE LEDs, we will put a LED each 3.4mm (1.2mm between each).
Based on this, the LED panel will take roughly 11cm x 14cm. Since the PCB is 19cm x 19cm, we have plenty of space for other components. I will try to fully route one LED panel and its drivers to check if it is possible.
For now, here is an idea of how I was hopping to do the routing:
Technically, all components (except for the power supply, which I haven’t checked) fit in. What I need to figure out is if routing is feasible,
Altera made a spreadsheet named “Power Delivery Network” designed to determine an optimum number, type and value of decoupling capacitors to achieve the target impedance. I select the VRM type (Switcher), the supply voltage (3.3V), maximum current (2.58A), transient current (I typed 30%, but it seems extremely complicated to obtain a value without having the programming of the FPGA already done) and ripple tolerance (5% given the specifications of the FPGA and knowing that we don’t have transceivers for PCIe, which is the only bank requiring at most 3% ripple). For the spreading inductance, BGA Via inductance and plane capacitance profile I left the default values because I don’t know how to estimate that.
The tool looks up the capacitors it has in its database and tries to find the optimal combination for our target. With the preceding values it outputs 2x 0.01µF, 2x 0.047µF, 1x 1µF and 1x 10µF capacitors, with their respective ESR, ESL and mounting inductance (Lmnt).
Development board decoupling
If I take the configuration of the development board of our SoM, they are using 4x 10µF and 9x 100nF capacitors. If I use the capacitors pre-configured in the Altera tool, it shows that the resulting impedance is higher than the one I got with my inputs, but given that the development board has to be designed for any configuration of the FPGA, their decoupling capacitors are certainly adapted to more extreme power draws than what we will be experiencing. So, I think it would be a good idea to keep what Aries did with their development board.
I changed the LED layout algorithm to allow us to set a number of LEDs for each row. To improve regularity, the algorithm only takes the bottom row’s number of LEDs, and the row above this has one less LED, and so on. There’s also a “margin” setting for the space between the outermost LEDs and the triangle’s edges.
Here are all the layouts I generated, printed on paper with a 1:1 scale, and a 5 cents coin for scale.
We’d appreciate your feedback on this: which variant is your favourite ? You can click on the images to display them in their full size.
In order to determine how much current the motor pulls, we had to make it turn with a load and monitor its consumption. The perfect load was in hand, we took last year’s LED pannel, as ours will have approximatly the same weight and dimension, therefore giving a good estimate on our power consumption.
We took the same brushless motor as last year, a MEGA Acn 22/20/4. Which is connected to a motor controller, a EZRUN Max 10 SCT. It is rated to be able to supply up to 120A, so we could not take this value to size our power supply. So I tested the whole system to see how much would it drain.
First I had to understand how the controller worked. The datasheet is not very helpful, as it only says to put a RC receiver on the input wires. So I emulated one with an arduino. A RC receiver uses PPM signal, and is waiting for a 1 to 2ms pulse every 20ms. 1ms being the command for neutral throttle and 2ms for full throttle.
In order for the motor controller to acknowledge that you sent a RC signanl, you need to start by sending neutral throttle command. It is a security measure to prevent the motor turning on when it has just been plugged in.
After came my first attempt with no load on the motor. It ran fine and the controller pulled around 1.5 to 2A. Then Itried with last year’s pannel, and it would not start rotating at the lowest speed, or be all jittery. My teacher told me that last year, in order to start the rotation, they sent a high speed command and backed down to lower one when it started. I did so and now the whole structure is rotating.
I filmed it slow motion to be able to determine the speed it’s rotating at. With the almost lowest setting it is rotating just under 20rps. At this speed it is pulling 4A under 12V. I tried making it rotate faster, so I just left it at the high speed command I use to start it up. I did not go well. Leaving a high speed command made the controller pull more than 20A because it was unable to match the requested speed. So the power outlet shut down.
In order to get the whole system to high speed I proceeded gradually. Letting it establish at low speed for seconds and increasing the speed slowly.
An other problem rose up, at low speed it was not that wobbly. The structure was only a bit unstable. At high speed it is a whole different story. The metal structure would move around the table and produce more noise. We will have to be very carefull about the placement of the component and plan to be able to put masses and the lower rotating part to balance the whole structure, as you would on a car tire.
Although we are not even done with the shematics, we wanted to figure out how much space we will have left on the PCB once the LED are routed. Indeed, since we can’t use blind vias, and must cross columns/rows signals, we know we are going to create a vias matrix. Thus, it will be hard to use the back of the LED panel other than for routing, or placing small components. In particular, the SoM’s connectors aren’t probably going to fit.
Taking inspiration from one of TI’s reference design, I tried to do a minimal routing of the LEDs only. Using NFC 93-713 class 5, I managed to place a LED each 2.7mm. RGB cathodes are routed on the surface, and anodes are routed in a medium layer using vias.
The good news are:
We can have a really small-pitch screen.
We have a lot of free space on the PCB. The minimum LED panel size is roughly 11 x 9cm whereas the PCB’s height is 19cm.
I will need to check with the other components we need, but I’m quite confident that we can avoid using an extra horizontal PCB.
On the mobile part of our system, we need to convert 12V to 5V and 3.3V. Each conversion has its constraints:
Both need to be able to start slowly enough in order to limit the inrush current from the 12V rail to a minimum.
The 5V rail needs to withstand the switch of its output current from almost 0A to 9A in a few dozens of nanoseconds, corresponding to the activation of a new LED scan line.
The 3.3V rail needs to be able to start quickly enough for the FPGA to startup properly.
I looked at the TI modules for our application. I chose the LMZ22005 for the 12V->3.3V@5A conversion, and the LMZ12010 for the 12V->5V@10A conversion because of the low count of external components required to make the design work. TI has an online tool (WEBECH Power Designer) allowing us to select a converter, choose the external components according to our output target voltage and current constraints and simulate its behavior (they have another downloadable program called Switcher Pro, but it is outdated and doesn’t have recent modules). It helped me confirm that the default 1.6ms of soft start time of the modules I chose was enough to limit the inrush current.
The second step is to check if we meet the FPGA requirements. The Cyclone V Device Handbook Volume I indicates the relationship between the rise time of the 3.3V rail and the Power On Reset (POR) delay. The Cyclone V Device Datasheet states that there are two POR delays that we can select: a fast one, between 4 and 12 ms and a standard one, between 100 and 300ms. In conclusion, the soft start time is quick enough for our FPGA to start properly.
Speaking of inrush current, we are in the worst case scenario for the FPGA inrush current at startup because we are powering all the banks with the same power rail (i.e. at the same time). But it translates to at most 2.92A for a maximum duration of 200µs (see table 10-1 of the Cyclone V Device Handbook Volume I), which is inside of our estimated power envelop.
Lastly, we need to be able to have very quick changes in current drawn on our 5V rail. The TI tool is a little buggy and depending on the component I choose in my design, the simulation can have voltage spikes (in the hundreds of volts, unrelated to the current being drawn). So I couldn’t simulate with higher output capacitor than the one selected by default (540µF), which would have probably reduced the output voltage variations (here: -4%, +2%). The current variation has been based on the rise and fall times of our LED drivers (TLC5957), which are respectively 40 and 16ns. The other interest of this simulation is the current actually used from the 12V rail: up to 12A.
However, I wonder if it wouldn’t be easier for the schematics to use the same module twice.
Because finishing the design of the PCB is now the priority task, I’ve been working on several parts of it: namely, linking the SD card connector and the galvanometer drivers.
The microSD card connector we found in ExpeditionPCB is manufactured by JAE (Japan Aviation Electronics). The pins correspond to those of the microSD standard and are linked to one of the SPI interfaces available on the STM32F7. MicroSD cards can work on supply voltage from 2.7 to 3.3V, so we just use the same 3.3V supply as the F7.
The drivers of the galvanometer work with a balanced analog input ranging from 0 to 5V. Since the DAC of the F7 outputs a single-ended signal ranging from 0 to 3.1V (according to the datasheet), this is an issue we had to resolve.
We basically had to convert an analog single-ended signal to a balanced one, and amplify it with a 5/3.1 ratio. We achieved this by using an ADA4941-1 amplifier with two resistances, as represented below.
This circuit is composed of a non-inverting amplifier (taking IN and FB as entry), which, with the resistances of 10kΩ and 6.2kΩ, multiplies the signal by 1+3.1/5 = 1.62 = 5/3.1 (approximately). Then a inverting amplifier with a gain of 1, create a signal symmetric to the OUTP signal with respect to the REF signal value. We set REF at 5V so that the signal can have a 5V range around the offset value of 5V. That’s also why we linked the REF signal to the GND port of the driver, so that the driver can see the signal as a balanced signal.
For the two processors STM32F7 and the STM32F1, we need to use externals clocks. Indeed, for the STM32f7, the processor can use a 16MHz internal clocks, but in order to have the best performance STM32F7 can provide, we will add an external clock of 26 MHz. We will do the same for the STM32F1, but with an external clock of 16 MHz.
Also, we will use two XLR connections in order to have a sound signal wich the animation will be synchronize with. After find out about XLR connection and signals, I understood that a connector XLR has 3 pins, carry at 24 V, and receive two symetrics signals but out-of-phase. So, we have to desymetrize the sygnal. To this end, we will use an instrumentation amplifier:
Wednesday afternoon, the teachers suggested that we make the icosahedron bigger while keeping the same amount of LEDs. This avoids packing the insides together too much, and holes in the PCBs will improve cooling, which is even more important than we previously thought because we messed up the consumption estimation (too low).
The new sphere will have a 35-ish cm diameter (triangles have 18.5cm sides now). I’m currently changing the way we place LEDs: before, we specified spacing constraints and our OpenSCAD program would then put as many LEDs as possible on the triangle. That’s no longer what we want: we want a fixed number of LEDs on the triangle, and the program’s job is finding the layout. For instance, one can specify a number of rows and a different number of LEDs for each row.
When I’m done with that, I’ll print the triangles on paper as a check and then perhaps build a full-scale model with them (thin cardboard will do the trick, I think). It’ll be useful for designing the inner structure, checking that the LEDs layout is uniform enough, and of course, cluttering our desks !