So, I have this project I've been working on.
I have a transmitter powered by an arduino and an IR transmitter. In the transmitter, it sends out a series of pulses (like a pattern) for different instructions. The pulses are hard coded.
For example:
1 long pulse and 1 short pulse (with 200ms waits in between the pulses) means to increment something on the receiver
1 long pulse and 2 short pulses (with 200ms waits in between the pulses) means to decrement something on the receiver
3 short pulses means to reset the state of the receiver.
What need to figure out now is how to make the receiver register these pulses so that it knows to execute the above instructions.
I was thinking at first to make a few if-statements, but the arduino has to be aware of the duration of the pulses and this is where I get hung up on. Since an arduino (like all other machines) are FSMs, it only knows its current state, how do I make the arduino literally wait to see how long the pulse is and then execute accordingly.
The only thing I can think of is somehow syncing the clock in the receiver arduino so the pulses happen at each clock cycle, so the arduino would look to see if at each tick if it's gone high or low? the problem is, if I do that, the receiver arduino works at 8MHz, whereas the transmitter is at 16MHz, would probably have to divide it by 2?
Anyway, it was just a thought.
I would like to know how you guys would go about doing this and what would be the best way to execute reading these pulses.
I know there's an IR library out there, but I don't want to use it...
how do I make the arduino literally wait to see how long the pulse is
Note the time that the start of the pulse is received (using millis() or micros()) and the time that it ends. Subtract one from the other and you have the length of the pulse. The Arduino does not wait for the start or end of the pulse but acts when they happen.
(Never really used it though... does pulseIn block?)
Do you think pulseIn() would work on two different arduinos with different clockspeeds?
From what I see on the page, it doesn't look like it would be a problem...
I just need to make sure the pulses are very close to exact when it gets received.
I only ever used it when I got my Uno 4 years ago, and that was just out of curiosity. Never really got my mind round it. So I posted anyway just so you could follow up but I don't have any real advice here sorry.
I only ever used it when I got my Uno 4 years ago, and that was just out of curiosity. Never really got my mind round it. So I posted anyway just so you could follow up but I don't have any real advice here sorry.
It's cool! It definitely helped regardless. I've been looking into it already.
Do you think pulseIn() would work on two different arduinos with different clockspeeds?
Why would it need to? You only need to determine the pulse length/interval on one Arduino. The sending Arduino knows what pulse length/timing it used.
You can't use pulseIn() to measure the time between events on different Arduinos. You can only use it to determine how long it takes for a LOW pin to go LOW again after it goes HIGH or to measure how long it takes for a HIGH pin to go go HIGH again after it goes LOW.
PaulS:
Why would it need to? You only need to determine the pulse length/interval on one Arduino. The sending Arduino knows what pulse length/timing it used.
You can't use pulseIn() to measure the time between events on different Arduinos. You can only use it to determine how long it takes for a LOW pin to go LOW again after it goes HIGH or to measure how long it takes for a HIGH pin to go go HIGH again after it goes LOW.
Not sure what you mean by determining the pulse length/interval...
So the receiver would get the pulse, go high and wait for it to go low, how would it 'wait' or do the subtraction? A timer is ms or us needed? then subtract when the pin goes low to find the difference in time?
Do you think pulseIn() would work on two different arduinos with different clockspeeds
Sure. If they're configured right (F_CPU is correct) they should agree on 200 ms pauses, short and long pulses (whatever short /long means).
Problem is rather that you can't tell after a long and a short pulse, if there will be another pulse or not.
The problem with pulseIn is that's blocking, which makes it hard to wait for 'nothing' to happen.
Sure there's a timeout, but I'd rather use UKHeliBob's idea.
1 long pulse and 1 short pulse (with 200ms waits in between the pulses) = 110100000
1 long pulse and 2 short pulses (with 200ms waits in between the pulses) = 110101000
3 short pulses means to reset the state of the receiver. = 101010000
This shows a start bit, min. 5 data bits and enough pauses to safely notice them as stopbits.
Asynchronous communication is easier with fixed length data
But a 600 ms (minimum) pause could be used as end-indicator.
Are you using TSOP ( 38kHz or similar ) receivers or pure phototransistors?
Not sure what you mean by determining the pulse length/interval...
How is the receiver supposed to know that the sender sent "a long pulse"? Or "a short pulse"? Or "1 long pulse and 1 short pulse (with 200ms waits in between the pulses)"?
Whatever is receiving the pulses goes from LOW to HIGH to LOW (or HIGH to LOW to HIGH). You need to determine how long between transitions to distinguish a long pulse from a short pulse and to distinguish a pulse from an interval.
The IRremote library already does this, using interrupts, which are far more accurate than pulseIn().
