JP1 Remotes

[The Robman]

I've written a executor that should be able to send the signals that you need using just 2 variable data bytes. Do you have the ability to verify what the remote is sending and maybe make adjustments if the signal is incorrect? I ask because I have absolutely no expectation that this will work the first time and I haven't tested it.

The following zip file contains a KM upgrade, the PB file and a spreadsheet that shows how I'm looking at the data.

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

First off, I had to reverse your view of the data, so a 1 is now ON and a 0 is now OFF.

Separating the start and stop bits, the 12-bit signal looks something like this...

1-000000000-11

I can replicate the start bit by using a leadin pair of "+630 -0" and I can replicate the stop bits with a leadout time of +1260. However, that still leaves 9 data bits, so to reduce it to 8 I included the 9th data bit in with the leadout.

The 9th bit of the first 4 words is always 1, and for the rest of all the signals it's 0, so, the format of the first 4 words is:

1-00000000-011

and the remaining words:

1-00000000-111

To switch from format1 to format2, I had to change the leadout from "OneOn, -1260" to "-1890".

The 1st and 3rd bytes are constant, so I have hard coded them in the executor. The 2nd, 4th and 5th bytes are supplied via the variable data.

If you look closely at the data in the 2nd byte, bit2 is 1 for the 3 short signals and it's 0 for the 3 long signals, so I use this for that purpose in the executor.

You'll notice that bytes 6 thru 15 are all $FF for the "download" button, and you'll also notice that bit4 of the 2nd byte is 1 for the "download" button (it's 0 for all the others), so I use this to format the download signal in the executor.

Unfortunately, there's nothing to differentiate between the 2 "start" buttons so I faked something. I set bit0 of the 4th byte data for the 2nd start button in the KM data, then in the executor I use this to differentiate between the two, but I always reset it to 0 in executor.

6 of the bytes used for the two start buttons are constant, only 4 are different.

Hopefully this made some sense, so if it doesn't work, you can have a crack at fixing the executor in PB.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[Lonewolf]

Yes, I have a USB dongle to capture signals and I wrote a program to decode them; it would be neigh impossible to debug this thing without.

[Lonewolf]

Ok, after looking at the executor you sent me and coming up with a bunch of questions I decided to give it a shot anyway. Using E7 EA 55 as a test, the remote transmits:

[The Robman]

You see now why I asked for the complete list of hex codes earlier. Before I attempt this again, could you please post the absolute complete list of the hex codes that you need to replicate (and if the data in any of the bytes doesn't matter, mention which.

Where are you getting the data that needs to be sent? Are you aware of any rules encoded into the data? (eg, if this bit is a 1, that bit will always be a 0, etc)

I think there is something somewhere that expains all the register usage, etc but I don't recall where it is. It's all engraved in my memory so I don't really need it.

In this case, the $0146 routine doesn't know how long the complete signal is, because I'm pretending that this is a 1-byte signal with leadin (for the start bit) and leadout (for the stop bits) portions. I'm calling the $0146 once for ever byte that needs to be sent.

If you were to attempt to send the signal all at once, you would be limited to 10 bytes of data (ie, R03 thru R0C).

Here's a (from memory) list of all the relevant registers:

R00 - button press count
R01 - skip # of fixed bytes
R02 - don't remember
R03-R0C - protocol input data
R0D - minimum # of repeats required
R0E - carrier freq - part1
R0F - carrier freq - part2
R10 - # of fixed bytes
R11 - # of variable bytes
R12 - # of bits per fixed byte
R13 - # of bits per variable byte
R14-R24 - internal protocol data (this is where the burst pair times are stored)
R28-R2A - protocol control bytes
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[Lonewolf]

[The Robman]

How do you know what data to use? There must be a finite list of commands that you need to program into your remote.

How many bits/bytes are in each of the following:
<break> <command> <ID> <data>
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[Lonewolf]

Yes, I'm only putting a handful in the remote, but that list is constantly changing as I make tweaks. I don't even have a complete list of what I want in the first version of the remote put together yet; the data is coming from multiple sources and it's taking me a while to collect and organize it. I fully expect to still be working on this 6 months from now...

Oops, I forgot the <crc>. The long ones also have up to 10 additional <data> bytes plus another <crc>. Each "byte" is 9 bits long. Like I posted above,

<break> <command> <ID> <data> <crc> [<additional data> <crc>]

break: 11xxxxxx 0
command: 00nnnnnn 0
ID: 01nnnnnn 0
data: 10nnnnnn 0
crc and everything after: nnnnnnnn 1

Edit 1: Do you know if there's a flag that you can check to see if a button's still held down?
Edit 2: Wow, I just found your post in the Acer Keyboard thread, and I think it explains just about everything That post and the note about CALL 010AH / JRC a few posts up really should be in the assembler help file... I think R2C might help here.

/LW

[Lonewolf]

I got it! Since the 64-bit limit is not an issue if we call $0146 manually, I'll write an executor that takes up to 10 8-bit bytes, with the first byte telling it which prefix* to use and how long the data is. The executor will then add the lead-in, toggle R2C.2 as needed to make the 9th bit, and call $0146 after setting the data length registers appropriately.

* there are only 3 "prefixes" with the long data: "FF/0 38/0 7F/0 8A/0 crc/1 53/1 00/1" "FF/0 2B/0 7F/0 84/0 crc/1" and "FF/0 30/0 7F/0 8A/0 crc/1 00/1 00/1" The remaining data is at most 9 bytes long once these are removed.

To save space, I'll then write another executor that takes exactly 5 bytes, with the first byte telling it which break and 9th bit style to use.

By doing it this way, I will not need to use any key moves or macros thus making the 2-byte key move limit is a non-issue. This will also allow repeating as I can call $010A and loop as needed.

I think it's time for me to get coding

Is there a way to make it transmit LSB first? This way I can punch in exactly what it should come out as. I guess I could always RRC/RLC it myself if I really want this...

Oh, are any of the working registers reserved for anything? I noticed you started with W5.

/LW

[The Robman]

You can reverse the bits in the executor, but why waste code/memory doing that when you can do it in advance yourself? I can show you how to do it in Excel if you need.

W5 is the only scratch register that will survive a call to $0146, so if it's just some temporary work you can use any of them, but if you want the value to survive a $0146 call, you should use W5.

Also, regarding the keymove limits, you can always create "dummy" upgrades that have all the buttons that you need pre-coded, then you can do "key based" keymoves based on those upgrades (eg, copy the VOL+ button rather than entering hex codes).
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[Lonewolf]

Well, I got it working. Unfortunately toggling R2C.2 didn't work out so I had to do it the hard way, and I ended up writing 1 executor that handles both the short and long codes as both share about 85% of the code. I was hoping to make a "loader" protocol for the short codes to save key space, and I got it to JP to the actual protocol just fine, but it hard locks when it calls $0146. Do you know of any way to switch the running executor without reloading the key values? I.E. I need a dummy executor that tells the remote to load 5 command bytes for the key, and once they are loaded it switches to the real executor. For now I have the same executor loaded twice with the only difference being the number of command bytes it expects. It's 191 bytes long and I've uploaded it if you want to look at it. It's definately an art to do so much in only 192 bytes! I think I ended up rewriting it at least 12 times... Is there a reason everyone JP's to $0146 to end it? I just RET'ed and it seems to work fine...

Oh, is there a list of callable functions around here? I see a few references to $0161 and another one that's a delay loop, but I can't seem to find a list. I'm thinking about just dumping and disassembling the core code, but it would be nice to have a starting point.

/LW

[The Robman]

[Lonewolf]

[mr_d_p_gumby]