Amstrad DRX-780i Sky Satelllite Box

[alanrichey]

IR Source files uploaded at:

https://www.hifi-remote.com/forums/dload ... le_id=6391

Protocol appears to be XMP - Device 49 - Sub-Device 32 (not supported in RemoteMaster)

Thanks in advance for any assistance.

Al

[The Robman]

Try this...
https://www.hifi-remote.com/forums/dload ... le_id=6392

[alanrichey]

Crikey, that was quick I'll send the codes to the 'customer'

Thanks

Al

[The Robman]

can we split the fee ???

[alanrichey]

If I'm ever in Chicago I'll buy you a beer

[alanrichey]

I never actually heard back from the original requester, but I have just had someone else ask for it and he tells me it works. Well done

I'm now trying to do an ADB 5800, closely related to the ADB 5810 experimental BIN file you uploaded. Unfortunately, as my Remote has broken and I am now using a widget, I don't have an IR.EXE file to upload for you. It is coming up with XMP-R, Device 42.19.

As the key codes are working, can we work out the device codes from just one waveform ?

Al

[The Robman]

If DecodeIR says the device codes are 42 and 19, you should enter 42 and 28 into RM.

[alanrichey]

Which Protocol ID ?

[The Robman]

same as in the Amstrad file

[alanrichey]

If DecodeIR says the device codes are 42 and 19, you should enter 42 and 28 into RM.

Is there a logic to that ? I notice that for the earlier Amstrad posting you changed 49.32 to 49.35

I now have an XMP/Dreambox with 26.0, what should I use for that ? Can I work it out ?

Al

[The Robman]

The first device code (which is really the 4th byte of fixed data) controls a byte that is pure device code, so there's no need to change anything (hence the 49 and 42 in earlier examples didn't change), but DecodeIR and RM both take different incorrect views of the second device code (which is really the 1st byte of fixed data).

The first nibble (1/2 byte) of this byte is the actual device code, the second nibble is a checksum that can be calculated.

RM treats the whole byte as a device code, so you need to enter a code value that sets both the device code and the checksum correctly. For the Amstrad this byte should be "23" so you would need to enter 35 in RM to set it correctly.

DecodeIR seems to know that the 2nd nibble is a checksum so it doesn't include it, but rather than just reporting 2 as the device code, which is the correct value, it seems to zero out the checksum nibble and then report the whole byte as a device code, so it changes the hex from "23" to "20" and then reports that as decimal 32.

However, to get the RM device code from the DecodeIR device code, you need to know the full hex. If DecodeIR reports 49.32, the 49 tells you the 4th byte is 0x31 and the 32 tells you that the first nibble is 0x2. The middle two bytes are always "0F 44" giving you hex "2x 0F 44 31"

Here's how you can calculate the "x" checksum:

1) convert each nibble (except for the checksum nibble) to decimal
2) ADD all the decimal values
3) subtract the result from 256
4) MOD it with 16 (ie, divide by 16 and keep the remainder)
5) convert the result back to 1 nibble of hex.

There is an outstanding request to get this XMP protocol synced up here:
https://www.hifi-remote.com/forums/viewtopic.php?t=10773

[alanrichey]

I've read this 6 times now and I'm still not sure I am with you

When you say that the first nibble is the device code, surely a nibble is limited to 0-16, whereas device codes seem to lie between 0-254 ?

Or is the nibble just part of the device code and they reverse engineer the checksum to get the rest of it ?

In your example of 49.32, giving a second device byte of 0x2 I see the logic, but with 42.19, as in a previous example, that gives a second device byte of 0x13. So how does that get translated to a single byte ?

Sorry, I must be missing something obvious

Al

[The Robman]

When you say that the first nibble is the device code, surely a nibble is limited to 0-16, whereas device codes seem to lie between 0-254 ?

A device code is whatever the engineers at the OEM company decide it is, so if they decide to use a nibble rather than a byte as a device code, so be it. I don't get any say in the matter. All I can do is describe what I see.

Or is the nibble just part of the device code and they reverse engineer the checksum to get the rest of it ?

You could look at it that way if you like, and that's certainly how RM currently views it.

In your example of 49.32, giving a second device byte of 0x2 I see the logic, but with 42.19, as in a previous example, that gives a second device byte of 0x13. So how does that get translated to a single byte ?

I created a spreadsheet that converts DecodeIR device codes into RM device codes the other day. I'll load it up later this afternoon. Hopefully it will help explain.

Sorry, I must be missing something obvious

There's nothing obvious about this stupid XMP protocol, so don't sweat it.

[The Robman]

In your example of 49.32, giving a second device byte of 0x2 I see the logic, but with 42.19, as in a previous example, that gives a second device byte of 0x13. So how does that get translated to a single byte ?

You keep the '1' and drop the '3'. To be honest, I don't know how DecodeIR comes up with the device codes that it does, so I was just speculating earlier. When I decode XMP learns, I always ignore what DecodeIR displays and decode the signal by hand so I know exactly what's needed, so that's how I come up with the real device codes. I then experiment with RM to see what I need to enter in order to generate the correct hex.

Here's the spreadsheet that I mentioned earlier...
https://www.hifi-remote.com/forums/dload ... le_id=6638

[alanrichey]

Is there something missing from it ? If I try and add a new line to the CALC worksheet it comes up with ?NAME###. Is DEC2HEX stored somewhere else ?