The difficulty with the resolution is that at the end of the day it all comes down to size. More LEDs require more board space, more board space presents a much greater mechanical challenge and costs more money.
MKI used 5mm clear through hole LEDs due to cost and ease of use. If these are all packed in as tightly as they possibly can and interlaced, then the minimum PCB diameter required to accommodate them can be calculated as:
D = (N*5)/Pi
without taking into consideration shaft diameter. In hindsight diffused LEDs should have been used; clear LEDs provide very small points of light, rapidly losing luminosity as viewing angle increases i.e towards the edges of the sphere. I took a brillo pad to them in an effort to diffuse them which was fairly successful but far from perfect. If diffused LEDs were used then the calculation becomes:
D = (2*N*5)/Pi
meaning even the original LED resolution would require a PCB with diameter of at least 407mm.
For Globe I switched from through hole LEDs for which the smallest RGB versions are 5mm to domed right angle surface mount. These have a body length of 3.2mm but a dome of only 2mm. By once again interlacing the calculation for diameter becomes:
meaning we could fit our original 128 LEDs onto a ~165mm PCB…or cram even more LEDs onto a PCB of the same size.
Because PCB is generally paid for by the square cm/inch, the cost increases exponentially with diameter. Realistically I didn’t want to push the diameter much beyond 300mm MKI, having used a PCB of similar size previously and the cost just becoming silly otherwise. If we rearrange our calculation we can calculate the amount of LEDs we could fit on a board of that size to:
N = (D*Pi)/(2*2)
If we account for a 40mm shaft + an additional 60mm for peripheral connections this becomes:
N = ((D*Pi)-100)/(2*2)
With a strict board size of 300mm this would yield an LED count of 210. Fudge the numbers a little bit and we can achieve an LED count of 240, board diameter of 310mm with the bottom 10% of PCB being taken up with connections. This means that the displays imaginedresolution is 270 which is a convenient factor of 1080, so what you see is a vertical resolution divided by 4 with the bottom 30 pixels cut off.
Mark I had an resolution of 1024 x 128 yielding a total pixel count of 131,072. Globe has a resolution of 1920 x 240 yielding a total pixel count of 460,800.
Depending on how funding does I will investigate the possibility of switching to flex PCB bent round the outside of a hoop. This would mean I could switch over to some very small 1x1mm LEDs with a lens of only 0.6mm meaning it would be possible to fit 2 or 3 times the number of LEDs onto the same diameter display, or with an increase to 400mm possibly even 4 times this meaning a full HD resolution might be achievable…
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  * vertical resolution per bank  * colour depth  * rotation frequency ) 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.
This blog has been written for those who are interested in the development of Globe and the design behind it. I have tried to keep the engineering terms to a minimum leaving it accessible to all, but if you do come across something that you don’t understand please do write a comment and I will attempt to better explain it.
I have also tried to keep the posts honest; where something has gone wrong either by a silly mistake, oversight or just bad luck, I have left it in. If you are still trying to decide whether to back this project then please don’t be dissuaded when you come across something like this.
The blog posts are meant to be read sequentially and to that end I have tried to make sure their publication dates place them in the correct order, but just in case that goes awry I have also numbered them.
If this project meets its funding target on Kickstarter I shall keep this blog going to provide updates on the progress of the project so do keep checking back here and if there’s something you would really like to see included in the final version, let me know!