14: Working code!

After a lot of head scratching and a fair amount of tweaking the code has finally been beaten into  a working form. Because the hardware isn’t yet finished I have to capture the image by moving a camera with a long shutter speed across the board.

Colours are a little off, only have the boards LEDs were captured and a couple of pixels are dead but aside from that…working
What the earth looks like while static…a random blur of colour equating to a blueish white

The captured waveforms below show that the read/write cycle takes currently takes about 22.5% of the time available in a cycle. Therefore we could theoretically handle a frame rate almost 4.5 times higher at our current rate of 12 fps (not particularly useful) OR a resolution about 4.5 times greater. This would mean that we could potentially reach a resolution of 1920×1080 (much more useful!).

One whole image read write cycle (time high is idle)
Idle for 35.2us out of every 45.4us or approx 77.5% of the time
One line being written to and one line being read from SDRAM takes 10.2us of every 45.4us or 22.5%
I noticed the LEDs and drivers got quite toasty so I had a look on my thermal camera. The temperature measurement suggested the drivers were running about 70 celcius (at peak current sink)

12: Globe PCB v2 soldered and ready for testing

After roughly two full days soldering I am finally finished and ready for testing. There will inevitably be some dry joints/bridges on the LEDs because they are really  fiddly to solder.

I still need to clean the flux residue off along with my grubby fingerprints but I shall do that as the last thing before mounting.


11: Globe PCB v2 arrives

The new boards are in, looking even nicer in matt than they did in gloss and ready for soldering. All those silly little mistakes from v1 have been taken care of so this should go smoothly.


10: Motor madness

After all the motor related issues of the first project I decided something pretty beefy was needed. If at ~480rpm my poor little DC motor was using about 180W, depending on the amount of power being lost as heat, it is fair to say that we will need about double that to be certain of reaching the desired speeds of 720 – 900rpm.

The problem with motors is that not only do you need the motor itself but also the driver which can get pretty pricey. Luckily Tony from the workshop had a spare ABB ACS141 VFD leftover from one of his own projects, capable of driving up to 0.75KW three phase motors.  I paired this with an ABB 1/2HP motor with a nominal speed of 1440 RPM which should satisfy the requirements of this project.

If funding goes ahead I will be looking to downsize the motor and controller, probably switching over to a 24V BLDC so I don’t have to deal with the complications of having the VFD and dealing with three phase inside a commercial product.

2017-03-30 15.20.46
Maybe slight overkill

9: Shiny new sliprings

These slip rings from MOFLON should mean that I never have to suffer the problems that the completely under-specced ones that I used back in the first display caused. Rated for 1500rpm with 4 power and 14 data lines these will allow the transfer of 5V up to 20A, HDMI and USB data and a tachometer pulse.

Depending on how long these last and how the campaign fares I am going to have a look into some gallium alloy/wireless slip rings.

2017-03-23 17.57.36
So very shiny

Update 08/07/2017

As I have been getting quotes in for the various components I will be using for the commercial versions of Globe I hit a little snag. Finding slip rings rated for the sort of lifespan I am looking for has been virtually impossible. The rings in this blog post are rated for 80,000,000 spins, which sounds like a lot, but if you do the math turns out to not be as long as one might hope. If we say that someone is going to have Globe running for 8 hours a day (being used in store for advertising or on display as an art piece) then we can work out the amount of days it would last. Assuming 900RPM then the maths goes like…
(((80,000,000/900)/60)/8) = 185.18 days

So little over half a year of life out of them, which is simply nowhere near good enough. Finding reasonably priced longer life ones has been virtually impossible however. A similar version (minus all the data channels) by moflon would have run up to about $700 PER UNIT and that’s when buying at least 100 units. Considering that most of the slip ring suppliers seem to basically be making the same models, I didn’t have much luck elsewhere.

I then had a look into  to liquid metal slip rings mercury/gallium alloy. An American company called Mercotac do a range of mercury slip rings with a life span up to a billion revolutions…unfortunately because they use mercury that makes them a massive RoHS no-no. Many of the Chinese slip ring manufacturers offer similar liquid metal slip rings, but they actually have an even shorter lifespan that the originals, only about 50,000,000 revolutions.

And so then I came to look into wireless slip rings. These use induction to transfer power over short air gaps, similar to how electric toothbrushes charge. Because they are completely contact-less there is no wear and therefore they have a very long life. The difficulty with them is that they are a fair amount more complex than conventional slip rings and depending on what your input and output power requirements are can involve some slightly complicated electronics.

Very few companies seem to be in the business of wireless slip rings at the moment. A company based in New Zealand, powerbyproxi, have some interesting products including a 150w version, but they are more designed for industrial applications (IP68 rated) and priced as such. While waiting for a quote back from these guys I was having a look at some of the off the shelf components necessary to create my own wireless power transfer system and found them to actually not be too expensive or complicated at all. A fair amount of development and testing would go into creating my own but it actually seems like the most viable option at this point, and may even result in a spin off product (though I imagine there aren’t more non-industrial slip rings on the market due to there being very little demand).



8: Safety first

The MKI used polycarbonate and aluminium for its case. Polycarbonate is well known for being bloody tough and easily worked, perfect for when you have no idea whether things are going to be flying off at you and you need to throw something together quickly and cheaply. The downside is that it tends to pick up and retain scratches and marks.

Since I am fairly confident that the PCB itself will not disintegrate or have components pinging off I decided to instead go for a pre-built acrylic 5mm edge glued 400mm cube. While not as resilient as polycarbonate, acrylic still has a significantly higher impact resistance than regular glass and far cheaper for one off prototyping than some of the more advanced glasses (tempered/laminated).

If the Kickstarter reaches its funding I am going to investigate the possibility of either switching to either a custom formed acrylic enclosure formed of two semi-spheres or a cube of toughened glass/acoustic.

7: Globe PCB v1 – A somewhat mitigated disaster

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.

This slideshow requires JavaScript.


6: Globe PCBs arrive

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.

This slideshow requires JavaScript.

5: Globe Test PCB

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.

2017-03-23 18.01.07
Purple OSH Park goodness

4: Globe PCB design

POV MKI used 4 PIC32s each controlling 4 TLC5951 LED drivers which each in turn drive 8 RGB LEDs, with one of the PICs acting as master and the other three as slaves. Since we are only increasing the number of LEDs, LED drivers and required SPI control lines, we can either apply more microcontrollers to the problem or switch over to using an FPGA. To use more microcontrollers would simply be too cumbersome (and a pain in the arse to try and interface video with) whereas an FPGA while being slightly more complex to code would make life far more simple in terms of overall circuit design and performance.

The Spartan 6 LX9 is the FPGA of choice, basically as beefy a chip as you are going to get while still coming in an easy to solder TQFP package. Due to having LEDs on both the left and right side of the PCB, the image data for LEDs on one side of the board needs to be offset by half an image from the other side. This means one of two things needs to be done, either the data being streamed via HDMI needs to fudged so that every second horizontal line is half an image offset or the whole image needs to be buffered on the PCB side and appropriately accessed by the FPGA.

  • To do the former would be an absolute nightmare either requiring everything that one wants to display to go through a program that does the fudging or rewriting the entire video driver
  • To do the latter requires the use of an external memory module for the FPGA, one image requiring 1.382Mb (1920*240*24) and the LX9 only having 576Kb. In reality at least two images need to be stored, one for writing in and one for reading out.

The other matter that needs to be considered is the necessary data rate. If we are aiming for 15 FPS then our required data rate will be about 332Mb/s (1920*240*24*2) or just over 41MB/s. Luckily the SDRAM controller that Mike Field wrote can handle that (as long as reads and writes are performed at least semi-sequentially). The SDRAM module used is a 256Mb Micron MT48LC16M16, slightly overkill but it’s hard to get hold of anything smaller.

A TFP401 is used to decode the HDMI LVDS signals into nice 24bit output data with HSYNC, VSYNC, DE and Pixel Clock brought out for easy interfacing. Throw in a TPD12S016  HDMI buffer with inbuilt logic level shifter allowing the EDID to be handled by the FPGA, avoiding having to have an additional EEPROM to store it.

We will be sticking with the TLC5951 which I used in POV MKI. I really like this chip; it offers 12bit PWM control over each channel, a 30Mb/s data throughput, daisy chaining, up to 40mA per channel current sink and a host of features such as global brightness control for each channel. While it’s a bit irritating having to pad and transfer an additional 50% of data, since our images and HDMI data is only 24bit, the high data rate makes up for it. It also comes in both a DSO and a tiny VQFN (which will come in useful if the flex PCB design is explored).

Mark II will use 240 LEDs requiring 30 TLC5951 drivers. The maximum SPI transfer rate for the drivers is 30Mb/s, we can therefor calculate the maximum number of SPI drivers that can be run in with the calculation:
N = 30,000,000/(12*24*15*1920)
So N = 3.62, rounded down to 3, which conveniently results in 10 series of 3, easy to program, layout and route.

Power wise, three voltage supplies are needed: 5, 3.3 and 1.2 volts. The LEDs will require the highest current by far; if each LED channel requires 20mA that’s 60mA per LED*240 LEDs, coming out at 14.4A. For simplicity the board will be supplied by a single 5V supply rail with a current limit of 30A (always better to have a bit of headroom and most power supplies tend run most efficiently at ~50% load) which will use a dual output buck converter to provide the 3.3V and 1.2V. All the LEDs anodes can be connected to the 5V rail; the drivers providing the necessary current limiting. The total 3.3V current requirement should no more than 2A. The TPS54292 provides a 1.5 and 2.5A configurable voltage outputs which should be ample for this design. TIs’ Switcher Pro (soon to be replaced) makes designing your voltage regulator a lot easier than trying to work through equations from the data sheet, thumbs up to TI for that.

While the slip rings should be capable of transferring HDMI signals there is the possibility that they aren’t which is why I am including a Raspberry Pi Zero on the PCB. The Pi Zero is a pretty neat little bit of kit, much smaller and lighter than a regular Pi with minimal connectors on (2 micro USBs, 1 mini HDMI, SD card and 40 PIN GPIO header). In the worst case scenario I can connect the Pi Zero via a miniHDMI to HDMI cable to the port on the bottom of the board (yeah it will look pretty sketchy). For MKIII all the data connections via slip rings will be removed (unless there is an overwhelming demand for them) and instead a Pi Compute module will be added to allow Globe to appear as a networked computer enabling users to wirelessly control, stream content and even RDP to.