Parking Sensor
-
@korttoma
Even if it's only active for about 3-4minutes per day?
The problem is i got no way of getting power to where i want to place it.
And also if i did it would have to be something like 230V to usb adapter.
And plugging one of those in outside seems like a fire hazzard (even indoors they are known to start fires).What if i hook it up to a small solar panel to charge the batteries?
Otherwise i guess i'll just have to stick with the old tennisball on a string method :D
@leothlon I'm not saying it can not be done but according to the datasheet the LED chip can consume up to 20mA ( http://www.adafruit.com/datasheets/WS2812.pdf ). So with 24 of them you will be looking at almost 500mA for just the LEDs.
http://ncalculators.com/electrical/battery-life-calculator.htm
btw, there is another thread about safe AC DC transformers here
- Tomas
-
@leothlon I'm not saying it can not be done but according to the datasheet the LED chip can consume up to 20mA ( http://www.adafruit.com/datasheets/WS2812.pdf ). So with 24 of them you will be looking at almost 500mA for just the LEDs.
http://ncalculators.com/electrical/battery-life-calculator.htm
btw, there is another thread about safe AC DC transformers here
@korttoma The online documentation I read said:
"The pin labeled PWR +5V is the power input pin, and should be connected to a suitable power supply. An input voltage of 5 V is used to power the ring, and each LED on the ring can draw up to 50 mA at 5 V when outputting white at full brightness. That means the ring could draw up to a maximum of around 1.2 A."
Although Hek's code does not operate all the pixels at full white brightness, I decided to play extra safe and use a 2A supply.
-
@korttoma The online documentation I read said:
"The pin labeled PWR +5V is the power input pin, and should be connected to a suitable power supply. An input voltage of 5 V is used to power the ring, and each LED on the ring can draw up to 50 mA at 5 V when outputting white at full brightness. That means the ring could draw up to a maximum of around 1.2 A."
Although Hek's code does not operate all the pixels at full white brightness, I decided to play extra safe and use a 2A supply.
@Dan-S. Yeah I'm sure thats true. Please post a link to the documentation if you can find it. Anyhow I guess we can agree that running this device on batteries would be difficult.
- Tomas
-
@Dan-S. Yeah I'm sure thats true. Please post a link to the documentation if you can find it. Anyhow I guess we can agree that running this device on batteries would be difficult.
-
@Dan-S. Yeah I'm sure thats true. Please post a link to the documentation if you can find it. Anyhow I guess we can agree that running this device on batteries would be difficult.
-
But isn't the distance sensor rather power hungry as well?
The dist-sensor but be awake all the time taking measurements (which needs to be interpreted by the MCU).. so sleep mode is not an option on this.
@hek said:
But isn't the distance sensor rather power hungry as well?
You could wake it with a reed switch attached to the garage door...
door open, sense and display until steady state and go to sleep on a timeout or door closed interrupt
-
@hek said:
But isn't the distance sensor rather power hungry as well?
You could wake it with a reed switch attached to the garage door...
door open, sense and display until steady state and go to sleep on a timeout or door closed interrupt
@BulldogLowell said:
You could wake it with a reed switch attached to the garage door...
door open, sense and display until steady state and go to sleep on a timeout or door closed interrupt
I like that idea. I was planning on having garage door sensors tied in with this anyway. FYI here is a link to the ultrasonic module docs which list 15mA as the current draw.
-
Just to add my two cents, as I have a window nearby, I'm planning to run my parking sensor with a solar battery bank, like this one.
I'm waiting for the ring now. It is the last piece missing ;-)
-
This was fun to build :)
However, my HC-SR04 is making a high pitch sound when distance is close and a more static sound when distance is further. I have tried with 3 different modules and 2 different Nanos and 2 different power sources. Is this normal?
-
This was fun to build :)
However, my HC-SR04 is making a high pitch sound when distance is close and a more static sound when distance is further. I have tried with 3 different modules and 2 different Nanos and 2 different power sources. Is this normal?
@msebbe It's normal for a :dog: or a bat. :laughing: Either you have really good hearing, or there's something wrong with your HC-SR04. The ultrasound is supposed to be well above human hearing range (40 KHz). My HC-SR04 is quiet and I don't hear any sound from it.
-
This was fun to build :)
However, my HC-SR04 is making a high pitch sound when distance is close and a more static sound when distance is further. I have tried with 3 different modules and 2 different Nanos and 2 different power sources. Is this normal?
-
This was fun to build :)
However, my HC-SR04 is making a high pitch sound when distance is close and a more static sound when distance is further. I have tried with 3 different modules and 2 different Nanos and 2 different power sources. Is this normal?
-
@msebbe It's normal for a :dog: or a bat. :laughing: Either you have really good hearing, or there's something wrong with your HC-SR04. The ultrasound is supposed to be well above human hearing range (40 KHz). My HC-SR04 is quiet and I don't hear any sound from it.
-
Was checking out operation of parking sensor after changing MAX_Distance to 200 from original 100--wanted earlier start from wall. Also changed the Panic distance to 60--more space from wall during testing. Noticed that the led ring did not start from 1 pixel and increase from there as the distance closed. It started at 7 lit pixels. Examined the formula for newLightPixels and made a change which corrected this.
The current newLightPixels formula is:
int newLightPixels = NUMPIXELS - (NUMPIXELS*(displayDist-PANIC_DISTANCE)/MAX_DISTANCE);
The portion of the newLightPixels formula (displayDist-PANIC_DISTANCE)/MAX_DISTANCE) is intended to map the interval between PANIC_DISTANCE and MAX_DISTANCE to the interval (0,1). In other words, when you are at the PANIC_DISTANCE it should calculate to 0 and when you are at MAX_DISTANCE it should calculate to 1, advancing linearly between the two values as the distance closes and vice versa. Clearly when a displayDist = PANIC_DISTANCE, the numerator of the division of the formula calculates to 0. However when displayDist = MAX_DISTANCE, it does not calculate to 1.
In order to correct this I changed the portion of the formula to:
(displayDist-PANIC_DISTANCE)/(MAX_DISTANCE-PANIC_DISTANCE))
Note the only difference is subtracting the PANIC_DISTANCE from the MAX_DISTANCE in the denominator. Now when the displayDist = MAX_DISTANCE, the formula returns the value 1. So the proposed new newLightPixels formula is:int newLightPixels = NUMPIXELS - (NUMPIXELS*(displayDist-PANIC_DISTANCE)/(MAX_DISTANCE-PANIC_DISTANCE));
I tested it both by plugging values into the formula and in operation of the Parking Sensor. Now the leds climb smoothly from 0 as you enter the MAX_DISTANCE zone. rather than starting at some number other than 1 (7 in my case).
-
Cool, I had this happen as well, so great fix! Now all I need it to do is talk to domoticz, not picking it up yet... :)
-
Have one more proposed change to parking sensor code. Noticed that even when I was standing still there seemed to be quite a few changes in number of leds lit. In checking the internet, learned that variability of distance readings was particularly a problem for those using the sensor in robots. The preferred solution seemed to be taking the median of several readings.
See:
http://blog.microcentertech.com/2013/05/minipingbot-construction.htmlFortunately, the Newping library has a built in function to address this issue by taking the median of several readings (default = 5). So I modified the code as follows:
// int fullDist = sonar.ping_cm(); original code
unsigned int fullDist = (sonar.ping_median() / US_ROUNDTRIP_CM);
// Get average distance for 5 pings, convert to cm
// US_ROUNDTRIP_CM = distance sound travels in cm/secAs a result, the jumping around of the number of leds appears to have decreased significantly and the response is much more stable. Hope this helps others.
-
Have one more proposed change to parking sensor code. Noticed that even when I was standing still there seemed to be quite a few changes in number of leds lit. In checking the internet, learned that variability of distance readings was particularly a problem for those using the sensor in robots. The preferred solution seemed to be taking the median of several readings.
See:
http://blog.microcentertech.com/2013/05/minipingbot-construction.htmlFortunately, the Newping library has a built in function to address this issue by taking the median of several readings (default = 5). So I modified the code as follows:
// int fullDist = sonar.ping_cm(); original code
unsigned int fullDist = (sonar.ping_median() / US_ROUNDTRIP_CM);
// Get average distance for 5 pings, convert to cm
// US_ROUNDTRIP_CM = distance sound travels in cm/secAs a result, the jumping around of the number of leds appears to have decreased significantly and the response is much more stable. Hope this helps others.
@Dan-S. Thanks for your investigation! I made the changes and it seems to work well!
About the high pitch sound I mentioned earlier; I changed NEO_KHZ400.
Adafruit_NeoPixel pixels = Adafruit_NeoPixel(NUMPIXELS, NEO_PIN, NEO_GRB + NEO_KHZ400);to
NEO_KHZ800This removed the annoying high pitch sound :D
-
@Dan-S. Thanks for your investigation! I made the changes and it seems to work well!
About the high pitch sound I mentioned earlier; I changed NEO_KHZ400.
Adafruit_NeoPixel pixels = Adafruit_NeoPixel(NUMPIXELS, NEO_PIN, NEO_GRB + NEO_KHZ400);to
NEO_KHZ800This removed the annoying high pitch sound :D
@msebbe Glad everything worked out well for you. Your comment made me think about changing mine to 800 also. From what I could glean from looking on the internet, 800 is more appropriate for newer devices, e.g., the led ring. So I am going to change to 800 also. Thanks.
-
Just built this with my 4 year old. She loved it! She did the project management and directed me which wire goes where. Got to start them young!
I was really shocked at the brightness of the LED ring. I mean, I knew it would be bright from looking at the videos, but wow.
My setup was to connect my UNO to the PC, load code and branch power directly from the UNO's 5v pin. I had no cap or resistor in place either (neither was there a radio hooked-up). This was just a bench-top proof of concept and it worked right out the box (after I soldered leads to the ring). I went through all the adafruit example codes and worked without a hitch. I may, or may not, exceeded WAF level 10. Now she is giving me more projects for these "neopixel" lights.
