JP1 Remotes

It's me again, continuing to do battle with my Atlas 5-Device PVR (SA_7SA_7 unextended sig) remote.

If I take ANY rmdu file and open it in RM, and then select the "Atlas 5-Device DVR-PVR Extender 1" as the remote, I get a HOST of Load Errors, and the rdf ultimately is NOT selected.

In RM 1.78, one gets about 35 lines of errors in the pop-up window, in RM 1.79, only four, but the rdf is rejected nonetheless.

Help?

Capn Trips, Do you have 2K Atlas? Reason I ask I've just attempted to make port 1K to 2K extender but I edited the 1K extender RDF file. If that's not too hot, 2K won't be either. So I need a tester. Or you do

ElizabethD wrote:Capn Trips, Do you have 2K Atlas? ...I need a tester. Or you do

Nope and "No I don't".

Happy with the 1K for my basement (alternate) HT, whilst I have a JP 1.3 30003000 with LOTS of memory (but no extender yet ) for my main HT.

But I repeat my plea for help with the original 1K extender rdf. I cannot get any version of RM to accept this rdf. I've downloaded fresh versions of the rdf from the zip file in the extenders section, as there is none in the rdf.zip distribution yet.

The rdf works fine in IR, so I am operating an extended remote, but it doesn't work in RM.

In the [Special Protocols] section, try changing
DSM
to
DSM=01FC

Is this the errors you get

java.util.NoSuchElementException
at java.lang.Void.<unknown>(Unknown Source)
at java.lang.Void.<unknown>(Unknown Source)
at java.lang.Void.<unknown>(Unknown Source)
at java.lang.Void.<unknown>(Unknown Source)

java.lang.NullPointerException
at java.lang.Void.<unknown>(Unknown Source)
at java.lang.Void.<unknown>(Unknown Source)
at java.lang.Void.<unknown>(Unknown Source)
at java.lang.Void.<unknown>(Unknown Source)

Setting devParms[ 0 ](Device Code) to 12
Setting devParms[ 0 ](Device Code) to 12

Since my copy for 2K made no objections, I figured there maybe something funny with the original 1K RDF file, like invisible characters??. So, I just renamed the 1K file, selected all text and pasted it into notepad and resaved under the previous name. Now it works what you want to do. No errors. But, even though the original file isn't there, RM displays two instances of 1K RDF file.

Hi Mike!

mr_d_p_gumby wrote:In the [Special Protocols] section, try changing
DSM
to
DSM=01FC

That fixes the RM issue
but results in IR giving me alerts (that I didn't have with the previous rdf) that my DSMs won't work because I don't have the 01FC protocol upgrade loaded (I know that it's built in to the extender and the protocol upgrade is NOT required, but the IR pop-up is (very mildly) annoying).

But I can live with acknowledging a pop-up in IR as opposed to a fatal error in RM.

I made the 01 fc change but didn't believe it would do anything so then I went and did the copy and past thing -- two changes at one time evil strategy.

The DSM message is in the 6131 as well. I got used to it but you can add just the device if you have room for 3-5 bytes and then IR will be quiet.

ElizabethD wrote:The DSM message is in the 6131 as well. I got used to it but you can add just the device if you have room for 3-5 bytes and then IR will be quiet.

Actually. I HAVE added the dummy device. Without it, DSM doesn't show up as an option in the Special Protocols tab and one would have to manually build the DSM sequence on the Keymoves Tab. Never dealt with the 6131, so I don't know how that behaves, but for the SA_7, IR still asks about the Protocol upgrade (unless that "=01FC" is omitted from the RDF) - which I promptly ignore.

When I got home I checked my 6131. I do have the DSM device added and IR is not quiet. I gues I got used to it So they do behave the same which stands to reason as the extender is based on the same source. Sorry for confusing things.

Capn Trips wrote:Actually. I HAVE added the dummy device. Without it, DSM doesn't show up as an option in the Special Protocols tab and one would have to manually build the DSM sequence on the Keymoves Tab. Never dealt with the 6131, so I don't know how that behaves, but for the SA_7, IR still asks about the Protocol upgrade (unless that "=01FC" is omitted from the RDF) - which I promptly ignore.

The 6131 and the Atlas extenders both have the DSM functionality built in, so the dummy protocol is not actually used. However, IR was never modified to provide a way to activate the DSM without the protocol being present. The usual approach, as Liz has stated, is to put the dummy protocol in IR while you are creating the DSM functions, and then when you are done, to delete it if you need the space.
See https://www.hifi-remote.com/forums/viewt ... 2063#p42063

Perhaps I'm splitting hairs here, but the dummy PROTOCOL is not required to build the DSM functions, only the dummy UPGRADE. As I see from my experience:

No dummy upgrade NOR dummy protocol - build the DSMs the REAL old-fashioned way, with hex sequences on the Keymoves Tab;

Dummy upgrade but no dummy protocol - DSM becomes available on the Special Functions tab, but you get an IR alert that the Protocol is missing after completing building a DSM (and you're wasting a few bytes of memory);

Dummy upgrade AND dummy protocol - everything works fine (but you're wasting some more memory, all of which is recoverable).

Do I have it about right?

I think what Mike means in the 3rd line from the bottom, is you have to add a dummy device, not protocol.

In your paragraphs sequence:
1. DSM non-dummy protocol is built-in right in the extender code. That's why it's not required for user to add. The dummy upgrade/device is required for user to add. And without the protocol, hidden as it is from IR, it won't work. It really is IR issue that it isn't recognizing the protocol that's built in.
2. I guess so, when the DSM protocol isn't imbedded in the extender, as this one is.
3. I don't think that's what you meant, just upgrade but no protocol, if so, I don't think that can work
4. Yup. Protocol built-in, device is user added. The only memory you waste is something like 5-6 bytes for the device.
5. Just about right.

BTW, in case you're interested ,the Atlas extender source says it's perfectly ok to modify the boundary between the keymoves and upgrades (with matching rdf change), so Hal or Mike must have tested it.

ElizabethD wrote:
1. ... The dummy upgrade/device is required for user to add. And without the protocol, hidden as it is from IR, it won't work. ...

Maybe we're just parsing words, at this point, but I really think you 're wrong, here. The dummy Device Upgrade is NOT required for DSM to work, NOR is it required to be able to build the DSMs in IR. It IS required if you want IR to be able to support building the DSM functions the "easy way" on the Special Functions tab. Without the dummy Device Upgrade, you can still build DSMs and they will work, but you have to do it "manually" on the Keymoves Tab, without the intutive interface that the Special Functions tab provides.

ElizabethD wrote: ... The only memory you waste is something like 5-6 bytes for the device.

Which is recoverable. After building your DSM functions, you can delete the upgrade and the functions will still work. They will just no longer appear on the Special Functions page in IR, but on the Keymoves page.

I see. I was responding to the building phase with the DSM protocol assumed built-in. No choice. What you say does apply to others.
Yes, we can build with any protocol absent. And IR will warn, regardless whether it's DSM or LKP or any other special.
Are we on the same page now?