Unable to control RGB LED strip with RF transmitter

[Ric]

@codelicious

It looks like somehow the code doesn't allow broadcasting the correct signal. I can't detect the RF signatures when I use an arduino to listen.

Not sure what you mean by this. I think your code is properly doing what you're telling it to do. Whether you're telling it the right thing is the question. It doesn't seem reasonable that it should take nearly a minute to transmit a simple instruction, and that you need to transmit it 6 times.

[codelicious]

@Ric

Did you wait long enough to see that the onboard LED would turn off?

As you suggested, it took 5 minutes 57 seconds to turn off the on board LED light. The LED strip didn't respond during or after the transmission is over.

[codelicious]

After not seeing LED strip responding to voice commands, I was using an arduino hooked up to a RF receiver to listen for RF signals that should be transmitted from Photon after my voice commands. It looks like it registers something but it looks like background. It is not the signature RF code (a collection of long and short signals) that it should transmit to turn lights off or turn them red for instance. I hope that makes sense.

[ScruffR]

I’m too rather convinced the collection of short and long signals you saw is what your code is sending.
Maybe you should try delayMicroseconds() instead delay()

How exactly did you collect your timing data?

[codelicious]

In the tutorial I was following, after recording the signatures, there was a loop function that increases signal delays 10 seconds every transmission cycle. The code keeps sending off and on signals with increasing delay and in each cycle, on board LED fires. You basically count how many times it blinked and adjust the delays accordingly. In my case, both 13th and 14th cycles turned LED strip off and on. Hence 130-140 ms delay.

[ScruffR]

@codelicious

I used this receiver-transmitter kit to record and broadcast signals by using the tutorials that I posted in my first post.

@codelicious

In the tutorial I was following, after recording the signatures, there was a loop function that increases signal delays 10 seconds every transmission cycle.

Maybe you should look again at that code and see if I didn't have a point about the time scale
I wrote the above post before I looked at the code just from common sense, but after checking the code I'm absolutely certain that I was right.

[codelicious]

Sorry, it was my mistake in writing 10 seconds. The code I used increments at 10 microsecond steps. The code I’m talking about is here:

http://arduinobasics.blogspot.com.au/2014/07/433-mhz-rf-module-with-arduino-tutorial.html

I was able to use this sketch to turn the LED strip on and off. This is also where I copied the chunk of the code for photon project.

Time delay in the code looks OK to me, but I’ll try delayMicroseconds() version and will keep you posted.

[ScruffR]

If you look here (part 3 of your linked tutorial and origin of your code)
433 MHz RF module with Arduino Tutorial 3
(code line 115+)

       /* Transmit a HIGH signal - the duration of transmission will be determined 
            by the highLength and timeDelay variables */
         digitalWrite(rfTransmitPin, HIGH);     
         delayMicroseconds(highLength*timeDelay); 
         
         /* Transmit a LOW signal - the duration of transmission will be determined 
            by the lowLength and timeDelay variables */
         digitalWrite(rfTransmitPin,LOW);     
         delayMicroseconds(lowLength*timeDelay);  

I'd say your code does not look the same

The original code uses delayMicroseconds() while you use delay() (which is milliseconds - factor 1000)

---

If you just post a link without extra characters, it'll be clickable. With a leading blank it'll not get expanded.

[codelicious]

It worked!!! Thank you very much! Now I can automate everything home!

Couple questions for me to understand it better though, I’d appreciate if you can give me your insights or point me to the right direction to read up on this a little more.

1. It makes sense why you need to define color signal arrays as constants since they are not changing once defined. But if we omit const would it still work? What’s the theory behind defining it as constant

2. Why did you choose to use if(command.equalsIgnoreCase()) as opposed to command == "" notation?

3. Would the return value of -1 matter within controlRGB section? Can it be any other integer?

4. I don’t exactly understand why we wrote this section like this: transmitCode(const uint8_t* code, int len). I understand how it works but why the asterisk?

(related to 4 )5) In IR application which worked previously, arrays were defined as integers even though it is not really treated as numbers. What is the benefit of using characters vs integers in the context of this piece of code?

6. If I wanted to send repetitive commands with one time voice control (to simulate pressing dimming button 10 times in a row), how would I do that in this code?

You guys are the best, thank you for great insights!

[ScruffR]

@codelicious

It makes sense why you need to define color signal arrays as constants since they are not changing once defined. But if we omit const would it still work? What's the theory behind defining it as constant

If you declare variables const they will only live in the "unchangable" flash memory, but when you don't they will live once in flash and also get a space in RAM where they could be altered. So you'd use twice the memory and have some extra work on bootup to copy the values from flash to RAM.

@codelicious

Why did you choose to use if(command.equalsIgnoreCase()) as opposed to command == "" notation?

Because then you'd be free on the casing. You could write on or ON or On and oN and all of these would sattisfy the condition.

@codelicious

Would the return value of -1 matter within controlRGB section? Can it be any other integer?

It could be any, but it should be "meaningful" and since all your other returns could return "any" positive number -1 is a good one to distinguish from them.

@codelicious

I don't exactly understand why we wrote this section like this: transmitCode(const uint8_t* code, int len). I understand how it works but why the asterisk?

The asterisk makes the parameter a pointer to the place where the data lives. In this case it's a per reference parameter in contrast to a per value parameter.
For more background you can google these terms.

@codelicious

In IR application which worked previously, arrays were defined as integers even though it is not really treated as numbers. What is the benefit of using characters vs integers in the context of this piece of code?

Mainly space considerations. Integers take up four bytes while char or uint8_t use only one.
And you could treat your arrays as strings too (as long you have no embedded 0 in there.

@codelicious

If I wanted to send repetitive commands with one time voice control (to simulate pressing dimming button 10 times in a row), how would I do that in this code?

Use a loop like for() to call the function multiple times.