JP1 Remotes

The Robman · Posted: Thu Oct 13, 2011 5:21 pm Post subject:

It looks like you just re-loaded my file, I don't see your HCS08 code in there.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

vickyg2003 · Posted: Thu Oct 13, 2011 6:02 pm Post subject:

The Robman · Posted: Thu Oct 13, 2011 8:13 pm Post subject:

Nice, I got it this time. I have a suggestion as to how you might be able to save a few bytes. Given that you have to use a buffer byte for the checksum anyway, why not use DCBUF rather than DCBUF+8. Then, rather than supplying the seeding value in DCBUF+4, supply it in DCBUF.

If you think it's a good idea, I could re-arrange the S3C8 version so that the first byte is the checksum seed also.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

The Robman · Posted: Thu Oct 13, 2011 9:30 pm Post subject:

Well, I took a crack at changing both versions to use the 1st byte for the checksum instead. I have no idea if I got either of them right, but here it is:

http://www.hifi-remote.com/forums/dload.php?action=file&file_id=10019

and here's the protocols.ini entry for it:

vickyg2003 · Posted: Fri Oct 14, 2011 9:30 am Post subject:

I just tested the HCS08, it works and its smaller. Smile

The Robman · Posted: Fri Oct 14, 2011 9:32 am Post subject:

Cool. That saved 6 bytes from the HCS08 version and 3 bytes from the S3C8 version.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

vickyg2003 · Posted: Fri Oct 14, 2011 1:51 pm Post subject:

I tested the s3c8 version too, and that works as advertised as well.
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.

The Robman · Posted: Fri Oct 14, 2011 2:22 pm Post subject:

thank you
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

3FG · Expert Joined: 19 May 2009 Posts: 3367

I've been doing some work on DecodeIR, and this was one of the items on the To Do list. I prefer an approach different to the one proposed in this thread. Some background:
The GI 4DTV IR protocol has an error correcting feature which is usually termed a Hamming Code. If any single bit of the 12 bits of IR signal is wrong, the scheme detects the error and allow the IR receiver to fix it. Rob described the pattern of bits that make up each parity bit while explaining an executor for this protocol.

The Robman · Posted: Sat Feb 08, 2020 7:00 pm Post subject:

THis is probably a question for 3FG, Barf or Mathdon, but I've been trying to figure out how the 4dtv signal matches up with the Hamming codes. I can see now that what I was calling a "seed" value before was really just the missing bit of the unit code. But what I can figure out is how to make the right checksum generate using the info on the Hamming wiki page.

Obviously, one main problem when talking about binary is (a) are you reading it left-to-right or right-to-left, and (b) when you talk about positions, is the first position 0 or 1 ?

I have put together a spreadsheet here which has all the 4dtv codes that I know of, plus the 8 Shaw setup codes that Dave talked about in the last post. I can still generate the right checksum using my formula but not using the Hamming formula. You can see that I made two attempts, one assuming they were reading L-R and another R-L.

http://www.hifi-remote.com/forums/dload.php?action=file&file_id=25849
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

3FG · Expert Joined: 19 May 2009 Posts: 3367

Hi Rob,
The exact order of the bits isn't important; the key is that "Each data bit is included in a unique set of 2 or more parity bits". Here is a table that shows how to map your designation onto the wiki page:

Barf · Posted: Sun Feb 09, 2020 4:38 am Post subject:

FWIW, this is the IRP form used in IrpTransmogrifier (and thus IrScrutinizer and RemoteMaster):

The Robman · Posted: Sun Feb 09, 2020 11:47 am Post subject:

I totally hadn't anticipated that the Hamming bits would be out of sequence, now that you've provided the bit labels I see that the formula exactly matches the one that I've been using. And regarding that extra virtual bit that is being used for the unit code, I would label that d11 as it needs to be in all 4 checksum bits.

Now that I have full clarity, I think my original proposal for this thread is valid. My hacked 4dtv executor uses just 1 variable bit, which limits us to 8 variable bits, so we need a way to supply that 9th bit, and that's what I was calling the seeding byte earlier. One option would be to just supply the one bit as fixed data, kinda like how the RC5 executor has one bit as fixed data, which would allow the user to mix and match unit codes within the allowed range. Or, I could have 3 bits of fixed data and 6 bits of variable, which would meet most people's needs.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

3FG · Expert Joined: 19 May 2009 Posts: 3367

I'm not at all clear what problem you're trying to solve. The GI [4DTV Official] entry in protocols.ini is already setup using the GI3 translator to provide 3 bits of unit number (device number) in fixed data, and 6 bits of OBC. That would seem to match your

The Robman · Posted: Sun Feb 09, 2020 4:43 pm Post subject:

I wrote the hacked version of the 4dtv executor back when we really tried to always have a single variable byte whenever possible, and just to see if I could. Kevin Timmerman made the first attempt where he calculated the checksum using assembler, but it was a complicated piece of code, then I came up with the idea of feeding the formula into the executor by way of the fixed data.

I was trying to find Kevin's original code when I stumbled back across this old thread, which led me to wanting to understand the Hamming connection. I am curious how you spotted the Hamming thing, what with the bits not being in sequence.

I disagree about always wanting to use official executors. Remember the ReplayTV and Tivo executors, but used 2 variable bytes unnecessarily, so we saved folks a lot of memory by making our own versions available, plus we added a lot of goodies into the ReplayTV exec. Do you recall the case of the Apex DVD player where you had to press a SHIFT button in order to get the arrow buttons to work? So we wrote an exec that would do that for you, and UEI even cloned it and make an official version. Even with 4dtv, the official exec unnecessarily uses 2 bytes where I was able to make a version that uses 1. I know remotes have more memory now, but there was a time when it was hard to squeeze everything in and that's where our homemade execs really helped.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!