Author: edcatley

Ok so this one was mostly my fault. Despite all the time I spent agonising over the schematic entry I ended up cocking a few things up. I was considering pasting and hot airing the board rather than manually soldering but since this would require doing each side of the board all in one go and anticipating potential screw ups I decided to manually solder stage by stage, testing as I went…wise choice.

Before I detail all of these I will mention what went right:

• Voltage regulator: The voltage regulator does its job giving a nice clean 3.3V and 1.2V
• FTDI: The FT2232 does its job allowing me to program the FPGA and communicate with it.
• HDMI buffer: Does its job, level shifts nicely, impossible to tell if it does anything to the HDMI signal since A. the HDMI sockets screwed (more on that in a sec) and B. I don’t have easy access to a scope to check the signal anyway.
• FPGA: After some tinkering I was able to program the FPGA and test that it does at least something that I told it to.

So what went wrong?

• FPGA flash: I switched the SI & SO lines resulting in the flash being unprogrammable it first. Straightforward fix to cut the traces and swap the lines. After that it was programming happily.
• FPGA configuration: Some pins that should have been pulled high or low for configuration were not/connected to things which would pulling in the wrong direction. Fixed by cutting traces, rewiring and adding pull up/down resistors where needed.
• Thermal reliefs: The thermal relief connects for the polygons were too big (I failed to take into account the use of 2oz copper), making soldering the ground connection on pretty much all the components a massive pain. This caused occasional dry joints and in general slowed down the assembly.
• Untented vias under components: Putting vias under components was fairly mandatory for a 2 layer board with fairly dense component placement, leaving them untented was not. By not doing so caused the excess solder added during the SMD soldering process to cause a short behind the package legs between 3.3 and 1.2V. A simple continuity test between all power rails after this prevented any damage to the board but did require further time to be wasted visually inspecting and fixing any time such a problem did crop up.
• HDMI socket: Somehow during the move from Eagle to Altium the schematic component library got screwed with the negative and shield pins getting switched on every single data and clock line. To fix this should have been possible…just, but would have required some pretty ninja like cutting and wiring. Even then it may not have worked since the traces would no longer be matched lengths.

Aside from a few other trivial issues there wasn’t too much else that went wrong. Once I hit the HDMI issue and realised what a pain it would be to fix I decided that simply getting a new board made with all the other problems fixed would be the sensible route. While being another £250 expense which I could have really done without, I felt it would be best to have a prototype that didn’t have cut traces and wires hanging off it for any pictures that would feature in the Kickstarter campaign. It also gave me an opportunity to remove the clock and data buffers (unnecessary as I will send this data through the GS lines) and the ESP8266 wireless module (unnecessary due to the recently released Pi Zero having in built wifi).

So at the time of writing this my new PCB has just shipped from China – cue import duty, which should turn up towards the end of this week. The only manufacturing difference between this board and the last is the decision to go for a matte black solder mask, mostly just out of curiosity. I will have a little vote on which people would prefer.

 

PCBs are in from China. I always buy two since most of the cost goes into tooling and it’s always good to have a backup in case you accidentally  screw one up beyond repair.

I used PCB Cart and I am pretty damn pleased with the service.

I wont go into too much detail about the PCB layout, aside from answering the question that most people are probably asking when looking at this; “why is there so much empty space in the middle of the board, it makes it look a bit strange?”. The answer to that is that I originally intended to design the board with big crescent slots cut out on either side to reduce air resistance when it’s spinning because without them it will be moving a fair amount of air. Unfortunately I am not a mechanical engineer and I really don’t know whether putting the slots in would cause the disk to become structurally unsound when spinning or even whether putting those slots in would help all that much after all it is the PCB that is closest to the edge that is travelling fastest and therefor going to have most air resistance. It is something I would love to investigate but I simply couldn’t afford to risk this PCB breaking. If the Kickstarter campaign gets funded I will definitely try sticking some in there, possibly with hilarious results.

I went for:

• 3.2mm PCB: MKI was made with a standard 1.6mm substrate which had a little bit of flex in it. Considering that I am spinning this board faster and that it’s slightly larger I wanted to ensure that flex was kept to a minimum in case it caused breaks in solder joints/traces. I can assure you all this board is very rigid, I might even be able to reduce the thickness to 2.4 or even 2mm. As with the lack of slots, better to pay a few $ extra to minimise the risk of the thing breaking apart.
• 2oz copper: The 5v power line is distributed to the LEDs in two large arc traces around the edge of the PCB. Without wanting these traces to become too wide and push all other components towards the centre I decided to bump up to 2oz copper.
• Silver immersion: Probably could have got away with HASL here but it only cost about $20 more and I was doing a lot of SMD soldering I thought it was probably for the best. It’s a slight departure from ENIG which is what I would normally opt for; I chose it because it is less likely to form a brittle joint and also happened to be a smidgen cheaper.
• Black solder mask: Generally I go for green solder masks because I’m poor and most of the time no one is going to see your PCB anyway. Since the whole point of this PCB is to be on display looking badass I decided to shell out a little more for black. While it tends to show up scratches a little more and is virtually impossible to see traces for visual inspection when you have to *ahem* cut them to fix an inevitable mistake you made, I am pretty damn please with the result.

Before investing too much time and money in designing the full Globe PCB a smaller test board was needed. The purpose of this PCB was to test the following:

1. TFP401 interface with FPGA
2. SDRAM interface with FPGA
3. Modifying EDIDs
4. FPGA SPI controller & interface with TLC5951
5. First version of code

The board was designed as a shield for the Papilio Pro. The P. Pro is a development board with a Spartan 6 LX9, 64Mb of SDRAM and an FT2232 USB interface with 48 female headers. If you are interested in playing round with an FPGA it makes a great place to start.

The shield had a TFP401A, a couple of linear voltage regulators, 4 daisy-chained TLC5951s, an HDMI socket and a small EEPROM to hold the EDID.
at this point I hadn’t settled on the number of TLC5951 to be connected in series or the use of the HDMI buffer to handle the I2C level shifting for the EDID FPGA interface.

The nice thing about the code written for this test board was that it was more or less the code required for Globe. While it only made use of two of its SPI lines the code for all additional ones was implemented as well, all data that would be required for the full board was buffered, written to and read from the SDRAM.

The nice thing about the SPI control of the LED drivers is that it is pretty easy to tell whether the code is doing what it’s meant to be doing at a glance. If I make the PCB “screen” fully green, if the code is working then all the LEDs will become statically green. If the latch signal occurs incorrectly or the data ends up skewed during its buffering, even if a single bit is lost or appended to the data the resultant LED colour just becomes an ever changing jumble.

Suffice it to say, everything worked…eventually.

The Globe project started out in 2012 as my final year project of my bachelors degree at the University of Kent. Before I get stuck into this blog, depending on which end you are reading from, I fully acknowledge that this first version looks shonky as hell. Provide a third year with a tiny budget and an overly ambitious project and the result is a half working travesty with an amusing backstory.

It used 4 PIC32 microcontrollers each driving 4 daisy chained TLC5951 LED drivers to achieve a total resolution of 1024×128 24bit colour. Each LED driver can achieve a transfer rate of ~30Mb/s  which in the current configuration would be capable of delivering the required data of ~18Mb/s (horizontal resolution [1024] * vertical resolution per bank [32] * colour depth [36] * rotation frequency [15]) with a fair amount of time to spare for overheads. Able to store about 4 pictures in the program memory of the PIC’s it could cycle between these images…and that’s about it.

Originally intended to be programmable via an Xbee blutooth module (never got that working) it required spinning down and manually programming with 4 different hex files each time the code or image list needed changing which became extremely tedious.

Due to a very limited budget and my own inexperience this first iteration suffered from intermittent dropouts of banks of LED drivers due (from what I can tell without being able to probe a PCB doing about 480RPM) to power transfer issues initially via my own DIY slip rings and later a set of 300RPM rated ones from China (they helped, but not much).

In addition to the dropouts the display also never appeared to the human eye quite as it was meant to. Due to health and safety concerns the University wouldn’t let me go ahead with my original plan for the motor which went something along the lines of “just rip one along with its driver out of a broken washing machine and bung it in there”. I can kind of see their point…
Sticking to low voltage and having not much money but needing something with a reasonable amount of oomph left me in somewhat of a difficult position. In the end I settled on an RC starter motor. At about 7V it draws about 25A so got pretty toasty after running for about a minute. My solution was to cut some big slots in the casing, pointed a fan at it and hoped for the best.
The problem with this motor, coupled with the dropout issue, was that it prevented the board ever spinning at the speed it was meant to. As mentioned in one of the other posts, the POV effect to really work the board would ideally be spinning at 700-900rpm. Being limited to sub 500 meant that to the human eye the display always appeared somewhat faded and washed out.

Edit 08/09/2017 – What was said above about the washed out appearance being caused by the slow spin speed is partially correct, but the problem is almost certainly more related to the lack of gamma compensation. The need for gamma compensation is something I realised when working on Globe and is pretty thoroughly covered in this Adafruit article.