How to make upgrade from lirc conf file for iMON-PAD remote

[johnsfine]

I don't recall why I ignored this last month. Unfortunately I can't do much better now.

At a quick glance I don't see an easy pattern to those learned signals.

But I also don't see what would be a problem for LIRC. It's fairly normal frequency and timing. LIRC shouldn't need to recognise the structure.

For your stated goal of supporting the power signal, what is wrong with using a learned signal (I haven't looked back for context in your earlier posts, so what is wrong may be obvious).

[pjigar]

Thanks johnsfine!!

Well I can use the learned signal but I am using extender!! So extender will not allow me to learn signal. Is there any way to create "learned key" section in the extender? If not then I have to create a one button (power) upgrade and use a key move to use that functions.

So that's why I need someone to help me generate that one power button using "some" protocol that my extender will understand.

Thanks,
pjigar

[pjigar]

One note of reminder: This iMon-PAD remote has two categories of buttons:
1. Mouse pad buttons
2. Rest of the buttons

Mouse pads buttons are very hard to decode, apprently they have so many positions in that one pad, so you end up with ten's of different signals from pad.

Also to refresh the history: Traditional IR receivers hands off demodulated IR data stream to software/firmware for further decoding (of protocol). The iMon receiver does things differently, it demodulates as well as decodes the signal and hands off kind of "command" to software/firmware. So LIRC works just fine since it only looks at the commands not the demodulated data stream. And hence, the LIRC config file has no timing information (or other protocol information) in it. If it would have that information then it will be very easy to understand the protocol.

[The Robman]

Just FYI, I have spent most of the morning looking at these signals, and I gotta let you, it's a monster! Your last comment leads me to believe that the LIRC config file may contain what we call OBCs, which would be an enormous help in trying to decode this data.

So, could you post the config file in the Diagnosis Area and post a link to it here please.

[The Robman]

Here's some of the scoop on this puppy. If you try to group the timings into pairs, there are just too many for it to be practical, so you have to look at the timings by themselves.

There are 7 different timings (used for ON and OFF):

0440
1265
2090
2915
3740
4565
5390

and you'll notice that these are all 825 apart.

The positive (ie, ON) times convert to zeroes and the negative (ie, off) times convert to ones. Here's how you convert the learned signals into binary...

zeroes
+0440 =1
+1265 =2
+2090 =3
+2915 =4
+3740 =5
+4565 =6
+5390 =7
etc

ones
-1265 =1
-2090 =2
-2915 =3
-3740 =4
-4565 =5
-5390 =6
etc

[pjigar]

Thanks, Robman for looking at the IR file. I also realized that the protocol is really messed up when I looked at learned signal in IR.exe. I tried to look at several buttons' learned signal and tried to find "repeating pattern" but no luck. The only pattern I could pin-point was that a pattern that repeates twice. This repeating pattern is, again, different for each button. That's why I said, if there is an easy way to generate just one power button by creating some kind of mini-JP1 upgrade.

I have dig up the lirc.conf file for this remote. It is uploaed here:
http://hifi-remote.com/forums/dload.php ... le_id=2218

But this file, unlike other lirc.conf file you decoded, does not have mark-space timing.

[The Robman]

Apart from the last set of learned codes from the jog dial or whatever that is, where the repeat signals do sometimes change, it's easy to see where the repeat pattern starts in all the other signals, just look for the really long off time. However, normal signals use just 2 burst pairs, one for ONE and one for ZERO. On occassion we'll see a protocol that uses 4, and there are even a couple of them than use 16 pairs, but this one has more than that. Which is what leads me to believe that they are not pairs at all. The first trick is finding a way to write an exec to replicate all of the bursts and the next one is to try and find the pattern so you don't have to use 5 or 6 bytes of variable data.

[pjigar]

The reason I keep repeating that I need upgrade ONLY for a power button is two fold:

1. The power button is interpreted in two "modes/states".
a. When HTPC if off: It is decoded by a hardware IR module(Which is always powered) that can decode this IR signal and interpret it so that HTPC will be turned ON. This process happens without any (traditional) OS running on HTPC.
b. When HTPC is on: The power button is decoded and passed on to traditional OS like windows or Linux. In this case IR module just acts as a pass-thru agent.

2. Once traditional OS is up and running and if you are using LIRC/WinLIRC, you are not limited to using just iMon-PAD remote. Instead one can use ANY other remotes supported by LIRC. And all of these remotes has known protocols and JP1 upgrades available.

So in essence, if we can have a power button JP1 upgrade for this remote then there is no need to create upgrade for ALL iMon-PAD buttons. If someone wants to keep using thier iMon-PAD (Very unlikely for advanced HTPC user) then LIRC already supports iMon-PAD remote in it's own way. Now you get the point why I JUST need a power button JP1 upgrade. And in this case, searcing for patterns and all that is not that important; we can sacrifice few raw bytes to generate the signal we need.

I am not too familiar with firmware language and OS/memory-map organization. So I need expert's help in order to create a power button JP1 upgrade.

Thank you,
pjigar

[The Robman]

Just FYI, I have written a protocol upgrade that will just send the POWER function, but I haven't had a chance to test it yet. This is so that pjigar can use it to power on his PC, then after that he'll use some other code to work everything by changing the config file.

I doubt that anyone here is going to sort out this protocol so that it supports all of the functions because it's a mess. I've forwarded the info to UEI just in case one of their protocol writers wants to take it on, as at least they're getting paid to do this.

[pjigar]

Thanks Robman for creating the upgrade. Please post the upgrade when you get a chance. I can try it out.

hansdegit, please read my latest post on http://www.hifi-remote.com/forums/viewtopic.php?p=34838.
Posted: Mon Sep 26, 2005 12:56 pm

What I am saying in this post is: "power" button IR signal is THE only signal that we must absolutely generate since it is interpreted by the hardware. Now once you have that generated by JP1 remote, you have two choices:

1. Use LIRC in Linux which supports iMon receiver fully. And then upgrade your JP1 remote with any one of several remotes supported by LIRC.
2. If you want to stick with Windows (Like I do) then you have to use Girder and WinLIRC. Now unfortunately, WinLIRC is not maintained actively so the iMon IR receiver is not supported by WinLIRC. It only supports home-brew serial port IR receiver. I ended up building one of these receiver (as well as transmitter). So in other words, when PC is off I use iMon IR receiver to turn it on. Once PC is on, I use serial IR receiver using WinLIRC and Girder.


Hope this helps to setup your HTPC.

[pjigar]

Oh, forgot to mention. If you decide to go with option# 2 then WinLIRC will need configuration file for your remote. For us, JP1 people, it could be any remote for which JP1 upgrade is available. WinLIRC has built-in "Learn" feature that can create configuration file for your "remote" but it is very picky and unreliable. I was not able to create config file using WinLIRC successfully. So ended up installing Linux on one of the parition. Linux version of learn tool (Called irrecord) is very good at decoding signals. So if you ever need any LIRC config file then let me know, I can help. All I will need is the JP1 upgrade for the remote you are interested in.

[The Robman]

Thanks Robman for creating the upgrade. Please post the upgrade when you get a chance. I can try it out.

I will, but these things never work right the first time, so there's no point in posting it now only to have you confirm that it doesn't work. I need to load it in one remote and learn it to another and then check what the resulting signal looks like. I'll then figure out what's wrong with the signal and correct it. Once it looks like the one that I'm trying to replicate, I'll post it.

hansdegit, please read my latest post on http://www.hifi-remote.com/forums/viewtopic.php?p=34838.
Posted: Mon Sep 26, 2005 12:56 pm[/url]

Just FYI, there's a little icon to the left of the word "posted" (that looks like a small piece of paper). This icon is a direct link to the post, so when you want someone to look at a specific post, you can use it to get a direct link, like this...

http://www.hifi-remote.com/forums/viewt ... 4850#34850

[hansdegit]

Pjigar,

I use MediaPortal, which I can control using a Hauppauge remote. If I can find a way to conceil the IR "eye" of the receiver into my Silverstone case, then I'm very happy.

Too bad that those guys from Soundgraph didn't use an industry standard protocol.

Thanks for your hints and tips, by the way.

[pjigar]

You can!! If you open the case and look behind the VFD face plate, there is space on both side of VFD. I put my IR eye (home made) on the right side of VFD (Case facing forward) i.e. near CD-ROM bay. If you use flashlight and look, their IR eye is also on that side. If you don't have enough space then you can "push" their IR eye down a little bit with small srew driver or some thing. I have placed my IR eye above original IR eye and taped it from inside to keep it in place. I am also going to put IR blaster diode on the other side of VFD. By the way my IR blaster (home made) is very high powered so I hope it will work "after bouncing from the walls".

[hansdegit]

Pjigar,

Brilliant!

Again, brilliant!

That's the first thing I'll do after breakfast. On saturday, that is...
Thank you very much.