|
|
View previous topic :: View next topic |
Author |
Message |
epv
Joined: 23 Feb 2008 Posts: 8
|
need help with em4102.c manchester decoding |
Posted: Tue Mar 04, 2008 12:47 am |
|
|
Hi. I'm playing with an EM4095-based RFID basestation. (for reference, it's the Parallax/Grand Design one) As a sort of challenge, I wiped the Parallax-supplied code and have been trying to get the em4095.c/em4102.c drivers from CCS to work on it.
After a little work making it fit on the onboard 16f627A (ie, read-only, MOD tied to ground, pic has no CCP2, etc..) I feel like I have it close to working, but I can't get the decoding to work out.
The pulse widths measure almost perfect 32/64 clocks, header_search_4102() finds headers, etc, but decode_data_4102(data) fails to decode the data because the row-parity check fails; here is the 50 bit stream read from each tag (plus what i get if i read another 10 bits further) :
tag1: 00000111100000000110000000010110001101111110101111+0100011111
tag2: 00000010010001101010101001111011101111101100011101+0110011111
Both tags produce these respective bitstreams absolutely reliably, and with no tag present I get dribs and drabs of random noise with the occasional 9-ones header found, but nothing repeatable.
Are extra bits getting stuck in somewhere? I'm not really sure where to proceed from here. If I pretend the initial 5 0's are spurious, it still doesn't pass parity check.
If nothing else, it's certainly been educational...
eric
PCM compiler version 4.049;8/6/2007 (linux) |
|
|
kolio
Joined: 06 Feb 2008 Posts: 26
|
|
Posted: Thu Mar 06, 2008 9:10 am |
|
|
According EMMarin 4102 datasheet page 4 table and your sequence:
00000111100000000110000000010110001101111110101111
it will look like:
0000 0
1111 0
0000 0
0011 0
0000 0
0010 1
1000 1
1011 1
1110 1
0111 1
These are data nibbles, followed by even row parity bits and they are obviously OK.
But looking in em4102.c , we'll find a bit comparision expressions, in which I already stopped to trust!
As far as I remember there were already compliants about wrong bit comparision, weren't there?
So, try to use "^" instead of "==" or "!=" operators and write your own routine.
wish you luck |
|
|
epv
Joined: 23 Feb 2008 Posts: 8
|
|
Posted: Thu Mar 06, 2008 11:31 am |
|
|
kolio wrote: | According EMMarin 4102 datasheet page 4 table and your sequence:
00000111100000000110000000010110001101111110101111
it will look like:
0000 0
1111 0
0000 0
0011 0
0000 0
0010 1
1000 1
1011 1
1110 1
0111 1
These are data nibbles, followed by even row parity bits and they are obviously OK.
But looking in em4102.c , we'll find a bit comparision expressions, in which I already stopped to trust!
As far as I remember there were already compliants about wrong bit comparision, weren't there?
So, try to use "^" instead of "==" or "!=" operators and write your own routine.
wish you luck |
Yes, yes, thank you - I wasn't aware that bit comparison operations don't work, and wasted a couple of hours discovering that independently in trying to figure out why the parity was "failing" - with the != and == on bits eliminated, it works perfectly. Thanks! |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|