Generating Nokia12

[Barf]

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

The debouncing is taking place in the receiver, not in the remote. I wrote that sentence just to add an understanding of why the up-event could be used. (Actually, mainly meant for myself )

The simplest alternative would be to junk repetitions altogether. The best, at least theoretically, would be to implement the up-event. Keeping it as it is is, after all, also acceptable.

[The Robman]

Here's the binary for the signal:

100000010101 - sent while held
100010010101 - release signal

So what we really have is a 7-bit OBC, rather than an 8-bit OBC, where the extra bit is a toggle that gets set on release.

[The Robman]

Vicky, I've modified your PB file here:
http://www.hifi-remote.com/forums/dload ... le_id=8130

I don't know how to do the AND in the HCS08 code, so you'll need to fix that statement.

[vickyg2003]

Rob, thanks for the clarification on what Bengt was telling me, I didn't understand that at all. I updated your PB file with the HCS08 change and debugged the s3c8 protocol too. Both have been tested and the KM file has been updated with the appropriate protocols.

Bengt here is the protocol string for the HCS08,
Upgrade protocol 0 = 01 FF (HCS08) Nokia Like IR Keyboard (PB v4.01)
20 17 24 4B 11 87 C4 80 04 04 08 00 52 00 8B 00
00 00 52 33 88 00 CF 00 8B 6E 12 B2 CD FF 5F 6E
09 56 CD FF 92 24 0B 45 13 88 CD FF 74 3B 56 F2
20 EA 1E 61 CC FF 5F
End

[The Robman]

Here's the updated file:
http://www.hifi-remote.com/forums/dload ... le_id=8135

Vicky,
I just noticed a typo in my S3C8 code, the JRC statement (after the $010A call) should jump back to "send" rather than "start". I think the code will work "as is", but we should change it just to be safe.

[vickyg2003]

I just noticed a typo in my S3C8 code, the JRC statement (after the $010A call) should jump back to "send" rather than "start". I think the code will work "as is", but we should change it just to be safe.

Yes a long Hold on that key would probably crash the remote. Its been changed in both places.

[Barf]

It works beautifuly. It is noted intuitively that the remote+receiver is much more robust against unintended double presses, than with the previous implementation.

Note that I have posted a fix to DecodeIR in another thread.

Next challenge would be to emulate things like Alt-F2 (pressing and holding down Alt, pressing F2 (short), releasing Alt).

[The Robman]

Next challenge would be to emulate things like Alt-F2 (pressing and holding down Alt, pressing F2 (short), releasing Alt).

We can certainly replicate the signal, but what we can't do is let you press multiple buttons simultaneously on the remote.

I would recommend that you learns the various ALT+ type combinations that you're looking for using your Widget and then post the ICT files to the Diagnosis Area (and post links to them here).

[vickyg2003]

It works beautifuly. It is noted intuitively that the remote+receiver is much more robust against unintended double presses, than with the previous implementation.

If you are still getting unintended repeating, we can remove repeating all together.

Note that I have posted a fix to DecodeIR in another thread.

But that's not going to help us is it? Of course you've probably tested this, and can see it, but I thought that this signal isn't really a Nokia12. Maybe I'm not reading this right, but this is what I read about Nokia12


Nokia12
IRP notation: {36k,msb}<164,-276|164,-445|164,-614|164,-783>(412,-276,D:4,F:8,164,-???)+
EFC translation: MSB

Doesn't that mean that the Device would be 4 timing pairs and the Function would be 8 timing pairs. In your Nokia Like signal, the Device has 2 timing pairs and the Function is 4 timing pairs.

(Not to be confused with the UEI implementation)

Or am I just showing that I still don't understand what is going on

[The Robman]

..but I thought that this signal isn't really a Nokia12. Maybe I'm not reading this right, but this is what I read about Nokia12

Nokia12
IRP notation: {36k,msb}<164,-276|164,-445|164,-614|164,-783>(412,-276,D:4,F:8,164,-???)+
EFC translation: MSB

Doesn't that mean that the Device would be 4 timing pairs and the Function would be 8 timing pairs. In your Nokia Like signal, the Device has 2 timing pairs and the Function is 4 timing pairs.

(Not to be confused with the UEI implementation)

Or am I just showing that I still don't understand what is going on

If that is the IRP for Nokia12, then it perfectly matches this signal, although it's missing the recently discovered toggle bit that gets set on release. You're seeing the signal as a 2-bit dev and 4-bit OBC because you're not looking at bits, you're looking at pairs. If you convert the signal to binary you will see the 4-8 format.

Keep in mind that...
0 = 00
1 = 01
2 = 10
3 = 11

Here are the numeric buttons:

Base4 - binary - button
200111 - 100000010101 - key_1
200112 - 100000010110 - key_2
200113 - 100000010111 - key_3
200120 - 100000011000 - key_4
200121 - 100000011001 - key_5
200122 - 100000011010 - key_6
200123 - 100000011011 - key_7
200130 - 100000011100 - key_8
200131 - 100000011101 - key_9
200132 - 100000011110 - key_0

[vickyg2003]

Oh pooh, I'm never ever going to understand this intellectually. This is why I can't do the decodes! My mind just doesn't bend this way!!!! Fortunately I can make the pictures look right.

[The Robman]

What are you not seeing? You know that there are 4 pairs and you're already able to process them with labels 0 thru 3. To think of them in binary terms, process them as 00 thru 11 instead.

Here's the codes for the "1" button.

Code: Select all

 2  0  0  1  1  1
10 00 00 01 01 01

Here's how I do it, step by step...

1) Here's the timing data that you posted for the "1" button...

+416 -278 +166 -610 +166 -278 +166 -278 +166 -444 +166 -444 +166 -444 +166 -112360

2) Next I edit all the pairs to their labels with a "^" suffixed so I can easily identify them later, if needed. So in this case, to get to the 200111 code, I would replace +166 -278 with 0^, +166 -444 with 1^, etc

+416 -278 2^0^0^1^1^1^+166 -112360

3) To get to the binary, I can now edit 0^ to 00^, 1^ to 01^, etc. I could also have gone direct to binary in step 2 replacing +166 -278 with 00^, etc

+416 -278 10^00^00^01^01^01^+166 -112360

4) Finally, edit out the ^

+416 -278 100000010101 +166 -112360

Now, of course, when I'm doing this, I'm working with a complete set of codes, not just one button. Does that help?

[vickyg2003]

I looked for through my remotes, and found that my 10820n has a couple of Nokia32 devices, so I took a look at that signal. Sure enough, this has half as many timing pairs as I expected it to have based on the IRP notation.

I'm reading your explanation and my head is swimming, I'll read this again tomorrow when I'm fresh and see if this makes any more sense to me.

[vickyg2003]

So Nokia12 and Nokia32 the numbers in the name reflect the number of BITS. In IRP, F:8 means the function is shown in 8 bits. The fact that the number of bits usually corresponds with the number of bumps, is because I've always been working with binary codes before. But the Nokia12 protocol is a quad protocol so each bump is represented by 2 bits. 00, 01, 02, 03. So the number of bits will be 2x the number of bumps.

The other non-binary protocol that is often discussed is the XMP (dreambox) which is a hex protocol. So obviously the bumps represent 4 bits 0000, 0001,0010,0011,0100,0101....1111. So if you were to put an xmp signal into colon(:) type IRP notation, F:8 would be 2 bumps.

This makes my head hurt!

[The Robman]

I finally see what the issue is, you're always looking at the visual image in IRScope whereas I'm looking at the actual data. With data, I can edit it to look like whatever I want, so I can easily convert the "4 bumps" into 8 bits but you don't have a way of editing your "4 bumps" into "8 bumps".