DVICO TVIX HD M-5100SH

Post by **vickyg2003** » Sun Jun 07, 2009 3:14 pm

I made that last statement as a way of correcting my earlier statement, as I could see that you were following my earlier statement.

Definately following your lead here.

When I started working on this last Thursday I noticed that the leadout time was very large and much larger than the time reported in the signals, so my intention is to come up with a more realistic time and then try testing it.

Okay, I went back and read three pages of posts (and reading is NOT my strongest skill) and I can't find any link to the raw timings..... If it is in the thread, I probably took a peak and so the link is grayed out and I'll never find it.

I don't have a feel for what a timeout should look like, but I did notice that we are nearly at the upper limit for what PB allows so it makes sense that we were going the wrong way.

Post by **The Robman** » Sun Jun 07, 2009 7:05 pm

vickyg2003 wrote:Okay, I went back and read three pages of posts (and reading is NOT my strongest skill) and I can't find any link to the raw timings..... If it is in the thread, I probably took a peak and so the link is grayed out and I'll never find it.

I got the timings from a CCF file posted in this thread (quoted below) from page one.

friday wrote:i have seen today, that my remote (htr 2) for my NAD - amplifier has a interface too. but it looks different. it has 8 pins.

this remote can learn signals!
is there any way to use this interface?

[edit]
i have found a ccf file on remotecentral for a tvix 5000, but it should also work on 5100 and the newest 6500.

btw. in file-section is a rdf-file URC-39930 BJ0
is that matching with my URC-39930rj0-03 ?

when i use it, ir shows my devices, but i am not sure if this is save.
friday

friday · Post by **friday** » Mon Jun 08, 2009 2:33 am

thanks for your large attendance, but after a night of sleep and a helpful dream of this i have an idea

is it possible to start the automatically repeat a little bit later? as i said. the speed of repeat is ok! but when the repeat starts a bit later, i think my problems are blown away

friday

Post by **The Robman** » Mon Jun 08, 2009 6:45 am

If what I suspect is true, that's what the processor in the device itself will do once the signal is formatted correctly.

Post by **vickyg2003** » Mon Jun 08, 2009 11:00 am

Rob, Thanks for finding that link for me. I just couldn't find it! This has been a good exercise for me, since I only used DecodeCCF once before (Thanks to the capn, for helping me out there). Anyway I popped open the CCF and of course got the GAP notification that I'd expect with a nonstandard signal. I then did the form that had the raw timings.

One of them was
8993_4522 578_552 578_1682 578_1656 578_552 578_1682 578_552 578_552 578_1682 578_1682 578_1656 578_552 578_1682 578_1682 578_552 578_552 578_552 578_552 578_552 578_552 578_552 578_552 578_552 578_552 578_552 578_552 578_552 578_552 578_552 578_552 578_552 578_552 578_552 578_49199 8993-2235 578-97241

I looked back at the protocol and see that

['1' Burst] ON (uSec): 578
OFF (uSec): 1674

['0' Burst] ON (uSec): 578
OFF (uSec): 564
Xmit '0' Reversed: No

[Lead-In] Style: Half-size after 1st
Burst Mid-Frame: No
After # of bits:
[Lead-In] ON (uSec): 9038
OFF (uSec): 4502

[Lead-Out] Style: 2 = [OneOn, -LO]
[Lead-Out] OFF (uSec): 131066
OFF as Total: Yes

So I see the lead in pair, the ones and the zeros, but there are 3 pair of numbers at the end of the signal, that I'm not sure what they represent.

578_49199 8993-2235 578-97241

I assume one of these are the leadout pair. Should the 49199 be the leadout OFF time? And if so what are the other two pair of numbers.

Like you, I think the device should delay before it starts repeating, but from my own experience even the OEM remotes repeat too fast for my slow fingers.

I really think that Friday needs is an extended remote where we have so many more options.

Perhaps some carefully written MACRO's might do the trick.

Post by **ElizabethD** » Mon Jun 08, 2009 11:30 am

vickyg2003 wrote:So I see the lead in pair, the ones and the zeros, but there are 3 pair of numbers at the end of the signal, that I'm not sure what they represent.

578_49199 8993-2235 578-97241

I assume one of these are the leadout pair. Should the 49199 be the leadout OFF time? And if so what are the other two pair of numbers.

578-49199 is silence, leadout
Next is leadin and another silence indicating one repeat IMO

Post by **vickyg2003** » Mon Jun 08, 2009 12:09 pm

Thanks Liz

The leadin pair 8993_4522 and the second pair 8993-2235 must be the [Lead-In] Style: Half-size after 1st.

Friday this upgrade speeds up the repeat. It just might improve things, because its more like what your device was expecting to see. Its counterintuitive, but it might work.

Upgrade protocol 0 = 01 FF (HCS08) PID 01 FF (RM v1.73)
20 15 23 47 11 CD 4D 08 08 01 21 03 45 01 21 01
1A 5f B4 11 A7 08 CB 3F 62 3F 63 6E 03 AA CC FF
5F
End

You've mentioned a handicap, but I'm not quite sure how this effects your ability to use a remote. Are you able to do SHIFT functions? Perhaps we could do two upgrades, one with repeating arrows, one without repeating arrows, and have a shifted arrows do the repeating arrows and the non shfited arrows do the non repeating kind. Do the Shift-arrow when you want to move through 100's of titles, and the regular arrow to hone in on the correct title when you are close, and the regular arrows to navigate the menu.

Post by **The Robman** » Mon Jun 08, 2009 12:44 pm

This signal is formatted just like an NEC1 signal, except that the first byte is the device code, the second byte is the command code (obc) and the next two bytes are always zeroes.

The NEC1 format calls for the data portion to be sent once and then the signal that's sent for repeating purposes contains no data, so it's just a leadin pair and a leadout pair.

In the string that you quoted, this portion is the data string....

8993_4522 578_552 578_1682 578_1656 578_552 578_1682 578_552 578_552 578_1682 578_1682 578_1656 578_552 578_1682 578_1682 578_552 578_552 578_552 578_552 578_552 578_552 578_552 578_552 578_552 578_552 578_552 578_552 578_552 578_552 578_552 578_552 578_552 578_552 578_552 578_49199

and this portion is the repeat string...

8993-2235 578-97241

So the first leadin is 8993_4522 and the second leadin is 8993-2235. You'll notice that the OFF time is about half in the second pair.
The first leadout pair is 578_49199 and the second pair is 578-97241.

The NEC1 protocol calls for an "off as total" leadout pair. What this means is, when you define the leadout time in PB, you need to select the total time for the data string. Therefore, the more ONEs that are in the data, the shorter the final leadout off time will be. The leadout times in this CCF are shorter when there are more ONEs in the data, so this is an "off as total" signal. I calculate the total time for the data portion to be 94,477. The leadout time used for the repeat portion is 97,316, which is close enough.

Take a look at the spreadsheet below to see my breakdown of the signal:
https://www.hifi-remote.com/forums/dload ... le_id=6828

I haven't tested this myself, but the following protocol should produce the correct leadout time.

Upgrade protocol 0 = 01 FF (HCS08) TVIX 5000 (PB v4.01)
20 15 23 47 11 CD 4D 08 08 01 21 03 45 01 21 01
1A B8 86 11 A7 08 CB 3F 62 3F 63 6E 03 AA CC FF
5F
End

Post by **The Robman** » Mon Jun 08, 2009 12:48 pm

vickyg2003 wrote:Friday this upgrade speeds up the repeat. It just might improve things, because its more like what your device was expecting to see. Its counterintuitive, but it might work.

Upgrade protocol 0 = 01 FF (HCS08) PID 01 FF (RM v1.73)
20 15 23 47 11 CD 4D 08 08 01 21 03 45 01 21 01
1A 5f B4 11 A7 08 CB 3F 62 3F 63 6E 03 AA CC FF
5F
End

Vicky,
You've entered 49k as the leadout time *and* you've specified "off as total". This will produce a leadout time of almost zero because the data itself is between 44k and 48k.

friday · Post by **friday** » Mon Jun 08, 2009 1:10 pm

huh, and which should i try tomorrow ?

Post by **vickyg2003** » Mon Jun 08, 2009 1:30 pm

My apologies Friday. I have turned this into a learning thread for me. Hopefully you will benefit from the end result of my education.

Rob, so when it says leadout total that's the total time of the signal. If so, then when I decoded your protocol, it was just about at the correct timing with the total time at 109050.

So should I change that setting and then increase the lead out time as you first suggested?

Post by **The Robman** » Mon Jun 08, 2009 2:12 pm

See my description of the leadout time in my previous post.

Here's what I do in the spreadsheet that I loaded, I could all the ONEs in the data and multiply them by 4 (ie, an ON time of 1 unit and an OFF time of 3 units), then I count all the ZEROs and multiple them by 2 (ie, an ON time of 1 unit and an OFF time of 1 unit), then I multiply the result by 565 uS (the unit of time) to come up with the data time, then I add this to the leadout time to come up with the total time.

I think I over estimated the time at 109k, I now think it should be 94.5k. I don't know if that 15k difference is big enough to cause the problems that we're seeing, but we'll find out if Friday can test it.

Post by **vickyg2003** » Mon Jun 08, 2009 6:25 pm

Rob, as you guessed, I totally missed your post above. It answered all of my questions. Thank you.

Friday, if Rob's upgrade doesn't improve things, we'll need to pursue other options. I'd like to see your IR file because I think we could do something with keymoves if you have enough unused memory.

friday · Post by **friday** » Tue Jun 09, 2009 5:49 am

i have tested rob´s upgrade, but the repeat comes to fast.
i compared it with orig. remote. and there it is very fast too.

so i went back to vickys upgrade

Upgrade protocol 0 = 01 FF (HCS08) PID 01 FF (RM v1.73)
20 15 23 47 11 CD 4D 08 08 01 21 03 45 01 21 01
1A FF FD 11 A7 08 CB 3F 62 3F 63 6E 03 AA CC FF
5F
End

it seems that this is a bit slower. it feels so.

and macros/shifted-keys are in my special situation not possible. because i cant reach the shift-key very well with my fingers (hard handycap)

Post by **The Robman** » Tue Jun 09, 2009 6:37 am

friday wrote:i have tested rob's upgrade, but the repeat comes too fast.
i compared it with orig. remote. and there it is very fast too.

Wait up, so you're saying the original remote repeats too fast also? That's what we've been trying to replicate, so that would have been very useful to know up front.

If the FF FD time from Vicky's upgrade is still too fast, we would need to write some assembler code to introduce a larger delay.