JP1 Remotes

I've added an updated IR file here . Look at the macros on DVD and VCR. DVD has 2 X_ dev selections. First press of DVD, the macro executes correctly.
Pressing VCR does nothing the first time. Second press of VCR executes.
This is, I think, Capn's bug. It might be confusing the issue using this in a LKP.
Best,
jeff

bump.

Bill (or anybody smarter than me),

Any progress on figuring out the device selection challenges?

Cap'n

haven't had a chance, been traveling (In the UK right now) I will be back in CA on 3/1, and hope to get a shot at it. I did bring the source with me, but no remotes. I'll probably look at it one night this week when I don't have anything else to do.

sorry

binky123 wrote: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.

Code: Select all

		LD	R_Dev,RC1		;Change device index to O_device
		LD	R_DevA,RC1
		CALL	LEDblink		;blink LED to indicate device change

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.

While awaiting the resolution of the device selection problems, can we get this fix to the multiplexer implemented?

I can work around MOST of the device selection issues with keymoves (keymove every function desired from one device to another - there is no shortage of keymove memory after all), but I DESPERATELY need to multiplex (10 Devices and only 5 Device buttons!)

Thanks.

Bill,

Both Beta 2 and Beta 4 versions of this extender are in the File section right now, but in different locations, which can potentially lead to confusion for some.

Your opening post in this thread has a link and reference to version Beta 2 of this extender (in the overall Atlas Extender folder), while I believe that version Beta 4, in the OCAP SUB-folder, is the currently operative one.

Might I recommend that the Beta 2 version be deleted, and perhaps the beta 4 version should be in its place in the general Atlas folder (where the Beta 2 has been), as non-OCAP Atlas (1055 3000 and 3033) owners might not be able to find it in the OCAP sub-folder.

(or even better, Beta 5 )

...OK...shutting up now...

As suggested, I have updated the base note to point to the V0.04 beta release in the OCAP directory and have deleted the V0.02 version in the top level Atlas directory.

as for Beta 0.05, soon, I hope.

BTW, the "issue" reported by Binky that the O_Dev didn't get set is not quite correct. Earlier in the code there is a LD that stores the current device that is in W1 into the device table. The extra LD's for R_Dev and R_DevA are there to update the pieces that the remote uses, the pieces that the extender use are updated previously.

The actual code is

LD R_DevTbl[W0],W1.
.
.
LD R_DevA,RC1
LD R_Dev,RC1


-bill

[/code]

I'm also having the same problems with the device changes, but everything else is working well

Is it necessary to keep the original protocols/devices that the remote came with or is it ok to remove them before installing the extender?

I don't know if this is the same as the device change bug but I have a macro: X_TV;A;X_CANCEL

on the first press it doesn't switch to the tv but executes the A button on the current device.

subsequently some of the remote keys seem to be switched to the tv mode. I can upload the ir file if it would help in debugging.

edit: doesn't happen with all macros, just one I have on PIP Channel -

I had a chance to go thru the code and the remote internals a bit and I think I found out how things work.

I was able to get the multiplexor working but I'm not sure what the correct approach should be for this remote. Normally, the multiplexor changes the RAM copy of the setup codes table. This is not sufficient for the Atlas 3000 I was using as the remote loads in the EEPROM copy every time it works on a keypress. One workaround was to update the RAM copy and then write it out to EEPROM.

I also noticed that the VOL+/-/Mute keys send an extra IR code out in CBL mode. I was able to get rid of this by adding a line in the extender.

I also noticed the 1 button lag in switching the device modes. I think this is a result of the R_DevA(active) and R_Dev(current) registers being swapped. I swapped mine and I was able to get rid of the lag.

Binky

thanks for those finds! Adding the fix for multiplexor will be easy, I just have to go fishing for the right entry point to update the settings.

This is progress! I've not been able to dedicate much time to this over the past few months, although I did have my remotes out last night and am still having trouble with my USB interface on the 3033 remote (Tommy and I are in discussion about this)


-bill

Please, please, please, please, please, please, please, please, share the updated extender files!

(Shameless begging )

the modified v0.04.asm file should look like this and then the line to stop the switching to CBL mode when VOL+/-/Mute are pressed: I'm not sure how frequent you change device codes but we may want to look for a different solution than updating the EEPROM all the time. I don't know what the rating is for the number of erase/write cycles that can be done. It might be 100,000.

Thanks for the updated lines binky. I recall staring at that part that set the active device, but without more info about what's in the various registers, I'd just been guessing

I added these changes and rebuilt. I'll need a couple of days before I can test it. I'll post back with some feedback.
Thanks again,
jeff

I tested another method for the multiplexor and it seems to work with no writing to the eeprom. It can probably be incorporated into the activation/deactivation extender code.