:: spoke n' light ::

1. Hardware:
   1. LED control. The use of LED drivers seems impossible because of the timing issues described in Prototype I. One option would be to use a couple of drivers and switch between the two (something like "double buffering" the LED display). To keep things simple, I will directly control the LEDs from the PIC. I will stick to the 18F452, as I know it already and can live with 32 LEDs.
   2. Grayscale images. Using digital potentiometers to control each LED is out of the question. PWM is the only way to get some grayscale, but the fast motion of the LEDs may not allow for PWMing. To be tested.
   3. Transistors. I will use the same architecture (sinking the LEDs through transistors). I got a version of the transistor arrays that has eight transistors on each chip, so I only need four of those.
   4. Power. By using a couple of "AA" batteries to directly run my LEDs, I can get rid of the 220 Ohm resistors that I currently use to protect the LEDs from the +5V running on the board. Still not sure if the PIC can run off this +3V power source or will require a different battery.
   5. Powerless. Is there a way to generate enough electricity for the device to run from the fast rotation? I am sure a set of wire coils and magnets placed in the right spots can give some juice...
   6. Powered Oscillator. Just more accurate and will earn me an additional output pin.
   
   
2. PIC software:
   1. Uploading images. It would be nice if displayed animation could be sent via serial, IR, bluetooth etc. This will require additional external memory, as PICs have a very limited amount of RAM. For future versions.
   2. Sleep mode. The PIC can be put to sleep if it didn't receive a magnetic interrupt for a while (say 5 seconds). It can also automatically wake up based on an external interrupt (magnetic interrupt). So long ON-OFF switch...
   3. Compression. Looking at the header files which contain the animations, there are long sequences of zeros and ones... This can certainly be compressed by the Matlab tools. But can it be decompressed by the PIC in real-time? I started planning the real-time decompressor and will discuss it in a different page.
   
   
3. Matlab tools:
   1. Optimize resolution. Grid2polar should know how much ROM it has free for the vectors and automatically propose a resolution to best fit that memory.
   2. Simulate latency. A slight change in the simulation tool will make it look more realistic. Easier to code that change than explain it here.
   3. Grayscale support. If PWM turns out to be possible, then the Matlab tools should be upgraded to generate vectors with a higher "depth" (more than one bit per LED state).
   
   
4. Mounting:
   1. LED strings. The LEDs strings will be made of clear plastic tubes, so that they are visible from both sides of the bicycle (a dim mirror image will be seen on the reversed side).
   2. Electronics box. The power supply, PIC, and transistor arrays will be housed in a plexiglass case, which will be mounted as close as possible to the center of wheel to reduce moment force.
   3. Forward wheel. The advantage of mounting on the forward wheel is that there are less obscuring objects (gear mechanism etc.) and that the wheel can be easily unmounted (so I don't leave the device in the street). For demo purposes, back-wheel mounting is better as it can be spinned much faster.