JP1 Remotes

[The Robman]

I just captured all the signals from a "streamzap" remote and funnily enough, when I ranthem through DecodeCCF they all showed up as "StreamZap". But the thing is, I've never heard of this protocol before and it doesn't appear in KM or RM.

If DecodeCCF recognizes it, someone has obviously decoded this before and probably written an executor for it, but I checked the "Misc" folder and it wasn't there. So, does anyone have any additional info and hopefully an executor I can use? If not, I can create one easily enough, but no point in duplicating work.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[jon_armstrong]

It's in the PVR folder. The Protocol is RC5 with an extra device bit.

EDIT: I just looked in the file and the PB file is there also.

BTW, I know you know this but it's in OBC and you need to multiply the true OBC decoded from from IR/DecodeIR by 4. It may save you a step.
_________________
-Jon

[jon_armstrong]

OK, I was going to clean this up and do my best to make the OBC's agree with the decodes. It look like KM Master is still broken with MSB comp values< 8-bits. MSB looks correct

Here is a brief analysis. The first column is true OBC, second is those values when Bits/Cmd=6 MSB and the third Bits/Cmd=6 MSB-Comp and the binary of those two columns of hex values:

000 00 3F 00000000 00111111
001 04 3E 00000100 00111110
002 08 3D 00001000 00111101
003 0C 3C 00001100 00111100
004 10 3B 00010000 00111011
005 14 3A 00010100 00111010
006 18 39 00011000 00111001
007 1C 38 00011100 00111000
008 20 37 00100000 00110111
009 24 36 00100100 00110110
_________________
-Jon

[johnsfine]

Why can't I convince you two to use (enhance) RM in these situations?

I haven't checked yet myself to see if anyone ever added Streamzap to protocols.ini. Assuming not, it should be real easy to do.

The syntax for protocols.ini is very flexible for number of bits and MSB vs. LSB, etc.

It's quite easy to take the output from PB, plus a basic understanding of how OBCs relate to hex commands, and create a protocols.ini entry (obviously you both have far beyond a basic understanding of how OBCs relate to hex commands across a spectrum of protocols).

[The Robman]

Thanks Jon, I found it and have moved it to the Misc folder where it should be: Streamzap.zip.

I checked out the upgrade and I can see an easier way to get that extra 1/2 bit in there. You can make it be the lead-in time. I've quickly thrown together a slightly updated version, take a look: Streamzap-rob.zip.

I didn't know about that bug in KM. To fix it, go to the p-work sheet and change the value in cell R3 from

=IF($I$3="n","R","L")

to

=IF($H$3="n","R","L")
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[johnsfine]

[Mark Pierson]

[The Robman]

[johnsfine]

I just committed a new protocols.ini file at Source Forge, which should be included in the next release of RemoteMaster.

In it, I corrected the Streamzap protocol. It now matches the decodes and does not match KM (version 8.32).

Does someone want to fix KM? Or is there a further tweak I should do in protocols.ini to make it able to correctly import from an incompatible KM upgrade? Or should I just document the minor incompatibility.

The fixed data for Streamzap includes a flag bit for OBC>63 (high bit of fixed data, On for OBC>63 and Off for OBC<64).

RM now has a checkbox for that feature on its setup sheet and correctly defaults that bit to Off (since OBC is almost always <64).

KM defaults to OBC>63 and you need to add 128 to the decoded device number in order to make it not default to OBC>63.

Note also the executor is NOT a mini combo. It supports only one set of 64 OBC numbers, not three sets as are supported in RC5 and other similar protocols. So if you have both OBC<64 and OBC>63 in the same device you'd need two upgrades. Since OBC>63 is so rare, I don't really think that needs fixing. But if people using Streamzap start asking for a mini combo version, that's an easy change to the protocol executor and I assume (by following the RC5 protocol.ini entry) it would be easy in protocols.ini.

A fixed data byte in Streamzap is like the fixed data byte in RC5 but shifted one bit to the left, pushing out the lead-in bit (which is then encoded as a lead-in burst rather than a bit) and making room for one extra device bit at the bottom. (So the OBC>63 bit is the top fixed data bit in Streamzap but second to top in RC5, even though they occupy the same position in the generated IR signal).

[Capn Trips]

See this thread:
http://www.hifi-remote.com/forums/viewtopic.php?t=5123

Apparently, these problems have not been fully resolved in either RM or KM. As I understand it:

In RM, the StreamZap protocol is treated correctly (i.e. default OBC<64, check box for OBC>63), but the StreamZap protocol has the wrong protocol ID. RM comes up with 0124, where it SHOULD be 0123. Can this be fixed in the next release of RM? (It seems to dopey me like a trivial fix.)

In KM, the problem seems to be a bit deeper. Although the StreamZap protocol generates the correct protocol ID, KM does not differentiate between the OBC>63/< 64 cases, and generates fixed data corresponding to OBC>63 only, which is (a) reportedly the less likely scenario, where most StreamZap upgrades use the lower OBCs, and (b) if one enters low OBCs, then the fixed data is simply incorrect. Can this be fixed in the next release of KM?
_________________
Beginners - Read this thread first
READ BEFORE POSTING or your post will be DELETED!


Remotes: OFA XSight Touch, AR XSight Touch
TVs: LG 65" Smart LED TV; Samsung QN850BF Series - 8K UHD Neo QLED LCD TV
RCVR: Onkyo TX-SR875; Integra DTR 40.3
DVD/VCR: Pioneer DV-400VK (multi-region DVD), Sony BDP-S350 (Blu-ray), Toshiba HD-A3 (HD-DVD), Panasonic AG-W1 (Multi-system VCR);
Laserdisc: Pioneer CLD-D704.
Amazon Firestick
tape deck: Pioneer CT 1380WR (double cassette deck)
(But I still have to get up for my beer)

[gfb107]

[Mark Pierson]

I'll fix KM and upload the new version as soon as I get home.
_________________
Mark

[The Robman]

I've just checked my files and the $0123 protocol isn't pre-installed in any of our S3C8 remotes, so I'm thinking that the best solution might just be to modify the exec so that it supports the full range of OBCs. It should be a fairly simply fix.

Any thoughts?
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[Mark Pierson]

[The Robman]

I have just updated KM (v8.41) so that it uses a new executor for Streamzap. This new exec supports the full range of OBCs from 0 thru 127.

Greg/John, here's how it works. I now treat the device code as 7 bits (down from 8), which causes it to shift to the left. I now treat the OBCs as 7 (up from 6) which causes them to shift to the right. I automatically add 64 to the OBC, which XORs the MSB. Then, in the exec, I do an "RLC" on the OBC followed by an "RRC" on the fixed byte, which basically takes the XOR'd MSB from the OBC byte and shifts it into the fixed byte.

I had to delete the Mits and Moto exec code as it would no longer work with this exec.

Here's the PB file...
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=3187

Here's the old code if someone wants to modify it...

Mits 740:
0C 18 11 80 0F E0 D0 04 20 08 06 02 06 02 06 51 A4 20 01 01 17 5A 06 A5 5D 49 40 85 5D 4C 00 FF

M6805-C9:
0C 19 11 20 0F E0 D0 04 20 08 06 02 05 02 05 6D 53 20 00 F3 01 57 06 AE 5A F6 A8 40 F7 CC 01 83

M6805-R16:
11 24 11 20 11 85 85 10 08 06 00 D2 D3 00 D2 D3 51 A4 00 00 D2 00 01 57 06 AE 5A F6 A8 40 F7 CC 01 AF
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!