The best option is to use the search function here. The support for infrared libraries on Spark is pretty basic so far (compared to Arduino and other platforms), but there are some attempts at porting to Spark available via this forum…
Once we take delivery of our Photon, we should be able to quickly add support for Photon (+Spark?) into AnalysIR which includes automatic code generation for sending signals. The photon is at a good price point for ‘wifi-IR remotes’ - can’t wait!
I think it is possible to record and analyze IR codes with Spark. I think it is just that no one has worked on it hard enough yet.
The Spark core has some challenges and the Photon will be better, but the design tradeoffs might involve things like temporarily turning off the cloud and WiFi to do the recordings.
@bko As a matter of interest, what are the challenges? or how long can the cloud/wifi stuff block user code/interrupts?
Most IR systems can work pretty well with +/- 100 uSecs on timings and it usually isn't an issue if the odd signal is lost or corrupted.
(e.g IRremote only measures to +/- 50 uSecs and that is after any additional distortion introduced by the IR Receiver )
I think you are assuming you are seeing the demodulated IR signal with the 30-50kHz sub-carrier already converted to baseband. So when you say you can sample at around 50uS, that is roughly two samples per sub-carrier period. This is great for consumer remote control IR with AM modulation etc. but not the only kind of IR even in consumer remote controls (I am looking at you Bang & Olufsen) and in the another thread we are talking about data over IR which is a different animal. I don’t think the current Spark architecture lends itself to high-speed interrupt-driven communications using PPM etc.
To your other question: you need to separate out the cloud, which can be blocked for up to 10 seconds, from the WiFi connection, which cannot be blocked for long without turning it off. Let’s say for some reason I have a really long IR code that last more than 6 seconds or so. If we don’t service the WiFi connection for 6 seconds, the TI part is going to timeout the connection and we are going to have problems for sure. But if you have a normal consumer IR signal, it should not be a problem.
Thanks for that, it sounds like there are no real issues so. Good to know.
Sounds like the more relevant question may be: How long can the WiFi & cloud block the user code?
Some clarifications:
Yes, I was referring to demodulated signals (BTW its not AM modulation for CIR)
The 50(100) uSecs I mentioned was the timing accuracy of the demodulated marks/spaces of the signal, not the modulation period.
B&O modulation is at 455kHz & is very rare and Vishay don’t even sell IR receivers for this anymore. 99.9% of people can ignore it and the rest can probably afford to fund commercial solutions Once demodulated it is 'similar 'to a common TV signal.
If you did have a 6 second IR sequence of signals, they are usually made up of multiple shorter discrete signals (with 100ms+ gaps in between) and would be treated at a low level as such - so that should not present an issue for cloud or WiFI. (Hopefully)
It will be interesting to see if it is possible to measure modulation frequency of IR signals (up to 60kHz) with the cloud active. It is possible on a 16MHz Arduino. I will try it out when I get a Photon.
(To measure the modulation frequency, you only have to measure once per cycle and just a handful of samples are usually enough. To measure the duty cycle you have to measure twice per cycle. Again most people don’t need that ,as there are only a few in use & easy to guess)
This code and example from Christian Maher - https://github.com/cmaher/ac_control has been by FAR the easiest setup I have come across. Worth checking out - someone should publish the lib he is using to git so it is searchable on particle build.
I extracted the code from @AnalysIR to a separate library, which can be found on Particle Build under IrTransmitter. I listed you as the author, hope you don’t mind.
Since that was posted we have also published an improved version using our uPWM hack, which gets you hardware PWM and better signal fidelity/accuracy and longer range.
Only thing with the uPWM is that the output signal is inverted, but we have also linked a simple circuit to handle that
... and since uPWM was posted we have come up with our A.IR Shield Photon, which features high quality IR components, configurabe IR Power, dual IR receiver & dual IR emitters, improved hardare PWM etc see