I have a code that sends 384 pulses at 38kHz with an infrared LED. It's very easy to understand it. At the beggining the code sends the pulses using the LED and in the middle of the code I check the sensor if it has any signal coming. So far so good, yes? Please, take a look:
My question is this: I first send the pulses, so when I reach the line "if (digitalRead(IRsensorPin) == LOW){" the pulse should already have passed the sensor. So why does it work? It should not work cause I first send the pulse and then I check for the pulse but as I understand the 384 pulses should already have passed the sensor.
I have no idea why this code works. I would be glad to listen smarter people to help me understand this.
gilperon:
Thank you for helping me. I know it is working cause when I run that code everything works, the LED blinks which means it's reporting the signal that is being sent. It works, but I have no idea why. Do you?
That doesn't really address your question about what if (digitalRead(IRsensorPin) == LOW){ does.
I guess my question is, how do you know what the sensor is reporting. Maybe it's just responding to something extraneous that has nothing to do with the pulses you send.
You have not said what you are sending the pulses to? Is that device responding in any way?
What happens if you insert a short delay (perhaps 10 millisecs) between sending the pulses and reading the sensor?
Would it make any difference to your project if you deleted the code for reading the IR sensor?
gilperon:
My question is this: the pulse should already have passed the sensor. So why does it work? It should not work cause I first send the pulse and then I check for the pulse but as I understand the 384 pulses should already have passed the sensor.
The 38 kHz is a carrier frequency. The IR receiver has a 38 kHz band-pass filter which has inherent delay. That is how you can tell the the pulse stream was detected even after it is done being sent. You could also use digitalRead() as part of the delay between pulse transitions to detect the reception before the pulse train was done being sent.
If you want to detect it even earlier you could use a falling-edge-triggered interrupt.
As has already been pointed out, you haven't explained what you mean by "works".
It is not obvious what your code does because it does not have setup() and loop() functions and therefore does not compile - which means it can't be uploaded and tested.
It is difficult to see how you can detect a train of 384 pulses, each 13 microseconds wide and spaced 13 microseconds apart. This means that the entire sequence of pulses lasts slightly less than 10 milliseconds. I think it is safe to say that your eyesight is not good enough to detect them. So I reiterate the initial question - What do you mean by "works" and how do you know it "works"?
There's no way that your code can detect those pulses after they are sent. Presumably your emitter and detector are only a matter of, at most, a few tens of centimetres apart. It takes light only a few nanoseconds to travel that kind of distance. There is no chance that your code can detect the last pulse, never mind all 384 of them.
There's no way that your code can detect those pulses after they are sent. Presumably your emitter and detector are only a matter of, at most, a few tens of centimetres apart. It takes light only a few nanoseconds to travel that kind of distance. There is no chance that your code can detect the last pulse, never mind all 384 of them.
That is exactly what is at the root of my earlier question.
And it is why I don't understand the following comment.
johnwasser:
The IR receiver has a 38 kHz band-pass filter which has inherent delay. That is how you can tell the the pulse stream was detected even after it is done being sent
As far as I can see (from the code) the sensor is on the transmitting device and only tries to start detecting an IR pulse after all the pulses have been sent.
As far as I can see (from the code) the sensor is on the transmitting device and only tries to start detecting an IR pulse after all the pulses have been sent.
Yup - even if Tx and Rx are physically separate devices, there's no way the Rx can detect those pulses.
Or, there is an as-yet undiscovered principle of physics at work here which involves time travel.
gilperon:
if I want to send the 384 pulses and being able to read all the 384 pulses is it possible to read them in the line after I have sent the pulses?
Not with an IR Remote receiver. For that you would want to use a raw IR Phototransistor. I would put the 'read' between the time turning on the IR LED and turning off the IR LED. Of course there is then no need to limit yourself to a 38 kHz pulse frequency.
Are you using this as a reflective object proximity detector? You could use a phototransistor, comparator, and digital input but that would be sensitive to ambient IR. One thing you can do to filter out ambient light is to take analog readings with the IR LED on and off. Then a comparison between the two values would give you a better sense of how close the object is.
At MOST the digitalRead() detects an IR signal ONCE (because it there is only ONE digitalRead() ) so there is no chance that it is reading a frequency, even if there is a frequency to read.
The reality is that your sensor is detecting something else that has nothing to do with your transmission.
I/we know exactly what your code snippet is doing.
(about 3cm) and in less than a 1 microsend
It's actually 3 orders of magnitude smaller than that. It takes about 1 nanosecond to travel 3cm. The arduino UNO, for example, has a clock rate of 16MHz which means that the basic rate of instruction execution is one instruction every 62.5 nanoseconds. Immediately after turning off IRledPin for the 384th time, your code has a delay of 13 microseconds. In the time that the Arduino is delaying here, the light from the IR can travel 3,900 METRES.
for some reason arduino is lighting up the LED ... but arduino IS reading that frequency
Just because you can't explain it, doesn't mean there isn't a perfectly logical explanation which does not require time travel, fairies and/or aliens from the planet Quog. The fact that the LED is lighting up after you've sent 384 pulses does not mean that therefore it is detecting those pulses.
You still haven't posted your entire sketch (in code tags) and you haven't said exactly how you have wired up the emitter and detector.
For example, do you have a pullup resistor on the IRsensorPin? If not, why not?
Have you tried running your program without the for loop? Does it still "detect" something?
I already spent more time than I have trying to understand this and still no success
If you'd stop looking for nonsensical reasons to explain something that has a perfectly rational explanation, you might learn something useful and take a lot less time doing it.