56 kHz IR Sensor Interference from 38 kHz Signal
erco
Posts: 20,255
Just received some Vishay 56 kHz IR sensors from Junun. Hoped they wouldn't glitch when they receive a 38 kHz signal from an IR remote, but they do. Also tried two different Waitrony 56 kHz units, same result. The strong IR remote signal still punches through.
I'm surprised and certainly disappointed. With all their internal digital filtering circuitry, there shouldn't be any crosstalk at all.
Possibly it's immune to a weaker 38 kHz signal, but I was hoping·these would allow a robot·to·track towards a 56 kHz·IR beacon·while also receiving 38 kHz signals·from a standard·IR remote. But that won't work, the IR remote signal is so strong it glitches the 56 kHz receiver and would interfere with beacon tracking.
Anybody have success using 2 IR carrier freqs simultaneously? Maybe different sensors.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."
I'm surprised and certainly disappointed. With all their internal digital filtering circuitry, there shouldn't be any crosstalk at all.
Possibly it's immune to a weaker 38 kHz signal, but I was hoping·these would allow a robot·to·track towards a 56 kHz·IR beacon·while also receiving 38 kHz signals·from a standard·IR remote. But that won't work, the IR remote signal is so strong it glitches the 56 kHz receiver and would interfere with beacon tracking.
Anybody have success using 2 IR carrier freqs simultaneously? Maybe different sensors.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."
Comments
You can add external filtering if you like. Run the digital output through an RC lowpass filter and then into a Schmitt-triggered gate. This will eliminate the glitches. Of course, if you're using it with a Prop, you can do the additional filtering in software.
-Phil
So if 'bot 1 wants to find it's nest, it first sends a please ack message to it's nest. When the nest receives a please ack from it's "master" it sends an "ack" message over an over again only TO THAT 'BOT, until the 'bot lets the nest know it's docked. The nice thing is that with a decently robust error checking mechanism, there is no cross-talk, no overlap. The worst case is that it can take a bit longer for any given platform to "lock" onto a message (longest being about 1 second, shortest being about 50ms).
Even nicer is that the same IR/emitters that handle communication can double as obstacle detection, or for receiving commands from a regular TV remote, etc.
In our case we use 3ms start bit, 2ms for a "1" bit and 1ms for a "0" bit. Generally SXes handle all the protocols for the host, but this 1ms unit schema will work for Basic Stamps. Additionally, because the start bit and 0/1 bits are substantially different from, say, SIRCS, there is no interference when someone in the house uses a regular remote (the start bits are all wrong, the pauses/lengths for bit pulses are all wrong).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php
I should be paying you guys for your lightning-fast, informed replies. I certainly do appreciate your technical knowledge, vastly superior to my own.
In this particular case, I'm looking for the quickest, simplest, low-tech implementation with minimum parts. Specifically, I want to add beacon tracking and IR proximity sensors to my Poor Cousin (AKA Retrobot in the new ROBOT magazine) with the fewest number of parts. AND I'm hellbent on using the single BS2E on the robot that's monitoring my encoders, so·I can't afford any more processor overhead.·I need an easy·hardware solution that will use minimal external circuitry.
I'm going to have LOTS of these sensors on the robot. Besides 2 or 3 beacon receivers, I'll have about 8 perimeter IR sensors on my robot. Not unlike the 10 Pings on the robot Ken sent to Phil.·One 556 circuit generating a 38 or 56 kHz·IR signal, which is piped out to each sensor.·Each sensors is simply an IR LED and an IR receiver, digital signal out for object detected. And I'll figure out a poor man's way to multiplex those into the stamp with the fewest pins. Maybe even RCTime... ain't THAT Ghetto?
Again, I thank you for your excellent and functionally superior suggestions. I'm just taking a different road for this particular project. I've enjoyed the success of·using low-tech methods thus far,·so·I want to continue and see how far I can push a single Stamp. I promise to stop short of achieving world domination. I plan to use a Propeller for that. [noparse]:)[/noparse]
erco
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."
But first, a few anectodal observations about IR receiver modules. My shiny new (OK, black) 56 kHz Vishay modules are HONESTLY continuous signal acceptable. That is, they stay active low as long as they continuously receive an unmodulated 56 kHz signal. I have tested Waitrony 38 kHz modules that are marked "continuous signal acceptable", but curiously, they still require a continuously modulated signal, such as a LM556 can produce. Many other modules are not continuous signal acceptable, and they have filters to only pick up properly encoded signals. Not useful in my simple application.
10 years ago, the Sharp "tin cube" 40 kHz sensors were the only game in town, and about 50% of them would detect an unmodulated 40kHz signal. But today, the 56kHz units are the only ones I find that can detect an unmodulated signal. Based on that, I'll use them for my perimeter obstacle detection system. I plan to use just a bit of processor power to check the IR sensor array while looping through my encoder monitoring program. After ~10 sequential active low readings, I should be sure that it is the 56 kHz signal and not some encoded 38 kHz remote signal bleeding through.
I'll start with 4 front-aimed sensors, and run those 4 outputs through a 4012 4-input NAND gate, so any low signal from any of the 4 units will give a low output. So that's just one IF check inside my program loop instead of four. Then I can stop the robot, stop worrying about the encoders, and then take a closer look at the 4 individual sensors to locate the obstacle.
Thanks for your comments, guys! Every word helps! BTW Zoot, your multi-Bot world sounds intriguing. I want to hear more about that. Do you have a website, or have you posted a thread about it?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."
Basically, it's just like sending or parsing any kind of IR "remote" code, the question is how often to you send/check and what do you do with the info.
In the case of my own self-charging 'bot, there are two IR detectors (Panasonic 38khz demodulators) separated by a black foam care "vane" about 7" long. The detectors sit at the back on either side of the vane. The effect is that unless the 'bot is essentially pointed straight at the transmitting beacon, only one or the detector will receive the data stream. When the 'bot is straight on, both will receive the stream. The nice thing, again, is that since the beacon is actually sending an encoded message TO that specific 'bot and FROM itself, other 'bots will disregard the messages, and in addition will keep out of the way (see below).
I would say the only twist I've put on on these methodologies, is to establish a simple syntax for the actual messages that is more conversational rather than programmatic, and allows for newer platforms to be constructed that will interact in a loose way with existing platforms without necessarily knowing anything about the platforms.
The short version is something like this:
- all platforms are required to answer a "please ack" with an "ack" (for basic self-identification and so 'bots can know "who's around")
- messages are broken into a basic set of "questions" and "replies". Any given platform can be set up -- independently -- to do what it will with certain question/answer combinations. We actually sat around and tried to break up basic friendship overtures into their simplest building blocks:
Questions/Requests:
Are You There? (request ack)
How Are You?
Will You Join/Play/Interact with Me?
Please Leave Me Alone?
Answers:
I Am Here (ack)
Yes/Good
No/Bad
Maybe/OK
The idea is that you can build up some interesting interactions that may go something like:
bot $5: "Bot $6, are you there"
bot $6: "I am here " (acks ARE REQUIRED TO BE GIVEN)
bot $5: "How Are You?"
bot $6: "Yes/Good" (e.g. maybe only when his light detector sees bright light is he "good"
bot $5: "Will You Play with Me?"
bot $6: "No" (maybe because each time $5 says no to *him*, he increments a counter that says $5 is not his friend)
etc.
Keep in mind that what it actually means to "join/play" is up to each platform. At it's simplest, both 'bots may be just sit still "next" to each other, like dudes around the keg. More specifically programmed platforms may do something more synchronized.
- last but not least, any platform that gets a "broadcast all" message or a specifically addressed message from any 'bot with a LOWER address IS REQUIRED to "stop in place" until it is no longer reading that lower addressed 'bots transmissions. In our house, the bigger faster 'bots all have lower addresses. The reason is that once you have 5 or 6 or 8 'bots running around, all of different sizes and speeds and evasive capabilities you have UTTER CHAOS on your hands in about 5 minutes. A Boe-bot will get trampled even in trying to "obstacle avoid" a bigger 'bot. It also *looks* chaotic and messy, which is not good for demonstrations. So the smaller 'bots, for the most part, "freeze" in the presence of the bigger 'bots -- this turns them (for a short while) into stationary obstacles for the bigger 'bots, so they can maneuver through the crowd without crushing anyone. Of course, none of it is perfect, as different 'bots with different intensity IR emitters, detector positions, heights, etc. don't always see Rx/Tx what would be ideal, but it works out OK. Mostly because the bigger 'bots all have pretty high power TX emitters, while the smaller 'bots often share their IR obstacle detection capability with the Tx/Rx (i.e., the smaller 'bots "talk with their eyes", while the bigger 'bots generally have separate obstacle detection and Tx/Rx setups).
Attached below is the in-house white paper we use with the actual messaging formats. Right now I'm actually using a slightly longer Tx frame than is in the docs (mostly to allow for more time to do a bit of obstacle detection between Tx/Rx sessions), and with some additional time granted during an Rx timeout if most of a message has been received, but this is basically current reality on the ground.
You'll note that the messages/acks conveniently break down into 2-bit chunks. You'll also see that the upper 8 bits of the message are reserved for "platform-specific" messages -- essentially this is a message space that does not conform to any syntax or schema. Some platforms do not use this space, some do (i.e. it's way to allow for specific platforms to receive messages like "forward/reverse/turnLeft/turnRight/stop", or "reset your EEPROM parameters"). We wanted to leverage a portion of the already working protocol for "remote controls" and the like that fall outside the bounds of our protocol.
Last but not least, you'll note that the postions of bits and their meanings in the messages, as well as address assignments for each 'bot were chosen to provide the "shortest" full data packets for the 'bots that need them most. Remember that if 1ms = 0 and 2ms = 1, transmitting $FFF will take much longer than transmitting $700. In any case, the actual firmware generally keeps an "age counter" on the last received message as well, which is amazingly useful for having the platforms react appropriately. As it can take 1-1.5 seconds (under worst circumstances, with multiple 'bots transmitting at once) to lock on, it is advantageous to know of the last received message came 1 second ago or 65 seconds ago. In the case of the later, the 'bot can say "well, I know he *was* here, but he's long gone now".
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php
Post Edited (Zoot) : 3/1/2010 7:51:52 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."
last note re: IR data/code -- same trick Phil used for his Ping))) echo-location demo (an simple IR schema was used to tell which Ping))) to trigger and when). You probably know this, but if you hook a 555 up to all your IR anodes (or cathodes) for the IR emitter modulation, then the other pins of each emitter to a Stamp pin, you can turn on a given emitter with just high/low and or use PULSOUT to get very precise and sub 1ms modulation bursts, whereas a FREQOUT for the modulation is limited to 1ms units (plus consumes more code).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php