Request for IR Receiver Protocol

Ringo setup, hardware, basic programming. User to user support.
jsbrown86
Posts: 2
Joined: Sun Feb 28, 2016 2:49 am

Request for IR Receiver Protocol

Postby jsbrown86 » Sun Feb 28, 2016 2:53 am

Hello,

I'm new to using the Ringo robot and I'm trying to send an IR signal from an Arduino board and receive it with the Ringo. Does anyone have any detailed information on the Ringo's IR receiving protocol?

Thanks in advance!

Kevin
Posts: 137
Joined: Tue Jul 28, 2015 12:56 am

Re: Request for IR Receiver Protocol

Postby Kevin » Sun Feb 28, 2016 3:30 am

Hello js,

The actual protocol is spelled out somewhat in the Ringo Guide toward the end. You can find that on the Getting Smart page on the website.

The Ringo robot is actually essentially an Arduino UNO minus the headers and having all the parts directly connected to the processor. You can probably load the Ringo Base Sketch directly onto an Arduino board and it should work fine. (If you're using an UNO or whatever other board, just be sure to select the correct board in the Boards menu inside Arduino so it uploads correctly).

On Ringo, the IR send pin is on Arduino Pin 10. You can probably wire an IR source to this pin on your Arduino board and it should send using the commands described in the Ringo guide book.

On the same note, if you wired a 38 KHz IR receiver to Arduino Pin 3, you should be able to also receive IR comms using the same software.

If you want to hack the code further, check out the IR send functions in the RingoHardware tab. You can probably copy these into another sketch of your own.

A final note, the standard Arduino boards run at 16 MHz, but Ringo runs at 8 MHz (this is because we run him at a lower voltage which isn't stable at 16 MHz). This could possibly cause your signal to send at twice the normal speed. I can't remember how the software knows what clock speed you're running, but I'm pretty sure this is calculated automatically when you select a given board from the Boards menu - so I thing this will be adjusted automatically in the compile process. So I don't think this will be a problem.

Let me know if you get something working. I've never done this myself but others have asked about it. If you got some sort of clean example running please share.

Thanks,
-Kevin

jsbrown86
Posts: 2
Joined: Sun Feb 28, 2016 2:49 am

Re: Request for IR Receiver Protocol

Postby jsbrown86 » Fri Mar 04, 2016 1:43 am

Thank you!
I also wanted to ask about the included remote control, in particular its carrier frequency and modulation/pauses when a button is pressed (apologies in advance, I'm kind of new at this sort of thing).

Kevin
Posts: 137
Joined: Tue Jul 28, 2015 12:56 am

Re: Request for IR Receiver Protocol

Postby Kevin » Sat Mar 05, 2016 1:42 am

js-

I've got some basics here...

38 KHz carrier frequency
9 ms (about) preamble at start of packet
Packet bytes are transmitted LSB first
Zero off time about 500 uS
One off time about 1600 uS

Basically the 1's and 0's are actually indicated by the time the carrier is off. The carrier is turned on for (I'm speaking from memory here) about 600 uS between each bit. So it's on for 600 uS, then it's off for either 500 or 1600 uS depending on a 1 or a 0, then it's back on for 600 uS again.

All remote controls do work a bit different. 38 kHz is the most common carrier frequency, but it seems almost every brand of TV and VCR ever made used slightly different coding for the actual protocol. If you're interested in trying to hack the code to work with other remote controls, or to make Wink randomly change your TV channel, a fellow named Ken Shirriff wrote a really nice library for controlling all kinds of things. It is rather large from what I remember but it does the trick. I haven't used it myself, but Dustin who wrote most of the Ringo code did play with it some.

Link:
https://github.com/z3t0/Arduino-IRremote

If you want a real challenge... you can code up the "heckler" bug. Dustin did this at one point with some success. Not sure if he ever published the code or not, but here's the general idea....

Let Wink observe IR communications for a while. If they match a certain length (they're not just random blips from flashes of light), he can then remember them. I think Dustin used a set of arrays that just marked raw timing - when the carrier came on and when it turned off. You can use the micros() function to get this timing with fairly tight resolution.

After a while, after enough sequences have been seen and memorized, the robot then somewhat randomly re-broadcasts the same sequences in random orders with his IR sender.

The idea is that after you visit a friend and show off the robot, you put it on the coffee table with the power still on and let him do his thing. After a bit of channel surfing the friend is confused that his TV begins to randomly show menus, change channels, change volume, etc. :lol:

In theory this should automatically work with any remote control because it doesn't need to know the protocol at all, because it's just measuring the raw timing between blips from the remote and re-creating the same sequences.

This level of coding is above my ability and free time, but I'd share it with the world and give props to the writer if it ever comes about. :D

Hope that helps!
-Kevin

duskykmh
Posts: 2
Joined: Mon Mar 07, 2016 12:31 am

Re: Request for IR Receiver Protocol

Postby duskykmh » Mon Mar 07, 2016 12:36 am

Hey Kevin! I'm working with Jacob on this project.

I was wondering if the Ringo is prone to having IR reception issues? The provided remote control doesn't seem to work often with the Ringo and we think that maybe the Ringo's IR receiving is what's making our project difficult.

Should we try to change the Ringo's IR library to match another more accepted IR protocol?

duskykmh
Posts: 2
Joined: Mon Mar 07, 2016 12:31 am

Re: Request for IR Receiver Protocol

Postby duskykmh » Sat Mar 12, 2016 4:18 am

Thanks to some amazing luck from Jacob, we discovered that the Ringo receives NEC protocol infrared transmissions! He was frustrated and spammed his tv remote control while working with an IR receiver and it chirped! :lol:

We were unable to decipher packets, but we were able to use if(IsIRDone()) as a way to signal action when it received an IR signal that WASNT from the remote control. Hopefully that is useful information to somebody.

Kevin
Posts: 137
Joined: Tue Jul 28, 2015 12:56 am

Re: Request for IR Receiver Protocol

Postby Kevin » Wed Mar 16, 2016 3:01 am

That's good to know that it's using the NEC protocol. I always assumed it was some random proprietary protocol. The way that all started was that we got some basic remotes off ebay that were designed to control LED lighting strands and just made the robot protocol work with it. Then we copied the carrier and packet information and sent it to the factory that made our remotes and they just duplicated the outgoing signal.

We were having some receive issues with Ringo, but this was largely corrected when we went to the Base Sketch Rev06. If you're still using code based on the Rev05 base sketch, try to copy it into the new one and that'll likely solve your problems. If you're still having trouble with Rev06 I'd appreciate any help debugging. I spent quite a bit of time chasing my tail over that problem. What I did was to wait until the very end of the IR handler to re-enable the interrupt on the IR pin. This shouldn't have made any difference in how it worked, but once I resorted to random guesses, I got lucky and this significantly improved things.

If you're into hacking code a bit, have a look at the IR Receive functions in the RingoHardware tab. That's where the magic happens. Basically a function is triggered via interrupt each time the IR receiver pin transitions. The handler then marks the time (I think it adds this to an array if I remember). Then when you call another function (I think it's IsIRDone or something like that), that function actually parses through the received timing stamps and turns it back into 1's and 0's.

I have done a lot of testing having a hair wire soldered to the output pin of the IR receiver and watching on a scope and I always get a nice clean signal with proper timing, but for some reason the handler will still occasionally miss it.

There may be something to be said for the fact that the IR receiver is kind of buried in the middle of the robot, which cuts down on its visibility but I still get clean looking signals on the scope if the sending source is anywhere nearby.

A final consideration is maybe the battery in the remote is low? I haven't heard of this before and all the remotes I've used seem to last forever but anything is possible. Maybe remove the battery and check it with a meter.

If you guys make any new discovery or progress on this I'd be happy to hear. I've got a feeling that handler could be improved a bit still. The timing on IR remotes is really slow compared to what the processor could handle, so I can't imagine why it would be hard to correctly clock in. If you can differentiate between a 500 us gap and a 1600 us gap, then reception should be 100% so I am quite puzzled and the IR handler appears to do exactly what I expect it to. I still wonder if maybe something is overflowing during the process somewhere. I'm a much better hardware designer than coder so I could certainly be overlooking something.

If you google around, you can find a page where a guy named Ken Shirriff wrote a really nice complete IR remote receiver library that reads (and possibly sends?) a lot of different protocols. Maybe try that library directly and see if you have any significant improvement in reliability. We don't use it in the base sketch because the library is quite large when it compiles, but it may have the key to making things run better.

Thanks!
-Kevin


Who is online

Users browsing this forum: No registered users and 1 guest