JP1 Remotes

Hi Vicky,
What Capn is describing is what I described several posts back. To change devices, it takes 2 key presses of that device key to change device keysets.

IMO, it's been in all versions its just been tricky to figure out what was going on and what the pattern was. I wish I was better with the software to try and fix this - I've not gotten the zen of the extenders in a remote control.

DKP and LKP work, provided you don't do any device selection in the executed macros. If you do, then you'll see the bug above.

The issues with locks and VPT, etc. were throwing me off too, but wasn't that just in the unextended remote? Once I turned all that stuff off, then the unextended remote seemed to work well. Binky's posted fast macros and DKP/LKP protocols for the unextended remotes elsewhere.

Best,
jeff

greenough1 wrote:To change devices, it takes 2 key presses of that device key to change device keysets.

I may be picking a nit, but that's not a PRECISELY accurate description of the behaviour. It does not take 2 keypresses to change a device. The device change occurs as a result of the FIRST button press, but the device change takes effect AFTER the function assigned to the target button is executed.

Example: C_CBL and V_AUD are currently "active"

(1) I press Ch+ initially it makes CBL execute Ch+;
(2) I now press Vol+. The CBL device executes a Vol+ command, but ANY SUBSEQUENT BUTTON PRESS will execute the corresponding AUD function - REGARDLESS of button set "membership" -
(2a) so yes, if I press Vol+ again, NOW the AUD device will execute Vol+ (the "2 consecutive presses" that Jeff refers to above), but
(2b) if I press Ch+ next, it will execute the AUD device's Ch+, and the NEXT press of any button will now execute the associated CBL device command.

So again, just for precision of understanding the symptom, the "Device change" associated with a particular button press occurs AFTER the assigned function has been executed for the PREVIOUSLY-"active" device. It's not an issue of TWO button presses. It's an issue of WHEN in the logic sequence the device change occurs.

I've figured out that since there is SOOOO much keymove memory, a rather inelegant workaround is to keymove any functions (like Vol+/- and Mute) into every device mode, and not have to deal with the changing devices.

I have not yet confirmed (or experimented with) the issue of macro strings with embedded device shifts. If the device shift occurs after it is desired in such a string, then I may find that to be a bit problematic. I can see keymoving LOTS of functions to various device modes (unused shifted and x-shifted buttons abound) as a possible, but rather unwieldy, workaround.

Anyways, if anyone can make the Multiplexer work in the Atlas JP1.3 extender (or can tell me that it does work and how) then I'd appreciate any pointers. Right now, the Multiplex keymoves result in an extremely short flicker of the associated Device button, but no change to the assigned setup code.

Hi Capn,
So I guess we might be talking about two different symptoms? Mine (which I described previously) was based on device key presses with very simple macros on those keys. Here's the LINK again for the simple setup.

To change from controlling one device (where change == pressing and having active that devices keyset), you had to press that key twice otherwise you were stuck with the previous device setup. Check it out and let me know how what you think.

Best,
jeff

Jeff Wrote:
I've not gotten the zen of the extenders in a remote control.

It sure takes a lot of zen to get one of these extenders to run! In my case its women's intuition. It sure takes a lot of hours though.

I was so sure I only had a few more hours of "fun" left that I started eyeing this extender. I got a little ahead of myself though. After 16 hours of working on my 1067, I don't have anything to show. It looks like I've got another whole weekend of tests to run to see where my problem lies. Or more! Its like very, very hard sudoku! You know the kind where you have no solid clues so you guess, and then you find you need to erase the whole thing and start over!

My wife always tells me there's no guessing allowed in soduku - you just have to look at the puzzle correctly. I say that's easy for someone who knows how to look at it

Bes,
jeff

greenough1 wrote:Hi Capn,
So I guess we might be talking about two different symptoms? Mine (which I described previously) was based on device key presses with very simple macros on those keys. Here's the LINK again for the simple setup.

To change from controlling one device (where change == pressing and having active that devices keyset), you had to press that key twice otherwise you were stuck with the previous device setup. Check it out and let me know how what you think.

Best,
jeff

Well, my device key macros are like your DVD, AUD,and VCR button macros and they work first time, every time - never requires a second press.

As for your CBL and TV macros, I see several probelms with them, none of which I would expect to work simply with a second button press. When you press CBL, I assunme you are trying to call the CBL/Phantom 2 DSM, but if your O-buttons are not yet assigned to CBL, I'm not sure what it will execute for Phantom2. Similarly, for your TV macro. I think you need a X_CBL and X_TV command respectively in those macros BEFORE you invoke Phantom2.

Further, the X_TV command WITHIN your TV/Phantom 2 DSM serves no purpose.

So do you use the Multipplexer? I can't get it to work for me at all.

I was trying to simplify the setup (and follow some other advice) and I see I just goofed it up.
I'll fix it and take a look later.

Best,
jeff

Using the v0.02 asm file(not sure if there is a more recent one or not), for the multiplexor, it seems the ChgDev: section has a bug as it never sets the R_DevO or O_device. It only sets the current and active devices.
In the Extender Multiplexor Protocol, the R_DevO value is used to indicate which slot to put the new setup code into. The initial value is zero so its possible your setup codes are being placed into the CBL device button slot, regardless of what O_device you choose.

There is a much newer ASM file, however, I'm traveling right now nd the files are on my machine at home. I'll send them to you when I get back on Saturday

Can you send it to me also? Thanks, jeff

P.S. I did fix my IR file. But when using a DSM to select keyset, instead of setting keysets directly with a macro, results in the device being stuck on TV. I didn't test not setting O_ keyset since that might be buggy. Since there's a newer asm file, I'll wait for that.

Thanks,
jeff

UncleMiltie,
And also whatever documentation/code you were going to send me. Thanks!

Oh what the heck. Add me the mailing list too.

Ditto

Further challenges - LKP on device buttons is goofy. Too hard to describe, but I think it's related to device assignment sequences within the LKPs.

Bill, can you please post the latest version of the extender files and I'll make the changes suggested above to get Multiplexer working. I have developed workarounds for the bizarre device assignment behaviour.

1. Don't use device assignment sequences in other macros/lkps - just use the default ones - all keysets to the same device.
2. Keymove the receiver's Vol keys to each device mode.
3. Make standalone macros for setting up devices. DO NOT modify any keyset assignments.

(There's PLENTY of memory and buttons to which to assign these keymoves and macros)

HOWEVER - despite all of these accomodations, I still HAVE to have a usable multiplexer to cover all of my devices. That's all I need (...and this chair ... and this paddle game ... and this...)

...and the "stretch" goal, as we call it, would be to ultimately get the bizarre device selection behaviour under control in the extender.

Thanks

Capn Trips wrote:Further challenges - LKP on device buttons is goofy. Too hard to describe, but I think it's related to device assignment sequences within the LKPs.

I have developed workarounds for the bizarre device assignment behaviour.

1. Don't use device assignment sequences in other macros/lkps - just use the default ones - all keysets to the same device.

Can you explain how you make LKP useful then. I have my extenders setup so that on a short keypress I run a DSM that does keyset assignments. Are you saying don't run the DSM on the short side, just put in the keyset assignment directly? What about doing X_ temporary device selection on the short side? I'm showing my ignorance by not knowing, in detail, what happens for that case, i.e. does X_ execute the macro for that device? If so, that's good.

Best,
jeff