Atlas 3000 & 3033 JP1.3 extender

[unclemiltie]

Yeah, but how many rdfs will be maintained in the rdf zip distribution with the same sig? I know that there are one-offs (3A33 for 1055 vs. 1056) but it would become a truly unwieldy management issue to maintain multiple RDFs for the same remote AND signature!

Since I've not been an advocate of maintaining the extender RDF's in the main distribution, this would not be an issue for me. But others have a different opinion.

My position has been that given that you need to have the extender hex to install it, including the RDF along with that hex is a way to ensure that it matches and you have the right one.

the other side of the coin is that there is value in consistency in the unextended and extended RDF since they share a lot of common parts.

[xnappo]

My position has been that given that you need to have the extender hex to install it, including the RDF along with that hex is a way to ensure that it matches and you have the right one.

the other side of the coin is that there is value in consistency in the unextended and extended RDF since they share a lot of common parts

The problem is, of course, that the updates and protocol areas are improved, and new fields get added and Vicki's new tool allows me (the RDF librarian) to easily update these - but the ones in a zip with the extender will not see the fix.

Anyway, I understand where you are coming from too - I think your idea for having the extender RDF contain only override information may be a good one. We will see what the others have to say

xnappo

[vickyg2003]

There has been an ongoing discussion about Extender RDF's and this topic has boiled back to the top of my mind and I have been thinking about it.

Anyway, what if we did something like this:

In the RDF directory, there are two RDF's as we have today, let's use the Atlas for example:

30333033 is the unextended RDF
3A333A33 is the extended RDF

Now, instead of the extended RDF duplicating everything that is in the unextended RDF, the extended RDF has a reference to the unextended RDF (as some others have done to make the maintenance easier)

OEMRemote = 30333033

What this does is tell the tools that for everything that is not specified in this RDF, go get it from the unextended RDF. That way there is a button list, valid setup code list, protocol list, etc that doesn't have to be maintained twice. The extended RDF's would only specify those things that are different.

Well the button list isn't always stable by signature. Look at the 15-133,15-134,15-135 sceneraio.

The protocol/setup list isn't always stable by signature, look at the replay or the Millenium.

Most of the RDF, other than the protocols section should be stable. The librarian has a tool to updated the protocols section in all the RDF's so this is not a problem.

I personally LIKE having my RDF's in the hands of the librarian. Even though I read every post here, things get past me. When I find an error, I like to have someone to report it to. I had a message to another extender developer in my outbox for over 10 months before giving up. I don't see YOU going AWOL especially since you've been reinfected, , but it happens.

Also as a person that LOVES to diagnose IR problems, having to download every zip file to collect the RDF's would take half the fun out of it.

The librarian job is a very important position here. Its also a bit of a thankless job and we tend to wear them out. They do a huge job, but they only hear about problems, and we tend to not thank them as often as we should. I've worked with both Nils and Chris and realize what a HUGE task the librarianship is.

I think the central librarian is a great way to handle a sweeping change like adding an Extender Section to every extender RDFs. I also like knowing that there is one central person that I can tap on the shoulder and say, hey we have a problem with this set of RDF's instead of having to figure out who did which RDF. I don't REMEMBER who did which remote, although I do know which ones are yours, simply because we've both been working on extenders during the same time period.

[unclemiltie]

unclemiltie,If you're opening up the Atlas extender 2.10, please don't forget that the FAV key is not working. While I'm still struggling with something else I'm doing wrong there in another thread, the FAV issue is an older one and it would be great to be able to use it just as in 8910, 15 5-button sequences, whatever they may be (not just channels).

Really? That wasn't something that I was aware of. Can you email me a setup that doesn't work and tell me what's wrong with it?

(and if that's the case, I suspect that it's the same issue with all of the other JP1.3 extenders since they share the same code)

Liz, you should have my direct email, if you don't PM me and I'll remind you

[ElizabethD]

Bill, I've PMd. The address of yours I have I think is obsolete.

Re:FAV - I tried a minimacros approach that I read about.
For instance,
mdavej suggested here (before his ToadTogs solution)
http://www.hifi-remote.com/forums/viewt ... 2364#72364
to create couple macros on F1 key for instance.
But that's impossible since IR won't allow duplicates.
Chaning commands on F1 key does not behave like FAV unfortunately.

Anyway I can mail you IR file and a upgrade which gets keys confused I wrote about in another thread.

[ElizabethD]

Please don't forget that the FAV key is not working........

The Atlas didn't come with an OFA type FAV key where you could program a list. It did come with multi-macros that execute a different macro every time the key was pressed.......Personally I like the FAV keys. If I redo my Atlas, I'll be adding FAV support.

Well, it looks like Bill's Atlas extender does have the FAV code working, after all, 'cause it's now running here I'm waiting for Bill to confirm some of the stuff I see.

[unclemiltie]

Well...

Liz found a real bug and one that is surprising that no one else has reported it in the past. The FAV support on the Atlas extender (and all of the JP1.3 extenders) just does not work. Simple coding mistake, but I can assure you that it never worked.

Amazing as this is a pretty widely used remote, so I guess that no one is using FAV.


I shipped a test version to Liz tonight that based on my testing with a remote appears to process fav right. But I don't use it, so she's gonna load up her config and put it to the real test... pointing it at something.

If all goes well, V2.11 of the Atlas extenders as well as updated versions of the other JP1.3 extenders will be released in the next 3-10 days.

[unclemiltie]

This fixes the FAV bug that Liz found on the Atlas and was present on all JP1.3 extenders written by me.

http://www.hifi-remote.com/forums/dload ... le_id=9371

[StillLearning]

Hi:

I seem to get -1 bound errors and no pre-defined devices macros when I load this new extender.


All of the device selection numbers are 4095. Red of course and the types all show <error>.

The Comcast version does not do this.

I am using the lastest RDF 1.32

StillLearning

[unclemiltie]

I can't check this, my Mac had a hardware failure this morning and I will be without it for a week or so as it gets fixed.

I could have built this without the device numbers zeroed, which I usually do.

If the 10 bytes starting at $60A are FF then I messed this up

This should not impact you, just set the devices to what you need and load the file.

If you really want to "fix this" you can edit the hex file and put all zeros in those 10 bytes and that will stop the error.

Sorry about that!

[ElizabethD]

Bill,
I just ran ExamDiff on your Atlas hex file in the distribution vs the last one I have from you.
$60A-$613 bytes are missing.
Everything else is the same. So since hex files are otherwise identical, RDF which I have obviously belongs.
So, if you wish I can put my entire 2.11 zip file in Diagnosis for people to use while you suffer from your broken computer.
My hex file

600: 33 41 33 33 33 41 33 33
800: FB 04 53 52 00 00 00 00
60A: 00 00 10 00 20 00
610: 30 00 30 00 01 0C 01 FF 00 00 00 0F 0F 00 00 00
620: 00 00 00 00 00 00

Distribution hex file

600: 33 41 33 33 33 41 33 33
800: FB 04 53 52 00 00 00 00
614: 01 0C 01 FF 00 00 00 0F 0F 00 00 00
620: 00 00 00 00 00 00

[StillLearning]

yupe,

If I edit the 3A33ext-notes.hex to match ElizabethD's version,
It returns back to the normal devices code of 000 no type errors and the default device macro defs are back in place.

Thx Liz... Sorry about the crash unclemilite.

[unclemiltie]

I took the hard drive out of the Mac last night and looked at the assembler source and indeed I had the conditional assembly flag that doesn't zero the devices turned on. (I was trying to figure out why Extinstall won't copy the ones from your original config and never turned it back off)

Anyway, on both the 3000 and 3033 files, if you add:

60A: 00 00 10 00 20 00
610: 30 00 30 00

On Liz' file the second line ran into the 614 default settings stuff, but they can be separate. Either will work.


you will be back in business. Until I can really boot up the Mac and then run the windows VM on it, I can't reassemble and generate new files. The Apple guys tell me it'll be about a week before the machine is back

[unclemiltie]

edited Extender distribution for both 3A00 and 3A33 extenders is now in the files section

Sorry for the inconvenience.

[xnappo]

Does the new extender fix the backlight problem? Even with my work-around of sending a discrete on in some of my macros, it sometimes seems to get messed up in 2.10 and require a battery pull.

Thanks,
xnappo