Spoke POV: Schematics

Continuing on from the previous post (http://jovanranst.blogspot.be/2017/03/spoke-pov-idea.html), I'll be working out the schematics and looking into some problems/restrictions in this design.

General schematic

To get a good grasp of what will be necessary, I always make an abstract plan before even thinking about the actual hardware chips and such. Problems are so much easier to see ahead of time if you simply make a drawing. So here it is:

Ir's pretty strait forward:

1. The LED matrix needs 4 8 bit shift registers to control, chaining the shift registers after each other allows the full matrix to be controlled via one SPI communication line.
2. A communication chip via UART, still not decided between WiFi and Bluetooth.
3. Memory for the image data, FLASH is cheap and comes in bigger sizes than EEPROM.
4. The HALL sensor triggering the main controller.
5. Main controller connect all the components.

Problem 1: update speed

One of the first things  to look at is the speed at which the image needs to be refreshed. The baseline 

for this is 12 frames/sec. Any lower than that will result in flickering images.

The frame rate is the same as the rotations of the bike wheel and is calculated as follows

Frame rate[per sec] = speed[m/s]/(wheel diameter * PI)

If for example, as is on my city bike, the wheel is 28 inch (71.1cm) and you are riding 20 km/h the resulting frame rate will be: 2.5 frames/sec. Which is way to low to provide a clean image AND you're already driving at 20 km/h.

To solve this I will be placing 4 led bars in each wheel, as this will instantly increase the frame rate fourfold. As now each led bar only have to display a quarter of the image in a quarter the rotation.

So the speed is now: frame rate[per sec] = (speed[m/s]/(wheel diameter * PI)) *4

Resulting in 10 frames/sec at 20 km/h and 12.5 frames/sec at 25 km/h. So riding slowly is not an option but 25km/h is realistic.
An added bonus to having four bars means I will have an sync update from an HALL sensor four times per rotation seriously reducing the risk of loosing the image position. Of course this comes at the cost of having four times the hardware. You win some, you lose some.

Problem 2: communication speed

Since I'm using shift register to control the led matrix, I can send the data to them via the SPI interface in the controller.

Additionally with the use of 4 led bars and not wanting to repeat the full master controller on each bar, which would mean a lot of extra cost and handling for no extra functionality, the four bars can be seen as four led matrix's placed one after the other.

This means that its technically one giant line of 4(bars)x4(at each bar) shift register. The problem here again is speed as will be apparent by the following calculation: 

First one small simplification. The amount of data needed to set all the leds of the matrix is defined as 8 times the amount to set one row(3*8bit color shift regs + 8bit common). This is a simplification as it doesn't take into account the load and hold functions of the shift registers.

So one cycle in the martix is 256bits

Presuming each led can only be turned on or off, so one bit color depth, the data the master needs to send to show just one line of the image is:

• 1bit(color)* 256bits(matrix) * 4 led bars = 1024bits of data

This might not sound like much but don't forget, this is just 1bit color and only 1 line in the image. Let's now say that we would take 120 lines in an image, which is not all that much, suddenly its not just 1024bits but 122880bits. AND this needs to be send in the time of one quarter of the rotation speed. Because at that point the next image needs to start. So you get.

• 122880bits at 12.5/sec[25km/h] is 1,536MHz

Very feasible value, but this is still just for 1 lousy bit of color data. An image of only 1 bit color depth is just pathetic. A lot more interesting is something like 256-color, which is the bare minimum we would need.

256-color is stored in one byte(8bits) with 3 for Red, 3 for Green and 2 for blue. Because we are simultaneously controlling all three the colors the blue will still be 3 bits that we need to parse, even if it contains no LSB it needs to be shifted in. 3bit data results in an intensity control per one seventh of the power, so seven transitions need to be made.

• 7transitions(3bit color) * 256bits * 4 led bars = 7168bits of data
• (7168bits *120lines) at 12.5/sec is 10.752MHz

A nearly impossible speed to achieve with small 8bit controllers especially if we add that all this image information comes from the FLASH memory thus meaning that the speed will essentially double. And where not even discussing the rise in speed if the bike goes any faster than the 25km/h. This problem needs to be addressed with a change in the schematic.

This change will be addressed in a coming post but first notice the sudden rise in speed just from going to 3bits in stead if just the one bit.

The speed correlates as follows.

• speed increases with (2^n)-1 with n the number of (highest)bits per color.

So for example 8bits per color equals to 255 times the speed of the one bit, and 16 bits per color is a whopping 65535 speed increase.
The fix in speed will have to come from this exponential correlation.