Show Posts
Pages: 1 2 3 [4] 5 6
46  Forum 2005-2010 (read only) / Interfacing / Re: Manchester encoding algorithm and library on: February 14, 2008, 05:54:08 pm
Oops, sorry I kind of left you all hanging after posting partial code. I had both waitOnlvl and waitOnTime in my code and cut out the wrong one, the one which is used. Anyway, waitOnlvl is similar to pulseIn so next time I'm working on this I'll try to switch to that.

As someone noted before it takes some time for the levels to level off, so transmitting one byte then going off and doing something for some time, will not work. My transmitting arduino is only checking a few digital inputs as well as one analog input so I have it looping, doing these things and alternately transmitting the byte. The reading of the pins doesn't take that long so it is as if the data is being sent repeatedly in quick succession. If your code needs to do things which take awhile, then simply call the sending function in a for loop to send it out repeatedly a bunch of times - I don't remember what the datasheet calls for but it may be something like 15ms, which is the length of about 15 byts (?)

Here's the code. The waitOnTime can be omitted from the previous code posted.
Code:
int waitOnlvl(byte vLvl) {
  byte wlvl = digitalRead(12);
  byte wlvl2 = wlvl;
  int lvlcnt;
  while (wlvl2 != vLvl) {
    lvlcnt = 0;
    while (wlvl2 == wlvl) {
      wlvl2 = digitalRead(12);
      lvlcnt++;
    }
    wlvl = wlvl2;
    delayMicroseconds(40);
  }
  return(lvlcnt);
}
47  Forum 2005-2010 (read only) / Interfacing / Re: Manchester encoding algorithm and library on: January 21, 2008, 10:32:42 pm
Alright, now I've got the code working good without the temp vars. Thank you anaidioschrono, moving the tilde fixed everything but that still doesn't explain the erratic/unusual workings of the previous code.

Here it is, fixed:
Code:
   if ((preamble == 150) && ((curdata >> 16) == (~curdata & 0xFFFF))) {
      return(curdata >> 16);
    }

Here is the whole receive function in working order. Also, a number has changed to make this compatible with 1200bps modules. It will auto-adjust to any baud rate.

Code:
// Receiver code for OOK / ASK / FSK RF links using custom encoding
// copyleft 2008 by Derek Yerger
// thanks to anaidioschrono of arduino forums http://arduino.cc
byte waitOnTime(byte vCyc) {
  byte wlvl = digitalRead(7);
  int lvlcnt = 0;
  while (lvlcnt < vCyc) {
    wlvl = digitalRead(7);
    lvlcnt++;
  }
  return(wlvl);
}

unsigned int recvInt(void) {
  // check for level change
  unsigned long starttime = millis();
  int tmocyc = 0;
  byte reftm = amlvl + 40;
  byte reftm2 = reftm + (reftm / 2);
  //read potential bits
  unsigned long curdata = 0;
  unsigned int preamble = 0;
  byte lvlq = 0;
  byte cbit = 0;
  waitOnlvl(0);
  waitOnlvl(1);
  while ((preamble != 150) && (tmocyc < 5000)) {
    preamble = (preamble << 1) + (curdata >> 31);
    curdata = curdata << 1;
    cbit = waitOnlvl(0);
    if ((cbit < reftm) && (cbit > amlvl)) {
      reftm = cbit;
      reftm2 = reftm + (reftm / 2);
    }
    if (cbit > reftm2) curdata++;
    waitOnlvl(1);
    tmocyc++;
    if ((tmocyc % 128) == 127) {
      if (millis() - starttime > 1000) tmocyc = 5000;
    }
  }
  if (tmocyc == 5000) {
    return(0);
  }
  else {
    if ((preamble == 150) && ((curdata >> 16) == (~curdata & 0xFFFF))) {
      return(curdata >> 16);
    }
  }
}

Hope that helps smiley
48  Forum 2005-2010 (read only) / Interfacing / Re: Manchester encoding algorithm and library on: January 21, 2008, 09:22:28 pm
Yes, this sure has me confused! You are right, that shouldn't ever evaluate as true.

I moved the expressions to their own temp variables and had the function return where the proper data should be (curdata >> 16), and also made the proper revisions to where it figures the NOT value, as such:

Code:
   unsigned long tmp1;
    unsigned long tmp2;
    tmp1 = curdata >> 16;
    tmp2 = ~curdata & 0xFFFF;
    if ((preamble == 150) && (tmp1 == tmp2)) {
      return(tmp1);
    }

And it works as expected. Well, it was working before, but now it works AND makes some sense. Maybe I'm not understanding the way those expressions are evaluated and compared in the if statement.

I might post this in one of the software forums, perhaps someone there could shed some light on why the if statement evaluated before. Perhaps when it evaluates (curdata >> 16) it is placing the result back in curdata, but even if that is the case, it should still not evaluate.
49  Forum 2005-2010 (read only) / Interfacing / Re: Manchester encoding algorithm and library on: January 20, 2008, 09:14:12 pm
OK, now I'm really confused.

Although this code is working 100% all good, I've found something that just does Not Make Sense. Check it out:

On the sending end the data goes out in this order:
Code:
 xmitByte(curInt >> 8);
  xmitByte(curInt & 0xFF);
  xmitByte(~curInt >> 8);
  xmitByte(~curInt & 0xFF);

So, first the proper data is sent, then its inverse goes out last.

On the receiving end, data is shifted in one bit at a time into curdata, so the last bit in is LSB and the least significant two bytes should be the current int's inverse, right? Well here's the code which is working:
Code:
if ((preamble == 150) && ((curdata >> 16) == ~(curdata & 0xFFFF))) {
    digitalWrite(ledPin, LOW);
    return(curdata & 0xFFFF);
  }

So the function returns curdata & 0xFFFF which technically should be the current data inverse. But everything works this way, and the number my function returns correlates with what the transmitter is sending. And it isn't that all of the bits are flipped, because the preamble is still properly recognized.

But when I change the return to what it "should" be (curdata >> 16) then the code stops working and only returns one of two numbers (00 00 or 8D A7). This makes no sense, am I just missing something blatantly obvious here?

Of course, I'm happy to have my RF links up and running as they should be, but I still am curious about why the code behaves like this. Can anyone point me in the right direction?
50  Forum 2005-2010 (read only) / Interfacing / Re: Manchester encoding algorithm and library on: January 18, 2008, 01:21:41 pm
That is correct.
51  Forum 2005-2010 (read only) / Interfacing / Re: Manchester encoding algorithm and library on: January 15, 2008, 04:40:02 pm
Finally! I've figured out what's going on here.

First off, from http://forum.sparkfun.com/viewtopic.php?t=246
Quote
The HT12E encoder chip used in Laipac's datasheet uses a different type of encoding. For Zeros it outputs "001" and for Ones it outputs "011". With this encoding (after you are syncronized), your receiver will measure how long the signal is high to determine what bit was sent.

This would explain why the "high" not as long as "low" when transmitting a square wave.

So, some modifications were made to the transmitter code to only use the time "high" for meaningful data. This means the data rate will be variable depending on how many 1s.

Code:
int dlyms = 208;
void xmitByte(byte vData) {
  byte bitv = 128;
  for (int bitc = 0; bitc < 8; bitc++) {
    if (vData & bitv) {
      digitalWrite(xmitpin, HIGH);
      delayMicroseconds(dlyms*2);
      digitalWrite(xmitpin, LOW);
      delayMicroseconds(dlyms);
    }
    else {
      digitalWrite(xmitpin, HIGH);
      delayMicroseconds(dlyms);
      digitalWrite(xmitpin, LOW);
      delayMicroseconds(dlyms);
    }
    bitv = bitv >> 1;
  }
}

So a zero is high 208us low 208us, and a one is high 416us low 208us.

Example usage with corresponding preamble:
Code:
 for (int xbr = 0; xbr < 3; xbr++) xmitByte(0);
  xmitByte(150);
  xmitByte(curInt >> 8);
  xmitByte(curInt & 0xFF);
  xmitByte(~curInt >> 8);
  xmitByte(~curInt & 0xFF);
  xmitByte(0);

The preamble is: 0x00 0x00 0x00 0x96. The 96 in binary is 01101001. As you can see the transmission includes the MSByte & LSByte of the data followed by its inverse. This will be used for error checking later.

On the receiving end:
Code:
// copyleft 2008 by Derek Yerger
byte amlvl = 15; // minimum timeout the routine will use in "clock recovery"
int waitOnlvl(byte vLvl) {
  byte wlvl = digitalRead(7);
  byte wlvl2 = wlvl;
  int lvlcnt;
  while (wlvl2 != vLvl) {
    lvlcnt = 0;
    while (wlvl2 == wlvl) {
      wlvl2 = digitalRead(7);
      lvlcnt++;
    }
    wlvl = wlvl2;
    delayMicroseconds(dbg[1]*2);
  }
  return(lvlcnt);
}

unsigned int recvInt(void) {
  // check for level change
  unsigned long starttime = millis();
  int tmocyc = 0;
  digitalWrite(ledPin, HIGH);
  byte reftm = amlvl + 20;
  byte reftm2 = reftm + (reftm / 2);
  //read potential bits
  unsigned long curdata = 0;
  unsigned int preamble = 0;
  byte lvlq = 0;
  byte cbit = 0;
  byte abc = 0;
  waitOnlvl(0);
  waitOnlvl(1);
  while ((preamble != 150) && (tmocyc < 5000)) {
    preamble = (preamble << 1) + (curdata >> 31);
    curdata = curdata << 1;
    cbit = waitOnlvl(0);
    if ((cbit < reftm) && (cbit > amlvl)) {
      reftm = cbit;
      reftm2 = reftm + (reftm / 2);
    }
    if (cbit > reftm2) curdata++;
    waitOnlvl(1);
    tmocyc++;
    if ((tmocyc % 128) == 127) {
      if (millis() - starttime > 1000) tmocyc = 5000;
    }
  }
  if ((preamble == 150) && ((curdata >> 16) == ~(curdata & 0xFFFF))) {
    digitalWrite(ledPin, LOW);
    return(curdata & 0xFFFF);
  }
}

Here the routine shifts data in, shifting the MSB of curdata into preamble. When preamble is 150 the loop exits. This means two bytes (0x00, 0x96) need to shift into preamble before the loop exits, or until 1000 ms has elapsed. The tmocyc var is to avoid calling millis() too often.

Once the loop exits, the preamble is checked, and the data in curdata compared for the integer and its inverse. If this matches up the function returns the number.

I've tested this with a counter and it is working great. The proper data comes out, and no erroneous data is returned either. I hope this helps all of you in the same situation I was a week ago. Please keep this thread updated with any libraries that come of this. Also, I'm sure there are minor improvements which could be made to make the code smaller.
52  Forum 2005-2010 (read only) / Interfacing / Re: Manchester encoding algorithm and library on: January 15, 2008, 12:16:38 pm
Update:

Yes, I've had a preamble for locking onto, it is simply 4 bytes of 0's, then the char 150. Also, if the current data buffer >> 16 == 65535 then all the bits are inverted and the processing continues.

The issue with timnings has to do with the bit slicer, which according to http://www.rfm.com/corp/appdata/AN43.pdf

Comparison of the simulation results shows that for a low level signal, the data out of the
comparator, for the 1's, is approximately 30% narrower than the data in. In the case of a
high level signal, the data out of the comparator, for the 1's, is approximately 25% wider
than the data in. This is important to understand if maintaining the data width or pulse
width is critical. When maintaining data width or pulse width is important to the
performance of the receiver system, it will be necessary to either lower the data rate or
increase the low pass filter bandwidth.

So, I'll be working out a workaround for this.

With bitcnt < 47, that number is an arbritrary number paired with the send code and is used to differentiate a long pause or slow pause between transitions. In the latest code I posted, this number is calculated by (shortpause + (shortpause / 2)) where shortpause is the shortest interval it has been between a level change. Obviously this isn't working due to the inconsistencies of the bit slicer output.
53  Forum 2005-2010 (read only) / Interfacing / Re: Manchester encoding algorithm and library on: January 15, 2008, 01:12:07 am
anaidioschrono, that is great! I can't seem to get this stuff working because my receiver is having inconsistencies.

I think it is great that you would like to clean it up and put it into a library. I'm usually off to the next project when something like this is worked out, but I'd like to see something like this in a library and it's great to see this made available to those in need of these things.

I ended up changing the receive code twice but have run into an issue. When receiving a stream of 0's the receive data line does not match the transmit. If the transmit is going on/off for ~208 microseconds, the output of the receiver follows the same frequency but at a different duty cycle, being "low" about twice as long as it is "high".

I also changed the receive code to shift bits into an unsigned int, so the "preamble" can be detected in curdata >> 16 and the "packet" in curdata & 0xFFFF. Additionally, some code to detect the "clock" was added. What this is doing is similar to before in detecting how long it takes to go from low to high or high to low. The threshhold time between a long pause (current bit != last) and a short pause (current bit == last) is figured out by the shortest pause, + 1/2 that value.

I'll have to switch back to this old code to see what the difference is between the ways of interpreting, however the newer code may be better for adapting to different baud rates, plus it may be smaller code for doing all the shifting in one loop. Try it out-

Code:
// Copyleft 2008 by Derek Yerger

int dbg[2] = { 180, 90 } // timings which can be changed during runtime
  int waitOnlvl(byte vLvl) {  // wait for pin 7 to become vLvl, then wait dbg[1]*2 microseconds
  byte wlvl = digitalRead(7);
  byte wlvl2 = wlvl;
  int lvlcnt;
  while (wlvl2 != vLvl) {
    lvlcnt = 0;
    while (wlvl2 == wlvl) {
      wlvl2 = digitalRead(7);
      lvlcnt++;
    }
    wlvl = wlvl2;
    delayMicroseconds(dbg[1]*2);
  }
  return(lvlcnt);
}

unsigned int recvInt(void) {
  // check for level change
  unsigned long starttime = millis();
  int tmocyc = 0;
  byte reftm = amlvl + 20;
  byte reftm2 = reftm + (reftm / 2);
  //read potential bits
  unsigned long curdata = 0;
  byte lastbit = 1;
  byte lastbit2 = 0;
  byte lastlvl = 1;
  byte lvlq = 0;
  byte cbit = 0;
  waitOnlvl(0);
  waitOnlvl(1);
  while (((curdata >> 16) != 150) && (tmocyc < 5000)) {
    curdata = curdata << 1;
    lvlq++;
    while (lvlq > 0) {
      lastlvl = 1 - lastlvl;
      cbit = waitOnlvl(lastlvl);
      if ((cbit < reftm) && (cbit > amlvl)) {
        reftm = cbit;
        reftm2 = reftm + (reftm / 2);
      }
      lvlq--;
    }
    if (cbit > dbg[0]) {
      lastbit2 = lastbit;
      lastbit = 1 - lastbit;
      curdata = curdata + lastbit;
    }
    else {
      curdata = curdata + lastbit;
      if (lastbit2 != lastbit) lvlq++;
      lastbit2 = lastbit;
    }
    if ((curdata >> 16) == 65535) {
      curdata == ~curdata;
      lastbit = 1 - lastbit;
      reftm = cbit;
      reftm2 = reftm + (reftm / 2);
      lvlq++;
    }
    tmocyc++;
    if ((tmocyc % 128) == 127) {
      if (millis() - starttime > 1000) tmocyc = 5000;
    }
  }
  if ((curdata >> 16) == 150) {
    return((unsigned int) (curdata & 0xFFFF));
  }
}

I think the main issue will be with how the receive data looks:


And like I said the above (new) code is not working right but it may have to do with the receive data. It may be a good idea for the final library to be more like the above code, though, for reasons stated above, plus having more user data (an unsigned int instead of a byte). Also, some sort of error checking would not be a bad idea. Once I figure out what's the deal with this erroneous(?) duty cycle I'll see what I can come up with for software.
54  Forum 2005-2010 (read only) / Interfacing / Re: Manchester encoding algorithm and library on: January 11, 2008, 11:04:13 am
After toying with my small project integrating these RF links, I have found it to be unstable at moderate distances. To improve the reliability I have rewritten the code in order to have it recover the clock. I'm working on cleaning this up and testing it, and once I'm finished I'll post updated code.
55  Forum 2005-2010 (read only) / Interfacing / Re: Manchester encoding algorithm and library on: January 08, 2008, 09:38:05 pm
OK, I have completed a small function which works for my purposes. It works as follows:

The sending arduino now uses a subroutine to send a byte. It looks like this:
Code:
void xmitByte(byte vData) {
  byte bitv = 128;
  for (int bitc = 0; bitc < 8; bitc++) {
    if (vData & bitv) {
      digitalWrite(7, HIGH);
      delayMicroseconds(208);
      digitalWrite(7, LOW);
      delayMicroseconds(208);
    }
    else {
      digitalWrite(7, LOW);
      delayMicroseconds(208);
      digitalWrite(7, HIGH);
      delayMicroseconds(208);
    }
    bitv = bitv >> 1;
  }
  digitalWrite(7, LOW);
}

Note that these timings are hard-coded and go at roughly 2400bps.

For making it easier on the receiving end I chose to begin a transmission with the bytes with ASCII values 0, 0, then 150. This was chosen since it is fairly recognizable and will help the receiving end differentiate between data and static.

I have tested this sending four bytes at a time, repeatedly in bursts: 0 0 150 [any byte] 0

It comes in on the other arduino seemingly reliably. The receiving arduino uses another subroutine which is periodically called by the loop(), and will spend a maximum of 500 milliseconds waiting for legible data to come in. It waits until two of those three bytes (an integer of 150) are seen, then reads the next byte and returns it to the calling function.

Code:
byte recvByte() {
  // check for bit change
  unsigned long starttime = millis();
  byte bitin = digitalRead(12);
  byte bitin2 = bitin;
  while (bitin2 == bitin) {
    bitin2 = digitalRead(12);
  }
  bitin = bitin2;
  delayMicroseconds(120);
  //read potential bits
  unsigned int curdata;
  byte lastbit = 0;
  long bitcnt = 0;
  byte bittmo = 0;
  while ((curdata != 150) && (millis() - starttime < 500)) {
    while (bitin2 == bitin) {
      bitin2 = digitalRead(12);
      bitcnt++;
    }
    bitin = bitin2;
    delayMicroseconds(120);
    curdata = curdata << 1;
    if (bitcnt < 47) {
      if (lastbit > 0) curdata++;
      while (bitin2 == bitin) {
        bitin2 = digitalRead(12);
      }
      bitin = bitin2;
      delayMicroseconds(120);
    }
    else {
      lastbit = 1 - lastbit;
      curdata = curdata + lastbit;
    }
    bitcnt = 0;
    bittmo++;
    if (bittmo > 32) {
      bittmo = 0;
      lastbit = 1 - lastbit;
    }
  }
  if (curdata == 150) {
    byte curbyte;
    byte bitnum = 0;
    while (bitnum < 8) {
      while (bitin2 == bitin) {
        bitin2 = digitalRead(12);
        bitcnt++;
      }
      bitin = bitin2;
      delayMicroseconds(120);
      curbyte = curbyte << 1;
      if (bitcnt < 47) {
        if (lastbit > 0) curbyte++;
        while (bitin2 == bitin) {
          bitin2 = digitalRead(12);
        }
        bitin = bitin2;
        delayMicroseconds(120);
      }
      else {
        lastbit = 1 - lastbit;
        curbyte = curbyte + lastbit;
      }
      bitnum++;
      bitcnt = 0;
    }
    return(curbyte);
  }
}

void setup() {
  pinMode(13, OUTPUT);
  pinMode(12, INPUT);
  pinMode(11, OUTPUT);
  digitalWrite(13, HIGH);
  Serial.begin(115200);
}

void loop() {
  //  delay(100);
  byte tmp = recvByte();
  if (tmp > 0) {
    Serial.println(tmp, DEC);
  }
  Serial.println(analogRead(0), DEC);
}

Please forgive me for the messy code, it is nothing elegant and probably uses a less common approach to making sense of the bits. To sum it up, the routine looks for the state of the input pin, and checks how long it has taken to change. A longer gap and the current bit is opposite the last, and a shorter delay means the current bit is same as last. Here also the timing is hard-coded, and there are areas of code which could be optimized but I was having trouble doing this (getting erratic results).

In conclusion, this has been my quick hack so I can use these wireless TX/RX in a small project of mine. The code could certainly be cleaned up and possibly put into a library but I certainly don't have time. Hopefully this code will help someone else in the process  smiley
56  Forum 2005-2010 (read only) / Interfacing / Re: Manchester encoding algorithm and library on: January 08, 2008, 02:32:25 pm
Hello all,
I've finally got around to trying to use these and would like to have a standalone arduino capable of transmitting data over these RF links.

Currently, for my purposes I only need to be able to send a recognizable "on" or "off" signal to indicate the status of a remote sensor. This will still require some sort of "encoding" so the receiving end can discriminate between static and the intended signal.

So far I have hooked up my 2400bps transmitter to an arduino, and am having the arduino repeatedly send a byte using manchester encoding.

The receiver is just hooked to an oscilloscope sat this time as I wanted to ensure timings were right, etc.

Things seem to be working in order, although I've found erratic results if the transmitter's data pin is not set to "low" after sending the bits.

I do not have any experience with interrupts and for simplicity's sake would rather have the receiving arduino check the airwaves periodically for a transmission. This may not be good for sending actual data, and it will use up a decent chunk of processor time in order to be reliable, but for my purposes will be fine.

I'll post my progress in this thread as things develop.


So far, the test code snips look like (some non-relevant code snipped and ellipsized):
Code:
byte xmit;
byte xmitdly = 208;
...
void setup()
{
  pinMode(7, OUTPUT);
...

void loop()
{
...
  digitalWrite(7, LOW);
  delayMicroseconds(xmitdly);
  byte bitv = 128;
  for (int bitc = 0; bitc < 8; bitc++) {
    if (xmit & bitv) {
      digitalWrite(7, HIGH);
      delayMicroseconds(xmitdly);
      digitalWrite(7, LOW);
      delayMicroseconds(xmitdly);
    } else {
      digitalWrite(7, LOW);
      delayMicroseconds(xmitdly);
      digitalWrite(7, HIGH);
      delayMicroseconds(xmitdly);
    }
    bitv = bitv >> 1;
  }
  digitalWrite(7, LOW);

The variables xmit and xmitdly may be set by the computer by code that is out of the context of this discussion, but essentially xmit holds the byte value to transmit.
57  Forum 2005-2010 (read only) / Interfacing / Re: Wireless temp & humidity.  Is it feasable on: May 13, 2008, 10:38:01 am
It is doable.

I would recommend using some cheap RF links like those sold at sparkfun. They can be had cheaper even on ebay.

They may require encoding. I wrote a small library for this, here's a page about it.

I have also made a wireless t/h sensor with bluetooth, here's a writeup about it.

I recommend sensirion sensors for this task. Here's an old writeup about those on arduino.

If you are looking for minimal power consumption, you could use some kind of sleep mode on the MCU. A more efficient way of doing this would be to have the arduino store the readings in local memory. When the memory is full, the data could be sent to home base. The RF transmitter can be switched on/off using a switching transistor so it is powered only when data needs to be sent.

To store more data on the arduino between uploads to home base, I would use a modified version of elias gamma code. This encoding saves space by storing the difference between the last&current readings.

An extra two bits could be used to represent:
00 - no change
01 - absolute reading - followed by 16-bit integer indicating absolute reference. Used to begin encoding and also when change in reading is more than 15.

10 - positive change
11 - negative change

the last two are needed since gamma code only stores positive integers.

Using this encoding scheme on temperature readings, I have attained 300% compression. Where a day's worth of readings at one per minute, with integer resolution, would consume 2,880 bytes, encoded it may be as small as 1k. So, using this encoding up to a day of readings could be stored on an ATMEGA MCU's limited RAM.

The cost for the transmitter might be-
$6 - atmega8, RBBB
$25 - SHT71 temp/humidity sensor
$10 - TX/RX pair
total ~$41

Receiver- atmega w/ rbbb, $6, using receive module from above. Plus any additional hardware to interface to an LCD display or a PC.

Hope that helps get you started in the right direction. At least, I can say with certainty that you could do at least 3 wireless sensors with a receiver, for $100.

Also note, ne of the battery-operated sensors could run up to 6 months on 4 AA lithium batteries, if you integrate the power saving features I mentioned above.
58  Forum 2005-2010 (read only) / Interfacing / Re: RF data and PWM on: April 06, 2008, 01:41:12 pm
I used pin 11 for PWM. The only line added to the RFRecvEx sketch was analogWrite(11, 123); at the end of setup(). HTH
59  Forum 2005-2010 (read only) / Interfacing / Re: RF data and PWM on: April 05, 2008, 03:22:06 pm
Hi,
I tried adding an analogWrite to the setup() routine of my sketches using RFRecv. I was unable to reproduce the problem. Are you sure it is the analogRead causing the problem? Have you tried removing the line and testing it again?
60  Forum 2005-2010 (read only) / Interfacing / Re: RF data and PWM on: April 04, 2008, 05:49:13 pm
Did you use the latest code in that thread (the library)?

Regardless, in the receive code I wrote, the function monitors for 5 seconds for valid data, so the analogWrite in your code shouldn't occur while attempting to receive.

I'll have to take a look at how analogWrite works and how it could possibly interfere with timing. That may be where the problem is. If I get time I'll put an analogWrite in my sketch that utilizes the receive code, and see if I can't reproduce the problem.
Pages: 1 2 3 [4] 5 6