JP1 Remotes

I try to emulate an IR keyboard using an URC-7781 (JP1.2; HCS08). It turns out that the protocol involved is the Nokia12-Protocol, It appears as this cannot be generated by the current status of Remotemaster/IR. "Nokia Quad" and Nokia32 does not do. Am I right?

Problem still open...

I have looked at Protocolbuilder in order to implement Nokia12 as an additional protocol. However, PB in its elementary use, is for protocols mapping one bit to one burst pair; the Nokia12-protocol (just as the "Nokia Quad") maps two bits to one burst pair, of which there are four (see IRP-notation in first post), so it does not fit into the PB native framework directly.

I would be very grateful if someone can at least point me into the right direction. I have read all the documentation with PB, and they end here.

Barf,

Do you have working Learns of this protocol? The reason I ask, is it seems that XMP is often mis-reported as Nokia 12.

Generating these codes will require someone with assembly programming skills. It would help if you could provide some good learns.

Hi Vicky,

I do not have "learns", but I can generate perfectly clean and working signals, however not from a JP1-remote (yet!!). Here are all the signals, in Pronto representation, of all the keys on the IR keyboard (which is described on my website here, in case anyone is interested). It does not contain any information not contained in the irp-representation, but since you asked.

I moved this thread over to the Protocol Decodes area, because every one of the pronto hex codes that I tried to decode with IRTool and decodeIR from December 2009, are decoding as the same device and the same OBC, indicating that they are not really Nokia12s or that I have a problem with the tools.

I don't know how to decode these pronto codes into raw timings.

Someone who knows the ins and outs of proto decodes is going to have to give you a hand here.

Also, if your JP1.2 remote is a learning remote could you post an IR file with a couple of learns from the Pronto? I'd like to be of some help with this, but I am really visiually oriented. I like seeing the results on the scope. It helps me immensly to see how the thing looks.

Here are some of the timings that those "nokia12" codes have. The numbers 1,2,3,4,5,6,7,8,9,0, and the minus sign all decode as Nokia Device1,OBC8. The = & backspace decode as Device 2, OBC 8. Obviously these are not Nokia12's.
I'm cluelss as to how these are supposed to Decode.

This protocol has 4 burst pairs. The signal is MSB and the entire signal repeats.

Here's the data (in pronto hex)

freq: 0073
lead in: 000f 000a
leadout: 0006 0fd2
0 = 0006 000a
1 = 0006 0010
2 = 0006 0016
3 = 0006 001c

and here are the OBCs:

001 - key_esc
002 - key_f1
003 - key_f2
004 - key_f3
005 - key_f4
006 - key_f5
007 - key_f6
008 - key_f7
009 - key_f8
010 - key_f9
011 - key_f10
020 - key_grave
021 - key_1
022 - key_2
023 - key_3
024 - key_4
025 - key_5
026 - key_6
027 - key_7
028 - key_8
029 - key_9
030 - key_0
031 - key_minus
032 - key_equal
033 - key_backspace
034 - key_tab
035 - key_q
036 - key_w
037 - key_e
038 - key_r
039 - key_t
040 - key_y
041 - key_u
042 - key_i
043 - key_o
044 - key_p
045 - key_leftbrace
046 - key_rightbrace
047 - key_backslash
048 - key_capslock
049 - key_a
050 - key_s
051 - key_d
052 - key_f
053 - key_g
054 - key_h
055 - key_j
056 - key_k
057 - key_l
058 - key_semicolon
059 - key_apostrophe
060 - key_enter
061 - key_leftshift
062 - key_z
063 - key_x
064 - key_c
065 - key_v
066 - key_b
067 - key_n
068 - key_m
069 - key_comma
070 - key_dot
071 - key_slash
072 - key_rightshift
073 - key_fn_down
074 - key_leftctrl
075 - key_leftmeta
076 - key_leftalt
077 - key_space
078 - key_rightalt
080 - key_rightmeta
082 - key_sysrq
083 - key_scrolllock
084 - key_pause
085 - key_insert
088 - key_delete
095 - key_up
096 - key_102nd
097 - key_left
098 - key_down
099 - key_right
100 - key_numlock
126 - key_btnright
127 - key_btnleft
201 - key_fn_up

more later

Cool, I can see it!

+166,-278 is 0
+166,-444 is 1
+166,-610 is 2
+166,-776 is 3

so this would be

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

I can see how you got to 21 for the key_1
lead in pair +416 -278

+166 -610 +
+166 -278 = 0 * 64
+166 -278 = 1* 16
+166 -444 = 1* 4
+166 -444 = 1

+166 -112360 lead out.

Is this similar to the Nokia12 protocol, with just fewer bits?

I had to dig out my Pronto Decoder spreadsheet to get the timing data (that's why I didn't post it earlier) but your times appear to be correct.

Also, the frequency is 36kHz.

Thanks Rob. There will probably be more questions, but this gives me an exercise to see how Base4 encoding works. I've got some good Learns to test against, and I'm happy as a pig in slop.

Here's a tip, you'll notice that the difference between the 4 OFF times is 166, so you could use 278 as a base time and then use the two bits being processed as an index to determine how many times you'll send the 166 delay.

Here's a rough draft of how you could tackle this protocol:

pair 1: +416 -278 (leadin)
pair 2: +166 -112 (base pair)

: *** leadin pair ***
@loop1
send pair1

; *** fixed data ***
set W4 to 2
load fixed byte to W3
call @loop2

; *** variable data ***
set W4 to 4
load variable byte to W3
call @loop2

; *** leadout pair ***
send pair2
send 112148 microsecond delay

; *** repeat? ***
CALL $010A (is button still held?)
if yes, go back to @loop1
return

@loop2
send pair2
rotate W3 to left twice
load W3 to W2
mask W2 with 00000011b
increment W2

@loop3
send 166 microsecond delay
DJNZ W2,@loop3 (ie, decrement W2, and loop back to @loop3 if not zero)

DJNZ W4,@loop2 (ie, decrement W1, and loop back to @loop2 if not zero)
return



So...
Loop3 controls how much OFF time to add to the base pair.
Loop2 controls the four 2-bit pairs in the variable byte (or the two 2-bit pairs in the fixed byte)
Loop1 controls the main signal (for repeats)

Does that make sense?

Thanx Rob. Your last post is a substantial help. (I was beginning to despair, reading a some of the previous entries in this thread ) I expect to get some time to work on the problem soon.

Bengt

Does that make sense?

?

Yes I think so.

I took a different approach,

1 = 166-248
0 =0.-166

Changed the command bits to 2
and then manipulated the data buffer to have a 1 followed by the required by the number of zeroes specifed in each 2 bit pair.

I haven't seen any results yet, since I misplaced my JP1.2 cable. Hopefully I'll find it tomorrow and see how things look
[/quote]

In case you're curious to see what my approach would look like in PB, here's a PB file...
https://www.hifi-remote.com/forums/dload ... le_id=8130