--- 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
>
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 Brendan Murphy●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
Reply by Tom Walsh●September 15, 20072007-09-15
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.
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?
>
> You might actually be able to do everything with an LPC2xxx and
> forget about the PICs.....
>
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)
> Thanks Richard,
>
> i will be using all these on single board. I have actually tried the
> spi master slave between 2 pic but i when i selected the 676 as
> slave and the 16f72 as master the first time i got the garbage value
> from the 676 and the next time what ever i was send to the slave was
> got back. so the problem was that in this process i could not send
> the code which was there in the 676 ram one by one.i think becos in
> the slave spi mode you can put some data in the send register of the
> slave. i donot know there could be an error on my part . this is the
> reason i was looking to the i2c . does any have any code on i2c on
> lpc2294 which could save me some hours.
>
> Thanks
>
> jitender singh saggu
>
NXP has posted some example code to the Files section here. It isn't
targeted for the 2294 but it would be a good place to start.
For SPI, it is common for the first byte clocked out of the master to
receive either 0xFF or 0x00 from the slave. The real data from the
slave comes on the second byte sent from the master.
You might try having the SPI output register at the slave prepared to
send 0x00 when it is first clocked. Then on the SSPIF interrupt, grab
the real data byte and put it in the output register for the next byte
clocking. There is some useful information in the PICmicro Mid-Range
MCU Family Reference Manual.
There are a lot of options when setting up SPI concerning polarity,
edge and sample point. Getting this straight may take a little work.
Still, SPI is going to be a lot easier to implement. Getting slave
I2C to work on the PICs will take a lot of effort.
You really need a logic analyzer to view the clock and data lines.
You can save days of troubleshooting with a simple picture. It is
absolutely required if you try to implement I2C! I have never gotten
I2C to work without one.
Reply by Brendan Murphy●September 15, 20072007-09-15
--- 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
Reply by jssaggu●September 15, 20072007-09-15
--- In l..., "rtstofer" wrote: >
> --- In l..., "jssaggu" wrote:
> >
> > --- In l..., Tom Walsh wrote:
> > >
> > > jssaggu wrote:
> > > >
> > > > Good morning veryone,
> > > > i want to interface weigand reader to the lpc , since the reader > > works
> > > > on serial protocol and any reader could send data at any time , > > the
> > > > data could be lost , can any help me in this regards.
> > > >
> > > As far as I recall, weigands do not work on a serial protocol,
> > they
> > > merely emit data in a serial fashion. They are very simple
> > devices
> > > using a hall-effect and a magnet to sense embedded iron wires in a > > > plastic card. With the ones we worked with, we
had a single output > > (data
> > > + ground). The idea was to collect the pulse train, then do a
> > > post-analysis on it. This was due to the fact that the data pulse > > rate
> > > was governed by how fast or slowly you swiped the card.
> > >
> > > Pretty simple stuff actually.
> > >
> > >
> > > TomW
> > >
> > >
> > > --
> > > Tom Walsh - WN3L - Embedded Systems Consultant
> > > http://openhardware.nethttp://cyberiansoftware.com
> > http://openzipit.org
> > > "Windows? No thanks, I have work to do..."
> > > ----------------
> > >
> > Thanks TomW
> > what the problem i am actually facing is i have made weigand serial > > protocol reader with pic 16f676 becos i want to
connect 8 nos of
> > reader to lpc i tried the master slave connection to 8 nos of 16f676 > > but in order to get the data from the 676 they must
become master > > and lpc 2294 to slave which i was not able to
design becos how the 8 > > master will be driving the lpc. Then i decided to
connect through a > > parallel bus and using 74ls138 selecting the each
676 by rotation. > > but now the problem is driving fanout of the 676.
now i am looking > > for the i2c connection but i donot know will it be
successful.
> > can u suggest ?
> >
> > Thanks
> >
> > jitender Singh saggu
> > I2C will work fine but there is a lot of code to write just to service > the state machines. That's not necessarily a
bad thing because for
> the PICs, the code will be identical. I2C is nice because it contains > an address for selecting a specific PIC. I2C is a
PITA to debug
> unless you have a logic analyzer.
>
> However, SPI should work just as well. There is no need for the PIC > to become a master. The LPC does have to do
something for the SS'
> input of each PIC.
>
> You need to have some protocol between the master and the slaves to
> determine whether data is present (return 0x0 if not?) and how much
> data to transmit. I don't know anything about the Weigand end of this > so I don't know how long a message might be.
>
> You will also need to pause the SPI between bytes to give the
> addresses slave time to retrieve the information. The slave should
> probably get ready to send the first byte as soon as it is selected. > You would usually clock a byte of 0xFF to the slave
and then on the
> next byte clocked to the slave, the slave would begin delivering data. >
> Something like that...
>
> Now, if these gadgets are located a long distance apart, I would just > implement an RS485 network and call it a day:
> http://www.bdmicro.com/code/robin/
>
> Richard
> Thanks Richard,
i will be using all these on single board. I have actually tried the
spi master slave between 2 pic but i when i selected the 676 as
slave and the 16f72 as master the first time i got the garbage value
from the 676 and the next time what ever i was send to the slave was
got back. so the problem was that in this process i could not send
the code which was there in the 676 ram one by one.i think becos in
the slave spi mode you can put some data in the send register of the
slave. i donot know there could be an error on my part . this is the
reason i was looking to the i2c . does any have any code on i2c on
lpc2294 which could save me some hours.
Thanks
jitender singh saggu
Reply by jssaggu●September 15, 20072007-09-15
--- In l..., "mjames_doveridge"
wrote: >
> --- In l..., "jssaggu" wrote:
> >
> > Good morning veryone,
> > i want to interface weigand reader to the lpc , since the reader works > > on serial protocol and any reader could send data
at any time , the > > data could be lost , can any help me in this
regards.
> >
> > Thanks
> >
> > Jitender Singh
> > If these devices just emit serial data at a variable rate, as
> suggested by others, could you not just use the 8 capture interrupts? > I ask because one of my projects has a similar
requirement: 8 flow
> meters that issue serial data at a variable rate. If there is some
> problem with this approach, could yourself or one of the other more
> experienced developers help me and explain it before I head down a
> black hole?
>
> I am a Windows developer now struggling with these little chips, and I > need all the help/hints/advice I can get
> Rgds,
> Martin
> 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
Reply by mjames_doveridge●September 14, 20072007-09-14
--- In l..., "jssaggu" wrote: >
> Good morning veryone,
> i want to interface weigand reader to the lpc , since the reader works
> on serial protocol and any reader could send data at any time , the
> data could be lost , can any help me in this regards.
>
> Thanks
>
> Jitender Singh
>
If these devices just emit serial data at a variable rate, as
suggested by others, could you not just use the 8 capture interrupts?
I ask because one of my projects has a similar requirement: 8 flow
meters that issue serial data at a variable rate. If there is some
problem with this approach, could yourself or one of the other more
experienced developers help me and explain it before I head down a
black hole?
I am a Windows developer now struggling with these little chips, and I
need all the help/hints/advice I can get
Rgds,
Martin
