Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
07/04/05 14:38
Read: times


 
#96521 - not necessarily error
Responding to: ???'s previous message
Sometimes it is better not to reject the data on occurence of a short "glitch".

This kind of encoding-decoding (Manchester, biphase, "FM") is common in RFID. In one of our projects, with my colleague, we concurrently implemented two methods of decoding - I measured the edges and rejected data on out-of-bounds times. He started a one-and-half-bit-time timer on an edge and then sampled the current level (well that was not classical manchester, there was a guaranteed edge transition at each boundary of bit and an extra in the middle to distinguish 0 from 1); he rejected bad data based on the higher level protocol violation only. On the same hardware, "his" algorithm resulted in twice as big reading distance than mine...

But back to your raw problem.
- 2 halfbit = "long", 1 halfbit = "short"
- in case of length violation reset to state A
- start in
A - waiting for synchronising long pulse, if high (10), goto B, if low (01), goto D
B - halfway through 0, waiting for low pulse. If long (01), emit 0 and goto D. If short (00), goto C
C - in between 00. Wait for short high pulse, emit 0 and goto B.
D - halfway through 1, waiting for high pulse. If long (10), emit 1 and goto B. If short (11), goto E
E - in between 11. Wait for shirt low pulse, emit 1 and goto D.

Off the top of my head, please check for sanity.

Jan Waclawek


List of 16 messages in thread
TopicAuthorDate
Decoding manchester with only capture in            01/01/70 00:00      
   the non-trivial excursion            01/01/70 00:00      
      Yes!            01/01/70 00:00      
         not necessarily error            01/01/70 00:00      
   A bit more about ...            01/01/70 00:00      
      Does this helps            01/01/70 00:00      
   Its not software Jim            01/01/70 00:00      
      Who's Jim?            01/01/70 00:00      
         well...            01/01/70 00:00      
   My example code            01/01/70 00:00      
   My idea used in past on 68332 TPU            01/01/70 00:00      
      It all becomes clearer            01/01/70 00:00      
   The answer....            01/01/70 00:00      
      problem in manchester decoding using pca            01/01/70 00:00      
      problem in manchester decoding using pca            01/01/70 00:00      
      problem in manchester decoding using pca            01/01/70 00:00      

Back to Subject List