Linux Infrared How To: Chapter 3 Specific Connections and Protocols
tldp.org
tldp.org
I began to look into it, and IrDA opened up my nostalgia. It reminded me of the simpler times in the 90s and 00s when PDAs, Gameboys, and even Tamagachi would communicate with each other with this infrared-light based protocols.
My dad even had infrared wireless headphones (to watch TV while my mom was sleeping). I've tried them back in the day, they were pretty reliable actually.
------
IrDA had some ambitions, you can see in this Linux HOWTO that there's ways to set up networking stacks and far faster protocols (4MBit and 16Mbit) over this infrared communication stack. It looks like the IrDA group continued to make standards all the way up to 1 Gbps, but I don't think it ever really became popular. Or maybe that was around the time Bluetooth started to take over?
For modern hobby electronic engineers, maybe IrDA still has a place? The lowest, simplest, layer of the IrDA protocol is FIR, a 115,200 baud almost-like UART protocol that is in fact, well supported in modern ATTiny, MSP430, and STM32 devices (!!!), with just a $4 led+phototransistor combo: https://www.digikey.com/en/products/detail/vishay-semiconduc...
It seems like its just a UART that communicates over infrared light, maybe 10cm to 2 or 3 meters away reliably? I think TV Remotes can go even further (with the 38kHz TV Remote protocol), but IrDA's UART is supremely flexible (indeed; UARTs are probably one of the easiest to use comms on these tiny microcontrollers).
So while using physical layer directly from microcontrollers is OK, most of the information at that link is now obsolete.
That said, while IrDA was fun when it worked, it was pretty finicky, and I am not really missing it. I am having a hard time thinking of a good application for full IrDA stack: optical communications are handy sometimes (for example, for device provisioning), but OBEX? IrCOMM? I am happy to never hear those words again.
Then again: the IrDA phototransistor module linked above has only 0.075mA of current consumption while active. So IrDA read is extremely low power. The LED may take up 100+ mA of current when transmitting data, but receiving is extremely efficient it seems. Even then, IrDA standard has the LED active only 18.75% of the time for zero-bits, and 0% of the time for one-bits... so maybe only 10mA-ish power usage when transmitting.
In contrast, the ESP32 is ~80 mA receiving, and ~200mA transmitting. 1000x more power on receive, and probably 20x the power on transmit.
This is a surprisingly low-power I/O mechanism. I mean... its just an LED (albeit infrared) and a photodiode/phototransistor, but that's all you need for reliable wireless communications.
----------
Raw UART is usable in the simplest of projects, but a tiny bit of "smarts" would help a lot. The next layer, IrLAP implements Layer2 of OSI model (addresses, framing, CRC-checks).
Something like IrCOMM would take too long for a hobbyist to implement, but I can see why each portion of the IrDA stack exists. RS-232 has hardware flow control (ie: remote side can say "please stop sending data, I'm busy", which is a very important signal). Implementing flow-control is part of the Tinytp protocol (so IrCOMM requires Tinytp). Tinytp is ontop of the multiplexing protocol, and that sits on top of the IrLAP protocol, which sits atop the physical layer.
Hmm... I think ultimately, a well designed product _would_ have to implement IrLAP and Tinytp (or at least, equivalent functionality). Resending missing packets / replaying data upon errors, having enough checksums to check those errors, etc. etc. is just an important part of protocol design.
This is where working with ESP32 / 802.11 is nice, because all that crap has already been done for you... and you can just sit atop TCP streams. But each element below represents an important communication principle.
------
Still though, UART / RS232 without any flow control is pretty much what you get at the IrPHY (lowest-level stack), with no software smarts at all. That's... fine? I've done plenty of hobby projects with just that.
If you want simple, get something like NRF2401 and send around raw radio packets. This will give you retry and checksums with minimal fuss. If you want to save power, you will have to implement sleeping code yourself, but it is not too bad.
If you want compatibility with users' devices there is BT/BLE. It is probably the closest thing to the original IrDA use case.
If you want debug/programming/generic UART use USB. As an extra bonus you get power as well.
If you want electrical isolation, use optical fiber or 3d-print a custom optical plug. I guess you can run IrDA over it, but plain UART will work as well, and will make adapter much simpler.
If you want to securely talk to a device without USB port (maybe waterproof/dustproof) then optical link may be handy.. but don't use it all the time, use optical link to transmit wireless channel/key and then switch to wifi/bt/nrf2401 link. This will give you much better UX, your link won't get broken because somone bumps the device. Oh, and yiu can run it super slow (10bps) and one way so users can transmit with their cell phone. Or use status LED as photo sensor so that you have no visible elements on your front panel.
.. so, what does this leave for IrDA? I can think about a couple of scenarios, but they all seem convoluted and uncommon.
Impressive part. Definitely seems to handle a lot of simple use cases. 10mA transmit/receive is certainly good. But we're still far away from 0.075mA receive currents that the TFDU4101 promises.
That's 0.075mA while _active_ and 0.00001mA (0.01uA typical) when sleeping/shutdown.
> If you want compatibility with users' devices there is BT/BLE. It is probably the closest thing to the original IrDA use case.
Yeah, that's definitely dead. There's no more PDAs, laptops or even USB dongles for IrDA these days.
> If you want to securely talk to a device without USB port (maybe waterproof/dustproof) then optical link may be handy.. but don't use it all the time, use optical link to transmit wireless channel/key and then switch to wifi/bt/nrf2401 link
I think the optical "wake from sleep" signal, followed up by nrf2401 is probably best for most purposes, as you note.
---------
I'm not sure if "securely talk" is super relevant. Just "talk" is fine, because wireless is... well... wireless. Its about convenience. (I know IrDA nominally is "more secure" than Radio since its shorter range, but... like NFC there's still security concerns IMO).
But what if 10kB is all you need to transmit (~1 to 2 seconds of IrDA 115,200 baud, and just a fraction of a second if you implement 1Mbit, 4Mbit or 16Mbit IrDA), that's more than enough to dump an environmental sensor log (ex: ATTiny only has like 32kB of Flash storage, so your entire memory dump is only going to be 30ish kB. Smaller ATTiny4 has only 4kB).
Something like... those E-Reader price tags probably fits within 20kB or so (https://www.opticonusa.com/products/electronic-shelf-labels/... is 152x152 pixels monochrome, or ~20,000 pixels). So the entire image would in fact fit within a fraction-of-a-second IrDA (albeit 1Mbit IrDA, rather than the default 115.2kBit IrDA).
EDIT: Seems to be a part like: https://www.digikey.com/en/products/detail/pervasive-display...
So if the infrared communication can "do it all", why even bother with a "Infrared to wakeup, then Radio to send/recv" kind of protocol? Just send the whole damn message over IrDA.
-----------
It seems like the sweet spot for IrDA / IR is for small (less than 50kB) messages with simple control schemes. From remote controls (just 8 bytes or so), to maybe log dumps (30kB), to simple images. That way, you're not actually having an "extended" infrared session. Its something that's done near instantly when you point-and-shoot the infrared signal to the thing.
IE: The IR-receiver just "never sleeps", at 0.075mA of current, its around the leakage current of some batteries, so there's no point making a sleep circuit. When it receives an IrDA message, you can have a quick session (Hey, are you X123152 device? Yeah I'm X123152 device. [insert cryptographic security here] Please send me your logs. Okay, here's a logdump: [30kB data dump at 1Mbit]. Hey, resend blocks #45, #99, #5555, those were in error. Okay, here's a resend: [resent blocks]. Etc. etc.).
At 1 megabaud or 4 megabaud, this all can be done in less than 10 milliseconds, in apparent instant speeds to a human.