3m MP8650 LCD projector

[dskull]

JP1 remote :15-2116
JP1 user :yes limited knowledge
original remote :no
file section :no
pronto file :no
partially working: no
learning :no

I have a 3m MP8650 LCD projector but do not have the remote
I have found raw IR codes for the remote but do not understand how to upload to my remot via JP1
http://www.remotecentral.com/cgi-bin/codes/3m/mp8650/?1
http://www.remotecentral.com/cgi-bin/codes/3m/mp8650/?2

also i looked for a pronto ccf or any pre made upgrade file but could not find anything that i could use

[gfb107]

You searched the file section? How did you miss the JP1 File Section -> Device Upgrades -> Projectors -> 3M Projectors upgrade file?

[The Robman]

Actually, I think he's saying that he didn't search the file section, which would explain it!

file section :no
pronto file :no

[dskull]

thank you for the pointer

however, I just tried that code and it did nothing with the projector.

is there a way to convert the raw IR data that i found (links in first post) to anything useful?

Dan

[johnsfine]

is there a way to convert the raw IR data that i found (links in first post) to anything useful?

That "raw IR data" is in a format called "Pronto Hex".

There is a JP1 version of the Irtool.exe program that can be used together with DecodeIr.dll to decode Pronto Hex.

Many of the samples on that site you quoted decode to Fujitsu protocol, device 134.198 various OBC numbers.

The other Pronto Hex samples there don't decode. My first guess is that those samples are just wrong. But I may try to look more closely later to see if the device might use a mix of two different protocols, one of which isn't understood by DecodeIr.

I just opened up slightly obsolete versions of KM and RM and saw that KM gave a choice for Fujitsu and RM didn't (if RM hasn't had Fujitsu added more cently, that's something else I should find time to do).

If DecodeIr and KM agree on the encoding of device, subdevice, and obc then you can type the values decoded by IrTool directly into a KM upgrade and reproduce those signals with your JP1 remote. For some of the less common protocols KM and DecodeIr are not in agreement, in which case you would need some more expert help.

The upgrade Greg pointed you to is for an entirely different code set. I assume that means 3M is rebranding projectors from different sources.

Edit: After actually looking rather than purely trusting DecodeIr: Those hex samples are seriously messed up. They aren't correct examples of anything. But there is so much internal redundant structure to a long protocol such as Fujitsu that DecodeIr can recognise it even severely trashed. I still think the Fujitsu decodes are correct. The signals that aren't decoded are pretty hopeless. Without a very good idea of what they're supposed to be you can't factor out the fact that half of the information has been zeroed out.

Maybe we can find the Fujitsu model or some other brand/model of this same device and get the signal info there. Seeing a 3M brand on a Fujitsu device almost certainly means the same device is also sold with brands other than 3M.

[The Robman]

I was hoping that you'd jump in some thoughts. I have never seen Pronto hex with complete zero words all over the place like that, so I wouldn't have any idea what sort of signal it would generate.

I could try loading it into my Pronto and then learn from the Pronto, but that's a slightly tricky process with my setup.

[johnsfine]

I'm pretty sure it wouldn't work in a Pronto, nor anyplace else other than IrTool.exe

So the best bet is using the Fujitsu decodes and looking for a setup code, upgrade or CCF file for Fujitsu 134.198

[The Robman]

I loaded them into my Pronto and tried learning them using a URC-8811, but while both remotes appeared to go through the motions well enough, the signals captured by the URC-8811 were garbage, as expected.

[The Robman]

There are real codes for the MP8660 that decode as Fujitsu 134.181

http://www.remotecentral.com/cgi-bin/codes/3m/mp-8660/

And another that is just 134:

http://www.remotecentral.com/cgi-bin/co ... projector/

[johnsfine]

After going to a different computer I've discovered I seem to be using a couple different combinations of IrTool/DecodeIr that disagree with each other on how to decode these signals.

With manual decode I see the internal subdevice value matches the device value for most of these, which is typical for Fujitsu and which DecodeIr represents as no subdevice.

Based on that it all seems to match setup code TV/0751 which is built-in on the 15-2116.

So try TV/0751 and see which functions work.

[johnsfine]

You may also find some useful information from Ampro projectors:

Rob's setup code cross reference for TV/0751 at
http://www.hifi-remote.com/ofa/devices-tv.shtml
lists only Ampro for TV/0751

I checked a few samples of Pronto Hex from the Ampro section of the Premise Systems database at
http://ir.premisesystems.com/search.aspx?m=AMPRO
Those matched both TV/0751 and my interpretation of the garbled Pronto Hex from the start of this thread.

[gfb107]

Protocols.ini has 3 entries for Fujitsu, all of which are incomplete and commented out. They only have the protocol name, PID, and code.

I'll look into how KM implemented these and flesh them out.

[johnsfine]

I'm not entirely happy with the way KM does it. I'd rather have RM do it a little better.

When the protocol executor KM uses is used for Fujitsu, the subdevice is encoded entirely in the hex cmd. It does not affect the fixed data at all.

The setup page in KM makes that confusing.

On the setup page for RM, it would be better to mark the subdevice field "default subdevice" and then use that on the functions sheet if you type an OBC without typing a subdevice.

I don't recall what level of support RM has for using setup page data solely as defaults for the functions page. If it doesn't have the right support, then we should just leave the Subdevice off of the setup sheet. Though there are cases in which that would make the user type the same subdevice number over and over on the functions sheet.

In most Fujitsu code sets the encoded subdevice field has the same number as the device field. At some point we decided that was clearer for the end user if we left the subdevice field blank for those cases. That fact may complicate the defaulting described above.

If we keep subdevice on both pages and the user leaves it blank in both places, that clearly is intended to correspond to a decode with no subdevice (so the subdevice byte of the hex command should match the device byte of the fixed data).

But if the user puts a subdevice number on the setup sheet, I don't see that there is any reasonably UI to let him override that to lack of subdevice number on the functions sheet.

BTW, other brands of Kasiekyo protocol use the same protocol executor, but use the bytes differently, so the way subdevice and obc get into the hex command is unique to Fujitsu's Kaseikyo protocol.

[gfb107]

RM does have support for command parameters getting default values from a device parameter. Here's the description from the notes at the top of protocos.ini

When the default value is in square brackets [], the value is an index into the CmdParm array. When the default value is in curly brackets {}, the value is an index into the DevParm array

I will set it up as you suggest.

There are 3 variants. If there is no variant builtin, we should offer variant 3, correct?

[johnsfine]

I haven't looked at what the variants are nor how they differ from each other.

Everything about the pid's, including which one to use if none are built-in, should be the same between Fujitsu and Sharp DVD.

The translation from OBC and Subdevice into hex command is totally different but the executor is the same.

Even if the choice of default variant for Sharp DVD had been made with no real justification, there is reason for the two enrties to agree on that choice.