Badge: Adventures in IR
Seairth
Posts: 2,474
in Propeller 1
So, working with the IR on the new badge has been very enlightening.
In particular, I was working on a new game that involved IR communication between two badges. Unfortunately, I had not paid much attention to the specifics of the driver that @JonnyMac had written, so unnecessarily spent two days trying to fix the wrong problem. In particular, the driver is half duplex, but I was using it like it was full duplex. (Clearly my own problem, not the driver's problem.) Realizing my mistake, I took that driver and made a two-cog full duplex version! It worked exactly like I need it to, so I moved on.
To my next problem. It turns out that full duplex IR has an inherent flaw: the IR receiver is picking up the transmitter's signal! I know I could alter the badge with a barrier between the two parts, but that would not fix reflections off of nearby surfaces. And since my application requires two badges to face each other, reflections will be significant. Even if the reflection is slight, it appears to be strong enough to introduce enough noise that the receiver cannot pick out the desired signal from the other badge. If I could make both the transmitted IR narrower and make the receiver input narrower, this might also reduce the reflected signal detection enough that two badges could effectively communication. Maybe. But beam shaping IR signals is not my forte, so I'm at a loss of how to proceed here.
And since the game is pointless without the IR, I will have to shelve it for now. Now I am sad.
In particular, I was working on a new game that involved IR communication between two badges. Unfortunately, I had not paid much attention to the specifics of the driver that @JonnyMac had written, so unnecessarily spent two days trying to fix the wrong problem. In particular, the driver is half duplex, but I was using it like it was full duplex. (Clearly my own problem, not the driver's problem.) Realizing my mistake, I took that driver and made a two-cog full duplex version! It worked exactly like I need it to, so I moved on.
To my next problem. It turns out that full duplex IR has an inherent flaw: the IR receiver is picking up the transmitter's signal! I know I could alter the badge with a barrier between the two parts, but that would not fix reflections off of nearby surfaces. And since my application requires two badges to face each other, reflections will be significant. Even if the reflection is slight, it appears to be strong enough to introduce enough noise that the receiver cannot pick out the desired signal from the other badge. If I could make both the transmitted IR narrower and make the receiver input narrower, this might also reduce the reflected signal detection enough that two badges could effectively communication. Maybe. But beam shaping IR signals is not my forte, so I'm at a loss of how to proceed here.
And since the game is pointless without the IR, I will have to shelve it for now. Now I am sad.
Comments
1. In the "discovery" state, let each badge transmit an ENQ signal, with random timeouts, during which it waits for an ENQ from another badge.
2. If a badge sees an ENQ, it responds with an ACK.
3. The badge then enters the "comms" state. The ENQing badge becomes the master, and the ACking badge the slave for the half duplex comms that follow. Just pick a protocol, wherein the master constantly polls for commands and data from the slave, while it's also sending commands and data.
4. If the slave does not respond to a poll, the master enters the discovery state again. If the slave does not receive a timely poll, it enters the discovery state again.
-Phil
Which is why -- for designs like this -- I use half duplex.
I was born at night, but not last night. If I do something in code that you think is somehow crippled, please consider that I have in fact worked with the associated hardware and considered real-world issues. The code base for these badges is mostly intended for newcomers; the last thing they need is twitchy code that sometimes works. It has be be reliable for them to have fun and want to keep exploring the Propeller.
I'm a little confused - surely it only has to appear to the user to be duplex, just like USB manages to appear to be Duplex.
Yeah, that is the only approach I've been able to think of too. My concern is that the responses will not be timely enough for the game to work correctly. But I guess I won't really know until I give it a try!
My apologies if I implied that the fault was yours in any way! I fully understand why you used half duplex and I fully acknowledge that the fault was on my side. Twice. Once for not paying enough attention to the fact that the driver was half duplex. And a second time for not realizing the inherent flaw of full duplex IR. In the former case, that was a "Doh!" moment that should have never happened. In the later case, I learned from failing!
As I have never worked with IR before, this has all been a learning experience for me. From that perspective, I am a newcomer. And your driver did exactly what you intended it to do: work well (thank you!) and make me want to explore more! I expect others to do the same. And I expect that at least one of them will also attempt to try doing a full duplex design and encounter the same challenges I did. And, if they are fortunate enough to read this post, they might avoid some of the dead ends I've encountered.
Are you talking about the user of the driver? Yes, I suppose that's true. If there were a relatively efficient way of mutually determining who the talker is and not starving either the tx or rx, it might be possible to hide the half-duplex details in the driver. As it currently stands, the original driver notes that the safe operating baud rate is 2400, so I suspect any solution will be slower than that.
I thought the lowest IrDA HW spec I'd seen was 115200, with options to go faster ?
Maybe range improves at the lower baud speeds ?
Well, as I mentioned earlier, IR programming is new to me (I'm learning as I go). According to the badge documents, the IR receiver operations at 36KHz. Doing a quick search online, 38KHz IR has a theoretical maximum bit rate of about 4Kbps. So 2400bps is probably reasonable for 36KHz modulation in the wild.
Ahh.. oops I saw IR and Serial, and I assumed IrDA, but I think you mean IR remote control.
Specs on those suggest >= 10 cycles min, and td = 7~15 cy and Tpo -5~+6 cy , so yes, a 10 cycle ballpark is about right.
Other graphs indicate around 0.1ms of variance with signal level.