PID $0123: StreamZap protocol

[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.

[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_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

[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")

[johnsfine]

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.

That's a nice improvement.

I don't see Streramzap documented in IRP notation anywhere. From the first PB file I assume it is

{38K,844,msb}<1,-1|-1,1>(C:2,T:1,D:6,F:6,-99)+

Since the first C bit is always a 1, the signals starts with a half bit of off, which is pretty much invisible, so you removed that to get

{38K,844,msb}<1,-1|-1,1>(1,C:1,T:1,D:6,F:6,-99)+

If you wanted to be picky about it (and assumed the original was exact) you would add the 844 uS gap removed from the beginning back on the end (increase the lead out by 844) so the frame rate would be the same. (But we assume the frame rate wasn't exact to 1% in the first place).

BTW, is it really 38k and 844 as those PB files indicate? I'm sure those are close enough to work, but we must have some reference for more correct values among all the discussions of StreamZap at RC.

[Mark Pierson]

I didn't know about that bug in KM.

Neither did I...

It's been fixed for the next release.

[The Robman]

If you wanted to be picky about it (and assumed the original was exact) you would add the 844 uS gap removed from the beginning back on the end (increase the lead out by 844) so the frame rate would be the same. (But we assume the frame rate wasn't exact to 1% in the first place).

BTW, is it really 38k and 844 as those PB files indicate? I'm sure those are close enough to work, but we must have some reference for more correct values among all the discussions of StreamZap at RC.

I didn't re-learn the signals from the original remote using a JP1 remote to confirm the timings, as I just assumed Jon's times to be correct. When I learned the signals from my protocol using my Pronto they matched up exactly with the originals, including the leadout time, so I think Jon got them right.

Here's a sample of the '1' button learned from the original remote...
0000 006c 0000 000c 0020 0020 0040 0040 0040 0020 0020 0020 0020 0040 0020 0020 0040 0020 0020 0020 0020 0020 0020 0020 0020 0040 0020 0c74

and here's the '1' button learned from my URC-6131 ...
0000 006c 0000 000c 0020 0021 0040 0040 0040 0021 0020 0020 0020 0040 0020 0020 0040 0021 0020 0020 0020 0020 0020 0020 0020 0040 0020 0c7b

Now let's see if UEI has got this one already!

[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?

[gfb107]

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.)

It is. Just edit protocols.ini, find the [Streamzap] section and change PID=01 24 to PID=01 23

[Mark Pierson]

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

[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?

[Mark Pierson]

modify the exec so that it supports the full range of OBCs. It should be a fairly simply fix.

Any thoughts?

Give it a shot... I'll hold off on the new version until I hear back from you (there's a few other minor rev's I want to get updated either way).

[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 ... le_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