prologikus:
I saw oem modules for other cars who achieve this functions but i really don't understands why they cost so much... Are they using photodiodes or something else?
Which "this" are you referring to? Automated dipping requires rudimentary cameras and some clever image processing. The difference between an oncoming car at 300m (where most countries' rules say you must dip) and a street light is very small. For a dumb light sensor, the difference is zero.
prologikus:
I don't know the difference between the us car lighting and the europa car lighting
I'm living in europe and my car lights switch looks like this:
In the top of the switch there are 3 states: off-daylight beams(how i call them)-low beam(there the daylight beams are turned on too
No. The middle position is called "parking lights" or "side lights" or maybe a few other variations. The purpose of those lights is so that others can see you.
Daytime Running Lights (DRL) is mandatory in several countries such as the USA and Sweden. It's actually different. The DRL does not include tail lights, whereas parking lights do illuminate the tail lights. In the USA, there are additional orange lights which must be visible from the side.
prologikus:
So... What is the best way of using(placing, etc) light resistors?
To detect daylight (and not street lamps or oncoming cars) then almost anywhere will work so long as it's not facing forwards or upwards. The footwell is 1000x brighter under daylight than at night. You really have to experiment with your particular installation.
MorganS:
Which "this" are you referring to? Automated dipping requires rudimentary cameras and some clever image processing. The difference between an oncoming car at 300m (where most countries' rules say you must dip) and a street light is very small. For a dumb light sensor, the difference is zero.
No. The middle position is called "parking lights" or "side lights" or maybe a few other variations. The purpose of those lights is so that others can see you.
Daytime Running Lights (DRL) is mandatory in several countries such as the USA and Sweden. It's actually different. The DRL does not include tail lights, whereas parking lights do illuminate the tail lights. In the USA, there are additional orange lights which must be visible from the side.
To detect daylight (and not street lamps or oncoming cars) then almost anywhere will work so long as it's not facing forwards or upwards. The footwell is 1000x brighter under daylight than at night. You really have to experiment with your particular installation.
It's not about swtiching the high beam, i said this many times .. !!
I came up with this circuit, is this good ?
i'm using 2n3904 as the npn and IRF5305PbF as the p mosfet
Also i built a first version of the light sensor using 2 light resistors one for picking up the upwards light and one picking up the sides:
i used a tube to exclude the lights from slides (for the upwards one) and use the first sensor, a backwards slde and a top cover to restrict the light only from sides (for the second one)
The interior of the tube is black-reflective and the exterior is matte
You can drive two or more MOSFETS from one single output. The current requirement is usually very small unless you need the fastest possible switching speed.
What you can't do is parallel two bipolar transistors. It seems like the outputs of both are joined together just under the 2k resistor. Only one of them will conduct and it will heat up, lowering its on-resistance further and ensuring the other one isn't doing any work.
I would drive the two MOSFETS with just one transistor. 10K seems high as the base resistor - have you done any calculations for this drive current?
MorganS:
You can drive two or more MOSFETS from one single output. The current requirement is usually very small unless you need the fastest possible switching speed.
What you can't do is parallel two bipolar transistors. It seems like the outputs of both are joined together just under the 2k resistor. Only one of them will conduct and it will heat up, lowering its on-resistance further and ensuring the other one isn't doing any work.
I would drive the two MOSFETS with just one transistor. 10K seems high as the base resistor - have you done any calculations for this drive current?
In my past experience driving only one of this mosfet i've already used 10k resistor for the npn base with a 1k mosfet gate-source and everything looks good so far.
Now, to clarify, I'll use only one npn to drive both mosfets using the same 2k resistor for the mosfet gate-source and update the circuit as soon as i can.
meanwhile i edited the prev post (#21) with the current updates.
V2 looks a lot more sensible indeed.
One MOSFET may be enough - depends on how much current you're actually driving.
The value for the pull-up resistor is quite low, I normally use 10-100k, even higher values are OK. The main difference is less current leakage when the MOSFET is on.
Note of caution......if you are thinking of "tapping" into existing light wiring you may need to know that many of the autos these days are negative switching and your modifications may well cause all sorts of feed-back problems.
boolean need_beam;
/////////////////CALIBRATOR
//TOTAL MUST BE 100%
int upS_perc = 60;
int sideS_perc = 40;
int dark_light = 600;
int bright_light = 700;
int readlight_maxcount = 5;
int nobeam_maxcount_delay = 10;
/////////////////END CALIBRATOR
int nobeam_count_delay;
int readlight_count;
int totalupS;
int totalsideS;
void readlightsensor() {
int upS = analogRead(uplightSPin); //read the current sensor data
int sideS = analogRead(sidelightSPIN); //read the current sensor data
totalupS = totalupS + upS; //SUM the readings
totalsideS = totalsideS + sideS; //SUM the readings
readlight_count++; //count the readings
if (readlight_count >= readlight_maxcount) { //if the COUNT reading reach it's maximum
totalupS = totalupS / readlight_maxcount; //AVERAGE THE SUM
totalsideS = totalsideS / readlight_maxcount; //AVERAGE THE SUM
//calculate the priority
int allS = ((totalupS * upS_perc) / 100) + ((totalsideS * sideS_perc) / 100);
totalupS = 0; //RESET the SUM
totalupS = 0; //RESET the SUM
readlight_count = 0; //RESET THE COUNT
if (allS >= bright_light) { //if there is already light detected
nobeam_count_delay++; //make sure we really don't need light
if (nobeam_count_delay >= nobeam_maxcount_delay) { //count how many times you don't need light
need_beam = false; //finnaly turn the light off
}
}
if (allS <= dark_light) {
need_beam = true; //WE NEED LOW BEAM!
nobeam_count_delay = 0; //RESET the no beam needed flag so it will count again
}
}
}
Initial code of reading the sensor in a average way
Note that there are 2 sensors: one reading the top light and one reading the side light
Another Note: the values from the callibrate section are not calibrated in any way, just random values so far!
/////////////////CALIBRATOR
//TOTAL MUST BE 100%
int upS_perc = 60;
int sideS_perc = 40;
As it must be 100 you don't need to initialise both, or you can initialise one and calculate the other. Easier and no risk for errors here:
int upS_perc = 60;
int sideS_perc = 100 - upS_perc;
prologikus:
readlight_count++; //count the readings
if (readlight_count >= readlight_maxcount) { //if the COUNT reading reach it's maximum
With loop() missing this looks just weird. What are you trying to accomplish here? Do you have any form of timing in your loop()? Nevertheless it makes more sense do do a millis() based delay here, rather than this awkward counting method.
wvmarle:
As it must be 100 you don't need to initialise both, or you can initialise one and calculate the other. Easier and no risk for errors here:
int upS_perc = 60;
int sideS_perc = 100 - upS_perc;
With loop() missing this looks just weird. What are you trying to accomplish here? Do you have any form of timing in your loop()? Nevertheless it makes more sense do do a millis() based delay here, rather than this awkward counting method.
This function is called in loop with the millis function
Still better to do the millis() timing in that unction and just call in loop(). Otherwise you have a maintenance nightmare on your hands as both the time frequency and number of counts change the final delay.
wvmarle:
Still better to do the millis() timing in that unction and just call in loop(). Otherwise you have a maintenance nightmare on your hands as both the time frequency and number of counts change the final delay.
So far i want to know if this is the best way of doing it or there are better ways
As said, to me that snippet looked weird to say the least, but as you failed to post the full code there's no way of giving specific suggestions beyond what I suggested already.
The rest of the code is itegrated in my project and it's long
But it's a simple fade animation using analogWrite from 0 to 255 on the pins mentioned #33
The problem is the big noise created by the circuit
prologikus:
The rest of the code is itegrated in my project and it's long
But it's a simple fade animation using analogWrite from 0 to 255 on the pins mentioned #33
You mention some "frequency" with three floating point numbers, one of which is >255.
If it's too long: write a minimal sketch that singles out the problem, in this case a sketch that does nothing but fading your LEDs in and out the same way it should be done in your main project. That not only allows you to post your code (so we can see if there are any issues there), it also helps you confirm that the problem is indeed in the hardware, not the software.
The problem is the big noise created by the circuit
Which circuit? The part that you didn't post I guess? The circuit that you posted doesn't have any obvious significant sources of noise.
.. !!
