Show Posts
Pages: [1]
1  Using Arduino / Project Guidance / Re: Using PWM for Radio Coomunication on: January 06, 2013, 05:47:30 am
Hi,
thanks for your responses. To your first question:

I wanted avoid using the main loop for timing sensitive code blocks. So my first ressort was use a customized PWM "algorithm". But this has proven to be overly complex.

To your second question:
There is a tone method, but it doesn't quite hit the spot for what I am doing. It has the same shortcomings as the shiftOut method. For neither solution can I naturally deal with that a 1 is a 25 ms HIGH and a 25 ms LOW pulse. I would have to model a logical 1 as a physical 10 and a logical 0 as a physical 00. This just seems to be wrong according to my gut-feeling. And yes I have a 434 MhZ transmitter attached to the arduino.

My current approach is, that I have setup a 555 timer, which is attached to an interrupt. I got this working this morning. This evening I will attempt to use the interrupt to clock the  HIGH, LOW pulses to the transmitter. If that works I might attempt to use the on-chip timer for this, but I am not really sure. Is it feasible?


Stefan
2  Using Arduino / Project Guidance / Using PWM for Radio Coomunication on: January 05, 2013, 12:33:28 pm
Hi,
hope this question has not been asked thousand times before. Here it comes:

I have used the salaea analyzer (excellent piece of engineering) to decipher the radio protocol of the radio controlled plugs used at home. I have found out that a 1 is transmitted as 0.25ms high and 0.25ms low and a 0 is transmitted as 0.5ms low. The prologue, command and device bytes have been found, so basically all I have to do is hack the code.

First I wanted to use the VirtualWire, but it seems to bring its own protocol, so this is  a no go. Do I really need to fiddle around with custom PWM registers to achieve radio communication? Is there some library I can use to help me on this?

Stefan
3  Forum 2005-2010 (read only) / Syntax & Programs / Re: Arrays Function Parameters Mess on: January 02, 2011, 12:42:02 pm
Hi Paul,
I thought about this, but I found this here: http://stackoverflow.com/questions/1106957/pass-array-by-reference-in-c claiming that any array function argument is passed by reference to the first element per definition in C. Is this link correct?

Nonetheless if I try your idea, I get this error:

error: declaration of 'buffer' as array of references

Any idea what I am doing wrong? Sorry for my C ignorance.

Stefan
4  Forum 2005-2010 (read only) / Syntax & Programs / Re: Arrays Function Parameters Mess on: January 02, 2011, 10:49:59 am
Hi Paul,
thanks again for your quick reply, I hope you are aware that you are forcing me in a defensive stance with your persistent questions about lost bytes - even though I am asking about a different problem. I am implementing a client for the LTBL protocol (http://blogger.xs4all.nl/loosen/articles/420470.aspx), which uses logical packages with a 2 byte header. As mentioned the readCommand function, checks this - here is the checkFor function which is used by the readCommand function:

boolean Ltbl::checkFor(byte bytes[], int arraySize){
  if(Serial.available() >= arraySize){
    byte firstByte = Serial.read();
    if(firstByte == bytes[0]){
      for(int i = 1; i < arraySize; i++){
        if(Serial.peek() == bytes){
          Serial.read();
        }
        else {
          return false; //peeked value did not match
        }
      }
      return true; //read all values correctly
    }
    else {
      return false; // first value did not match
    }
  }
  else {
    return false;//not enough values to read
  }
}


This function ensures that one byte is always popped from the buffer, as soon as the header is out of sync, it tries again with the next byte, otherwise it checks for the entire header and returns true if applicable for further handling. This ensures that I pick up at the next package / command once a byte is lost during transmission - currently I am happing that I will have a bad package read sometimes, as long as it continues to work afterwards.

I will gladly open a new thread in which you can enlighten me with additional insights on serial data handling.

But I would like to shine the light of expertise at the problem given to me currently. The blink function returns different values for the same buffer entry, depending if the function is invoked in the "reading" function or from the "calling" function. In both cases the data has already been read from Serial so timing can be excluded as a potential cause.


Regards

Stefan
5  Forum 2005-2010 (read only) / Syntax & Programs / Re: Arrays Function Parameters Mess on: January 02, 2011, 10:20:29 am
Hi Paul,
thanks for your quick response. Sure I am fully aware of the Serial "contract".  The read command does contain some logic for finding the proper byte sequences - and sure my loop and handleLightUpdate need some error handling for dropped or delayed bytes. Yet I am a pragmatic programmer and I am still working on my tracer bullet use case before I harden everything.

I refrained from using Serial.println() statements as I didn't want to have duplex serial handling - as mentioned in the previous post I use my little blink function:

void Ltbl::blink(int count){
  for(int i=0; i<count;i++){
    digitalWrite(13, HIGH);
    delay(100);
    digitalWrite(13, LOW);
    delay(100);
  }
  delay(200);
}


If I have blink(buffer[0]) in the last line of the pollPort function, the led blinks 3 times - as I expect from the serial input. If I add the statement blink(channels) in the handleLightUpdate function after the line int channels = buffer
  • [/font] the led blinks dozens/hundreds of times.

    I strongly assume this has something to do how arrays are passed between functions.
6  Forum 2005-2010 (read only) / Syntax & Programs / Arrays Function Parameters Mess on: January 02, 2011, 09:15:40 am
Hi gals & guys,
I have something like this:


void Ltbl::loop(){
  switch(_state){
[...]
  case Opened:
    byte commandChannel = readCommand();
[...]
    else {
      handleLightUpdate(commandChannel);
    }
    break;
  }
}

void Ltbl::handleLightUpdate(byte commandChannel){
  int buffer[7];
  pollPort(7, buffer);
  int channels = buffer[0];
  blink(channels);
  int red   = word(buffer[1], buffer[2]);
  int green = word(buffer[3], buffer[4]);
  int blue  = word(buffer[5], buffer[6]);
  light(red,green,blue);
}

void Ltbl::pollPort(int bytes, int buffer[]){
  while(Serial.available() < bytes){
    delay(10);
  }
  for(int i=0; i < bytes; i++){
    buffer = Serial.read();
  }
}


If I use a simple debug routine (blink - blinks the onboard LED the specified number of times) inside the pollPort Function I receive the correct number. Yet the int Array inside the handleLightUpdate contains gibberish - not the same values as in PollPort function. I tried passing & references and * pointers but without any success. What am I doing wrong?  :'(



Pages: [1]