15,902,879 members
See more:
Hi,
can anyone tell me what conversion rule is used to convert below numbers ?

0B2AA4CC > 0222646835
00AA62CD > 0005596219
0A24ACD0 > 0088232880

Both numbers are UID from EM Marine 125kHz ID card (probably EM4102),
left string is HEX number from existing DB and right string is gathered from USB card reader (HID device).

USB card reader should use 8H10D output, but it doesn't match when I try convert left number like:
C#
Console.WriteLine(BitConverter.ToUInt32(new byte[] { 0xCC, 0xA4, 0x2A, 0x0B }, 0));

I also tried to use little/big/middle endian, but no success.
Posted
Chris Ross 2 16-Dec-14 9:54am

I took a quick look at it, and at a guess the 'hex' number you show above is maybe a hex representation of a bit stream the device outputs? In the data sheet, notice that "Data can be codes as Manchester, Biphase or PSK" (page 1). I think it also carries a parity bit (page 5). Now, whatever device you are using to read the EM device probably handles the encoding/decoding ... but maybe it's up to you to strip the parity?
Sergey Alexandrovich Kryukov 16-Dec-14 10:34am
You need to understand the principle, which is quite simple, not the "rule". Programming is not done by formulas or grandmother's recipe.
—SA

## Solution 2

Write both values as hex, side by side, then as bits, e.g.
0B2AA4CC = 0000 1011 0010 1010 1010 0100 1100 1100
0222646835 = 0D455233 = 0000 1101 0100 0101 0101 0010 0011 0011

Do you see the pattern? The bit sequence is inverse (per nibble).

1) take the 8 digit hex number
2) convert each hex digit to the reverse bit sequence value
3) create a 10 digit decimal number from it
4) put all together 8-bit-hex > 10-digit-dec

[EDIT]
Some dense code to show the conversion working.
The nibbles to inverse are looked up by using the lowest nibble of the input value and shifting that input value right for each next nibble. The locked up value is then shifted left to the respective position and set into the target value.
C#
class Program
{
{ 0x0,0x8,0x4,0xC,0x2,0xA,0x6,0xE,0x1,0x9,0x5,0xD,0x3,0xB,0x7,0xF };
static UInt32 Convert8HTo10D(UInt32 val8H)
{
UInt32 val10D = 0x0;
for (int pos = 0; pos < 32; pos += 4, val8H >>= 4) val10D |= LOOKUP[val8H & 0xF] << pos;
return val10D;
}
static void Write8H10D(UInt32 val8H)
{
Console.WriteLine("{0:X08} > {1:D10}", val8H, Convert8HTo10D(val8H));
}
static void Main(string[] args)
{
Write8H10D(0x0B2AA4CC);
Write8H10D(0x00AA62CD);
Write8H10D(0x0A24ACD0);
}
}
This results in
0B2AA4CC > 0222646835
00AA62CD > 0005596219
0A24ACD0 > 0088232880
[/EDIT]

Cheers
Andi

v6
TheRealSteveJudge 16-Dec-14 10:42am
5*
Andreas Gieriet 16-Dec-14 10:44am
Cheers
Andi
TheRealSteveJudge 16-Dec-14 10:53am
You're welcome!
BillWoodruff 16-Dec-14 10:52am
+5 Brilliant ! Keep this up and the CIA is going to try and recruit you :)
Andreas Gieriet 16-Dec-14 11:02am
Thanks for your 5! That 8H10D seems quite common, but I did not find any description with a quick research. Since it is used in serial communication in connection with RFIDs, the bit sequence inversion might be rooted in that serial transfer (4-bits at the time, MSB/LSP first?). Wild guess.
Cheers
Andi

## Solution 1

The fact that two of the whatever-encoded values show the same decimal (?) result indicates no linear conversion is going on here. I assume you are going to need the device manufacturer's information on the internal formats.