PID $0123: StreamZap protocol

underquark · Post by **underquark** » Wed May 10, 2006 2:39 pm

I tried KM 8.41 with StreamZap but still have problems:

Device Code 34 ought to generate fixed data 1D
In previous versions of KM it generated DD
In this latest version of KM Device Code 34 gives fixed data of BB and I had to enter Device Code 113 to get 1D.

Post by **The Robman** » Wed May 10, 2006 2:54 pm

Don't worry about what values are in the fixed (or variable) data as they will be different using my new exec, worry about whether the upgrade generates the correct device codes and OBCs.

Post by **The Robman** » Wed May 10, 2006 3:51 pm

In case you want to know how it works. Take a look at the binary...

1D = 00011101
DD = 11011101

The first bit is the one that specifies whether the OBC is below 64 or not.
The second bit (in red) is the toggle, so it doesn't matter what value is supplied.
The remaining 6 bits (in blue) are the device code (in MSB-COMP format)

Now look at the binary generated from the current KM:
BB = 10111011

In this binary, the first bit is the toggle and the next 6 bits are the device code.

The OBC64 indicator has been moved into the MSB position of the variable bytes and it gets shifted into position by the assembler code.

gfb107 · Post by **gfb107** » Wed May 10, 2006 6:15 pm

RM v1.52 incorporates the new Streamzap executor.

Is there a corresponding change for Streamzap_57kHz?

Post by **The Robman** » Wed May 10, 2006 6:23 pm

I've never heard of it, does it work the same way?

gfb107 · Post by **gfb107** » Wed May 10, 2006 6:41 pm

Hmm, somebody added it to protocols.ini. The notes say

This protocol is identical to Streamzap except for frequency[/url]

Post by **The Robman** » Wed May 10, 2006 8:16 pm

That means that all they did was replace the first 2 bytes of the exec code. Therefore, if you were to replace the first 2 bytes of my new exec with their first 2 bytes, you would have an all-OBC version with the higher frequency.

mr_d_p_gumby · Post by **mr_d_p_gumby** » Wed May 10, 2006 8:31 pm

OK, here's a quick patch for the other processors. PB file here.

P8/740:
0C 18 11 80 0F E0 D0 04 20 08 06 02 06 02 06 51 A4 20 01 01 A5 5D 06 5E 6A 17 5A 02 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 B6 5A 38 5B 46 01 57 02 A8 40 B7 5A CC 01 83

M6805-RC16/18:
11 24 11 20 11 85 85 10 08 06 00 D2 D3 00 D2 D3 51 A4 00 00 D2 00 B6 5A 38 5B 46 01 57 02 A8 40 B7 5A CC 01 AF

Post by **The Robman** » Wed May 10, 2006 8:34 pm

Thanks Mike, I just added these to KM 8.42

underquark · Post by **underquark** » Sat May 13, 2006 6:07 pm

The Robman wrote:Don't worry about what values are in the fixed (or variable) data as they will be different using my new exec, worry about whether the upgrade generates the correct device codes and OBCs.

Ah, thanks for fixing this. I had merely seen the "wrong" fixed data but had failed to note the protocol tweak; naturally it works perfectly. Next time I test before saying something has a problem with it.

Post by **The Robman** » Sat May 13, 2006 8:04 pm

Glad to hear it works.

Post by **The Robman** » Wed Sep 29, 2010 11:14 am

It appears that we have got the bit breakdown for the Streamzap protocol wrong. I see that we have code to handle OBCs > 63 even though none of the current files have any OBCs that are greater than 63, so I did some research and I think this was based on the assumption that the Streamzap protocol was a modified version of the RC-5 protocol with 1 extra device bit, whereas I think it's really a modified version of the RC-5 protocol with 1 extra *OBC* bit.

There are several devices that "appear" to use multiple device codes. I say "appear" because the reason that two device codes are showing up is because, in my opinion, we are treating one of the OBCs bits as a device code bit.

Streap zap is currently defined as:

{36k,msb,889}<1,-1|-1,1>(1:1,~F:1:6,T:1,D:6,F:6,^114m)+

I would like to change this to:

{36k,msb,889}<1,-1|-1,1>(1:1,~F:1:7,T:1,D:5,F:7,^114m)+

I can update all of the current upgrade files and fix KM and RM to process Streamzap this way, but I'm reluctant to do so without the same change being made to DecodeIR.

Post by **The Robman** » Fri Oct 08, 2010 9:49 am

I've done some more research and found that the $0182 executor not only handles the protocol that we call "Echostar 2200" (56kHz) but it also handles the protocol that we call "Streamzap" (38kHz).

Given that this protocol is a clone of RC-5 with an extra OBC bit (not device code bit as is usually stated), maybe we should rename it to something based on RC-5?

Here's a PB file for the executor:
http://www.hifi-remote.com/forums/dload ... le_id=9022