Zaptor checksum (Motorola VIP1903)

theforcedk · Post by **theforcedk** » Sun Oct 05, 2014 8:42 am

Hi everyone

So I'm trying to get into the IR world and spent a great deal of time reading various posts here. I know this is not directly related to JP1, but I hope that I can contribute back when I get a bit more knowledgeable in the area.

I've come to the point where I need to figure out how to calculate the checksum/reverse it (?) for my remote in order to understand the protocol (good experience for me to learn this). I have recorded the signals from my Zaptor remote (top-set box: Motorola VIP1903), they look like this, for example button 1 and 2. 3 bursts are sent with a 73800 uS space in between.

button 1
00010000000000000101100101010100 - h: 0x10005954
00010000000000000101100101010100 - h: 0x10005954
00010000100000000101100101011100 - h: 0x1080595C

button 2
00010000000000000110100101010100 - h: 0x10006954
00010000000000000110100101010100 - h: 0x10006954
00010000100000000110100101011100 - h: 0x1080695C

According to this page: https://www.hifi-remote.com/wiki/index.php?title=Zaptor

The checksum is calculated using (if I understand correctly): (D:4+D:4:4+S:4+S:3:4+8*T+F:4+F:4:4+E)&15

But I'm unable to figure out what the different parts mean in the above, so I can try and do it myself in whatever language - not that important, I can adapt.

Can someone explain to me how the calculation is done?

Thanks for reading

3FG · Post by **3FG** » Sun Oct 05, 2014 11:13 am

The complete IRP specification was documented by mathdon, and can be found in the Wiki under Resources\IRP Notation. Vicky2003 has written an IR Protocol Primer, and part of it describes IRP notation in less rigorous terms, but of course with less precision. It is linked in the Wiki under JP1 Guides\Infrared Signals.
Also, the Wiki does not contain the latest version (2.44) of DecodeIR.dll documentation. You can get it by downloading RMIR or DecodeIR. There is a brief guide to IRP at the beginning of DecodeIR.html, intended for use in recalling some of the details. It includes this:

Bitfield: D:NumberOfBits:StartingBit. E.g. if D=47= 01000111, D:2:5 means x10xxxxx. D:2:5 = 10b = 2. ~ is the bitwise complement operator. ~D =10111000. Specifying the StartingBit is optional. D:6 is equivalent to D:6:0.

Post by **The Robman** » Sun Oct 05, 2014 11:22 am

The full IRP notation is

Code: Select all

UEI protocol: unknown
IRP notation: {36k,330,msb}<-1,1|1,-1>[T=0] [T=0] [T=1] (8,-6,2,D:8,T:1,S:7,F:8,E:4,C:4,-74m)+ \
              {C =  (D:4+D:4:4+S:4+S:3:4+8*T+F:4+F:4:4+E)&15}
EFC translation: MSB

The letters in the notation stand for:
D = device code (8-bits)
T = toggle bit (1-bit)
S = sub-device code (7-bits)
F = function code (aka OBC) (8-bits)
E = checksum seeding value (4-bits)
C = checksum (4-bits)

So looking at the first binary for button 1:
00010000 0 0000000 01011001 0101 0100

the device code is 16 (ie, 00010000)
the toggle is 0
the sub device is 0
the function code is 89 (ie, 01011001)
the checksum seed value is 5 (ie, 0101)

the checksum is a MOD(16) of all of those nibbles added together:

Code: Select all

 0001 - dev part 1
 0000 - dev part 2
 0000 - sub part 1 (including toggle)
 0000 - sub part 2
 0101 - func part 1
 1001 - func part 2
 0101 - seed
-----
10100 - result

The result is 20, do a MOD(16) on it and you get 4. Does that help?

More info here: https://www.hifi-remote.com/forums/viewtopic.php?t=12520

Post by **vickyg2003** » Sun Oct 05, 2014 11:37 am

I see that everybody is jumping in here. Getting started with IR can be very intimidating

My Infrared Protocol Primer (PDF) an article for beginners
https://www.hifi-remote.com/forums/dload ... le_id=6996

Mathdon's technical explanation of IRP in the wiki
https://www.hifi-remote.com/wiki/index.p ... P_Notation

Various Articles on IR Signals
https://www.hifi-remote.com/wiki/index.p ... ed_Signals

In addition, there is an excellent HTML packaged with RMIR called
Interpreting Decoded IR Signals.

theforcedk · Post by **theforcedk** » Sun Oct 05, 2014 12:03 pm

Hi again

Thank you very much everyone for your detailed explanations, that should get me in the right direction! I started using an Arduino, Analysir and a very big Google sheet. It's a lot of fun. Digging into an "unknown" protocol (it was when I first started anyway) is hard work, but a good experience.

spreadsheet screen shot

Barf · Post by **Barf** » Sun Oct 05, 2014 12:50 pm

theforcedk,

please have a look at the program IrScrutinizer. It implements the IRP notation and can compute and/or identify all the Zaptor signals for you. It also supports capturing and sending using the Arduino (of course, a suitable IR-LED and/or sensor is assumed).

Stinctly speaking, the definition of Zaptor contained in IrScrutinizer is not quite correct (does not get the ending sequence right). But that is easy to fix: change the text file IrpProtocols.ini (Zaptor protools are at the end) to read:

Code: Select all

[protocol]
name=Zaptor-36
irp={36k,330,msb}<-1,1|1,-1>([T=0][T=0][T=1],8,-6,2,D:8,T:1,S:7,F:8,E:4,C:4,-74m)+{C = (D:4+D:4:4+S:4+S:3:4+8*T+F:4+F:4:4+E)&15}[D:0..255,S:0..127,F:0..127,E:0..15]

and

Code: Select all

[protocol]
name=Zaptor-56
irp={56k,330,msb}<-1,1|1,-1>([T=0][T=0][T=1],8,-6,2,D:8,T:1,S:7,F:8,E:4,C:4,-74m)+{C = (D:4+D:4:4+S:4+S:3:4+8*T+F:4+F:4:4+E)&15}[D:0..255,S:0..127,F:0..127,E:0..15]

Post by **The Robman** » Sun Oct 05, 2014 1:03 pm

3FG wrote:The Wiki does not contain the latest version (2.44) of DecodeIR.dll documentation. You can get it by downloading RMIR or DecodeIR.

I have attempted to bring the wiki page for DecodeIR up to date, based on the changes described here, but if there were other changes not mentioned, they would have been missed.

theforcedk · Post by **theforcedk** » Sun Oct 05, 2014 1:17 pm

Barf, very nice, thank you - I'll check out the application. The calculations Robman posted seems to work, for most of the signals, but not for everyone. I'm unsure if this is actually a bug in my captures, but I just tried sending one of the "red signals" (Power signal), where my checksum calculation doesn't actually match with colum G, and the box picked it up just fine, weird!

Here's a link (sorry for the large image before): http://cl.ly/image/3m172M3U0b23

theforcedk · Post by **theforcedk** » Sun Oct 05, 2014 1:41 pm

For example, button 2:

Binary: 00010000000000000110100101010100

If I understand correctly, then 0100 (last 4 bits) is supposed to be the result of the checksum calculation below.

Code: Select all

0001 - dev part 1
0000 - dev part 2
0000 - sub part 1 (incl. toggle)
0000 - sub part 2
0110 - func part 1
1001 - func part 2
0101 - seed
-----------------------
10101 - result

The result is 21 and 21 mod 16 is 5.

The last 4 bits of the binary above is 0100 - I assume this is what I'm checking up against? - is 4 (decimal), not 5.

This works out OK for button1 which Robman calculated, aswell as other buttons in my sheet.

Link to Google sheet image

I'll do some more investigating.

Post by **The Robman** » Sun Oct 05, 2014 2:05 pm

You're not getting the last bit correct, the binary that you posted for the #2 button is:
00010000 00000000 01101001 01010100

whereas the correct binary is:
00010000 00000000 01101001 01010101

It's often hard to spot a logical 1 in bi-phase binary because the signal ends with "+1 -1 leadout" and the -1 and leadout merge into a larger off time.

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

theforcedk · Post by **theforcedk** » Sun Oct 05, 2014 2:19 pm

The Robman wrote:You're not getting the last bit correct, the binary that you posted for the #2 button is:
00010000 00000000 01101001 01010100

whereas the correct binary is:
00010000 00000000 01101001 01010101

It's often hard to spot a logical 1 in bi-phase binary because the signal ends with "+1 -1 leadout" and the -1 and leadout merge into a larger off time.

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

Hi Robman

Thank you. I see that our captures are not quite the same (mostly the last 0/1).. I'll try and figure out how to solve this when parsing the signal from Arduino.

Post by **The Robman** » Sun Oct 05, 2014 2:30 pm

what tool are you using to get your captures and how do you read that output?

Here's what a capture of the #2 button looks like when captured using a JP1 remote:

+2700 -1800; +600; -300 +300; -300 +300; -300 +300; +300 -300; -300 +300; -300 +300; -300 +300; -300 +300; -300 +300; -300 +300; -300 +300; -300 +300; -300 +300; -300 +300; -300 +300; -300 +300; -300 +300; +300 -300; +300 -300; -300 +300; +300 -300; -300 +300; -300 +300; +300 -300; -300 +300; +300 -300; -300 +300; +300 -300; -300 +300; +300 -300; -300 +300; +300 -74100;

logical 0 is -300 +300;
logical 1 is +300 -300;

the final +300 -74100; pair should really be +300 -300; -73800

theforcedk · Post by **theforcedk** » Sun Oct 05, 2014 2:55 pm

Hi Robman

Hmm, you're right - but, this appears not to be true for button 2 (probably others) in my end. Button 2 always ends with ~700 uS, whereas button 3 for example ends with ~330 uS. My exact Motorola model is vip1903cdb (note the CDB, Google has no results .. might just be internal version). It's a Danish box with firmware from a company called "Stofa" and the remote is also branded with the "Stofa" logo. The remote looks like Zaptor remotes (Google images: Zaptor remote), where the Zaptor logo is at the bottom, but instead it just says "Stofa".

I use Analysir to capture the data, but I've just tried the example sketch (IRrecvDump) from IRLib on button 2, which also ends in ~700 uS (see below).

I've uploaded raw data from Analysir + logic image below.

The mystery

Code: Select all

Decoded Unknown(0): Value:0 (0 bits)
Raw samples(52): Gap:54700
  Head: m2500  s1950
0:m600 s350	1:m300 s400		 2:m250 s400	3:m600 s700		 
4:m250 s400	5:m250 s400		 6:m250 s400	7:m300 s350		 
8:m300 s400	9:m250 s400		 10:m250 s400	11:m250 s400		 
12:m250 s400	13:m250 s400		 14:m300 s350	15:m300 s400		 

16:m550 s400	17:m250 s750		 18:m600 s700	19:m250 s400		 
20:m600 s700	21:m600 s750		 22:m600 s700	23:m600 s700		 
24:m600
Extent=25700
Mark  min:250	 max:600
Space min:350	 max:750

Decoded Unknown(0): Value:0 (0 bits)
Raw samples(52): Gap:7714
  Head: m2500  s1950
0:m550 s400	1:m300 s350		 2:m300 s350	3:m600 s750		 
4:m250 s400	5:m250 s400		 6:m250 s400	7:m600 s700		 
8:m300 s350	9:m300 s400		 10:m250 s400	11:m250 s400		 
12:m250 s400	13:m250 s400		 14:m300 s350	15:m600 s400		 

16:m250 s750	17:m600 s700		 18:m250 s400	19:m600 s700		 
20:m600 s700	21:m600 s400		 22:m300 s350	23:m300 s700		 
24:m600
Extent=25700
Mark  min:250	 max:600
Space min:350	 max:750

If you look at the capture, it's not actually logic 330/330 all through the data, but also 6xx/7xx, I decode these at HH and LL and 330/330 as H and L.

Here's the info I have for button 2:

Image of logic signal

Archive with raw data for button 2 (IRLib, LIRC and Pronto formats + RAW capture for button 3

Post by **The Robman** » Sun Oct 05, 2014 3:10 pm

As you can export the signal in Pronto format, you can use JP1 tools. For example, using IR.exe, I pasted in your Pronto code for the #2 button

0000 0073 0000 004E 005D 0043 0019 000A 000D 000A 000D 000A 0019 0016 000D 000A 000D 000A 000D 000A 000D 000A 000D 000A 000D 000A 000D 000A 000D 000A 000D 000A 000D 000A 000D 000A 000D 000A 0019 000A 000D 0016 0019 0016 000D 000A 0019 0016 0019 0016 0019 0016 0019 0016 0019 0A4F 005D 0043 0019 000A 000D 000A 000D 000A 0019 0016 000D 000A 000D 000A 000D 000A 000D 000A 000D 000A 000D 000A 000D 000A 000D 000A 000D 000A 000D 000A 000D 000A 000D 000A 0019 000A 000D 0016 0019 0016 000D 000A 0019 0016 0019 0016 0019 0016 0019 0016 0019 0A4E 005D 0043 0019 000A 000D 000A 000D 000A 0019 0016 000D 000A 000D 000A 000D 000A 0019 0016 000D 000A 000D 000A 000D 000A 000D 000A 000D 000A 000D 000A 000D 000A 0019 000A 000D 0016 0019 0016 000D 000A 0019 0016 0019 0016 0019 000A 000D 000A 000D 0016 0019 0024

Then I set the rounding amount to 300 and set Bi-phase to EVEN, which gave me this...

+2700 -1800; +300 +300; -300 +300; -300 +300; -300 +300; +300 -300; -300 +300; -300 +300; -300 +300; -300 +300; -300 +300; -300 +300; -300 +300; -300 +300; -300 +300; -300 +300; -300 +300; -300 +300; -300 +300; +300 -300; +300 -300; -300 +300; +300 -300; -300 +300; -300 +300; +300 -300; -300 +300; +300 -300; -300 +300; +300 -300; -300 +300; +300 -300; -300 +300; +300 -73200; +2700 -1800; +300 +300; -300 +300; -300 +300; -300 +300; +300 -300; -300 +300; -300 +300; -300 +300; -300 +300; -300 +300; -300 +300; -300 +300; -300 +300; -300 +300; -300 +300; -300 +300; -300 +300; -300 +300; +300 -300; +300 -300; -300 +300; +300 -300; -300 +300; -300 +300; +300 -300; -300 +300; +300 -300; -300 +300; +300 -300; -300 +300; +300 -300; -300 +300; +300 -73200; +2700 -1800; +300 +300; -300 +300; -300 +300; -300 +300; +300 -300; -300 +300; -300 +300; -300 +300; -300 +300; +300 -300; -300 +300; -300 +300; -300 +300; -300 +300; -300 +300; -300 +300; -300 +300; -300 +300; +300 -300; +300 -300; -300 +300; +300 -300; -300 +300; -300 +300; +300 -300; -300 +300; +300 -300; -300 +300; +300 -300; +300 -300; +300 -300; -300 +300; +300 -900;

Substituting for logical 1 and 0, I get this...
+2700 -1800; +300 +300; 0001000000000000011010010101010 +300 -73200;
+2700 -1800; +300 +300; 0001000000000000011010010101010 +300 -73200;
+2700 -1800; +300 +300; 0001000010000000011010010101110 +300 -900;

Fixing the final bit, and general cleanup, I get this...
+2700 -1800; +600; 00010000 00000000 01101001 0101 0101 -72900;
+2700 -1800; +600; 00010000 00000000 01101001 0101 0101 -72900;
+2700 -1800; +600; 00010000 10000000 01101001 0101 1101 -72900;

theforcedk · Post by **theforcedk** » Sun Oct 05, 2014 3:17 pm

Hi Robman

I'll try and convert your signal to the format I use, tomorrow, in my sketch (32 bit), eg:

0x10006954UL
space(73800)
0x10006954UL
space(73800)
0x1080695CUL
space(1)

.. and see if the box receives it. If it does, then I'm really confused, as it also accepts the signal I posted, which have different timings. I know there's some tolerance in there because of various things affecting the signal such as sunlight - but there's a long way from 750 uS to 330 uS.

Thanks a lot for following up on this.