I'd like to use an Arduino to record a digital signal , store it, and be able to play it back at a later date. I know the hardware limitations of Arduino's so I'll probably use an esp32 with a memory card to store the signals, but how would I go about recording the signal? I don't know the specifics of the signal other than it goes high then low then high then low etc, is there a way for me to read those and save how long the pulses are and the distance between them? NOTE: this is not a pwm signal, the total signal goes for about 2 seconds and is comprised of binary data (1 being high and 0 being low) so essentially reading a binary signal
You can certainly do what you describe, but one important factor will be the frequency and hence the number of changes over a period
1 Like
yeah, I was thinking about that, also you wouldn't happen to know exactly how to "record" the signal?
Some years ago I did something along those lines. I was recording keypresses on an IR remote. I had a structure that kept track of which key was pressed and the time it was pressed for. A phoney "no key" was used to keep track of times between keypresses. I used millis() to get the times.
If your signal changes slowly enough (i.e. > 10s of ms between changes would probably be easy), you could do something similar but even simpler. If you're just recording on and off, all you need to keep track of is the times. If your signal never remains the same level more than 255ms, you could use 8 bit bytes to store the values. Save the values in EEPROM and you could save 1000+ state changes.
Feed the signal in on of the interrupt capable pins, and attach a CHANGE interrupt to that pin. In the handler, do the calculation with millis() and the previous time the state changed. You couldn't write to EEPROM from the interrupt so you'd have to buffer it up in RAM.
I'm just writing this as I think it (and it's late here), so take it all with a medium sized salt lick.
Aaahh ok that makes a lot of sense thanks
You cant realistically start without knowing the bandwidth of your signal.
Can you tell us what device is generating this digital signal? Do you have a link to a manual for it?
It's this cheap infrared reader I got off Amazon. https://amzn.asia/d/f235Ak5
I think the Arduino IR library can provide raw data for you to save for later.
Or, you could buy a cheap DSO, or even a logic analyzer. They almost always have recording, view later modes.
And, if you're staying in the hobby of playing with Arduinos, you'll be using either one again and again and again...
2 Likes
This
actually works very well.
That's the sensor, we interested in the signal you are trying to record and play back.
It does sound like you are looking to capture and repeat IR remote control patterns. You would be better off with both a different sensor and to use the library suggested.
This is an old wheel, reinventing it would be non-trivial as well as a waste of time.
If that's where you are indeed headed.
a7
1 Like
The problem with the libraries around are the fact that they are designed for specific devices around, whether what I want is to be able to read any signal, no matter what pattern just by listening for changes in the signal and then to be able to repeat that back through the transmitter.
If anyone knows of a library that has a functionality like this that would be great.
In essence I'm trying to replicate Broadlink's rm4 where it can learn remote signals and play them back
Look again. I've not looked in some time, but I have always "known" that if a time should come when I needed to, there'd be plenty of help available.
Just now from under the umbrella I casually google
record playback ir remote arduino
and look what turns up:
Seems like the guy who wrote the kind of library that cuts this work down considerably has gone to the trouble of showing us how to make a universal remote.
Other links look equally plausible. Spend some time on a few of those, then come back and say what kind of help you with your idea.
a7
2 Likes
Sounds like you want to record a series of changes of state, with an accurate timestamp for each. Can, of course, get complicated, and large, with a long message at a high baud rate, for example, but is doable. Trick is, with something like a UART signal, the timing needs to be pretty precise at the higher baud rates, to meet the framing requirements which are based on a multi-megahertz clock signal. Whether you'll run into those limitations depends on the nature of the signals you're capturing/retransmitting. If they have a more lenient framing standard, then you should be good to go.
But, success will depend upon being able to get accurate enough timestamps, which in turn would depend upon no interrupts, other than the timebase itself, and whether you have enough memory to store the list of transitions, given that, for example, writing to SD is blocking.
Just some thoughts.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.