BS1 IR PULSIN problem

Croatia0987

Hello out there,

I'm new on this board and in the BS scene, if I am allowed to call this "scene".
Well, now to my problem/s:
In school we started to make a project for our "science and technique" subject.
In this subject, we decided to make a machine, which opens a door when you type in a code.

That's the theory. But we divided our project in two parts: On the one hand the type-in-the-code-stuff, on the other hand an open-the-door-stuff.

Those 2 parts are connected via IR.
The first part works very fine. We get after we typed in the right code an IR signal from the IR diode. We made this with another Microcontroller (language: c/c++).

Now the problem is the second part- the IR receiver and whole things with the BS. We don't know, how to write the program. The program should first show the breaks between the 1/0 signals (normal PULSIN command?!) and secondly we want to send an impulse from the P1 through another circuit (i.e. a LED, only to demonstrate that the microcontroller opened the second circuit).

Okay, now the programms we wrote for the IR receiver to show how long there's a signal coming through the IR receiver:
'{$STAMP BS1}
' {$PBASIC 1.0}
SYMBOL pulse = W1 '


Main:
PULSIN 0, 0, pulse
DEBUG pulse '
GOTO Main
ENDBut this program shows for pulse=0. I really don't know why, maybe I have to add something? For sure I have to add something.
Well, that was my first question- what have I to do to see how it pulses from the IR diode? Hope you can give answers and I'm sorry for my bad English, I live in Germany and yeah, after some years in school that's the best English I can offer you...

Mike Green

PULSIN tells you the width of the pulse (in units of 10us for the BS1). You didn't say how you're representing 0s and 1s. There are two ways that are often used: 1) After a synchronizing pulse, a 0 is the absence of a pulse and a 1 is the presence of a pulse at some expected time; 2) The width of the pulse determines whether it is a 0 or 1. #2 is easy to do with the PULSIN statement.

If your pulses are positive-going (0-1-0), use PULSIN 0,1,pulse. If your pulses are negative going (1-0-1), use PULSIN 0,0,pulse. For the sake of discussion, say your pulse is less than 1ms for a 0 and greater than 1ms for a 1. The PULSIN would return a value < 100 for a 0 or a value > 100 for a 1. Remember that the units are 10us. You'd have:

Main:
PULSIN 0, 1, pulse
IF pulse > 100 THEN oneBit
' here you'd do something if it's a zero bit
GOTO Main
oneBit:
' here you'd do something if it's a one bit
GOTO Main

Croatia0987

One question to your programm: Why is it PULSOUT?
We have 0-1-0 signal- positive going.

Now I did this:
Main:
PULSIN 0, 1, pulse
IF pulse > 100 THEN oneBit
DEBUG "Fail"
GOTO Main
oneBit:
DEBUG pulse
GOTO Main

But it fails again. I'm sending a signal to the IR receiver, but it always shows in the DEBUG terminal "Fail". And it doesn't care if there's a signal coming or not.
As you exactly said: I just want to determine if it is a 0 or 1, but it simply doesn't work.

Mike Green

Thanks for catching that. I meant PULSIN.

You didn't say the width of the IR pulse. The program I showed you assumes that the pulse is either shorter than 1ms ("fail") or longer than 1ms (oneBit). How do you define if the pulse is a 0 or 1?

Croatia0987

That's the problem. How can I get this width? Now I see, where my problem is...
We put a LED before the P0 so we cann see- LED on, P0 is 1. Before pressing a button it is off, so it is 0. Makes 0-1-0;

Mike Green

I assumed that your transmitter was putting out a pulse of some specific width that you could control. In that case you could use PULSIN. It sounds like your transmitter justs turns on the IR when a button is pushed and turns it off when the button is released. In that case, a PULSIN won't do what you need. You just need a simple test for whether IR is present, something like:

waitForOn:
IF PIN0 = 0 THEN waitForOn
waitForOff:
IF PIN0 = 1 THEN waitForOff
' Here you know that the button was pushed and released

Croatia0987

Well, after I used this:
waitForOn:
IF PIN0 = 0 THEN waitForOn
waitForOff:
IF PIN0 = 1 THEN main

main:
OUTPUT PIN2
INPUT PIN3
DEBUG"works"
GOTO waitForOn

I get only "works" in the debug terminal without a break. Soemthing is wrong, I don't know what. In follow I have to use a relay, the program I wrote works for it. So I have only to get the right signal for GOTO relay_circuit. I don't know why. I have to have it tomorrow, I don't know what to do... I worked on this now for 20 hours, and nothing is getting better.

Mike Green

You put "IF PIN0 = 1 THEN main" instead of "IF PIN0 = 1 THEN waitForOff".

Croatia0987

I don't get this. If there's a signal coming into the BS, then it skips to waitForOn. So if there's again a signal coming, it skips again to this? I don't get the sense, and after trying it, nothing happens in the DEBUG terminal (because the programm is always in the loop)- I think I'm too stupid for BS .

//EDIT: It seems, there's always Signal on my BS: I'll just take a few photos and load them up, perhaps you can help me better then

Our IR receiver, LED and a resistance. We're using this receiver: http://www.komputer.de/zen/index.php?main_page=product_info&cPath=24&products_id=56, Yellow Cable is VSS (at the receiver black cable, Ground), left green one Input PORT0, right green VDD.

If I push the button, the LED will light. That means, there's mass going into PIN 0. But why seems there to be always contact on this programm?:
INPUT PIN0


main:
IF PIN0=1 THEN go_on
GOTO main

go_on:
DEBUG"done"
GOTO main

After writing instead of "IF PIN0=1"--> "IF PIN0=0", nothinh happens in the debug terminal. Doesn't matter if I press the button or not.

Mike Green

This IR detector is similar to the one sold by Parallax and it behaves the same way. When there's no modulated IR coming in, the output is high (1). When it receives modulated IR (at 38KHz), the output goes low (0). You effectively have a negative going input pulse (1 - 0 - 1).

waitForOn: IF PIN0 = 1 THEN waitForOn

The above loop assumes that the idle state is high (1) and waits until the input changes to low (0).

waitForOff: IF PIN0 = 0 THEN waitForOff

The above loop assumes that the input is active (low - 0) and waits until the input is idle again (high - 1).

You need both because once the input is on, the first loop falls through to, say a DEBUG statement. After the DEBUG statement executes, your program goes back to the beginning. The problem is that your program assumes that the input is initially idle which is not true. The input is still active from the first time. The waitForOff loop waits for the input to become idle again before it continues on to the DEBUG statement. This may not be the order you want. You can do the waitForOff first, then the waitForOn or you can start with the waitForOn, do the DEBUG, and then the waitForOff after the DEBUG, before going back to the beginning. If you only do the waitForOn, your program will display the DEBUG message, then go back to the beginning where it will do the waitForOn again while the input is still active from the first time. This will fall through and the DEBUG statement will execute again and so on until the transmitter turns off.

Croatia0987

How can I include this to loops? Now I'm thinking I understand, why I need those loops.
My brain is damaged of this project, it seems to be easy when you explain it, but I don't know how.

Mike Green

Part of the problem here is that you have not described the IR transmitter nor have you described the circuitry that sits between the IR receiver and your Stamp board, so I'm just guessing what the actual signal is.

The suggestions I have made are about as simple as things can be and it's not clear to me what you don't understand. You might just try some experiments using DEBUG statements to identify where in the program you are as things happen like

main:
DEBUG "main",PIN0
waitForOff: IF PIN0 = 0 THEN waitForOff
DEBUG "off",PIN0
waitForOn: IF PIN0 = 1 THEN waitForOn
DEBUG "on",PIN0
goto main

Croatia0987

IR transmitter is a remote controll for a TV- between the receiver and the board there's only a LED with a resistance (as seen on the picture).
After using your programm, there's all of the debug messages in my screen without pressing any button.

Mike Green

Ah! You're using a TV remote control! I wish you had mentioned this earlier.

A TV remote control produces lots of pulses of modulated IR. It transmits several pulses of different widths to make up a group of bits that gives information about the button that's pushed. This burst of pulses is repeated as long as the button is held down. The "IR Remote for the BoeBot Robot" tutorial discusses several of the (incompatible) remote control protocols used and discusses how to receive one of the common protocols used by Sony remotes. In your case, you don't really care what button is pressed. It's easy to detect the start of the first pulse of the first group of bits that's transmitted when you hold down one of the buttons on the remote control. The difficulty is determining when the button is released. The best you can do is set up a counter in a word and initialize it to maybe 32767. You have a test to see if anything is received (PIN0 = 0). If something is received, you reset the counter to 32767 and go test again. If nothing is received, you subtract 1 from the counter and try again. If the count becomes zero, then some time greater than about 1/2 second has elapsed with no IR pulses and you can assume that the button is released. You can change the 32767 to a smaller number if the time limit is too large.

SYMBOL counter = W1

waitForOn: IF PIN0 = 1 THEN waitForOn ' wait for start of first IR pulse
DEBUG "Button On"
testForOff: counter = 32767 ' initialize time delay counter
testForOn: IF PIN0 = 0 THEN testForOff ' reset time delay on any IR pulse
counter = counter - 1 ' if no IR pulse, continue time delay
IF counter > 0 THEN testForOn ' time delay expires?
DEBUG "Button Off"
GOTO waitForOn ' start all over again

Croatia0987

I got the problem. It was simply the LED with the resistance. I don't know why this didn't work before, because the programm you send didn't work. Then we did a trobleshooting with our teacher, because it didn't work today- I just said I could do everything, it won't work. Then I just took the LED away- voil

Mike Green

Remember that, the more information you provide at the beginning, including complete schematics and a complete description of the pieces, the better and quicker the answer that you will get.