JP1 Remotes

Thanks Rob, I'll look at that after I beat up on the JP1.2 version for a while. This is a great learning exercise for me.

Just so we can tell if we're on the same page or not, i've compiled a spreadsheet that lists all the keys, along with their pronto hex, the base4 code, the real binary, the OBC, the binary using Vicky's method and the hex required for Vicky's method.

http://www.hifi-remote.com/forums/dload ... le_id=8131

As always Rob knows best. The results I've been getting from my trial are bizzare and if there is a pattern, to what is being emitted, I can't find it. I'm abandoning my attempt at buffer manipulation, (for now) and I am moving to an approach similar to Rob's suggestion.

You're idea was a good one, so I don't know that you should give up on it. It boils down to a trade off between using memory for the protocol or for the device upgrade.

Maybe my idea was a good one, but the IR engine doesn't like it. There is something extremely odd going on with the JP1.2 signals when the "on time" of zero is set to zero. I'm not seeing what I expect at all.

I've now got the signal appearing once, before it resets the remote, but I can't figure out how or why its working at all. I've got to figure out why the remote is resetting, but I'm really pretty close and have absolutely no idea how I got there.

bengt, Here is an upgrade to try. I've viewed a few of the numbers and it looks good.

nokiaKeyboard

What brand of IR keyboard is this for?

Rob, I've moved on to the sc38+. That's going to take a bit of work as first try locked up the remote with no signal emitted. Apparently the IREngine on the JP1.2 remote handles these things natively, which is why my first approach didn't work.

It has built in support for 4-burst signals? I'll have to look at your code to see how you did it.

The Robman wrote:It has built in support for 4-burst signals? I'll have to look at your code to see how you did it.

Yeah, apparently I was bumping up against it with my initial buffer stuffing approach. That's why the output wast comming out so weird. So no need to send individual pairs on JP1.2 remotes, you just do some intitial setup of registers, and then jump to the engine. Its using the repeats register for something else, so you need to do the check for the key being pressed, but you don't need to send the individual pairs. Its a lot simpler than the sc380 approach. Maybe the newer JP1.3 remotes have this support too, but with the sc380 processor you have to work with remotes that might not have that built in.

I'm hoping to work on the the samsung processors this afternoon. Its so relaxing working on these signals.

Rob, Vicky, I am impressed by your recent progress. I loaded Vicky's protocol implementation in an urc-7781 (jp1.2, hcs08) and -- everything seemed to work except for the repetition rate, which was much too high. Looking at the signal with the IRWidget showed approximately 90ms of "silence" between the signals, my Pronto codes said 0fd2, corresponding to approximately 112 ms (as Rob wrote in his PB file). I just analysed the original HW, and it turned out that 162ms turns out to be the delay it uses.

What brand of IR keyboard is this for?

It is a keyboard for an early satellite/cable digital TV receiver, by the German Pay TV provider Sky, the called "Premiere". That receiver, "dBox2", has been the basis of a very sucessful open source project, (in German, with some English content) to which I have contributed the during some years. Regarding the keyboard, I wrote an article on advanced software support, linked in my second post. Presently, the keyboard is available at German eBay for a very low price.

Bengt

You've got a Widget! Cool! Could you capture the "Number 1" to the IRScope, and post the resulting ICT file? Then I can fine tune the timings against the original device, instead of against learns of learns.

I've increased the time between repeats and have zipped it with the PB file. Support for the s3c8+ and the JP1.2 is included.

Nokia Keyboard

Vicky, the file you posted consists of two PB-files, so it should probably not reside in the device upgrade section... I tried the protocol string, and it fixes the delay that I talked about in my last post. So at least in some sense, this settles the original question; thank you very much!

However, there is another issue: also with the 160ms delay, it is very hard to just enter one keypress (instead of several), thus getting, e.g., 222 instead of 2. There is some "key-released-event" detection using the original keyboard, that fails with our signals. I may have a closer look into this, and chances are that I will even post some ict-files

In the meantime, I think it would be a good idea to get rid of the repetition altogether. Thinking about it, repetition makes sense only with the cursor keys up and down.

Barf wrote:Vicky, the file you posted consists of two PB-files, so it should probably not reside in the device upgrade section... I tried the protocol string, and it fixes the delay that I talked about in my last post. So at least in some sense, this settles the original question; thank you very much!

Oops, slip of the fingers.

However, there is another issue: also with the 160ms delay, it is very hard to just enter one keypress (instead of several), thus getting, e.g., 222 instead of 2. There is some "key-released-event" detection using the original keyboard, that fails with our signals. I may have a closer look into this, and chances are that I will even post some ict-files

In the meantime, I think it would be a good idea to get rid of the repetition altogether. Thinking about it, repetition makes sense only with the cursor keys up and down.

Show me an ICT file, and I'll see what I can do. I believe Rob had said that keyboards often have a release event.

I looked into the signals a bit further, and it turns out that an up-signal is generated when releasing a button on the original keyboard. When this happens, the standard distance beween signals, 161ms, may not be observed. The signal is the same as the original one, but with 128 added to the OBC. (Note that all the OBCs in my file was <= 127). There is some debouncing logic in the receiver, so that two normal signals followed by one up-signal is translated to one normal and one up-signal, making it easier to enter e.g. a one-digit number.

Here is one sample ict-file, recorded from the original component: The file consists of two normal signals and one up-signal. First the Pronto representation, then the UEI representation. Note that DecodeIR gives an incorrect answer.

I will take a look at this, but the ICT file would have saved me the steps of having to decode this. (A picture is worth a thousand words!)

There is some debouncing logic in the receiver, so that two normal signals followed by one up-signal is translated to one normal and one up-signal, making it easier to enter e.g. a one-digit number.

So I assume you want to keep the repeating, but add the debounce when its let up.

I'll look at this tonight.