Pioneer PDP 5016HD decoding problems

[Mark Pierson]

So the AA AA that should be fixed data, has become the first assigned function, and the next two bytes have been merged into a single function. That's not right.

There's no problem... just look at the raw hex from the upgrade and the raw hex in IR (click the Edit button).

IR: 5A 00 19 00 AA AA C7 37

RM: 5A 00 19 00 AA AA C7 37

IR doesn't know any details about fixed data, 1- or 2-byte commands, etc., so it makes guesses when displaying upgrades. When they're "short" the data can appear scrambled as is the case here.

[jimdunn]

So does that still leave us wondering why the (working) learned signals which decode as NEC1:170 don't work when they are created with an upgrade ?

i.e. klflote's upgrade should work but doesn't

Sorry -it's late here...

[johnsfine]

To my uninitiated eye - the difference appears to be the lead in of 9000 vs 8500, and the lead out, with 40500 vs 30000 and 96700 vs 78900

Looks to me like about a 5% difference in speed overall.

Almost no IR receiver could care about a 5% difference in speed, so it most likely doesn't matter. I'm not sure about the cause. Some possibilities are:
a) The original remote really was 5% faster than nominal for NEC1.
b) IR.exe doesn't understand that timing of learned signals varies slightly depending on the model of remote used for learning. I think it reports all learned signals based on 15-1994 timing. I don't know if the per model differences get up to 5%.
c) A defective oscillator in one of the several remotes involved in that comparison.

whilst in IR the fixed data are:
00

IR.exe is simply not programmed with parameter counts for built-in protocols. It can correctly load an upgrade into a remote without knowing that information. It only needs the information to display the upgrade correctly. It has rules for deducing the parameter counts, but those rules fail on very short upgrades, so it displays them incorrectly. But that isn't serious. It doesn't affect the operation of the very short upgrade in the remote.

[jimdunn]

It most likely doesn't matter.

Thanks, John - I sort of guessed it probably was too small a difference to make a difference because I've seen much bigger discrepancies in lots of signals which I know work (because I use them successfully)

Would it be worth klflote trying a Pioneer protocol instead of NEC1 ?

[jimdunn]

and if I reload the remote with the uploaded data (without changing anything in IR), the learned keys no longer work.

This is the part I don't understand.

Doesn't IR just save raw data for learns ?

If so, how could it be non-working after this procedure ?

Sorry if that's a question that betrays my lack of understanding - it just isn't making sense to me

[jimdunn]

A mild bump

Can someone help me understand the question I posed above ?

edit: That was nonsense - I understand the question, obviously, because I asked it - is someone able to answer it ?

How can downloading learned data to IR and re-uploading it to the remote cause the learned signals to no longer work ?

Am I basically wrong in assuming that IR just deals with raw data in the learned area ?

Shouldn't the re-uploaded signals therefore be identical ?


I promise not to be upset if the answer highlights my stupidity...

[binky123]

IR does expect the Learned data to be in a certain format and if it is not, it will try to modify it.

He should probably do a RAW(no RDF found) download and then save this .IR file and compare it to the one that he is uploading with IR.

[johnsfine]

I don't have a guess yet about why the learned signals don't work after upload. I think only an expert in the 9960 B01 would have a chance of figuring that out from what has been posted here so far.

All I can do is suggest an experiment that would probably generate enough infotmation that someone with general JP1 expertise could figure out the problem:

1) Do a factory reset on the remote itself to make sure we have a clean start.

2) Relearn and test some signals (I assume they will work).

3) In IR.exe in the advanced menu, enamble raw download. Then do a Raw Download and save that as file#1.

4) Do an ordinary download and save that as file#2.

5) Do an ordinary upload and retest the learned signals. I assume they won't work.

6) Do a raw download and save that as file#3.

7) Zip together those three files and put the zip in the diagnosis area and post its URL back here.

Hopefully we will see small but significant differences in raw data between those three files, which will identify the problem (which is probably some mismatch between the firmware in your remote and the rdf file).

[jimdunn]

Thanks both

That was an almost instant response to my "bump"

Have you nothing else to do ?


Hopefully klflote can find time to follow those (very clear) directions, and the solution can be deduced from his response.

thanks


Jim

[jimdunn]

IR does expect the Learned data to be in a certain format and if it is not, it will try to modify it.

Thanks Binky, that's something I didn't know.

[klflote]

I'm out of town for a few days, but I will try John's suggestions when I am back and post the data -- thanks for the ideas (and thanks Jim for the bump!).

One thing I noticed about the learned signals is that they always say that they apply to the VCR -- that's true of any signal I learn from any remote, including those I've successfully been able to create upgrades from (after changing the device type, of course). I wonder if that's a normal thing for IR, or if it's another indication that something funky is up with this remote.

[The Robman]

One other thing, when dealing with a URC-9960 B01 remote (with it's 4k EEPROM chip), you should always select the "Force >= 4k" option in IR when uploading and downloading.

[klflote]

One other thing, when dealing with a URC-9960 B01 remote (with it's 4k EEPROM chip), you should always select the "Force >= 4k" option in IR when uploading and downloading.

Yes, I've been doing that for all the data I've posted/discussed on this thread (it's one of the things I discovered I needed after my checksum problems).

[binky123]

I'm out of town for a few days, but I will try John's suggestions when I am back and post the data -- thanks for the ideas (and thanks Jim for the bump!).

One thing I noticed about the learned signals is that they always say that they apply to the VCR -- that's true of any signal I learn from any remote, including those I've successfully been able to create upgrades from (after changing the device type, of course). I wonder if that's a normal thing for IR, or if it's another indication that something funky is up with this remote.

This indicates the RDF probably needs to have LearnedDevBtnSwapped=Yes in the [General] section. This is probably causing the learned data to be corrupted as IR is expecting a certain format.

[klflote]

This indicates the RDF probably needs to have LearnedDevBtnSwapped=Yes in the [General] section. This is probably causing the learned data to be corrupted as IR is expecting a certain format.

This helped somewhat. Now, after downloading the file from the remote, the device shows up correctly, and if I upload back to the remote, the signals are remembered correctly.

However, I still can't get my upgrade file to work. I followed the instructions above, and I don't see any difference between the raw and standard download files. But I do see a substantial difference between the file uploaded from the remote after learning the signal, and the file sent to the remote after loading the upgrade device (which isn't really surprising, I suppose).

I have provided some new files at:
https://www.hifi-remote.com/forums/dload ... le_id=5024

Here is what I did:

1) Loaded the remote with my original saved configuration (Orig.ir)
2) Did an unlearn all programming, followed by a factory reset
3) Learned two signals (Power, Input) from remote
4) Downloaded as RawDownloadInitial.ir and StandardDownloadInitial.ir. Except for some comments, these appear to be the same to me. [I originally did this step before adding the LearnedBtnDevSwap to the RDF file, and the raw and standard downloaded data was indeed different. But after changing the RDF, they are the same.]
5) Uploaded StandardDownloadInitial.ir to the remote
6) Tested the remote -- the learned functions still work (one problem solved!)
7) Created a new upgrade (the data all seemed to be the same, but since the RDF file was different, I created a new upgrade anyway)
8) Added the upgrade device to Orig.ir (saved as OrigPlusUpgrade.ir)
9) Uploaded that to the remote. The TV signals no longer work
10) Downloaded the new data as DownloadAfterUpgrade.ir (which appears to be the same as OrigPlusUpgrade.ir)

Any other ideas? I guess it still seems odd to me that the Fixed Data of the upgrade appears as the hex command of the power button in IR, but of course I have no real understanding of how that works.