View previous topic :: View next topic |
Author |
Message |
pekka1234
Joined: 28 May 2017 Posts: 83
|
56bit hex code to decimal in pch? |
Posted: Sun May 28, 2017 12:28 pm |
|
|
Hello,
I am using PIC18F26J11 code with CCS/Pch 5.065.
I am geting data from Idsco RFID-reader.
It gives 57-bit binary code in Wiegand format.
Wiegand format is: one wire shows 1's, other wire shows 0's.
They give me 56 1/0 sequence.
The bits come in hex-code, but backwards.
I can convert code easy to ASCII-hex-format.
My customer wants it as decimal code.
I can't find the way to convert it, because it requires int64 format.
Is there way to convert hex-code to decimal format with this int32-compiler?
Can I use direct conversion from hex-to-decimal characters?
bin:001100100011100010011001001001011001101101000000 // wiegand code backwards
dec:1236337244714624
hex:046471324B3680
Regards Pekka |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9243 Location: Greensville,Ontario
|
|
Posted: Sun May 28, 2017 5:51 pm |
|
|
Ok... some issues to deal with..
Your BIN is only 48 bits, not 56 or 57...
There isn't anyway i can see that 48 bits can be 'recoded' into either of the hex or decimal values you show under it.
Perhaps you can give a real example (2 is better) of what your reader transmits ?
Jay |
|
|
pekka1234
Joined: 28 May 2017 Posts: 83
|
|
Posted: Mon May 29, 2017 2:16 am |
|
|
You are right I have removed unused bits
The original bits are:
00000010000010101001100110101101010001011001011001000000
and then the required hex:
0415335A8B2C80
Pekka |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9243 Location: Greensville,Ontario
|
|
Posted: Mon May 29, 2017 4:54 am |
|
|
well that's better. 56 bits and 4 hex characters but..
I can't see how that 56 bit data can become the 14 hex characters.
IE the 5th and 6th nibble of 4 bits is '9' ( 1001 = 9 ) yet there is no '9' in the hex number.
What I did was copy/paste into Wordpad, manually inserted spaces to better read the data. Whether you go forwards or backwards '1001' is '9'.
Jay |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19539
|
|
Posted: Mon May 29, 2017 8:00 am |
|
|
The card data is not a single number. Displaying it as such is pointless.
The original standard 26 bit Wiegand stream comprised a parity bit, a 'facility code' (8 bit), a card number (16bit), and then a trailing parity bit. To display this in decimal, you first check the parity on the leading 9 bits or the data, then if this is good, display a decimal number for the facility code (8 bits), then do a parity check for the next 17 bits, and if this is good, display a decimal number for the first 16 bits of this. So for a 26 bit stream, you would have a pair of numbers like:
234 21000
Where the first number is the facility number, and the second, the card number.
Now the layout for a 56bit stream, will depend on the application, and to display anything meaningful in decimal you would need to know this. Otherwise you will be displaying parity bits as if they are data. Classically a long sequence like this will have extra parity bits, possibly a floor ID, site ID, and then a card ID.
It is never standard to display Wiegand sequences longer than 26bit as decimal. The standard for 56bit is to remove the leading and trailing parity bits, and display the 54 bits between as a 14digit Hexadecimal number. This is why this standard is known as AG14 (for the 14 hex digits). Normally companies will then encode their own meanings into this, perhaps using the last six digits as the employee number etc.. |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9243 Location: Greensville,Ontario
|
|
Posted: Mon May 29, 2017 9:57 am |
|
|
Hay T
I made the 'assumption' that the 56 bits / 14 hex digits were the real data, say an ID (as it's an RFID reader..) so it should be easy to reverse order the bits, parse and then display the data.
On the surface, this is a pretty easy chunk of code to cut but....
It would have been nice to have a link to the mfr's product sheet to KNOW
what the 'data' format really is.
Jay |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19539
|
|
Posted: Mon May 29, 2017 10:27 am |
|
|
Except for the leading and trailing parity bits, it is the data.
However these bits are why online programs won't display the same data that is apparently there, since the nibble boundaries are not where one expects....
So remove the top bit and last bit (the parity bits), then code the number in hex.
0000 0100 0001 0101 0011
0 4 1 5 3 etc...
No reversal etc. It is the data required. |
|
|
pekka1234
Joined: 28 May 2017 Posts: 83
|
|
Posted: Mon May 29, 2017 1:37 pm |
|
|
Well, I have got the Idesco reader and three RFID tags from my customer.
I have not got any manufacturer's data.
Idesco is Finnish manufacturer and I am from Finland, but I have no contacts to the manufacturer.
So, I have no idea what first and last bits are.
I have only read and looked at data.
I have also the result.
Still how you can say it is easy to get decimal number.
Try it ! It needs int64 code.
Pekka |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Mon May 29, 2017 3:29 pm |
|
|
Post the model number of your Idesco reader. |
|
|
pekka1234
Joined: 28 May 2017 Posts: 83
|
|
Posted: Tue May 30, 2017 1:07 am |
|
|
It is Idesco model 7C20
It does't say anything to me, but I need not to know.
I know how it works.
There are two other chinese wiegand code readers which work well.
They give also 4-bit keypad codes.
The other will give 8-bit wiegand code.
The other will give 2*8 bit code.
It will gives first the code in inverted format, ie. 0 and 1 inverted and then right way 1 and 0.
Two reader/RFID devices of three different code readers must work at same time. The other code reader is outside and other is inside.
It is a door open system with internet connection.
Pekka |
|
|
|