This badge was going to have at least eight LEDs. I don't have a plan for them, but they will be there. For now, and often in prototyping, lights are a great debugging tool because it is possible to check statuses at a glance. The strip of addressable LEDs I had on hand was from a different project, but they didn't work there, so I am not positive they are functional. Eventually, I gave up and cut them out of the circuit and tried another strip, which did work. I was glad the hardware was all working together.
I wanted continuous feedback from red, infrared, and green statuses. The first LED is red and designates how much red light is visible to the sensor. The second indicator is green and reflects the available green light, and blue displays the infrared light. This pattern repeats across the light strip.
There was trouble when I tried to read the sensor continuously and display the values occasionally. I pondered the problem and then measured the time it took to read the data over the serial line. It took roughly sixty milliseconds from the call to the sensor to the final receipt. I broke it down the microseconds and found the following delays.
• Red19934 microseconds
• Infrared19933 microseconds
• Green19933 microseconds
To display the intensity of each value, I had to scale the incoming readings. The best way I know how to scale unknown numbers is to keep track of the highest and lowest data points that number ever reaches and use the map() function based on those limits. As soon as I implemented the routine, the program refused to run. I looked up the equation map used and found that it is possible to input values for a denominator of zero, and the DIV/0 was the problem. I added an IF statement to ignore any condition that would try to divide by zero, and it worked. I scaled the lights from 0% to 100% based on the reading extremes, and it worked well.
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
Completed projects from year 4
Completed projects from year 5
Completed projects from year 6
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, is 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 their post.
This blog, including pictures and text, is copyright to Brian McEvoy.
2020-01-15
LED strips
I wanted continuous feedback from red, infrared, and green statuses. The first LED is red and designates how much red light is visible to the sensor. The second indicator is green and reflects the available green light, and blue displays the infrared light. This pattern repeats across the light strip.
There was trouble when I tried to read the sensor continuously and display the values occasionally. I pondered the problem and then measured the time it took to read the data over the serial line. It took roughly sixty milliseconds from the call to the sensor to the final receipt. I broke it down the microseconds and found the following delays.
• Red19934 microseconds
• Infrared19933 microseconds
• Green19933 microseconds
To display the intensity of each value, I had to scale the incoming readings. The best way I know how to scale unknown numbers is to keep track of the highest and lowest data points that number ever reaches and use the map() function based on those limits. As soon as I implemented the routine, the program refused to run. I looked up the equation map used and found that it is possible to input values for a denominator of zero, and the DIV/0 was the problem. I added an IF statement to ignore any condition that would try to divide by zero, and it worked. I scaled the lights from 0% to 100% based on the reading extremes, and it worked well.
Testing reflective response and LEDs
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
Completed projects from year 4
Completed projects from year 5
Completed projects from year 6
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, is 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 their post.
This blog, including pictures and text, is copyright to Brian McEvoy.
2020-01-15
Comments
Post a Comment