JP1 Remotes

John, FYI, I was lookiing at the 16 variable bits and assuming two 8-bit bytes it looks like the XOR is either FF or F7. That makes me wonder if there is a make and break command or maybe one bit changes between a one time and repeat frame.

That's only relevant if you are going to modify Nokia.

Tobinh, could you also learn the numerals with a sharp tap of the OEM key rather than hold the key down.

Your FF and F7 are MSB of course. If you look at the pattern of function numbers, I think you'll agree LSB will be cleaner once we're really encoding and decoding this.

I think once we see another value in the third or fourth function burst (which we need to if there are more than 32 total commands) I think you will see that two XOR values are no longer enough. What is happening in the second have of the check byte does not seem to be an XOR. But we're both just guessing from insuffitient data. We won't know till we see such signals.

Did you check my irp notation and do you agree with it?

To everyone else, sorry about the cyptic parts of my posts that shouldn't be understandable to anyone but Jon.

John, my previous post was sent before I saw your more detailed explanation about the relationship among the variable bits. I agree with your protocol definition and how it could be done in PB.

I also agree that its LSB and we don't have nearly enough data to reach conclusions.

It appears that you are right about the Menu command, the correct code is:


0000 006d 0000 000e 0023 0011 0012 002b 0012 0011 0012 0011 0012 0011 0012 0011 0012 001a 0012 001a 0012 001a 0012 002b 0012 0022 0012 0022 0012 0022 0012 0bf7

Any Ideas on how to capture the trackball code? it appears to transmit every time the ball moves a given distance. IE a flick of the ball will cause a transmission for each incriment of the encoder. (I Think....)


Does that give you enough samples and info? I would like to do more, but job is calling me.

Thanks a bunch.

Sharp press "1"

Does it look like a valid code? Still haven't changed batteries, don't have access.


0000 006d 001c 0000 0023 0011 0012 002b 0012 0011 0012 0011 0012 0011 0012 0011 0012 0019 0012 0011 0012 0011 0012 002b 0012 0022 0012 0011 0012 0022 0012 21a3 0023 0011 0012 002b 0012 0011 0012 0011 0012 0011 0012 0011 0012 001a 0012 0011 0012 0022 0012 002b 0012 0022 0012 0019 0012 0022 0012 0011

I'm going away for a week starting Friday. I probably won't have time to invent a protocol upgrade for this before then. I don't know if any of the others who often create new protocols want to take a crack at it.
A pure PB method as Jon and I discussed would make a rather big upgrade (long hex commands) and take either a lot of manual effort or some interesting Excel tricks to generate those hex commands. An S3C80 asm approach would be better but narrows the number of people who would know how.

For samples, I think we do need more. As described above there are parts of the redundancy rule we can't determine because certain bits that must vary in signals we haven't seen haven't varied in the ones we have seen.

Are you going systematically through the remote's physical layout? The OBC numbers are arranged as if they correspond to physical positions on a remote rather than logical function and they're all close together. We need to see some that aren't close numbers to the ones we've seen. Maybe physically far on the original remote will be far in OBC number.

As for the track ball, it sounds like to understand that you would need to learn it several times with very short ball motions each time and then see how they compare to each other and see what cleaned up versions of them do when transmitted.

Tobinh wrote:Sharp press "1"

I would have bet Jon was wrong about that, but this sample makes it look like he was right.

I still don't see how it explains the non XOR pattern in the check byte (that I thought was Jon's reason for expecting this). But it does look like a make/break bit as Jon predicted.

Hopefully we can get away with ignoring that feature after we understand it well enough. Most devices accept commands without perfect make/break.

I'll try to get a complete map. It may take me a day or 2 (I am Married) I also have a keyboard which I have not tried to decode yet. I'll try to have that to.

Tobin.

The way I decode the three 1 keys (now LSB first):

03 04 8B -first segment TAP
03 84 9B -second segment TAP
03 44 9B -original segmet

I agree, and it's disturbing for a few reasons.

The simplest of those issues to investigate would be answered by learning a short tap on the 0 key. I think short taps on 2 through 9 would be redundant with what we just learned from 1, but 0 should be interestingly different. A short tap on down arrow might also be interestingly different.

The most disturbing is that the hold signal STARTS differently than the tap signal. You'd expect it only to end differently. Is that real or is it a learning defect? What exactly is the learning device being used? (Real Pronto, which model? or what kind of imitation Pronto)

A Pronto TSU2000 was used to sample the code.

Batteries were charged on the pronto, but as I mentioned the OEM remote did not have batteries changed. The led on the remote appears strong, but that may not mean much. The learn distance was probably 5 inches. It did not work any closer than that.

On most of my learned codes I tried to make sure that I could learn it twice before moving on. I would say that my sucess rate was 60-80% Often the first time would fail, but most of the time the next two or three would be ok.

johnsfine wrote:The most disturbing is that the hold signal STARTS differently than the tap signal. You'd expect it only to end differently. Is that real or is it a learning defect? What exactly is the learning device being used? (Real Pronto, which model? or what kind of imitation Pronto)

I think maybe the repeating segment is the hold key, so it's really in this order:

03 04 8B -first segment TAP -Make
03 44 9B -original segmet _HOLD
03 84 9B -second segment TAP -Break

jon_armstrong wrote: I think maybe the repeating segment is the hold key, so it's really in this order:

The problem with that idea is a TSU2000 would have learned both the Make and the Hold when you do a normal long press. All those hold samples had just hold. Sometime you can get that effect by pressing the original remote key before the Pronto in learning, or pressing it before aiming at the Pronto. But I assume Tobin didn't do that and the effect wouldn't be this clean if he did.

I know the TSU2000 is a very competent learner. There was a big gap between the two tap segments, perhaps that confused it. The theory is that maybe there is a big wait after the make to see if its really being held. I think he was having problems getting "good" learns.

At any rate, we will know by just testing our decoding concept. Since he has the TSU2000, I may do that by manually editing the Pronto hex and see what happens.

Tobin, try to learn some intermediate presses. Press, slight hesitation, and then release. Learn it four or five times. Stick with the numeral 1 command for now. We are trying to sort through the basics.

Also what happens when you use the learned commands? From the Tap and from the original learned command, particularly if you hold the original commands down?

I must admit that I haven't used the pronto on the unit (Pronto at work, Unit at home)

Also keep in mind I am a technologically adept engineer, The remote was aimed, the button was pressed after the learn command was issued, however I don't have alot of experience on using the pronto software and may be unaware of some of the catches of this system, so any suggestion are welcome. Now that I am aware of the Make-Hold-Break issues, maybe I can try to get some of these sequences.

Is there any way to have the pronto record everything?