JP1 Remotes

[johnsfine]

Taking a random stab (in my many CCF files) at protocols that decodeIR doesn't do yet, I noticed this one:

<1,-5|1,-11>(1,-17, D:5, F:6, 1-17,1,-7000)+

I noticed it in four of my CCF files with a timescale of 16.7 microseconds:
Lenco Satellite Decoder D2MAC
Oritron Satellite Decoder D2Mac
Barco Graphics 800/1208 Projector
Barco 801 graphics

I also noticed it in one CCF file with a timescale of 26.8 microseconds (but the same ratios). There it seems to be for a Revox Tuner B260, but some more typical signals (42Khz NEC1:172) also seem to be for the Revox Tuner and I'm not sure which are right.

I may find more of them after I tweak decodeIR to recognize it.

Have you seen it before?

Anyone know what company's protocol this is or what decodeIR ought to name it?

[johnsfine]

Continuing my research, I see Jon participated in Barco threads and protocol 002A is being used, and I see protocol 002A is pretty close to the protocol I thought I found. I think 002A is

<1,-5|1,-15>(1,-25, D:5, F:6, 1-25,1,-12000)+
with a timescale of 10 microseconds.

I'll need to recheck things, since that seems far enough off to be a problem if one was used for the other but close enough to confuse the decoder if both are floating around. Of course I rarely know how picky the actual IR receivers are. nor how innacurate the timing details in CCF, so these might be exactly the same even if I didn't compute one of them wrong.

[jon_armstrong]

John, I vaguely remeber this and I don't have very good notes. The best I can do is a protocol definition derived from a decoded a pronto ccf file from Guy Kuo (who I think generated it ) and it was:

{19,0k}<1,-4|1,-10>(1 -15,D:5,F:6,1 -15,1 -129m)+

The last Off (now in mS) may have been specified in multiples of time base in my earlier descriptions and it would have been too short by our convention. I think we use the convention that it is in multiples of units of TB unless the multiple>TB

So I think the final gap may be much longer than either of your two definitions unless those are in terms of time base for the first or you skipped a zero in the second one.

Otherwise, I agree with your comments.
_________________
-Jon

[johnsfine]

Thanks. I am testing the new decoder now.

I called the protocol "pid_002A" because I hate making up protocol names and less than half the samples I think I've found are Barco (and I don't remember if there is anything else named "Barco"). But maybe I should rename it "Barco" anyway.

I'm still bothered by the timing difference between these and the actual pid_002A, but I assum pid_002A worked for those who I assume used it based on the threads in the old forum.

As for that "convention". I always hated that in the old IRP format. IIRC, that was Barry's idea and I was overruled. I thought I was clear that it wasn't in my new IRP notation. Bare timing numbers are in units, not in microseconds, regardless of size. I hope you weren't a strong advocate of that convention (I should remember, but don't), because I value your ideas.

My lead out times above aren't accurately calculated. They were a quick rough estimate. I'm sure the 129m is a better value. But I don't think my numbers are off by 10x.

BTW, neither the size of the unit nor the size of the on time are very relevent in this sort of protocol. What matters most is the relative size of the three full bursts
1+5 / 1+11 / 1+17 from my rough version are 1 to 2 to 3.
1+4 / 1+10 / 1+15 are quite near 1 to 2 to 3.
1+5 / 1+15 / 1+25 from actual pid_002A is quite far from 1 to 2 to 3.

Also the total length of that middle one is fairly relavant
(1+11)*16.7 = 200.4
(1+10)*19 = 209
(1+15)*10 = 160

The Barco samples I have seem to have that 192 to 207 and the non Barco (with the same apparent time scale) 188 to 196, so I'm not as worried by that 160 as by those ratios.

[johnsfine]

But I think the oritron version of this has an extra twist:

( 1,-17, D:5, F:6, 1,-17, 1,-120m ( 1,-17, (D^30):5, F:6, 1,-17, 1, -120m)+)

I'm not sure, but I think that is what pid 002A is doing when the hex command is odd.

[jon_armstrong]

John,

First on the "convention" of time base versus actual, I agree with you that it should be all in units of time base OR in units of time.

I also agree about the On time particularly in these no-carrier signals and the more important focus on total interval. In fact, I have had the experience that they need significantly longer On periods than what is measured or they are not reliable, presumably due of the response times of both receivers and transmitters.

A question, when you said "I'm not sure, but I think that is what pid 002A is doing when the hex command is odd", did you mean one of the "unused" bits in fixed or variable data is odd OR if D or F is odd?
_________________
-Jon

[johnsfine]

By "hex command" I always mean the variable data. In 002A the top six bits of the hex command are the six bits of F in the usual sequence. The bottom bit is a flag for special behavior, that I still haven't retested, but I expect it matches what I now understand about the Oritron use of this protocol.

I hope we agree about representing time in IRP notation, but to be clear, I don't think it should all be in time or all be in units. I think each value should indicate what it is (an 'm' after the number for milliseconds. I think I spec'ed that 'u' after a number would mean microseconds, which would be perfectly understood by engineers, but I can imagine ordinary people might be put off by having no suffix mean "Units" while a "u" suffix means "Microseconds").

BTW, I've also noticed that really short on times work better if you build the protocol to transmit a longer pulse than the learning logic reports.

[jon_armstrong]