Using spin to send data on a 38kHz carrier

morris4019 · 2009-05-26 03:37

I'm taking advice, in that i will be using a microcontroller to control an IR·beacon, instead of·just a 555·timer.·That way i can transmit actual data signals rather than just 38kHz that could be anything. I can create the 38kHz carrier but have not had good luck finding any information on sending signals and recieving signals through IR. I can manually create pause in between pulses, but I still won't be able to send high and low bits in between pauses.

Does anyone know where i can find the information i need?

-Mike

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

======

······ I'll try everything once [noparse]:)[/noparse]

kwinn · 2009-05-26 04:39

Mike, the simplest way to send data over an IR beacon is to have x cycles on = 1, xcycles off = 0 (or vice-versa), and send a different code from each beacon. Of course you cant have too many zero bits in a row or you will loose sync so you need to pick the right data encoding for that. You may also need to make the receiver directional if the beacons are close enough to interfere with each other.

Leon · 2009-05-26 04:48

Will Spin be fast enough to modulate a 38 kHz carrier?

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

morris4019 · 2009-05-26 04:49

So doing some more reading... I've done this project with the stamp, and went back over the code. I'm just wondering if i'm right in my thinking. Each bit is seperated by a short rest, say 1ms. The duration of each bit dictates its state, so say 1.5ms=0/low, 2ms=1/high. Abviously the rest period between each pulse of data will be longer, say 2.5ms. And being that i am creating my own designation for the beacons and bots, I can mix them together as i want correct?

Say Beacon 1 ID = REST.0.0.0.1.REST
Beacon 2 ID = REST.0.0.1.1.REST
Beacon 3 ID = REST.0.0.1.0.REST.... and so on.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

======

······ I'll try everything once [noparse]:)[/noparse]

morris4019 · 2009-05-26 04:52

@Leon, I have already generated the carrier frequency to test my IR detector and emitters. I am just trying to find the best way to transmit data through the carrier.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

======

······ I'll try everything once [noparse]:)[/noparse]

Phil Pilgrim (PhiPi) · 2009-05-26 05:09

I would generate the carrier using one of the counters, outputting on a pin. This pin will drive an IRED when it's pulled low. Then, using the same pin, you can transmit via one of the serial I/O objects, such as FullDuplexSerial. The signal from the serial I/O will be ORed with the carrier, thus driving the IRED at 38KHz only when the serial signal is low.

-Phil

hinv · 2009-05-26 05:14

Finally something I can help with ;^)

Check out the Square Wave PE Kit Lab:
http://forums.parallax.com/forums/default.aspx?f=25&m=343747

They have an example of a sony remote control signal half way down the page.

Hope this helps,

Doug

Ken Peterson · 2009-05-26 12:41

I would use Pulse Width Modulation rather than Amplitude Modulation to encode the bits. That way you can avoid the problems of too many like bits in a row. It allows for greater clock disparity between sender and receiver. Even so, I like Phil's approach to doing the modulation by taking advantage of the wired-or configuration on the I/O pins.

I'm sure SPIN is fast enough, as your bit rate will need to be much slower than 38KHz. This assumes you use a timer to generate the carrier.

Ken

Mike Huselton · 2009-05-26 14:26

hinv,
I really liked the Square Wave object introduced in the Lab. The quality of the Labs is exceptional.
Andy, are you listening? You need to ask for a raise

.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH

kwinn · 2009-05-26 16:13

Ken, pwm is a good idea. Is there an object in obex that could do that using Phil's idea for modulating the 38KHz carrier?

morris4019 · 2009-05-26 18:14

Great information on that link hinv, thank you, thank you all! This was what i was looking for. I had previously gone through the entire PE Labs Fundamentals .pdf, and everything was in there except the small portion, that you pointed out, about working with a SONY remote as an example, to modulate the frequency.

Now Phil, i'm interested in what you were saying. From going through this Lab in the link above, it seems that it works almost like what you are talking about, except it is not using the FullDuplexSerial obj. Bascially i would have to manually configure high time, low time (ie .6ms = 0, 1.2ms = 1 for SONY configuration that is) possibly just using constants as reference. That way i could have a bin number, say 0101, then using my constants a method would either send out a 0 (.6ms) or a 1 (1.2ms) respectively. Now, the FullDuplexSerial i thought was used directly to send information to the serial terminal on a pc. Your saying that i can actually switch that to output to a pin, and in this case the same pin as the output to the IRED, right? And, being that I am holding that pin high, when the serial data gets ORed together with the frequency data, i'm left with the serial representation inside the carrier frequency? Is that right?

-Mike

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

======

······ I'll try everything once [noparse]:)[/noparse]

JonnyMac · 2009-05-26 18:17

I really liked Phil's idea of using a counter to modulate a pin and then or-ing a UART transmitter output to control the IR LED. As I had previously used a counter to handle IR modulation for a Sony controller and wrote my own simple serial driver (for use in a DMX project); I combined the two and the output seems to look good. Mind you, I'm just looking at a 'scope and I'm not sure how quickly the IR receiver will respond but this should get you started.

Post Edited (JonnyMac) : 5/26/2009 6:24:23 PM GMT

morris4019 · 2009-05-26 20:58

So let me ask one more question, because i cannot get my IR LED to work properly. I have the annode connected to a 1k resistor to power·and the cathode connected to P15 on my PROPELLER. Pin 15 should be set as input, correct, to only be active low?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

======

······ I'll try everything once [noparse]:)[/noparse]

Post Edited (morris4019) : 5/26/2009 9:07:40 PM GMT

kwinn · 2009-05-26 21:13

The pin the led is connected to needs to be an output to drive the led, and needs a smaller value resistor (100-220 ohms) depending on the current you want. The led will light when the pin is low.

Phil Pilgrim (PhiPi) · 2009-05-26 21:23

kwinn,

Your LED is backwards.
_____________

morris4019,

Your A15 pin should be set as an output always. Otherwise the counter will not output to it, nor will your serial output.

-Phil

morris4019 · 2009-05-26 21:30

see the link here (and above)

http://forums.parallax.com/forums/default.aspx?f=25&m=343747

this is the lab i was told to get my information from and it is showing that in fig 4 & 5 the circuit is hooked us as i've said. Cathode to the microcontroller and annode toward 3.3v through resistor. I also thought it might be a coding problem when i noticed something. In the lab on the link above, it shows using the SquareWave object, using the Freq() method as Freq(pin, module, freqency) whereas in my copy of SquareWave.spin it shows (module, pin, frequency). Is there 2 different SquareWave.spin objects? I copied and pasted the code (for squarewave.spin) from the PE Labs fundametals pdf.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

======

······ I'll try everything once [noparse]:)[/noparse]

JonnyMac · 2009-05-26 21:38

With a 1K resistor you're not going to get much current though the LED; I typically use 100 ohms with IR LEDs and the Propeller. If you're going to modulate the LED with a counter and control it with the same pin you must connect the LED anode to Vdd and control it from the cathode side. A high on the control pin will make both sides high; a low on the control pin will allow the counter to modulate it.

kwinn · 2009-05-26 21:54

You are right. Sorry, that's what happens when you flip a circuit meant to run from a pin with a high out and don't double check it.

morris4019 · 2009-05-26 22:03

So simple error on my part in the code only let it send one signal before stopping. So my IR LED works fine. Now on the other end, another cog has the job of monitoring for the signal. I don't get any reaction at all out of it, and have even tried giving it a little leeway. Basically i had it search for widthTime < 2900 and widthTime > 2000, as an example.

{{ File: 38khzsignalmonitor.spin
   This object uses a 38khz IR detector to monitor for carrier signals with data inside them.

}}
CON

  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000

  STOP_BIT  = 4800               ' Stopbit width in clock ticks
  START_BIT = 2400               ' Startbit width in clock ticks
  LOW_BIT   = 600                ' Lowbit width in clock ticks
  HIGH_BIT  = 1200               ' Highbit width in clock ticks
  REST_PER  = 600                ' Resting period in between pulses (pulled high so no signal transmission)

OBJ

  Debug : "FullDuplexSerial"

PUB MonitorSignal(DETECTORpin) | widthTime, index, data, tmp

  Debug.start(31, 30, 0, 57600)                         ' Setup the serial terminal for displaying the data.

  repeat                                                ' Repeat indefinately

    widthTime := 0                                      ' Set width time to 0
    repeat until ina[noparse][[/noparse]DETECTORpin]~                      ' Wait until input from detectorpin is low.

    repeat while ina[noparse][[/noparse]DETECTORpin]~                      ' Increment width time while the pin is held
      widthTime++                                       ' to a low value. (indicates signal comming through)

    if widthTime == START_BIT                           ' Check to see if the current signal is the start bit.
      index := 0
      repeat 5                                          ' Repeat 5 times
        widthTime := 0                                  ' Reset widthtime.
        repeat until ina[noparse][[/noparse]DETECTORpin]~                  ' Wait until detecotrpin goes low again
        repeat while ina[noparse][[/noparse]DETECTORpin]~                  ' Count up widthtime while detector pin is low
          widthTime++

        if widthTime == LOW_BIT                         ' If we got a low bit then set data[noparse][[/noparse]index] to 0
          data[noparse][[/noparse]index]~
        elseif widthTime == HIGH_BIT                    ' If we got a high bit then set data[noparse][[/noparse]index] to 1
          data[noparse][[/noparse]index]~~

        index++                                         ' Increment index.

      widthTime := 0
      repeat until ina[noparse][[/noparse]DETECTORpin]~
      repeat while ina[noparse][[/noparse]DETECTORpin]~
        widthTime++

      if widthTime == STOP_BIT
        'cmpData := data[noparse][[/noparse]0..4]
        repeat tmp from 0 to 4
          Debug.bin(data[noparse][[/noparse]tmp],5)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

======

······ I'll try everything once [noparse]:)[/noparse]

Post Edited (morris4019) : 5/26/2009 10:09:47 PM GMT

Phil Pilgrim (PhiPi) · 2009-05-26 23:18

morris4019,

I'm not sure about your timing. Your comments indicate timing in clock ticks, but the timing itself is done by incrementing in a loop without reference to the clock. Also, I'm a little concerned that if you do mean clock ticks, your data rate is much too fast for a 38KHz carrier. For example, a 600-tick low bit, is only 7.5us long at 80MHz. That's shorter than one period of your carrier.

Can you also show your transmit program?

-Phil

morris4019 · 2009-05-26 23:42

You are probably right. I got it running, but it does not even detect the start pulse, i think my numbering might be way off in comparison to how i am doing it. Here is the code i am running to generate the signal.

{{ File: 38khzsignalwithdata.spin
   This object will setup a cog to generate a 38khz signal and transmit data through an IR LED.
}}
CON

  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000

  STOP_BIT  = 4800               ' Stopbit width in clock ticks
  START_BIT = 2400               ' Startbit width in clock ticks
  LOW_BIT   = 600                ' Lowbit width in clock ticks
  HIGH_BIT  = 1200               ' Highbit width in clock ticks
  REST_PER  = 600                ' Resting period in between pulses (pulled high so no signal transmission)

VAR

  long cog
  long signalStack[noparse][[/noparse]50]
    
OBJ

  sqWv  : "SquareWave"

PUB Start(pin)

  Stop                            ' Stop any cogs that may be under control
  cog := cognew(SendData(pin), @signalStack[noparse][[/noparse]0])
  
PUB Stop

  if cog <> 0
    cogstop(cog)
    
PRI SendData(IREDpin) | us, rep, widthTime

  dira[noparse][[/noparse]IREDpin]~~

  us := clkfreq/1_000_000         ' Set a varible us to equal 1 micro second.

  repeat
    rep := 0
  
    outa[noparse][[/noparse]IREDpin]~~                ' Hold IRED pin high so that no signal is generated.
    sqWv.Freq(0, IREDpin, 38000)   ' Setup the square wave frequency to be generated. The square wave will output
                                 ' automatically when the output pin is pulled low.
    repeat rep from 1 to 7

      widthTime := lookup(rep : START_BIT*us, HIGH_BIT*us, LOW_BIT*us, HIGH_BIT*us, LOW_BIT*us, HIGH_BIT*us, STOP_BIT*us)
   
      outa[noparse][[/noparse]IREDpin]~               ' Start the square wave.
      waitcnt(widthTime + cnt)     ' Pause for respective duration.
      outa[noparse][[/noparse]IREDpin]~~              ' Pull high and rest
      waitcnt(REST_PER + cnt)      ' Wait for the REST_PER duration.

I hope i'm not completely wrong.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

======

······ I'll try everything once [noparse]:)[/noparse]

Phil Pilgrim (PhiPi) · 2009-05-27 01:36

Okay, so the times are in microseconds, not clock ticks. That might be okay, but it may still be cutting things short. The reason is that the IR detector does not respond immediately to a carrier, and your LOW_BIT is only 23 carrier cycles long. But let's assume for now that that's okay.

There are two main problems that I see with the receive program:

1. You're not measuring pulses in terms of absolute time, but in terms of cycles through a Spin loop. You need to involve cnt in these measurements to get the actual time.

2. You are checking for absolute equality in your comparisons between the measured times and the required times for each different kind of pulse. True equality will almost never hold. What you need to do is compare each against a range of values. If it's within the range, then it's that kind of pulse.

-Phil

morris4019 · 2009-05-27 02:49

I have made the modifications like you said, using a formula (cnt - t, where t is the cnt as soon as the pin goes low, and cnt is right after it goes high again), which seemed to even out the number a little bit. I have inserted a line to print on the serial terminal window the value held in widthTime, so that i can see what numbers are comming in for cnt. I think i may reading the inbetween bits instead of the data bits. Every single pulse that comes in is between 480 and 650. Below is the code that i re-wrote. Is there a chance that i am only reading the bits in between the data bits. All the pulses are the same round about number.

{{ File: 38khzsignalmonitor.spin
   This object uses a 38khz IR detector to monitor for carrier signals with data inside them.

}}
CON

  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000

  STOP_BIT  = 4800               ' Stopbit width in clock ticks
  START_BIT = 2400               ' Startbit width in clock ticks
  LOW_BIT   = 600                ' Lowbit width in clock ticks
  HIGH_BIT  = 1200               ' Highbit width in clock ticks
  REST_PER  = 600                ' Resting period in between pulses (pulled high so no signal transmission)

VAR

  long cog
  long monitorStack[noparse][[/noparse]100]

OBJ

  Debug : "FullDuplexSerialPlus"

PUB Start(MonitorPin)

  Stop                            ' Stop any cogs that may be under control
  cog := cognew(MonitorSignal(MonitorPin), @monitorStack[noparse][[/noparse]0])
  
PUB Stop

  if cog <> 0
    cogstop(cog)
  
PRI MonitorSignal(DETECTORpin) | widthTime, index, data, t,tmp, us

  us := clkfreq/1_000_000
  
  Debug.start(31, 30, 0, 230400)                         ' Setup the serial terminal for displaying the data.

  repeat                                                ' Repeat indefinately
  
                                              
    repeat until ina[noparse][[/noparse]DETECTORpin]~                      ' Wait until input from detectorpin is low.
    
    t := cnt                                            ' Set t variable to equal the cnt time when pin went low
    
    repeat while ina[noparse][[/noparse]DETECTORpin]~                      ' Incrementing cnt while the pin is held
                                                        ' to a low value. (indicates signal comming through)
    widthTime := cnt - t                               ' Calculate total cnt time that pin was low

    Debug.dec(widthTime/us)
    Debug.str(String(13))
    
    if ((widthTime/us) > (START_BIT - 1000)) & ((widthTime/us) < (START_BIT + 1000))
                                ' Check to see if the current signal is the start bit.

      index := 0
      repeat 5                                          ' Repeat 5 times
        
        repeat until ina[noparse][[/noparse]DETECTORpin]~                  ' Wait until detecotrpin goes low again
        t := cnt                                        ' Set variable t to equal the cnt time when detector went low.
        repeat while ina[noparse][[/noparse]DETECTORpin]~                  ' Count up widthtime while detector pin is low

        widthTime := cnt - t                            ' Calculate total cnt time that pin was low

                                                        'Check to see if we have a low bit, if it is set
                                                        'corresponding value to 0.
        if ((widthTime/us) > (LOW_BIT - 1000)) & ((widthTime/us) < (LOW_BIT + 1000))
          data[noparse][[/noparse]index]~

                                                        'Check to see if we have a high bit, if it is set
                                                        'corresponding value to 1
        elseif ((widthTime/us) > (HIGH_BIT - 1000)) & ((widthTime/us) < (HIGH_BIT + 1000))
          data[noparse][[/noparse]index]~~

        index++                                         ' Increment index.

      repeat until ina[noparse][[/noparse]DETECTORpin]~
      
      t := cnt                                          ' Set t variable to equal the cnt time when pin went low

      repeat while ina[noparse][[/noparse]DETECTORpin]~

      widthTime := cnt - t                              ' Calculate the total time that pin was low.

                                                        ' Make sure we got the stop bit before displaying the data.
      if ((widthTime/us) > (STOP_BIT - 1000)) & ((widthTime/us) < (STOP_BIT + 1000))
        
        repeat tmp from 0 to 4
          Debug.bin(data[noparse][[/noparse]tmp],5)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

======

······ I'll try everything once [noparse]:)[/noparse]

Phil Pilgrim (PhiPi) · 2009-05-27 02:56

You may well be reading the inter-pulse periods. Have you tried measuring pulses of the other polarity?

-Phil

morris4019 · 2009-05-27 02:59

Thats kind of what i was thinking of doing, by using "repeat until ina[noparse][[/noparse]DETECTORpin]~~" instead of "repeat until ina[noparse][[/noparse]DETECTORpin]~" right?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

======

······ I'll try everything once [noparse]:)[/noparse]

Phil Pilgrim (PhiPi) · 2009-05-27 03:35

The tildas (~) don't do anything, since INA is read-only. Just leave them off entirely. Then change your whiles to untils, and vice-versa.

-Phil

morris4019 · 2009-05-27 05:15

Perfecto! Thanks Everyone for helping me out. That was the trick, I had to check the oposite polarity. Works like a charm now...

Thanks again!
-Mike

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

======

······ I'll try everything once [noparse]:)[/noparse]

JonnyMac · 2009-05-27 20:05

Congrats on getting that working. As a follow-up to the suggestion I made yesterday I popped over to the electronics shop and picked up an IR LED. I put this into a Propeller Demo Board and pointed it at an IR receiver sitting on a PDB (it's output was going through a MAX232 to PST).

Good news: it works great up to 2400 baud. This is not fast by anyone's standard but probably faster than manually decoding in Spin and allows you to use simple_serial or fullduplexserial on the receiver side of your project.

[noparse][[/noparse]Edit] Since the IR baud rate is so low I added a version (not buffered, using code from simple_serial) that doesn't require another cog.

Post Edited (JonnyMac) : 5/28/2009 12:08:43 AM GMT

morris4019 · 2009-06-09 02:40

I have built a prototype on pre-drilled perf board from radio shack. Also, I have temporarily built a small enclosure that will be similar to the finished product. Below are the pictures.

The top houses 4 IR Emitters, later on the other 4 sides IR Detectors will be mounted so that it can send and recieve. 2 Buttons, 1 to cycle through the beacon ID it transmitss, and 1 to start and stop the transmission. Also, there is a toggle switch mounted on back to turn the whole system on and off. The pictures are with the top removed.

Thanks everyone for all of your help.

-Mike

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

======

······ I'll try everything once [noparse]:)[/noparse]

Post Edited (morris4019) : 6/9/2009 2:46:17 AM GMT

HollyMinkowski · 2009-06-09 04:13

I think IR LED remotes send a lot of power through their LED to get good range.
The LEDs seem to have a low duty cycle that keeps them from burning out from
going way over the rated drive current of the LEDs. (you can see the flashes in a camcorder viewfinder, they look pretty bright)

But if you keep the duty cycle low enough to massively overdrive your IR LEDs for
greater range you would need to keep the data rate low...but that would be OK if
you don't need to send data really fast. If the rate was low enough you could probably
put several amps through the LEDs and not destroy them. If your code burped and the
LEDs stayed on more than a fraction of a second though they would probably make
smoke

I'm not sure how long the pulse would have to be to get through to your IR
receiver because it probably needs a 38khz pulse long enough to make it through
a narrow filter centered on 38khz....I just don't know if this would effect detection of
very short pulses.

You could slowly modulate an LED by switching on/off a carrier at 38khz and sending
1 VERY short burst for 0 and two closely spaced bursts for 1. I just tried this with an
ultrabright white LED keyed by a pulse generator. The amount of light was astounding..like
a strobe light at a club. The LED did not seem to suffer damage. The calculated drive power was well over an amp.
duration of the pulse was approx 1ms....using an old board I made last year using an Atmega168
that drives a dc motor using pwm.... I just twiddled the code to give 1ms single and double pulses
and cranked up the drive voltage to the transistor.

Mike Green · 2009-06-09 04:36

It's always a good idea to check the LED's datasheet to see what the maximum current rating is. Switching on an LED for 1ms with 10A instantaneous current is not always the same as an average current of 0.010A. Except for high power LEDs designed for this, the wiring in ordinary LEDs is not that robust. You can see the bonding wire through the clear plastic. It's a pretty low current fuse. Even if the wire doesn't melt because the average heat produced is low enough, the atoms in the wire will begin to migrate under the instantaneous current flow and you can eventually get a failure from wire breakage. This is more of an issue with the chip metalization than with bonding wires, but it can happen eventually.

Using spin to send data on a 38kHz carrier

Comments