Not receiving ir pulsin
fleawhisk
Posts: 8
I have constructed the 555 Timer circuit mentioned in "Parrallax Weekend Ap notes" which was downloaded from the products-sensors-infrared detector section of the web site. The circuit is also in the BS1 Ap notes but I am using a BS2.
The circuit has been tuned as suggested in the "Robotics Student Guide"
The circuit will hopefully take a pulsout command and modulate it at 38.5 KHZ.
My pulsout command(repeatable) is: pulsout 9, 300 (300 microsecs).
My other stamp has an ir detector to receive it: ---> pulsin 10, 0, storeit
After receiving and debugging storeit ; I consistently get #'s 17 to 46 and everything inbetween.
Even if I change the pulsout to 750 or 1000 microsecs I still get the same #'s: 17--->46 !?!?!?
It will not receive the 300 microsec being pulsedout by the other stamp.
Help Please
The circuit has been tuned as suggested in the "Robotics Student Guide"
The circuit will hopefully take a pulsout command and modulate it at 38.5 KHZ.
My pulsout command(repeatable) is: pulsout 9, 300 (300 microsecs).
My other stamp has an ir detector to receive it: ---> pulsin 10, 0, storeit
After receiving and debugging storeit ; I consistently get #'s 17 to 46 and everything inbetween.
Even if I change the pulsout to 750 or 1000 microsecs I still get the same #'s: 17--->46 !?!?!?
It will not receive the 300 microsec being pulsedout by the other stamp.
Help Please
Comments
Did the last two programs in the Weekend Special AppKit work? If so, we know that your IR LED and detector are good, and able to communicate. The only possible gotcha there would be putting the IR LED in backwards when rewiring for the 555 timer. There may be other issues with the 555 timer circuit though.
Try the circuit shown in this post: http://forums.parallax.com/showthread.php?p=536500
Thanks for the reply!
I shall recheck all 555 connections/components.
I am sure my receiver ok because have used it quite often with your remote and stamp to stamp communication programs you wrote in the orig. Ap note. By the way these programs have helped TREMENDOUSLY over the past few years---> THANKS !!!!!!
Back to the circuit you referenced; when I loaded it it bought up up several posts on JVC remotearchives (thread: ir remote control w/ BS2). In sum the posts were somewhat confusing:
1. In your "Testjvctransmit.bs2" prog, the following code transmits a binary 1:
pulsout 6, 263 (pulsout 526 microsec)
pulsout 8, 550 (pulsout 1100 microsec)
tot: 1626 microsec
2. In the next to last post, "Noodles" posted on 5/25/05 that : the binary 1 of 2.1 ms(2100 microsec) - the 526 usec = 1574.
This is close but does not = the 1626 usec ???
3. Also if the delay i.e. 2100 usec needed between rising edges is 2100 usec for a binary 1 then
2100 -526 = 1574
To convert to the pulsout command one would divide by 2 giving 787
therefore should not the second pulsout read: pulsout 8, 787 (instead of 550)
to get the proper delay time/
Thanks, John Bell
Wow, that's excellent; thanks for letting me know.· One note about "Program Listing 1.4 – Display IR Remote.bs2" in the Weekend Special AppKit.· It takes 25 bytes of RAM, but now, there's a much better program now that only takes three bytes of RAM.· It's in the IR Remote Documentation·on the IR Remote Parts Kit page, and the program is called IrRemoteButtonDisplay.bs2.· That source code is also available for download as Source Code Example #2.
Regarding·the JVC Code example on the·IR Remote Control w/BS2 thread, keep in mind that there is some processing time as the BASIC Stamp 2 transitions from the PULSOUT command on P6 to the PULSOUT command on P8.· This adds to the low time, so I had to shave 237 off the PULSOUT command to P8.· It also takes some time going from the PULSOUT on P8 to the next PULSOUT on P6, which also contributes to that difference of 237.· I'm pretty sure that addresses all three points; please let me know if it doesn't.·
I used the Parallax USB Oscilloscope to view and tune the signal TestJvcTransmit.bs2 created.· Attached is a screen capture.· The blue trace on top is the signal on P6, and I put the cursors on the cycle time.· Note that the Delta for the cursor measurements is right·at 2100 us.· The red trace on the bottom is the "dummy signal" on P8 that establishes the correct low time on P6 (even though it involves fractions of milliseconds).· Note that there is some time between the end of the pulse on P6 and the start of the pulse on P8.· Likewise, there is some time between the end of the pulse on P8, and the start of the next pulse on P6.··Those two processing times combined are offset by the·reduction from 787 to 550 on the P8 PULSOUT.
Regards, Andy·
Post Edited (Andy Lindsay (Parallax)) : 7/15/2005 6:12:53 PM GMT
The reply was very informative and full of x-cellent documentation.
Much more understandable now.
Hope to work on it some this weekend but will be busy. If can't then hope to next week
Sorry this post does not help your thread.
But I need to ask.
A 300us blink rate (on/off 50%duty) is 38.5Khz???
I ran those numbers once and I came up with a much smaller number.
Was I that far off?
Thanks
Jack
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - PLJack - - -
Perfection in design is not achieved when there is nothing left to add.
It is achieved when there is nothing left to take away.
My problem is somewhat related to the esoteric discussion thread "IR REMOTECONTROL W/BS2" that was mentioned earlier. It can be obtained from the archives and/or public forums--> stamps in class.
1. the very first post by dimatt mentioned that using the JVC protocol a 526 usec pulse was 20 cycles on a 38khz carrier burst. I do not understand this. Can someone explain or reference a source that would relate khz cycles to the microseconds(in this case 526).
2. Why was 526 usec chosen (263 on pin 6 in pulsout statement) as a basis for programming the pulsout? I suspect it somehow related to the 20 cycles of 38 khz. After that the pulout length on pin 8 would have to be adapted to the particular protocol(in this case JVC) to give a meaningful binary one or zero..
The following will probably answer your first question in detail. It's merely a definition of frequency and how frequency relates to time:
http://en.wikipedia.org/wiki/Frequency
Or, mathematically: 1 / 526 = 0.00190114... or 20 cycles rounded and scaled.
As far as the second question is concerned, I can only presume that 526 u seconds is stated in the JVC protocol definition or standards. Each remote control may differ in its baseline pulse width. I honestly didn't look at that thread however.
Regards,
Bruce Bates
One of the reasons infrared is flashed on/off at that rate is to distinguish it from other infrared sources such as the sun, and indoor lighting. While the sun repeats its cycle once daily, lighting systems tend to flicker at twice the main power frequency. The voltage on electrical outlets pushes and pulls at 60 Hz in the US, and 50 Hz in other parts of the world. When the AC voltage is half way between it's push and its pull, there is actually 0 V for a moment, and it does this twice every push/pull cycle. That's why many indoor lighting systems transmit some infrared flicker at either 120 or 100 Hz. If an infrared receiver detects IR flashed on/off at 38.5 kHz, it assumes that an infrared remote is trying to send a message, and not the sun or indoor lighting.
I have heard that the first remote controlled televisions used ultrasonic sound, at a frequencies of 32, 38.5, and 40 kHz. Those old remotes used brief bursts of ultrasonic sound to transmit messages to the ultrasonic receivers in the televisions. I'm assuming that infrared was designed to be a drop in replacement for the ultrasonic systems, and that's where the tendency to communicate with bursts of infrared flashing on/off at those frequencies came from.
One full cycle of on/off at 38.5 kHz takes 1/38500 seconds. That's 0.00002597 seconds. If you multiply one on/off cycle by 20 repetitions, the time it takes to flash on/off for 20 cycles turns out to be .0005195 seconds, which is 519.5 us. If you run this same math for 38.0 kHz (instead of 38.5 kHz), you'll get 526 us.
The IR flashing on/off is called the carrier signal because it carries information. For infrared remotes, the amount of time it lets the signal run carries the information. A remote sending messages to a SONY TV lets that signal continue for 2.4 ms to let the TV know that a message is starting. After a brief rest of 0.6 ms, the remote again sends that 38.5 kHz signal. This second burst might last for 1.2 ms, which sends a binary 1 to the TV, or it might last 0.6 ms, which sends a binary 0 to the TV. After this second burst, there will be another rest where no IR is flashing on/off. The bursts will repeat 11 or so more times, with either 1.2 ms (binary 1) or 0.6 ms (binary 0) millisecond bursts. With 12 different combinations of 0 or 1, it makes it possible to send 4096 different combinations. In other words, this 12-bit message can send numeric values between 0 and 4095.
The reason we think about all this as pulses that last for 2.4 or 1.2 or 0.6 ms is because the output of the receiver inside the television set tends to send one voltage while it sees the 38.5 kHz signal, and a different voltage while it sees no signal. When graphed over time, they look like pulses. You can see lots of these graphs in IR Remote For the Boe-Bot <http://www.parallax.com/detail.asp?product_id=28139>, which is available for download from www.parallax.com -> Downloads -> Stamps in Class Tutorials.
History of the Remote Control
Interesting reading. Ultrasonics were actually an intermediate step, preceeded by flashlight control and wired control.