I thought I was making progress then Kye released his new improved SD driver. So I switched over to his newer driver (he changed a lot of method names and the way methods were called).
I also received a personal message from a forum member who also was working on a universal IR object. The code the forum member shared with me was so above and beyond what I was doing that I thought I'd just wait for him/her to share it on the forum. It doesn't save the codes to SD but it does such a good job compressing the code that a SD card isn't really needed.
I just switched over to a new computer. I just logged on to the forums for the very first time from this computer. So my information is kind of in flux right now.
I'll email the forum member to see if it's okay if I send you a copy of their code.
I'll also find the code I was working on and post it here in case it helps you.
I still want to adapt the new code to SD sometime. I just have too many "day job" projects I should be working on. Fortunately the day job projects are also Propeller projects so they are a lot of fun. Just not as much fun as hobby projects.
I just remembered one of the things I tried with the IR Magic code. I noticed the PASM code took up such little space inside the cog that I thought I would try to save the entire code within the cog and then write it to hub after the code had been captured. Seemed like a good idea, but the overhead needed to write to the cog takes about the same amount of time as just writing the information to hub as it is gathered. It was a good learning experience.
It might take a day before I'm organized enough to post the code. I'll also email the other forum member about sharing their code.
I have been playing with IR recently. IIRC I discovered an error in reading the data in that it was ignoring the first start bit - not sure now if this was a bug in my code or from the obex, so I am just posting here in case.
MagicIR is pretty janky - there are some basic things like a stop method missing, but the most egregious error is the size of IR codes - they could be compressed considerably. The playback routine should be redone in PASM, too, as a few devices have transitions that occur faster than it takes spin to setup a waitcnt. I know Beau had made some improvements including compression, although I'm not sure if he's done with it. I hope he shares it when he's done, though, because blind IR recording is pretty useful.
@Jason - decoding the protocol will give you the very best compression, the problem I ran into early on was compatibility. Some devices used RC5, some use SIRCS and some I couldn't figure out. My TV, Xbox, and stereo all were all non-sircs,non-rc5,non-NEC,non-rc6. You could probably write a record algorithm that could decode when recognized or store the delta when not, but I think compressing deltas will be easier and more flexible. And with decent compression, you'd still be able to store a few hundred codes.
I had some time to work on my project. I tried incorporating both the webserver api from Nick's MagicIr code into the Duane's EEPROM as well as Duane's EEPROM funcionality into Nick's Code and it would seem as there is just not enough room on the Prop. Maybe Nick you have tried this? Am I missing something is there a way to shorten the code to replace the terminal interface with one that can be sent over the network? I was using the api interface to script ir code transmission with the ability to retain codes during a power cycle.
Any advice that can be offered would be great! Maybe this is just too much to ask of the little prop.
Thanks again for everyones help!
Dylan
@Jason - decoding the protocol will give you the very best compression, the problem I ran into early on was compatibility. ...but I think compressing deltas will be easier and more flexible. And with decent compression, you'd still be able to store a few hundred codes.
I had similar issues, but some of the protocols are quite easy to figure out. I have a function written that will convert a Sony 12-bit code to the MagicIR format that works well. I'm in the process of writing a similar one for RC6a (my ReplayTV remote format). I bought a Harmony 700 recently and wanted to program a function that my current TV remote doesn't have a button for, so I looked up the Sony code, then got my "Propeller Remote" to play it so the Harmony could learn it. Worked like a charm.
For compression, Writing a routine to find a "time base multiplier" wasn't that hard - Most remotes use a fixed pulse length, then emit bursts that are something like "on for 1, off for 2" of those pulse lengths. Using deltas encoded as multiples of a base pulse length gets you values that could easily be encoded as nybbles or possibly bytes, with an escape for anything that didn't fit (like the off duration between repeats).
I also found that using the deltas + pulse length compression actually helps when figuring out the encoding, because you remove a lot of rounding error and clock slop in the conversion. I've written a routine that will determine if a MagicIR pulse set is a Sony12 code already, but I haven't done any others yet.
Comments
I thought I was making progress then Kye released his new improved SD driver. So I switched over to his newer driver (he changed a lot of method names and the way methods were called).
I also received a personal message from a forum member who also was working on a universal IR object. The code the forum member shared with me was so above and beyond what I was doing that I thought I'd just wait for him/her to share it on the forum. It doesn't save the codes to SD but it does such a good job compressing the code that a SD card isn't really needed.
I just switched over to a new computer. I just logged on to the forums for the very first time from this computer. So my information is kind of in flux right now.
I'll email the forum member to see if it's okay if I send you a copy of their code.
I'll also find the code I was working on and post it here in case it helps you.
I still want to adapt the new code to SD sometime. I just have too many "day job" projects I should be working on. Fortunately the day job projects are also Propeller projects so they are a lot of fun. Just not as much fun as hobby projects.
I just remembered one of the things I tried with the IR Magic code. I noticed the PASM code took up such little space inside the cog that I thought I would try to save the entire code within the cog and then write it to hub after the code had been captured. Seemed like a good idea, but the overhead needed to write to the cog takes about the same amount of time as just writing the information to hub as it is gathered. It was a good learning experience.
It might take a day before I'm organized enough to post the code. I'll also email the other forum member about sharing their code.
Duane
@Jason - decoding the protocol will give you the very best compression, the problem I ran into early on was compatibility. Some devices used RC5, some use SIRCS and some I couldn't figure out. My TV, Xbox, and stereo all were all non-sircs,non-rc5,non-NEC,non-rc6. You could probably write a record algorithm that could decode when recognized or store the delta when not, but I think compressing deltas will be easier and more flexible. And with decent compression, you'd still be able to store a few hundred codes.
Any advice that can be offered would be great! Maybe this is just too much to ask of the little prop.
Thanks again for everyones help!
Dylan
I had similar issues, but some of the protocols are quite easy to figure out. I have a function written that will convert a Sony 12-bit code to the MagicIR format that works well. I'm in the process of writing a similar one for RC6a (my ReplayTV remote format). I bought a Harmony 700 recently and wanted to program a function that my current TV remote doesn't have a button for, so I looked up the Sony code, then got my "Propeller Remote" to play it so the Harmony could learn it. Worked like a charm.
For compression, Writing a routine to find a "time base multiplier" wasn't that hard - Most remotes use a fixed pulse length, then emit bursts that are something like "on for 1, off for 2" of those pulse lengths. Using deltas encoded as multiples of a base pulse length gets you values that could easily be encoded as nybbles or possibly bytes, with an escape for anything that didn't fit (like the off duration between repeats).
I also found that using the deltas + pulse length compression actually helps when figuring out the encoding, because you remove a lot of rounding error and clock slop in the conversion. I've written a routine that will determine if a MagicIR pulse set is a Sony12 code already, but I haven't done any others yet.