JP1 Remotes

There seems to be a general dislike, shared by me, of IR "silently" changing data. That's why I put in a confirmation message. If the user says "No" to the cleanup, the Wav file generation exits. There is no way to "click away" the cleanup and so create an invalid Wav file, which seems to be one of Rob's concerns. If the user says "Yes" to the cleanup, the upgrade area is cleaned and the result is visible in the Raw Data page before you confirm (or cancel) the export itself.

By making IR put in a different checksum from that in the data file, IR.exe is using IRtoWAV to do something that cannot be done from command line use of IRtoWAV. I thought the point of linking IR.exe to IRtoWAV and ExtInstall was to make these easier to use, not to do something that they are otherwise not capable of doing. With my cleanup, you see and can save the cleaned file (again I emphasise that it is only the Upgrade area that is cleaned) and could use IRtoWAV from the command line to create the same WAV file.

If the objection is that the "garbage data" may not be garbage, just something that IR doesn't know about, then there is another option. Make the export contain not just the valid upgrades but also the garbage, i.e. extend the included data to the point at which the remainder of the upgrade area is filled with (an even number of) FFs. As the HCS08 remotes use an XOR checksum, it is unaffected by the omission of an even number of FFs.

There could even be, as Alain suggests, an Advanced option but not quite the one he suggests. The choice would be between (1) including the garbage data with no change to the content of IR, and (2) cleaning the upgrade area with the change visible to the user. I would make (1) be the default.

I really dislike the idea of a checksum going into the WAV file that cannot be seen in Raw Data. And no, it's not because I can't do it. I think it is the wrong thing to do. Rob thinks the IR data and the WAV file are two different things. My view is that the role of the WAV file is to copy selected data from IR to the remote. So you either copy it as it stands (garbage included) or after cleaning (garbage excluded), but in either case the data should be what is in the IR buffer. A different checksum would also make diagnosing WAV problems that much harder.
____________________

Graham

mathdon wrote:My view is that the role of the WAV file is to copy selected data from IR to the remote.

I think that's the root of where we disagree. My view is that the role of the WAV file is to let people, who don't have JP1 cables, add upgrades, etc to modem-equiped remotes.

I think you're looking at this as a technician whereas I'm looking at this from the point of view of the remote user. I can guarantee you that apart from maybe a few experts, nobody cares what data goes into the WAV files, just as long as they do what was expected. In fact, apart from Alain, myself and now you, I doubt that anybody else even knows what data goes into the WAV files.

So, if you're really objecting to re-calculating the checksum because you don't want to deny people the ability to see the value of the checksum that gets put into the WAV file, let's take a poll to see if there's anyone who really wants this, and count me as the first vote as someone who doesn't.

On the other hand, let's suppose there's a user who has some data in the upgrade section that appears to be garbage but really isn't, and let's say that this user wants to generate a WAV file for a friend. Under your option he's going to have to save a copy of his IR file before generating the WAV file and then re-load his original file afterwards, assuming he fully understands that IR is going to corrupt his data. And that's also assuming that he knows that the "garbage data" isn't really garbage. If the data was just something that none of us understood yet, he wouldn't find out that the data was needed until after generating the WAV file and his remote stopped working.

If you really feel strongly about this, and it sounds like you do, here's another idea. You could create a new pop-up option which would let people see the contents of the WAV file that they just generated, somewhat like the pop-ups that we use to edit upgrades and learned signals. Be aware though that the only time anybody is ever likely to use this pop-up is if there's a problem with the WAV files, like the one that you just fixed with the HCS08 WAV files, I can guarantee you that regular users won't need it.

Changing the subject a little, is there anyway that the IR2WAV functionality can be built into IR itself, as this would eliminate the need for a java install in order to use this feature.

At some point I'm going to integrate IR2WAV into RMIR, so if someone is going to port IR2WAV to something other than java, please keep that in mind.

Couldn't you incorporate the current IR2WAV java code into RMIR?

Yes, but I'm worried that if IR2Wav gets incorporated into IR, the incorporated version is the only one that will get updates, and then the Java version will become obsolete.

From the way Alain describes it, there shouldn't be any need to update IR2WAV in the future.

The Robman wrote:let's take a poll to see if there's anyone who really wants this, and count me as the first vote as someone who doesn't.

I second that. I think altering the upgrade section is far more dangerous than calculating a checksum on the fly, especially if it means adding yet another possible question dialog in IR to scare the average user.

Sure, but once it get's integrated into IR, it'll have access to the parsed RDF parameters, and then it would be possible for the IR2WAV function to do remote-specific things such as generate a special checksum for upgrades differently than the checksums that are calculated for the EEPROM image.

I'm just trying to stay involved and get the rest of ya'll to keep RM and RMIR in mind whenever anything gets changed or even proposed as a change.

OK, I concede to the will of the majority. The checksum for an HCS08 WAV upgrade file will be calculated on the fly during file generation and its value will be inaccessible to the user. This will be in Beta 7. I had hoped to move from Beta 6 to a general release but I think this necessitates a new Beta version. I regard this as a bug fix. I still don't want to add any new functionality before a general release of IR 8.00.
________________

Graham