Brendan Murphy wrote:
>
> --- In lpc2000@yahoogroups .com ,
> "jssaggu" wrote:
> > Thanks martin,
> > Actually weigand sensor transmit data on 2 line data1 and data0 so
> i
> > actually need 16 line for the sensors and the data on any of the
> > sensor can come at any time in the worst case all sensors
> > transmitting data to lpc simultaneously.
> > that is why i am using indepent pic to control each weigand and
> then
> > depending on protocol they will be transmitting to lpc.
> >
> > Thanks
> > jitender Singh saggu
> > Just as a matter of intrest, what is the highest equivalent bit rate
> that you'd be likely to see from one of the sensors?
>
IIRC, Wiegand uses 26bits (wires), they are either short or long wires.
There are two Hall Effect pickups, one is positioned to read the lower
half (clock) of the wires, the other pickup reads the upper half
(data). When a long wire is read, you get both clock+data, on a short
wire you only got the clock.
It has been a while since I'd messed with a Wiegand.
TomW
--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net http://cyberiansoftware.com http://openzipit.org
"Windows? No thanks, I have work to do..."
----------------
connecting 8 nos of weigand reader to lpc2294
Started by ●September 14, 2007
Reply by ●September 15, 20072007-09-15
Reply by ●September 15, 20072007-09-15
--- In l..., Tom Walsh wrote:
> Heheh, not that fast, Brendan. A Wiegand reader is nothing more
than a
> magnet and a Hall Effect sensor positioned opposite each other with a
> card slot in between. Think of the arrangement as a credit card
reader
> swipe. The plastic cards used in a Wiegand setup have are encoded
via
> iron wires sandwiched inside the card (plastic-wire-plastic). When
you
> swipe the card, the pickups read the presence of the wires as they
pass
> between the magnet(s) and Hall Effect sensor(s)
>
> How fast can you swipe the card?
>
> TomW
That's exactly my question.
How many transitions per inch?
How fast is the swipe likely to get (in inches/per sec)?
That'll give a figure for max transitions per sec.
I've no idea of the numbers, but say it's worst case 10,000 transitions
per second. Then.....
- timer interrupt every 50 usec (twice the bit rate)
- have the timer interrupt on an FIQ, to make everything a bit more
deterministic (and never disable FIQ)
- interrupt reads all the i/ps (doesn't matter much how many: say 16)
- if channel not idle, saves state of each channel (and current
interrupt count) in a separate buffer
- return, until next 50 usec tick happens
Say it takes 200 clock cycles to do all this (being VERY generous).
That's a good bit less than 10% of the available CPU at 60 Mhz.
Now, with all that spare CPU capacity, plenty of time in the background
to read all channel buffers, decode the sequence of bit transitions on
each channel, translate into data according to the encoding rules and
o/p the result somewehere.
Of course, I could be way out in the assmuption about transitions/sec,
but if I'm not I can't see why something like this wouldn't be feasible.
Thoughts?
Brendan
> Heheh, not that fast, Brendan. A Wiegand reader is nothing more
than a
> magnet and a Hall Effect sensor positioned opposite each other with a
> card slot in between. Think of the arrangement as a credit card
reader
> swipe. The plastic cards used in a Wiegand setup have are encoded
via
> iron wires sandwiched inside the card (plastic-wire-plastic). When
you
> swipe the card, the pickups read the presence of the wires as they
pass
> between the magnet(s) and Hall Effect sensor(s)
>
> How fast can you swipe the card?
>
> TomW
That's exactly my question.
How many transitions per inch?
How fast is the swipe likely to get (in inches/per sec)?
That'll give a figure for max transitions per sec.
I've no idea of the numbers, but say it's worst case 10,000 transitions
per second. Then.....
- timer interrupt every 50 usec (twice the bit rate)
- have the timer interrupt on an FIQ, to make everything a bit more
deterministic (and never disable FIQ)
- interrupt reads all the i/ps (doesn't matter much how many: say 16)
- if channel not idle, saves state of each channel (and current
interrupt count) in a separate buffer
- return, until next 50 usec tick happens
Say it takes 200 clock cycles to do all this (being VERY generous).
That's a good bit less than 10% of the available CPU at 60 Mhz.
Now, with all that spare CPU capacity, plenty of time in the background
to read all channel buffers, decode the sequence of bit transitions on
each channel, translate into data according to the encoding rules and
o/p the result somewehere.
Of course, I could be way out in the assmuption about transitions/sec,
but if I'm not I can't see why something like this wouldn't be feasible.
Thoughts?
Brendan
Reply by ●September 15, 20072007-09-15
A couple comments on Weigand and I2C for PICs.
First, it's "Wiegand", not "Weigand".
I work in the security industry, so I know a little bit about Wiegand (I
do mean a *little*). Wiegand indeed has two wires, one for 0 pulses,
the other for 1 pulses. It is an open collector bus, and it is rarely
more than a few kilohertz, although the actual low-going pulses can be a
little short for using a polled mode. These are not necessarily
straight off the read head, however. Many of the readers I've
interfaced to have active signal conditioning electronics.
Wiegand is more of an electrical standard than a format standard.
Typically a Wiegand word is 26 bits, but I've seen longer. We've done
several devices from HID that read track 1 and track 3 on a mag card,
and clock out more bits. Also, Prox card readers frequently output more
than 26 bits, especially the 37 bit format cards :)
Wiegand is typically used by alarm panels (there are probably other
applications, I've not had to worry about them). I've not had to mess
directly with panels, so I don't know how they work. Mostly I've
interfaced mag and Prox readers to our product (an intelligent lock with
an on-board database for 2400 users, that runs stand alone, or can
communicate with a server via RS-232, Ethernet, or 802.11bg, and handles
a keypad, mag cards, Prox cards, and some proprietary devices. They're
powered either by 6 AA batteries, or Power-Over-Ethernet (POE)).
Another common format is 'clock & data', which is also an open collector
type bus, but instead one line is a clock, and another data (how odd
they'd pick a name like 'clock & data' for that...). I've even written
some PIC code (gag a maggot... I hate PICs) that converts Wiegand to C&D
or C&D to Wiegand. While I won't post that code to the net, I will
share it via e-mail. I wrote it as a contractor before I went full
time, and I retain rights to it. There's actually both a PIC and an AVR
version, because I switched from one to the other (can't remember which
I did first).
I also have some slave mode I2C code that runs on a PIC18F4620, written
in C, using the Microchip C18 C compiler. It will be public domain, as
soon as I get around to putting it on my web site. If you want a copy,
email me, I'll get it to you sooner. Using the aforementioned code, I
have implemented a 4x3 keypad that also has a couple LEDs and a buzzer.
These are all managed through I2C, and can be set or cleared, their
status interrogated, etc. Keystrokes are buffered until read, yada yada
yada. I can't share that code, but it was a relatively small step to go
from the code I can release (written on my own time) to the keypad
code. While the keypad code is not in a production device yet, I've
beaten it up pretty hard, and it seems to be reliable (not for use in
life support devices, however).
I haven't looked closely, but the I2C code should be targettable at any
PIC part that has an MSSP. Since C makes a nice frame work for
expressing algorithms and methods, you could no doubt easily re-write it
in that disgusting excuse for an assembly language that a PIC has, and
target it at one of the more brain-dead PICs (which is to say, the
entire family).
If I had to interface "8 nos of weigand [sic]" (whatever the hell that
means), I'd first see if my power budget allows running the ARM7 at max
speed all the time, and see if you can indeed manage them with polling.
If I remember right, the typical low time of the Wiegand pulse was
around 1ms on the devices I interfaced to. At 60Mhz, using the timer on
the FIQ interrupt, you should be able to poll and debounce reasonably,
especially if you use Jack Ganslle's tricky little debounce state
machines. If not that, and you've got the capability, considering using
a small cheap ASIC and some VHDL code that effectively implements a
Microchip-style "interrupt on Port B change interrupt" (but be aware
that the PIC has some stupids about the port B change, and you can (and
will) miss interrupts. See their application notes),. but 16 bits wide
instead of 4. If you can't do that, considering using a MSP430 as a
front end processor, which (IIRC) has byte wide interrupt-on-change for
most of it's ports, and have it generate an FIQ to the arm. Or capture
it and clock it out using SPI (bleh), I2C (more betta), or a simple
clock and data scheme (easy, fast, simple).
Some of our people say that Wiegand is a dying market. Others say not
so, the legacy market will last for years and years. Personally, I
don't like protocols that aren't clean and definitive. Wiegand is
mostly certainly not that. While you can hang multiple readers on a
single bus, you can get collisions, and without a great amount of work,
you have to put same word-width devices on a given bus. I have no idea
if these alarm panels have multiple ports, or how they handle it. We
much prefer to do checksumming and error detection on the reader with
local error indication, and not forward unread cards to the panel or
server. I also prefer devices that allow me to interrogate them, so I
can do fault detection, remote configuration, and other fun stuff.
Wiegand is definitely a brain-dead one-way only protocol, which no error
checking beyond what the card (mag or Prox) itself provides (Prox cards
have self-check digits built in).
--jc
First, it's "Wiegand", not "Weigand".
I work in the security industry, so I know a little bit about Wiegand (I
do mean a *little*). Wiegand indeed has two wires, one for 0 pulses,
the other for 1 pulses. It is an open collector bus, and it is rarely
more than a few kilohertz, although the actual low-going pulses can be a
little short for using a polled mode. These are not necessarily
straight off the read head, however. Many of the readers I've
interfaced to have active signal conditioning electronics.
Wiegand is more of an electrical standard than a format standard.
Typically a Wiegand word is 26 bits, but I've seen longer. We've done
several devices from HID that read track 1 and track 3 on a mag card,
and clock out more bits. Also, Prox card readers frequently output more
than 26 bits, especially the 37 bit format cards :)
Wiegand is typically used by alarm panels (there are probably other
applications, I've not had to worry about them). I've not had to mess
directly with panels, so I don't know how they work. Mostly I've
interfaced mag and Prox readers to our product (an intelligent lock with
an on-board database for 2400 users, that runs stand alone, or can
communicate with a server via RS-232, Ethernet, or 802.11bg, and handles
a keypad, mag cards, Prox cards, and some proprietary devices. They're
powered either by 6 AA batteries, or Power-Over-Ethernet (POE)).
Another common format is 'clock & data', which is also an open collector
type bus, but instead one line is a clock, and another data (how odd
they'd pick a name like 'clock & data' for that...). I've even written
some PIC code (gag a maggot... I hate PICs) that converts Wiegand to C&D
or C&D to Wiegand. While I won't post that code to the net, I will
share it via e-mail. I wrote it as a contractor before I went full
time, and I retain rights to it. There's actually both a PIC and an AVR
version, because I switched from one to the other (can't remember which
I did first).
I also have some slave mode I2C code that runs on a PIC18F4620, written
in C, using the Microchip C18 C compiler. It will be public domain, as
soon as I get around to putting it on my web site. If you want a copy,
email me, I'll get it to you sooner. Using the aforementioned code, I
have implemented a 4x3 keypad that also has a couple LEDs and a buzzer.
These are all managed through I2C, and can be set or cleared, their
status interrogated, etc. Keystrokes are buffered until read, yada yada
yada. I can't share that code, but it was a relatively small step to go
from the code I can release (written on my own time) to the keypad
code. While the keypad code is not in a production device yet, I've
beaten it up pretty hard, and it seems to be reliable (not for use in
life support devices, however).
I haven't looked closely, but the I2C code should be targettable at any
PIC part that has an MSSP. Since C makes a nice frame work for
expressing algorithms and methods, you could no doubt easily re-write it
in that disgusting excuse for an assembly language that a PIC has, and
target it at one of the more brain-dead PICs (which is to say, the
entire family).
If I had to interface "8 nos of weigand [sic]" (whatever the hell that
means), I'd first see if my power budget allows running the ARM7 at max
speed all the time, and see if you can indeed manage them with polling.
If I remember right, the typical low time of the Wiegand pulse was
around 1ms on the devices I interfaced to. At 60Mhz, using the timer on
the FIQ interrupt, you should be able to poll and debounce reasonably,
especially if you use Jack Ganslle's tricky little debounce state
machines. If not that, and you've got the capability, considering using
a small cheap ASIC and some VHDL code that effectively implements a
Microchip-style "interrupt on Port B change interrupt" (but be aware
that the PIC has some stupids about the port B change, and you can (and
will) miss interrupts. See their application notes),. but 16 bits wide
instead of 4. If you can't do that, considering using a MSP430 as a
front end processor, which (IIRC) has byte wide interrupt-on-change for
most of it's ports, and have it generate an FIQ to the arm. Or capture
it and clock it out using SPI (bleh), I2C (more betta), or a simple
clock and data scheme (easy, fast, simple).
Some of our people say that Wiegand is a dying market. Others say not
so, the legacy market will last for years and years. Personally, I
don't like protocols that aren't clean and definitive. Wiegand is
mostly certainly not that. While you can hang multiple readers on a
single bus, you can get collisions, and without a great amount of work,
you have to put same word-width devices on a given bus. I have no idea
if these alarm panels have multiple ports, or how they handle it. We
much prefer to do checksumming and error detection on the reader with
local error indication, and not forward unread cards to the panel or
server. I also prefer devices that allow me to interrogate them, so I
can do fault detection, remote configuration, and other fun stuff.
Wiegand is definitely a brain-dead one-way only protocol, which no error
checking beyond what the card (mag or Prox) itself provides (Prox cards
have self-check digits built in).
--jc
Reply by ●September 16, 20072007-09-16
--- In l..., "Brendan Murphy"
wrote:
>
> --- In l..., "jssaggu" wrote:
> > Thanks martin,
> > Actually weigand sensor transmit data on 2 line data1 and data0
so
> i
> > actually need 16 line for the sensors and the data on any of the
> > sensor can come at any time in the worst case all sensors
> > transmitting data to lpc simultaneously.
> > that is why i am using indepent pic to control each weigand and
> then
> > depending on protocol they will be transmitting to lpc.
> >
> > Thanks
> > jitender Singh saggu
> > Just as a matter of intrest, what is the highest equivalent bit
rate
> that you'd be likely to see from one of the sensors?
>
> You might actually be able to do everything with an LPC2xxx and
> forget about the PICs.....
>
> Brendan
>
wrote:
>
> --- In l..., "jssaggu" wrote:
> > Thanks martin,
> > Actually weigand sensor transmit data on 2 line data1 and data0
so
> i
> > actually need 16 line for the sensors and the data on any of the
> > sensor can come at any time in the worst case all sensors
> > transmitting data to lpc simultaneously.
> > that is why i am using indepent pic to control each weigand and
> then
> > depending on protocol they will be transmitting to lpc.
> >
> > Thanks
> > jitender Singh saggu
> > Just as a matter of intrest, what is the highest equivalent bit
rate
> that you'd be likely to see from one of the sensors?
>
> You might actually be able to do everything with an LPC2xxx and
> forget about the PICs.....
>
> Brendan
>
