Communication to the individually addressable LEDs was established. They were able to changeable by remote and through the serial connection. Automation in the Arduino is still minimized but a couple light tricks, activated by the remote, were programmed anyway.
Originally, there was going to be a single RGB LED on the first iteration of the tagger. This was scrapped since it took three PWM pins and there was already a pin dedicated to individually addressable LEDs. Until a screen is installed, player feedback will happen on a 12-segment LED ring. These are readily available from Adafruit and eBay. It will be up to the programmer how these LEDs are implemented. It would be possible to use it as a life gauge where the LEDs disappear as hits are taken. It would be possible to use it as an ammunition gauge where the lights disappear as ammunition is depleted. It would even be possible to combine the virtual gauges.
Unlike the light ring, which required 12 bytes to determine color, the rest of the LEDs will be a single color. No provisions were written to program them individually. The point of these LEDs will be to light up the tagger and potentially a vest, with a single color to designate the team or notify when a player has been hit. For example, Brian may be playing on red team, so his vest is lit up red. When Jillian, who is on blue team, shoots him, his vest may flash blue for a moment to let her know her shot was successful. Again, this will be up to the programmer.
Normally, individually addressable LEDs are given three color values, Red, Green, and Blue. This is a pretty easy way to mix any color from OFF (all zeros) to bright WHITE (all 255). However, it is also easy to mix up the colors, especially when assigning random colors. As a way to avoid the confusion and reduce communication time, the data sent to these lights will be a single byte.
0 – Off
1 to 191 – Color spectrum. 0 is pure red, 63 is pure green, 127 is pure blue, 191 is purple/violet.
192 to 255 – Increasing intensity of white. White is generated by turning on all three LEDs with equal intensity.
Downloads:
The rest of the posts for this project have been arranged by date
First time here?
Completed projects from year 1
Completed projects from year 2
Completed projects from year 3
Disclaimer for http://24hourengineer.blogspot.com/ and 24hourengineer.com
This disclaimer must be intact and whole. This disclaimer must be included if a project is distributed.
All information in this blog, or linked by this blog, are not to be taken as advice or solicitation. Anyone attempting to replicate, in whole or in part, is responsible for the outcome and procedure. Any loss of functionality, money, property or similar, is the responsibility of those involved in the replication.
All digital communication regarding the email address 24hourengineer@gmail.com becomes the intellectual property of Brian McEvoy. Any information contained within these messages may be distributed or retained at the discretion of Brian McEvoy. Any email sent to this address, or any email account owned by Brian McEvoy, cannot be used to claim property or assets.
Comments to the blog may be utilized or erased at the discretion of the owner. No one posting may claim property or assets based on a post.
This blog, including pictures and text, is copyright to Brian McEvoy.
2017-04-09 (Su)
Each light has a pseudo-random color
Originally, there was going to be a single RGB LED on the first iteration of the tagger. This was scrapped since it took three PWM pins and there was already a pin dedicated to individually addressable LEDs. Until a screen is installed, player feedback will happen on a 12-segment LED ring. These are readily available from Adafruit and eBay. It will be up to the programmer how these LEDs are implemented. It would be possible to use it as a life gauge where the LEDs disappear as hits are taken. It would be possible to use it as an ammunition gauge where the lights disappear as ammunition is depleted. It would even be possible to combine the virtual gauges.
Generating a random color for all the lights
Unlike the light ring, which required 12 bytes to determine color, the rest of the LEDs will be a single color. No provisions were written to program them individually. The point of these LEDs will be to light up the tagger and potentially a vest, with a single color to designate the team or notify when a player has been hit. For example, Brian may be playing on red team, so his vest is lit up red. When Jillian, who is on blue team, shoots him, his vest may flash blue for a moment to let her know her shot was successful. Again, this will be up to the programmer.
Flashing LEDs
Normally, individually addressable LEDs are given three color values, Red, Green, and Blue. This is a pretty easy way to mix any color from OFF (all zeros) to bright WHITE (all 255). However, it is also easy to mix up the colors, especially when assigning random colors. As a way to avoid the confusion and reduce communication time, the data sent to these lights will be a single byte.
0 – Off
1 to 191 – Color spectrum. 0 is pure red, 63 is pure green, 127 is pure blue, 191 is purple/violet.
192 to 255 – Increasing intensity of white. White is generated by turning on all three LEDs with equal intensity.
Color scale representation
Downloads:
The rest of the posts for this project have been arranged by date
First time here?
Completed projects from year 1
Completed projects from year 2
Completed projects from year 3
Disclaimer for http://24hourengineer.blogspot.com/ and 24hourengineer.com
This disclaimer must be intact and whole. This disclaimer must be included if a project is distributed.
All information in this blog, or linked by this blog, are not to be taken as advice or solicitation. Anyone attempting to replicate, in whole or in part, is responsible for the outcome and procedure. Any loss of functionality, money, property or similar, is the responsibility of those involved in the replication.
All digital communication regarding the email address 24hourengineer@gmail.com becomes the intellectual property of Brian McEvoy. Any information contained within these messages may be distributed or retained at the discretion of Brian McEvoy. Any email sent to this address, or any email account owned by Brian McEvoy, cannot be used to claim property or assets.
Comments to the blog may be utilized or erased at the discretion of the owner. No one posting may claim property or assets based on a post.
This blog, including pictures and text, is copyright to Brian McEvoy.
2017-04-09 (Su)
Comments
Post a Comment