LED POV "display" for bicycles

Archive New Product Ideas
1

Hello :slight_smile:

My name is Jorge Pinto. I started the project “Bicycle LED POV” on May 2008. Until now we have a working prototype + schematic + PCB, and some firmware and software.

I think this project is cool because it involves a few different areas as mechanics; electronics; software; visual LED art and art animation. Also bicycles are growing thanks to problems of fossil fuels, and geeks loves bicycles :slight_smile:

Relevant characteristics of Bicycle LED POV:

  • Atmel AVR 8 bits MCU with integrated USB;

  • DataFlash memory of 1 megabyte - holds more than 1,000 images;

  • 64 LEDs at 20mA each one;

  • uses 2 AAA batteries - should work for 1,5 hours with 1,000mA NiMh batteries;

  • Only USB connection with PC needed: very easy to program the images and hack the firmware!!

  • All system parts (hardware, firmware and software) were developed with Free Software tools.

I am looking for some company that wants to assembly and sell it online, worldwide - I would be happy If SparkFun was interested.

It’s a community project with GPL V3 license, If you are interested please contact me to: casainho@gmail.com

Here is some pictures of a working bicycle LED POV - what this project will look like:

http://farm4.static.flickr.com/3111/259 … cbf94e.jpg http://farm3.static.flickr.com/2177/252 … 0fab_o.gif

And here pictures of actual hardware:

http://bicycleledpov.googlecode.com/svn … 2-700x.jpg

http://bicycleledpov.googlecode.com/svn … 1-700x.jpg

See all information about on [Hardware V1.0 page.

Thank you.](Google Code Archive - Long-term storage for Google Code Project Hosting.)

2

A very lightweight, RGB, programmable POV display would be wicked cool if the cost was reasonable. I’d want it fairly removable so that I could only put it on my bike for specific things - I mean I wouldn’t want it as part of my daily commute setup…

3

Shematic is ready:

http://bicycleledpov.googlecode.com/svn … review.png

PCB also (14,5cm x 4,7cm):

http://bicycleledpov.googlecode.com/svn … pcb-01.png

The latest version of schematic and PCB source files version are [always available on SVN server.

NleahciM:
A very lightweight, RGB, programmable POV display would be wicked cool if the cost was reasonable.

You know, actual hardware is programmable but with just one color.

We are anticipating an RGB version :slight_smile: – we are making the actual PCB with connections for free I/O pins of MCU, thinking in this PCB be used to development of RGB version. This system is “hack friendly” to let users implement theirs ideas in most easily way possible.

RGB will be more expensive for sure, thats why we are starting one just one color. Well, If this product have success, maybe some company want to invest and produce a RGB version… because we can develop for free the hardware + firmware + software.

NleahciM:
I’d want it fairly removable so that I could only put it on my bike for specific things - I mean I wouldn’t want it as part of my daily commute setup…

I understand :-) -- and me too, I would like to use this toy mainly on night party night rides or special days like Critical Mass :-)

Thank you for your feedback :wink: :-)](Google Code Archive - Long-term storage for Google Code Project Hosting.)

4

Seems an awfully like Lady Ada’s [Spoke POV product that you can order today.](Spoke POV - Persistence of Vision Toy with Kit)

5

riden:
… like Lady Ada’s [Spoke POV product that you can order today.[/quote]
This project pretends to be an improvement to Spoke POV of Lady Ada’s - Spoke POV was taken as reference, as knowledge base :slight_smile:

Relevant improvements:

  • USB connection with PC for programing images and firmware, while Spoke POV uses a kind of SPI, RS232(??) – Bicycle LED POV is much more “hack friendly” thanks to USB connection.

  • DataFlash memory instead of EEPROM memory – DataFlash for the same price and pin compatible have 32 times more memory, is a new memory technology when compared with EEPROM – With one EEPROM of 32 Kilobytes we can hold 32 images while for the same price we use one FlashMemory that holds 1024 Kilobytes, 1024 images :slight_smile:

  • Spoke POV do not work on GNU/Linux :frowning: while Bicycle LED POV do not need any driver for OS thanks to USB, software is working perfectly now on GNU/Linux and MS Windows - others not tested but should work perfectly.

  • Spoke POV is stopped in development while Bicycle LED POV is open to improvements from community - right now we are 3 persons developing and there is intention to next make one POV with RGB LEDS :-)](Spoke POV - Persistence of Vision Toy with Kit)

6

casainho:
Relevant improvements:

  • USB connection with PC for programing images and firmware, while Spoke POV uses a kind of SPI, RS232(??) – Bicycle LED POV is much more “hack friendly” thanks to USB connection.

I’m all for using USB for projects such as this which need a PC (Macs are PCs for this statement) host interface. As a generic hobby platform which will be connected to a USB host system, I like this arrangement. I’m actually sort of disappointed that nobody’s doing an Arduino port based on the AVR USB chips (instead of sticking an FTDI chip to a 168).

The last time I checked, however, the AVR USB chips were more expensive than the regular AVRs (yet [cheaper than an FTDI chip). And this application only needs to be using USB when in contact with the host. I’d think the software approach (of which [this is an example) might be appropriate here, if these are to become something that would be produced in any volume as the spoke POV is. The aforementioned software approach suggests itself here since, though it uses a lot of CPU, the USB would only be in use when connected to the host, and could be disabled in the usual mode when you need the CPU for refreshing the display.

There’s nothing wrong with using RS-232 (even just the TTL lines) for the host interface.

casainho:
DataFlash memory instead of EEPROM memory – DataFlash for the same price and pin compatible have 32 times more memory, is a new memory technology when compared with EEPROM – With one EEPROM of 32 Kilobytes we can hold 32 images while for the same price we use one FlashMemory that holds 1024 Kilobytes, 1024 images :slight_smile:

Can’t argue with that. :slight_smile:

casainho:
Spoke POV do not work on GNU/Linux :frowning: while Bicycle LED POV do not need any driver for OS thanks to USB, software is working perfectly now on GNU/Linux and MS Windows - others not tested but should work perfectly.

Without looking at Spoke POV, just off of comments I’ve read, I’m guessing Spoke POV is programmed using the AVR ISP interface. In a manner similar to that for loading firmware. If my guess is correct, there’s no reason why Linux support for it couldn’t be created. There are already several ways to program AVR devices over the ISP interface in Linux.

casainho:
Spoke POV is stopped in development while Bicycle LED POV is open to improvements from community - right now we are 3 persons developing and there is intention to next make one POV with RGB LEDS :slight_smile:

A perfectly valid and meritorious point.

I might suggest making the board less wide, if you can, so as to reduce the extent to which it will act as a wind vane. Does using SMT LEDs confer a benefit that you’re exploiting? Last I checked, SMT LEDs costed more than the through-hole variety; especially when thinking about RGB.

Why AAA cells? AAs would get you over double the run time, and they cost about the same.

Is the RGB version going to be much the same, only with 3 times as many latch chips in the chain?](http://www.obdev.at/products/avrusb/index.html)](http://dorkbotpdx.org/blog/feurig/benito_my_first_at90usb162_project)

7

lou:
I’m all for using USB for projects such as this which need a PC (Macs are PCs for this statement) host interface. As a generic hobby platform which will be connected to a USB host system, I like this arrangement. I’m actually sort of disappointed that nobody’s doing an Arduino port based on the AVR USB chips (instead of sticking an FTDI chip to a 168).

Although i don't use Arduino, i agree with you and i already thought a lot about it!!! I even started recently a [[code.google.com project with name "Open USB AVR"](http://code.google.com/p/openusbavr/) with objective of sharing source files for KiCAD or GEDA of schematic symbols and PCB footprints and even cheap and simple starter boards -- maybe the same as Arduino hardware :-) -- For software, I will suggest [[MyUSB Library](http://www.fourwalledcubicle.com/MyUSB.php) because have rich examples, host and device USBs :-) - also Atmel USB drivers.

There is AVR 8 bits USB and AVR 32 bits USB, I plan to work with both on that [“Open USB AVR” :slight_smile:

lou:
And this application only needs to be using USB when in contact with the host. I’d think the software approach (of which [this is an example) might be appropriate here, if these are to become something that would be produced in any volume as the spoke POV is. The aforementioned software approach suggests itself here since, though it uses a lot of CPU, the USB would only be in use when connected to the host, and could be disabled in the usual mode when you need the CPU for refreshing the display.[/quote]
Right as you said, see one image that describes the actual firmware ([see here the wiki page):

http://bicycleledpov.googlecode.com/svn … iagram.png

I don’t agree with you about using the “www.obdev.at AVR-USB software-only”, mainly because one thing, the AVR MCU must be programmed first time with that firmware!!! While AT90USB MCUs came from Atmel factory with USB bootloader, which means is very easy to hack the firmware!! No need to have another hardware programmer, the ICSP :slight_smile: – this perspective is for DIY, or for some one that will exchange their MCU, not for some company that have one ICSP to program MANY boards, like the one where i work :slight_smile:

lou:

casainho:
Spoke POV do not work on GNU/Linux :frowning: while Bicycle LED POV do not need any driver for OS thanks to USB, software is working perfectly now on GNU/Linux and MS Windows - others not tested but should work perfectly.

Without looking at Spoke POV, just off of comments I’ve read, I’m guessing Spoke POV is programmed using the AVR ISP interface. In a manner similar to that for loading firmware. If my guess is correct, there’s no reason why Linux support for it couldn’t be created. There are already several ways to program AVR devices over the ISP interface in Linux.

I must say that I also don't know much about Spok POV because I didn't bought it - to say the true, I don't like it because I can't use it, I just use GNU/Linux Ubuntu on my PCs.

SpokePOV firmware can for sure be programed by ICSP. After than that, there is a specific software to draw and send images from PC to hardware, and that program is OS specific and do not work on GNU/Linux :frowning:

lou:
I might suggest making the board less wide, if you can, so as to reduce the extent to which it will act as a wind vane. Does using SMT LEDs confer a benefit that you’re exploiting? Last I checked, SMT LEDs costed more than the through-hole variety; especially when thinking about RGB.

About board less wide, I must say that this is my first time working with KiCAD, I don't have experience doing PCBs, I just see other person doing that on my daily work, using Eagle. Also Donald Ziems, the other person working on schematic and PCB, is not professional on PCBs design.

About SMT components, I am using sizes of tracks and vias that I can drill on a CNC machine at work, with other small sizes PCB can be smaller for sure :slight_smile: – also with time we will get it :slight_smile:

SMT LEDs and other components because i am used to them, at my daily work – electronics circuits for LEDs lamps of cars, stop and tail mainly.

But, this project is result of the people working on it, if you can and want to participate, please join the discussion group of the project :slight_smile:

lou:
Why AAA cells? AAs would get you over double the run time, and they cost about the same.

Smaller size and weight. This project is not optimized for big number production, for cost!! more for DIY.. because for big number production, Spoke POV should be ok. Using USB means an expensive MCU plus royalties fees for using USB commercially - this are disadvantages for using USB, but I even prefer to pay more for that and have a system that is very easy and cheaper to hack - isn't this the keys of Arduino success?

lou:
Is the RGB version going to be much the same, only with 3 times as many latch chips in the chain?

Donald Ziems is the one interested in making after the RGB version. And yes, he told me about that possibility, of 3 times more data latches ICs. For sure that memory and MCU will be enough for RGB version... actualy, this board is very good to hacking, be it the next RGB version or some other thing not imaginable right now :-)

Thank you :slight_smile: – was a pleasure to receive all this feedback/ideas :-)](Google Code Archive - Long-term storage for Google Code Project Hosting.)](http://www.obdev.at/products/avrusb/index.html)

](Google Code Archive - Long-term storage for Google Code Project Hosting.)](Four Walled Cubicle - LUFA (Formerly MyUSB))](Google Code Archive - Long-term storage for Google Code Project Hosting.)

8

casainho:
I don’t agree with you about using the “www.obdev.at AVR-USB software-only”, mainly because one thing, the AVR MCU must be programmed first time with that firmware!!! While AT90USB MCUs came from Atmel factory with USB bootloader, which means is very easy to hack the firmware!! No need to have another hardware programmer, the ICSP :slight_smile: – this perspective is for DIY, or for some one that will exchange their MCU, not for some company that have one ICSP to program MANY boards, like the one where i work :slight_smile:

Well, there is that. What if one manages to hose the bootloader?

I suppose it’s the same if one hosed the serial bootloader on an Arduino.

casainho:
SpokePOV firmware can for sure be programed by ICSP. After than that, there is a specific software to draw and send images from PC to hardware, and that program is OS specific and do not work on GNU/Linux :frowning:

You’re already going to be doing most of the work of writing that software under Linux. The only difference being the communication protocol. Heck, you could probably even implement both back ends if you wanted to.

casainho:

lou:
Why AAA cells? AAs would get you over double the run time, and they cost about the same.

Smaller size and weight.

Really? There is a whole lot of open space on that board. AAs are only a little longer than AAAs. It might even be possible to design the board to accommodate either one. The weight difference is probably roughly equivalent to the mAh difference. What problem does the additional weight impose? You already have the cells nearer the hub end than the tire end of the spokes, right?

casainho:
This project is not optimized for big number production, for cost!! more for DIY… because for big number production,

I get that.

casainho:
Using USB means an expensive MCU plus royalties fees for using USB commercially - this are disadvantages for using USB, but I even prefer to pay more for that and have a system that is very easy and cheaper to hack - isn’t this the keys of Arduino success?

There are “cheap” MCUs that can do USB. Especially when one considers not having to add an FTDI chip. You’re already using one of them. And, then, of course, there’s the software implementation on low end AVR chips.

I’m not trying to talk you out of using hardware USB. I personally prefer it. It is just good to explore all options without discarding them for reasons that one cannot defend. I consider the hobbyist orientation to which you refer as a viable defense for your position in general and maybe even for this particular project. It just falls down if you ever get into a cost-sensitive situation such as mass-production.

Hardware USB just seems like overkill for this particular application. You’re cool with that, and that’s fine.

As for royalty fees, I assume you’re referring to the USB-IF dues and fees. You don’t have to pay those or submit to their certification testing unless you want to use the USB logo with your device. There are vendor/product ids you can use if you follow a few rules regarding your string descriptors.

The key to the Arduino’s success is that they developed an environment that makes it easy for people, who don’t necessarily even know how to code, to scale enough of the learning curve to do something with it pretty quickly. Most of that is on the compile/build side of things. Some of it is that the bootloader lets you program the firmware over the serial port, which everybody has or can get ubiquitously. Some of it is that the design and software are open. It certainly isn’t price, though having a design with broad appeal does help with efficiencies of quantity. If it were about price, the Arduino would be closer to $15 than $30.

9

lou:
Well, there is that. What if one manages to hose the bootloader?

I suppose it’s the same if one hosed the serial bootloader on an Arduino.

Sorry - my English is limited, I couldn't understand. Can you please explain better your idea?

lou:
You’re already going to be doing most of the work of writing that software under Linux. The only difference being the communication protocol. Heck, you could probably even implement both back ends if you wanted to.

I am not working on software, but since I know, Ricardo Lameiro (the one working on it) is using Python and a library for serial port - that library should be available on GNU/Linux em MS Windows, etc. We are using "USB-RS232 Device", so we get a general serial port on PC.

lou:
Really? There is a whole lot of open space on that board. AAs are only a little longer than AAAs. It might even be possible to design the board to accommodate either one. The weight difference is probably roughly equivalent to the mAh difference. What problem does the additional weight impose? You already have the cells nearer the hub end than the tire end of the spokes, right?

Yes, there is space on board. We decided for the smallest batteries rechargeable, normally available in all houses. In this case, AAA are smaller, less weight and that estimated 1,5 hours should be enough, IMO.

Well, Donald Ziems talked about using Lithium ion on RGB version… so, who knows? – I guess that If a company wants to make a medium volume production, the system must be optimized for price, so, all this that we are talking be different – actually is more like a project for our taste… :slight_smile: all is possible :slight_smile:

lou:
… It just falls down if you ever get into a cost-sensitive situation such as mass-production.

You are right... but now I am more focused on making this for DIY. If some company wants to sell it, then that company should work on that optimization, not me :-) -- I see this as a DIY project and a kind of prototype, for some big company take this idea :-) -- do you know, my main interest is learning electronics and firmware and help on a green planet, in this case, help on "bicycle idea" -- I would be very happy If some company would make this project even If more simple like Spoke POV.

lou:
As for royalty fees, I assume you’re referring to the USB-IF dues and fees. You don’t have to pay those or submit to their certification testing unless you want to use the USB logo with your device. There are vendor/product ids you can use if you follow a few rules regarding your string descriptors.

Hmmm... I must inform myself about that. I would be happy try to sell some units on Ebay, I am curious of how people will react to his toy -- sometimes I go to Ebay to find "strange" things with LEDs, etc :-)

lou:
The key to the Arduino’s success is that they developed an environment that makes it easy for people, who don’t necessarily even know how to code, to scale enough of the learning curve to do something with it pretty quickly. Most of that is on the compile/build side of things. Some of it is that the bootloader lets you program the firmware over the serial port, which everybody has or can get ubiquitously. Some of it is that the design and software are open. It certainly isn’t price, though having a design with broad appeal does help with efficiencies of quantity. If it were about price, the Arduino would be closer to $15 than $30.

So, from all that you said, using this AVR USB with USB bootloader preloaded on factory, the only advantages I see is that the MCU can be bought in any shop and not at specific one that preloads the bootloader; you don't need to have one more hardware device to program it by serial port since USB is available on all modern computers while serial port no.

I think price is one good reason - because we can find Arduino in a lot of shops by that small values and all software tools are free. I don’t think $30 is expensive for a board like that. I belive that soem shops simple don’t sell Arduino because it’s cheap and they prefer to sell other not so know boards to be able to have higher prices.

I really like the Arduino success :slight_smile:

10

casainho:

lou:
Well, there is that. What if one manages to hose the bootloader?

I suppose it’s the same if one hosed the serial bootloader on an Arduino.

Sorry - my English is limited, I couldn't understand. Can you please explain better your idea?

Ok, let’s consider your case. The chip comes from the factory with a bootloader pre-burned in the FLASH. There may even be one or more lock bits burned to prevent accidentally overwriting it. However, if a user manages to unlock the flash and burn something wrong there, the board will be bricked, and you won’t be able to upload new firmware to fix it. Maybe it’s an unlikely scenario, and maybe it’s not, but if it happens, the user is hosed unless there is, at least, an ICSP port to use to save the board from becoming landfill.

casainho:

lou:
You’re already going to be doing most of the work of writing that software under Linux. The only difference being the communication protocol. Heck, you could probably even implement both back ends if you wanted to.

I am not working on software, but since I know, Ricardo Lameiro (the one working on it) is using Python and a library for serial port - that library should be available on GNU/Linux em MS Windows, etc. We are using "USB-RS232 Device", so we get a general serial port on PC.

“You” includes everybody working on the project. Thus, Ricardo.

casainho:

lou:
There are vendor/product ids you can use if you follow a few rules regarding your string descriptors.

Hmmm... I must inform myself about that

https://whatever.metalab.at/user/cs/avr … icense.txt

11

lou:
Ok, let’s consider your case. The chip comes from the factory with a bootloader pre-burned in the FLASH. There may even be one or more lock bits burned to prevent accidentally overwriting it. However, if a user manages to unlock the flash and burn something wrong there, the board will be bricked, and you won’t be able to upload new firmware to fix it. Maybe it’s an unlikely scenario, and maybe it’s not, but if it happens, the user is hosed unless there is, at least, an ICSP port to use to save the board from becoming landfill.

The only way to user overwrite the bootloader, to "unlock the flash and burn something wrong there", is using ICSP, so, If user do that should also be able to recover. There is no ICSP connector on board so will be able to do that wiring cables to SPI DataFlash, for example.

“an unlikely scenario” as you said, I also think :slight_smile:

casainho:

lou:
There are vendor/product ids you can use if you follow a few rules regarding your string descriptors.

Hmmm... I must inform myself about that

https://whatever.metalab.at/user/cs/avr … icense.txt[/quote]

Thanks :slight_smile: – I will ready later with carefully.