Dreambox DM7000, DM7020 and Slingbox

binky123 · Post by **binky123** » Sat Jun 30, 2007 9:53 am

The Left Arrow OBC code is 51 00. The Right Arrow OBC is 50 00.
Cursor Left is 23 00. Cursor Right is 24 00.

I can't explain the behaviour of the Dreambox RC affecting future signals sent from the Slingbox.

There are three timing values in the protocol that can probably be tweaked but I'm not really sure what to do. There is a BurstOn(pulse), BurstOff(space) and a pause value between each BurstOff(space).

nuvolona · Post by **nuvolona** » Sat Jun 30, 2007 1:10 pm

Well, I think that until someone will try to make these tweaks in the protocol, maybe slingbox (USA version) remote will have some chances to work with a dreambox receiver, for now its just utopia... anyway its strange that the 0 key works so well, just that one

johnsfine · Post by **johnsfine** » Sat Jun 30, 2007 3:51 pm

binky123 wrote:So is the time scale issue the clock frequency that the S3C80 chip is running on?

That's a possibility (the slingbox being clocked at 2.5% slower than the frequency for which its XMP executor was coded). I don't know how to see past the poor sampling by LIRC well enough to be more detailed about why things are 2.5% slow or even whether they really are.

binky123 wrote:It seems from a rough visual comparison that WinLIRC samples(at 115200 serial baud rate)

What did I miss that is telling you WinLIRC is sampling at 115200?

binky123 wrote:the Dreambox RC pulse length longer and the space length shorter than what is captured for the Slingbox signals.

Very few IR protocols are sensitive to pulse vs. space durations. Most protocols care only about the "leading edge to leading edge" time, which is the time from the beginning of one pulse to the beginning of the next pulse. That is equal to the sum of a pulse duration and the directly following space duration.

From a crude analysis, I decided that value is 2.5% slower in the slingbox than in the dreambox remote.

binky123 wrote:I can't explain the behaviour of the Dreambox RC affecting future signals sent from the Slingbox.

I can't either.

binky123 wrote:There are three timing values in the protocol that can probably be tweaked but I'm not really sure what to do. There is a BurstOn(pulse), BurstOff(space) and a pause value between each BurstOff(space).

The protocol is able to generate at least 18 different space durations. I expect those are computed dynamically. If I look at the asm code of the executor I'll know a lot more including what one might try patching.

I know I'm supposed to know where to find a copy of that executor, but I don't. Maybe some less forgetful expert can email a reminder or some hex or whatever.

I'm not sure I should admit this. I have a slingbox myself, that I've never even turned on. I read the install instructions and decided it was too hard (because I don't have any network connections in the right places) so I set it aside to look at later and never got to it. I don't actually need or intend to use a slingbox for its real purpose. If I understood it better, probably I could set it up at a computer without any TV cable or VCR etc. and just try its remote against CaptureIR (which would give very detailed timing info about what the Slingbox really sends). But the install instructions are hard to use as a basis for such an improper install.

binky123 · Post by **binky123** » Sat Jun 30, 2007 4:22 pm

The links to the executor are in this post
http://www.hifi-remote.com/forums/viewt ... 8346#58346

When I installed/ran WinLIRC, it had an option to set the port speed to 115200 and so I believe this is the sampling rate but I could be wrong. I didn't look at the source code. I tried to set it to 230K but my UART chip apparently doesn't support this rate.

binky123 · Post by **binky123** » Sun Jul 01, 2007 9:01 am

The current values for BurstOn(pulse)=006A. BurstOff(space)=0167. Pause=003F. A Burst consists of BurstOn + BurstOff + Pause*N where N is the nibble being sent. The "0" digit sends 0E 0F 44 1A 00 00 00 00 0E 0F 44 1A 08 80 00 00 which seems to be working. This means out of the 16 possible nibbles, only these 0,1,4,8,A,E,F are recognized.

I experimented with RM's protocol.ini and added a 01 D0 protocol with a new BurstOn=006C and was able to create a new Slingbox PL bin which included the new protocol. I uploaded it here. At least this means we should be able to upload a new protocol once the new timing values are determined.

nuvolona · Post by **nuvolona** » Sun Jul 01, 2007 10:44 am

Thanks for the new file. I just tested it, still the "0" button only works.
No sign from the others, tested them all.

johnsfine · Post by **johnsfine** » Sun Jul 01, 2007 12:01 pm

binky123 wrote:Pause=003F. ... At least this means we should be able to upload a new protocol once the new timing values are determined.

If I analyzed those signals correctly, we should change the Pause to 003E or maybe 003D.

nuvolona · Post by **nuvolona** » Sun Jul 01, 2007 11:31 pm

Today is a big big day for Slingbox/Dreambox users because now Slingbox (USA model) IR remote works also for Dreambox!!!!

A very special THANK to binky123, who made this possible, for his effort, dedication, time spent and patience with me.
Thanks to johnsfine for the precious suggestions, to The_Robman for his first test attempt a few months ago and all the others who contributed and helped in this thread.

The file with the new protocol maybe still needs some minor tweaks, maybe about the size... but the result now is perfect, I can guarantee you!

Post by **The Robman** » Mon Jul 02, 2007 6:19 am

Can you link to the final versions of the files that are now working.

nuvolona · Post by **nuvolona** » Mon Jul 02, 2007 6:52 am

I still have to upload it, because I had to modify something in the original file that binky123 sent me (Slingbox couldn't accept it, like it was). But anyway I did all this in a rush earlier this morning, because I was in late for work. Tonight when I come back home I will check it again and upload it.

binky123 · Post by **binky123** » Mon Jul 02, 2007 8:05 am

Marcyjok wrote:I started Slingplayer and went to Properties -> Slingbox Configuration ->CHange Au/Vid setup -> USA -> Satelite receivers -> Other ->then I inputed code S1237 and I receive error:
0x93260001

nuvolona had the same error and I suggested reducing the number of buttons assigned to functions. The maximum size of a Slingbox upgrade(device+protocol) is 252d bytes. The size of the BIN file can't be more than 256d bytes as there is a 4 byte header.

The protocol executor should probably be changed from using 2 function bytes to 1. The 2nd byte for the Dreambox machines seems to be fixed at 00 so this could be added to the fixed data or have the executor automatically generate it.

Post by **The Robman** » Mon Jul 02, 2007 9:03 am

I don't want to have to read back through 8 pages to catch up with what you've all been doing, so if one of you could post the latest version of the executor and an upgrade file, I'll patch it so that it uses one variable byte.

binky123 · Post by **binky123** » Mon Jul 02, 2007 11:14 am

I have the 1-byte executor. Can you verify it looks ok and also create a proper protocols.ini entry for RM? I made 3 changes. dev-cmd byte; load #00 into R0A; Pause Timing value from 003F to 003E.

Code.S3C80=43 8b 41 8b 05 00 00 6a 01 67 e4 07 09 e6 0a 00 e4 03 07 e4 04 08 f0 08 56 08 0f f6 ff 90 f6 ff 2f fb 0b 46 08 80 f6 ff 90 f6 ff 2f 7b fb af 28 03 f6 ff 68 28 04 f6 ff 68 28 05 f6 ff 68 28 06 f6 ff 88 c6 f8 19 64 f6 01 58 28 07 f6 ff 68 28 08 f6 ff 68 28 09 f6 ff 68 28 0a f6 ff 88 c6 f8 9b 47 f6 01 58 8d 01 0a 48 c2 f0 c2 f6 ff 74 28 c4 8d ff 74 1c 12 f6 01 4c 56 c2 0f 6b 09 c6 f8 00 3e f6 01 58 2a f7 af f6 ff 68 1c 12 8d 01 4c 08 07 f0 c0 18 08 f6 ff b0 18 09 f6 ff b0 18 0a f6 ff b0 60 c0 0e 56 c0 0f 56 07 f0 44 c0 07 af 28 c1 f0 c1 02 12 02 01 af

The RMDU file for DM7000 with 2-byte is here
http://www.hifi-remote.com/forums/dload ... le_id=4522

Thanks.

johnsfine · Post by **johnsfine** » Mon Jul 02, 2007 11:26 am

Did you confirm that changing the 003F to 003E really mattered?

IIUC, the built-in executor with 003F fails and an upgrade executor with 003E works. But there may be other things wrong with the built-in executor that we don't understand and accidentally fixed by trying an upgrade executor.

I wouldn't have suggested trying 003E unless I thought it had a good chance of fixing something. But UEI invented the XMP protocol used by Dreambox, and they know its correct timing better than we do. They wrote the executor that is built-into the Slingbox and they know the timing rules for that better than we do. So I just wanted a little more evidence before concluding 003F was wrong.

binky123 · Post by **binky123** » Mon Jul 02, 2007 11:40 am

I don't think he really confirmed that changing 003F to 003E helped as I don't think a BIN was prepared with the original unmodified protocol. He tried 3 BINs(BurstOn=006C; BurstOn=68; Pause=003E) and reported 003E worked all buttons while BurstOn=006C had only the "0" digit working. If he is willing, he could copy the original Dreambox Code.S3C80 and see if it only works the "0" digit.