IR communication between BS2p and BS2 at 56kHz

midgtmn

Hello,

I am working on an autonomous blimp project for my Robotics class, and I am using Infrared beacon tracking. I am using a 56kHz carrier frequency for the communication.

I have based my code off the IR Remote For the Boe-Bot book available on the Parallax Website. They have example code used to transmit any "message" (ASCII character) between the two BS2's. They develop a simple IR language where 3ms pulse is a start bit, 2ms is binary 1, and 1ms is binary 0.

Due to the 56kHz carrier frequency, a BS2 is not capable of putting out the beacon signal, therefore a BS2p was used. A standard BS2 is used as the receiving module.

This chart is taken from the Basic Stamp Editor index on the Freqout command:
[noparse][[/noparse]IMG]http://i277.photobucket.com/albums/kk62/mibusmeatbag/FreqData.png[noparse][[/noparse]/IMG]

As you can see, the BS2p has vastly different units for use with the freqout command. I have translated the 56kHz carrier frequency to 14854 (56000/3.77) and the the bit pulse durations in "BeaconCode" program (3ms/.265~=11, 2ms/.265~=7, 1ms/.265~=4).

The receiver finds signal, so the beacon is putting out the proper 56kHz frequency, and it receives the start bit (3ms) pulse properly, but it constantly says the data bits are out of range. I have tried modifying the pulse durations on both the beacon and the receiver, but I cannot get it it to ever translate properly.

Is my conversion wrong for the Beacon side durations? Should I change the "language" to work at a totally different ms pulse width? Any help you can provide would be great! I have attached the beacon and receiver programs for reference.

allanlane5

What are you using to recieve this signal?

The "IR Remote for BOE-Bot" is using an off-the-shelf IR-decoder. The IR-decoder is designed for the 38 Khz signal used by many TV remotes. So, if you were going to go to 56 Khz, you'd need a 56 Khz IR-decoder.

If you have that, the only thing I can think would be a problem is that some of the IR-decoders require a "pull-up" resistor (10 Kohms is typical) to +5 on their output. And the one's I've used are "active low", so when they detect a signal they output a 'low' voltage.

Edit: Having looked at your code, you really need to remove the "WRITE" from your Beacon Program.· "WRITE" writes to the eeprom, and you only get a million writes before the eeprom location wears out.· I don't know how often you repeat your beacon program, but you really don't want to WRITE to the eeprom that often.

Edit2: Looking at your receive message code -- the receive timing is relatively close.· You simply cannot put a 1 mSec per character DEBUG statement in the middle of it, and expect anything to work.· The only way to debug this is to go ahead and receive an entire "message"·of information, THEN have a DEBUG statement summarizing what was received.· Currently, your "start bit found" DEBUG will delay your program 15 mSec -- by which time, probably the entire byte being sent by your Beacon will have been missed by your receiver.

Post Edited (allanlane5) : 2/12/2010 10:18:44 PM GMT

midgtmn

I am using a 56kHz IR decoder, that outputs active low PWM, so the code is matched up to them appropriately (PULSIN command and whatnot).

Wow, that is really useful information about the EEPROM write limit... it completely makes sense when I think of it as Flash memory... I'm somewhat surprised that Parallax didn't make some note of that. I understand I am spamming out the character "a" a whole lot instead of using the standard form that Parallax used where the reset button was hit each time. Seeing as I am not doing the reset button method, I no longer need to have that variable stored in "permanent" memory, I can just have it float. Goodbye WRITE command. Luckily, it doesn't do that command with EVERY loop of the beacon, or I would have already put upwards of 3 hours of writes to that EEPROM...


I'm intrigued about the DEBUG commands adding that much delay, because I actually got the program to work now, with the Debugs in there. Now that it works, they have since been commented out. I ended up noticing (through the DEBUG commands) that the receiver was getting a start bit (3ms), and then would get the last 4 digits of the binary pattern for "a", but missing the first 4. I extended the timing of the between pulse pause from 1ms to 3ms, and now it all works great. Maybe the greater time between pulses nullified the problems caused by the debugs. Certainly something for me to keep in mind in the future, and I don't doubt that it (ironically) threw a wrench into my debugging attempts. Thanks for the help!

Here is the reason I found for the start bit being detected, but not the data bits:

FOR counter = 0 TO 7

    IF irMessage.LOWBIT(counter) = 1 THEN
        duration = 2
      ELSE
        duration = 1
    ENDIF

    FREQOUT IrLedPin,duration,IrFreq
    PAUSE BtwnPulses

As you confirmed, my pulse widths defined at the start of the code were accurate, the problem is that Parallax's code doesn't actually use the variables for the Binary1time and Binary0time pulses, it has 2 and 1 manually inserted as constants. So my changing the value of the variable at the top didn't actually change the pulse width used in the Freqout command. Simply swapping "duration = 2" for "duration = Binary1Time", etc fixed that aspect perfectly.

I quite simply missed it, It was my fault for not looking over the Parallax code more. I'm not quite to the point of coding this sort of thing from a blank slate, so I have been using a lot of the example code bits as baselines to work from.

The reason I used the code that is capable of sending out characters, is that now I can create a series of beacon codes that the blimp will follow. So, when it gets to "a" it begins looking for "b", etc etc.

As I said, I have now changed the code so that the beacon has no active debug commands at all, and the receive code only outputs once it has decoded a character. Thanks a bunch for the help, especially the pointer about the limited write EEPROM.

Assuming I get it all working and in the air this weekend, I'll toss a video up here if anyone is interested!

allanlane5

Brilliant, glad you got it all working. I look forward to the video.

Humanoido

Which 56Khz receiver are you using? When it's working, I would look forward to seeing your project posted. I'm working on something similar with the Propeller Chip. You posted the code that is not working. Can you post the code that is working? Thanks!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
humanoido
*Stamp SEED Supercomputer *Basic Stamp Supercomputer *TriCore Stamp Supercomputer
*Minuscule Stamp Supercomputer *Three Dimensional Computer *Penguin with 12 Brains
*Penguin Tech *StampOne News! *Penguin Robot Society
*Handbook of BASIC Stamp Supercomputing
*Ultimate List Propeller Languages
*MC Prop Computer