Here's another odd thing:
My monitor takes a few seconds to initialize while powering up before it will accept a command to switch to a particular input. So my regular power on macros for DVD or watching through replay tv or watching directly from the cable box etc does the following:
1. Send discrete on to the monitor,
2. Do a toadtog check to see if monitor was already on,
3a. If monitor was already on, switch to input X and continue with the rest of the macro,
3b. If monitor was not already on, insert a pause (e.g. 3 seconds) and then switch to input X and continue with the rest of the macro.
Here's the odd thing...the pause is working great, but no matter how long I make it, the monitor will ignore the command to switch to a given input if the monitor was off to start. But if the monitor was already on, the same macro will work fine to switch the input.
However, if I throw a Dev_TV command in the macro right after the toadtog check, it works perfectly. And this isn't a question of the pause being insufficient, since I cranked the pause way up and never got anywhere. It is as if, by calling the phantom key that has the toadtog command, the macro lost the idea that the active device is TV (so that when I repeat the Dev_TV command after the toadtog call, all is well). I've got it all working now through that workaround, but I'm curious about this odd behavior...Why does it do that??
2116 extender version 1 versus 2?
Moderator: Moderators
Boy, go on vacation for a week and there's all sorts of excitement. 
So what's the final verdict on the 2116x2 Pause? That it inserts a very short pause, or that it doesn't work at all? If I remember correctly, mucked around with it enough so that it worked on my set up, so my guess is the delay increments are just very small. Let me know if that isn't the case.
If this is the case, I'll probably just update the documentation to say if you need a longer delay, to use the standard Pause protocol. I've got some other updates to make to the documentation when I get around to it too.
asinsh, post your dump in the Diagnostic section and I'll try to take a look at it and see if I can see anything with it. Are you using the standard Pause protocol? If so, did you check to make sure the registers it is using are safe to use? I don't think the extender uses them for any persistent data, but I wouldn't swear to it.
Oh, and why use v1 of the extender? Because v2 wasn't available until about a month later. That and v1 does use slightly less space.
David
So what's the final verdict on the 2116x2 Pause? That it inserts a very short pause, or that it doesn't work at all? If I remember correctly, mucked around with it enough so that it worked on my set up, so my guess is the delay increments are just very small. Let me know if that isn't the case.
If this is the case, I'll probably just update the documentation to say if you need a longer delay, to use the standard Pause protocol. I've got some other updates to make to the documentation when I get around to it too.
asinsh, post your dump in the Diagnostic section and I'll try to take a look at it and see if I can see anything with it. Are you using the standard Pause protocol? If so, did you check to make sure the registers it is using are safe to use? I don't think the extender uses them for any persistent data, but I wouldn't swear to it.
Oh, and why use v1 of the extender? Because v2 wasn't available until about a month later.
That and v1 does use slightly less space.David
Yes, it works but is not very useful if you need a significant delay. If you crank all the way up to FF, the increment is still way under a second. The standard protocol works fine, however.vasqued2 wrote:...So what's the final verdict on the 2116x2 Pause? That it inserts a very short pause, or that it doesn't work at all? If I remember correctly, mucked around with it enough so that it worked on my set up, so my guess is the delay increments are just very small. Let me know if that isn't the case....
Extender2 is really pretty amazing, but it seems very very finnicky. There are lots of macros that I had to screw around with to get to work properly...add an extra DEV_ here, change the order of the macro there, throw in some duration control with the device combiner, etc. But in the end, I was able to get everything working. And I love the increased speed, increased memory, toad tog (my first time using it) and custommodename.
By the way, I'm almost out of upgrade memory, but I have tons of keymove/macro space left. One thing to consider (I have no idea how practical this is) would be to allow the user to somehow define where the split is between keymove/macro memory on the one hand and upgrade device/protocol memory on the other. Is there a simple tweak in the code that would shift the allocation over towards the upgrade device/protocol side of things?
Alan
Post a file that works and a corresponding one that doesn't and I'll see if I can find anything.There are lots of macros that I had to screw around with to get to work properly...add an extra DEV_ here, change the order of the macro there, throw in some duration control with the device combiner, etc.
The source code is included w/ the extender. Just change the definition of NewKeyMoveArea and whatever other variables you need to change, make the corresponding changes in the RDF, recompile, and you should be good to go. The only thing to watch out for is that in an ideal world, byte 400 should be set to '0' otherwise the extender might not activate properly. You might get lucky and it might work anyway, or you might not.By the way, I'm almost out of upgrade memory, but I have tons of keymove/macro space left. One thing to consider (I have no idea how practical this is) would be to allow the user to somehow define where the split is between keymove/macro memory on the one hand and upgrade device/protocol memory on the other. Is there a simple tweak in the code that would shift the allocation over towards the upgrade device/protocol side of things?
David