[CyL3D] Rethinking the motor

We had a long discussion with a student from SpiROSE (last year’s project with a rotative LED panel). He told us the problem they faced with the motor and ESC (Electronic Speed Controller). They could not get a constant speed output from the motor because the ESC was overheating, causing a shutdown and a boot up. It was caused by the motor asking too much current. The motor was one the had on hand and not perfectly fitted to their use. It was rated at 2100 RPM per Volt. While turning at 1500 RPM the ESC pulled 5A on 12V from the power supply, the same 60W would go to the motor, but to rotate at 1500 RPM it only needed 0.7V so the output current from the ESC was closing in on the max output, which caused overheating.

So I am looking for a motor  with a lower RPM per Volts constant. I reckon a motor at around 500 RPM/V would be suitable for our project. For now I have have settled on Turnigy Aerodrive SK3 – 4250-500kv Brushless Outrunner Motor from HobbyKing. 

Another problem was to convey the power through the axis. They had to scrub the anodising paint from the top of the motor to make a connexion to a ball bearing which was connected to the motor shaft. I would like if possible to stay away from passing to much power through the ball bearing as it can cause sparks and damage the balls. To replace this connection I am looking toward brush slip rings.

[CyL3D] Size constraints

As we are proceeding with the schematics and the PCB placing, we are realizing that we will need more than a single PCB to make everything fit. We will then design an horizontal PCB, very much like SpiRose, though ours will be rectangular for budgetary reasons and it will only host our voltage regulators. The interface between the horizontal and vertical PCBs will be three big pads: GND, 3.3V and 5V. Hence, no signal integrity concerns (at least not at this interface). I placed our 12 to 5V converter on Xpedition Layout while conforming to the PCB layout guide of the module.


Furthermore, it appears that the PCB size of 190 by 190mm that we initially chose will be problematic for us to solder the LED automatically: the problem being the width of the PCB. I was going through the process of routing the LED drivers so that we could be stacking five of them on each side of the panel (according to our previous PCB layout idea), but that will have to be abandoned in order to make our PCB thinner. We will put 4 driver on each side and 2 above.

[CyL3D] Finalizing the schematics of our ULPI transceiver

Last friday we had a class about signal integrity. As we learnt about all the problems we could have, I finally understood the use of all the bypass capacitors and some of the other esoteric symbols or annotation that are no longer a mystery (such as 0-ohm resistors or DNI annotations)

Thus, I had to update the schematic of the ULPI/USB subsystem of our project.  You can see it below. Here are some important changes :

  • Disconnected the oscillator ENA pin : according to the datasheet, having the pin on high impedance does enable the oscillator.
  • Added USB power distribution switch, the TPS2051C that is needed not to break our USB device. It limits the current of our usb device to 500mA.
  • Added bypass capacitor to oscillator and power switch.
  • Updated power supply capacitors
  • Added 10K resistor for VBUS, connected to a 10uF capacitor that should be enough for our system. The USB 2.0 specification recommends a 120uF capacitor for hosts but we do not intend to hot-plug our USB device or have a cable between our device and our system. 
  • Added names to everything.
  • Connected the RESETBn pin to our nRST.
ULPI/USB Subsystem Schematic

As such, our ULPI/USB system should work. However, I have a doubt about whether or not I should add a resistor on the wire between the oscillator’s CLK and the USB3320C REFCLK. Our development kit has a resistor on its schematic, but the oscillator’s datasheet does not mention to put a resistor on the CLK output. If anybody has an idea about it, I’d be happy to hear it.

[CyL3D] LED Rooting

Quick post.

I finished placing and routing the LEDs, one each 3.4mm (not minimal but required to ease soldering).

We have less space and MOSFETs are going to take more space than I originally thought. Although, if we use less MOSFETs, it should be fine.

Still, we won’t have much free space at the top of the panel for the LED drivers. Since they are quite small, I think we can put them on the two sides.

Here is the updated routing idea:

Booting the FPGA & Schematization of the USB3320

For the past days, I have been working on the schematics of our ULPI transceiver, the USB3320 and when my colleagues were working on other parts of the schematics, I had to focus on other stuff such as making our SOM work and improving our system architecture.

Making our Cyclone V SOM work was a breath of air compared to the schematic part. Following the Quick Start Guide of our development kit, I had to make sure the jumpers were setup correctly (and they were – not sure if it was the factory default or if Alexis did his magic before giving us the devkit) and configure the UART0 interface. Once everything was set and connected on /dev/ttyUSB0, I simply plugged in the devkit and it booted correctly.

You can see the booting log on this pastebin post

As we would like to be able to use Wi-Fi USB dongles, we are currently adding host USB 2.0 support. Unfortunately, we must use the ULPI interface to communicate with our USB devices. Thus, we have to use a ULPI-USB transceiver.

ULPI works with a 60MHz clock and I am unsure for now if our FPGA can generate such an accurate reference. However, the USB3320 can work with a external oscillator and it has its own PLLs to generate a 60MHz clock from a 12MHz reference clock.

Below is a work in progress of the schematic of the USB3320 in our system. It also includes a Linear Voltage Regulator as the transceiver also needs a 1.8V DC supply. 

What is definitely missing are the appropiate capacitors and resistors that I have not added everywhere yet.

USB3320 Schematic (WIP)

[CyL3D] Schematics + routing continued

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,

[CyL3D] Decoupling of the SoM

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.

Auto decoupling

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).

Auto decoupling

Development board decoupling

Development board decoupling: capacitors

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.

Development board decoupling: impedance

[CyL3D] Motor’s First Turns

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.

LED pannel rotating.
Slowed down 16 times.

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.

[CyL3D] LED Routing

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.

[CyL3D] DC-DC converters

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.

Inrush current at startup

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.

Load transient

However, I wonder if it wouldn’t be easier for the schematics to use the same module twice.