Hardware
Willow Brugh
of additional places to look into?
Ron Bean
#5100 with good results. It's designed for retrofits, and works with
metal doorframes. Cost is about $100. I've seen cheaper ones, but they
only work with wooden doorframes.
Ron Bean
>of additional places to look into?
What do you have so far?
Loki (BrainSilo)
panic bar exit door strikes, let me know. Right now, I see em going
for around $400 each. For standard door strike plates, we've been
using whatever comes cheapest - usually off-brand ebay stuff for
around $20-$30/ea.
Loki
On Oct 23, 5:14 am, Ron Bean <bucketwo...@rbean.users.panix.com>
wrote:
james sweeney
system. While cheap strikes have some upsides, they tend to be
electromagnetic and have fairly high electrical requirements.
Our initial system here at Workantile Exchange used just that kind of
strike.
We found later on that, despite their higher initial cost, solenoid
driven strikes were were the $80-$100 price tag for two reasons:
1.) they can be powered via Power over Ethernet, allowing us to run a
single cable for all data / power needs
2.) they're more durable. They're tested to higher specs and have
longer service life.
Lokkju Brennr
solenoid strikes. I've had no problems running passive PoE for power
purposes so far. We actually only have three doors that need strikes
- two regular, which we current have strikes for, and then the sort of
odd one, that needs to surface mount on a panic bar exit door.
I'm currently using a dorkboard (low cost arduino board - about $10
total) with a small custom perfboard circut on it for the actual
access control and strike relay trigger, and it talks to wiegand RFID
readers. Up to 200 hashed RFID tag codes can be stored in the EEPROM
of each unit, and it has a serial control protocol to update the local
tag database. I really would like to use ethernet or xigbee - but the
cost is prohibitive for the circuits I've seen.
Loki
Patrick Callahan
the lines of price per door plus back end hardware.
Lokkju Brennr
for a controller that supports at least 100 tags/codes internally, can
control at least one strike plate/relay, and has a minimum of one door
sensor (say, open/closed door, etc) - and that includes some sort of
network/wireless communications back to a central server. I could be
dreaming here about the cost, but that's my target.
Loki
Lokkju Brennr
http://www.dclausen.net/projects/avr_ethernet/dclausen_ee281_writeup.pdf
james p sweeney
What are the purchase price / installation cost targets that others have?
James
Lokkju Brennr
readers support between 26 and 96 bits for the tag ID, but the huge
majority of tags are 26bit. Just take a 32bit hash of the tag id, and
store it. When reading the card, hash it's presented tag ID, and then
compare with stored ones. Network communications is best done on a
seperate VLAN, so encryption shouldn't be a concern there. As for
PoE, just use passive, not active, and you have zero added cost.
Loki // brainsilo.org
james p sweeney
As for "reasonable encryption", storing a hash locally works if you're not dealing with a centrally authenticated system. If you are dealing with a system with some sort of central authority (which the hackathon presupposes on some level) we need the ability to establish a secure channel through handshake of unknown parties, which requires more than simple hashing. And while we could hack together our own cryptographic setup, I'd prefer to spend the extra money on hardware that allows me to use some standard cryptographic libraries.
Really what this discussion seems to come down to is a question of audience: is this supposed to be a maximially simple hardware system for plug and play by the laity? or is it something more complex that requires a higher measure of comfort with wiring and coding to setup?
James
Lokkju Brennr
use injectors, otherwise, just use a switch the supports it.
Storing the hash locally is intended for offline use of the
controller, for when the space's central system is down.
I envision a multi-stage system:
each controller has a local database, and if the hash is int there,
the door is opened.
if the hash is not found, then the controller tries to contact it's
configured central server (if it has one) - this should be a local (to
the VLAN) system, so encryption isn't required - it could send either
the actual tag, or else a hash of it. The server can have multiple
auth modules - perhaps a local db with time based controls, as well as
the ability to connect into a multi-hackerspace shared auth system.
I much prefer to keep the door hardware, which you may need multiple
of, simple and cheap. Anything complex, like mutil-hackerspace auth,
or time based access, or anything else, should get offloaded to an
actual computer running an access control software suite - you only
need one to handle an essentially unlimited number of door
controllers.
As for the audience, I want the device to scale. If you use just one
or two, it has a local database that can be updated via ethernet. If
you have more, then you can run a central local server.
Loki // brainsilo.org
On Mon, Nov 29, 2010 at 9:36 PM, james p sweeney
Flemming Frandsen
> Passive PoE actually doesn't take much - if you are doing one or two,
> use injectors, otherwise, just use a switch the supports it.
This is what I do with outdoor Wifi gear all the time and our door controllers.
It's easy to find cheap switches that (less than $20) that can be
modded to provide passive PoE and at the same time be able to tolerate
the 24V I prefer for pPoE.
I did run into problems with too high voltage losses when trying to
power a hungry door strike directly over PoE, so in Version 2 I've put
in a 2.5A switch mode regulator so I can feed the door controllers on
unregulated 24V DC from SLA batteries and still get a stable 12V for
the strikes and the wiegand keypad/RFID readers.
> Storing the hash locally is intended for offline use of the
> controller, for when the space's central system is down.
This is exactly what we do, except, we havn't gotten around to needing
more keys than we have room for internally, so we run completely
off-line at the moment.
> this should be a local (to the VLAN) system, so encryption isn't required
Well, we use AES-256, which while overkill is an easy way to get peace of mind:)
> I much prefer to keep the door hardware, which you may need multiple
> of, simple and cheap. Anything complex, like mutil-hackerspace auth,
> or time based access, or anything else, should get offloaded to an
> actual computer running an access control software suite - you only
> need one to handle an essentially unlimited number of door
> controllers.
Agreed.
The total cost of our Version 2.0 was just around $35, including PCB,
excluding case.
Version 2.1 is around the same price, but it will not be built, at
least right now, due to the lack of ATmega328 at reasonable prices.
Version 3.0 is based on ATmega324 and will be slightly more expensive,
but still below $40.
I just finished laying out V3.0 last night and expect to fire a PCB
order at ITead some time next week: http://dc.osaa.dk
> As for the audience, I want the device to scale. If you use just one
> or two, it has a local database that can be updated via ethernet. If you have more, then you can run a central local server.
Yes, that's the idea, except, with Version 1.0 that has ATmega328's I
have 1k of EEPROM and that makes it possible to store 250 keys
locally, so far I'm not worried about running out of space:)
All the newer versions have external EEPROM, which starts out at 8kB,
so with room for 1600 keys I'll never run out of local space and might
even start using some of that space for logging.
The only reason to go online and talk to the master is to support
things like having time/day-limited keys or federated users.
--
Flemming Frandsen - YAPH - http://dren.dk/
Lokkju Brennr
That is an awesome design, and looks quite well though out. Right
now, my design, which doesn't support ethernet, and is done on a
perfboard, has a total part count of about 12 components... including
the perfboard and ATmega328. It works well though, and was put
together using nothing but scrap parts sitting around. After seeing
yours, I'll probably just switch to it, once you've tested your order.
What are you doing for firmware? Arduino, or straight C, or ASM, or?
Perhaps your code was on the page or in the archive and I just missed
it...
One thing to note that on my list of goals is to let members simply
use their own tags, if they already have them. Since your own tag
could be between 26 and 96 bits, normalizing the tag to a 32bit (or
larger) hash provides more than just the advantage of preventing
someone from duplicating all the ids in your database. I'd strongly
suggest always storing hashes, just like you would with passwords.
Loki // brainsilo.org
Flemming Frandsen
> The ones we currently have for our regular doors are 12v fail secure
> solenoid strikes.
We're using bolts similar to this:
http://cgi.ebay.com/Electric-Drop-Bolt-Door-Lock-Fail-Secure-/260598198179?pt=LH_DefaultDomain_0&hash=item3cacdcefa3
It needs a lot of power to actuate (like a couple of Amps for about
200ms), but it's easy to control using just a digital output because
it has a built-in driver.
... oh and it will unlock the door if presented with a powerful enough
magnet, I have an easy fix for that, though:)
> I'm currently using a dorkboard (low cost arduino board - about $10
> total) with a small custom perfboard circut on it for the actual
> access control and strike relay trigger, and it talks to wiegand RFID
> readers. Up to 200 hashed RFID tag codes can be stored in the EEPROM
> of each unit, and it has a serial control protocol to update the local
> tag database.
That's almost 100% the what we did for the ultra-fast hackish Version
1 we have in operation right now, except we used a tuxgraphics PoE
board and we update the EEPROM via Ethernet.
> I really would like to use ethernet or xigbee - but the cost is prohibitive for the circuits I've seen.
Well, I can't beat the $10, but I expect to be able to hit $40 with a
PoE solution.
The biggest advantage of Ethernet is that it's so incredibly easy to
interface with on the back end and the cabling is so easy, so I really
don't mind paying a bit extra to get Ethernet.
I did consider using CAN, but rejected it because I'd need something
up and running fast, so it's quite possible that I ought to revisit
that.
With CAN we could run several hundred kb/s at several hundred meters,
the driver is smaller than for Ethernet and the interface hardware
tends to be much cheaper as well, so it might be a win.
Lokkju Brennr
family have it built in...
What is the computer side interface like, cost wise?
Loki // brainsilo.org
Flemming Frandsen
> Flemming,
> That is an awesome design, and looks quite well though out.
Thank you.
> Right
> now, my design, which doesn't support ethernet, and is done on a
> perfboard, has a total part count of about 12 components... including
> the perfboard and ATmega328. It works well though, and was put
> together using nothing but scrap parts sitting around. After seeing
> yours, I'll probably just switch to it, once you've tested your order.
Well, we have a hackish version in operation right now and I have a
prototype of version 2.1 on my desk right now that works, so there
ought to be a good chance that it will work.
> What are you doing for firmware? Arduino, or straight C, or ASM, or?
> Perhaps your code was on the page or in the archive and I just missed
> it...
I haven't published the code yet, it's just standard C (C99 using avr-gcc).
The code contains hardcoded encryption keys, but I could take that
file out easily enough, so if there is any interest in the code I'll
publish it as it is.
I have not yet ported the code fully to V2/V2.1, so the two wiegand
interfaces don't do anything, but Ethernet and RFID works right now.
I'll probably abandon V2.1 and
> One thing to note that on my list of goals is to let members simply
> use their own tags, if they already have them. Since your own tag
> could be between 26 and 96 bits, normalizing the tag to a 32bit (or
> larger) hash provides more than just the advantage of preventing
> someone from duplicating all the ids in your database. I'd strongly
> suggest always storing hashes, just like you would with passwords.
Yes, that's what I do, I shift and XOR to get a single 32bit key for
each RFID+PIN pair, then store that:
rfid ^ (0xffff0000 & (pin << 16)) ^ (0x0000ffff & (pin >> 16));
The tricky bit is that the external RFID readers we use only give me
26 bit, no matter what the actual RFID contains.
The internal RFID reader is only limited by software, as long as the
RFID tag works at 125 kHz, you should be able to read it.
Lokkju Brennr
For hashing, I'm using a standard CRC32 implementation - it works, and
it's standard, so hey. We actually are planning on only using the
RFID, with PINs as emergency access. I guess it would make sense to
use both, but real security isn't really a priority for us - keeping
out people who don't know better is.
Interesting that your RFID readers don't send more bits - have you
made sure to try it with cards that are over 26 bits? All weigand
readers I've seen will support up to the 96bit max, but ill only send
as many bits as the card presents - we're using surplus IEI SlimLine
II's that someone gave us.
Loki // brainsilo.org
Flemming Frandsen
> CAN is interesting - I haven't played with it, but some of the ATmega
> family have it built in...
Yeah, but being an Atmel product those are probably not available for
actual purchase.
> What is the computer side interface like, cost wise?
I'd probably just use a pared down version of the door controller for
that, and stick an FTDI cable in the serial port on the board to get
USB access from the PC.
Using a door controller board as the CAN->Serial->USB interface also
means that it's easy to use the same unit as a controller for the UPS
and for charge monitoring.
Lokkju Brennr
but digikey has like 6K of them available at ~ $6/ea.
According to what I can see, the AT90 series should really just be
part of the ATmega series...
Atmel has a note for migrating from the ATmega to the AT90CAN:
http://www.atmel.com/dyn/resources/prod_documents/doc4313.pdf
Loki //brainsilo.org
Flemming Frandsen
> I'd be interested in the code, especially if it is in C.
I'll put it up on a public server soon, but I've attached a snapshot.
I've left out the config.c file so it will not compile out of the box,
but it only contains one function which has to return the AES key:
const unsigned char AES_KEY[32] = {...}
I also have some perl code that implements the PC side of the system
that I'll put up at the same time.
Notice that this code has been partially ported to Version 2 of my
hardware, Version 3 will be very different due to a completely new
pin-assignment.
> For hashing, I'm using a standard CRC32 implementation - it works, and
> it's standard, so hey. We actually are planning on only using the
> RFID, with PINs as emergency access. I guess it would make sense to
> use both, but real security isn't really a priority for us - keeping
> out people who don't know better is.
I'm also using CRC32, but only as a message integrity hash for the
encrypted packages as I was worried that crc32 would have too many
collisions with such a small input if used on the 8 bytes of RFID+PIN.
> Interesting that your RFID readers don't send more bits - have you
> made sure to try it with cards that are over 26 bits?
Yes, I'm quite sure, we got some out-door RFID readers not entirely
unlike this one:
http://cgi.ebay.com/RFID-125Khz-HID-compatible-reader-wiegand-26-bit-/180541816586?pt=LH_DefaultDomain_0&hash=item2a09217f0a
They only send 26 bits and will truncate the top bits, the USB reader
we have also truncates to 26 bits by default.
> All weigand readers I've seen will support up to the 96bit max, but ill only send
> as many bits as the card presents - we're using surplus IEI SlimLine
> II's that someone gave us.
Hmm, you are talking about something completely different here, the
common 125 kHz tags I've seen all talk EM4100 which is 32 bit + 8 bit
version/site number and all the tags I've seen have the version number
set to 0: http://www.priority1design.com.au/em4100_protocol.html
I've seen a few non-standard tags from HID that appear to send some
data on 125 kHz, but none of our readers will do anything with them
and they certainly don't speak EM4100.
Lokkju Brennr
> common 125 kHz tags I've seen all talk EM4100 which is 32 bit + 8 bit
> version/site number and all the tags I've seen have the version number
> set to 0: http://www.priority1design.com.au/em4100_protocol.html
>
> I've seen a few non-standard tags from HID that appear to send some
> data on 125 kHz, but none of our readers will do anything with them
> and they certainly don't speak EM4100.
So our SlimLine II readers, and many other HID brand readers (which is
what we always can get for cheap) support the full range of possible
bits - while 26bits is the "standard", 30, 34, 36, and 64 are common,
especially when dealing with site specific installations. See
http://www.hidglobal.com/documents/understandCardDataFormats_wp_en.pdf
. Even if the card does present 26 bits, you don't know for sure that
it is sending the standard pattern of parity/facility/id/parity. It
isn't really important, but if you want to be able to support any RFID
card, you have to think about it, and you should definitely not assume
that all readers will only send 26bits.
Loki // brainsilo.org
Flemming Frandsen
> What about the AT90CAN32? It looks very similar to the ATmega32M1,
> but digikey has like 6K of them available at ~ $6/ea.
> According to what I can see, the AT90 series should really just be
> part of the ATmega series...
Hmm, well, that could certainly work, though it's quite expensive
compared to the smaller ATmega328 that I started out with:)
... but being able to drop the super-expensive Ethernet parts would
more than make up for it and it has oodles of GPIO to spare.
This part is a much better fit and it's much cheaper:
http://atmel.com/dyn/products/product_card.asp?PN=ATmega32M1
The mega32M1 has a timer less than the mega328, but I bet I could make it work.
I use all 3 timers currently:
* Time out for end-of-message for the wiegand decoder.
* 125 kHz carrier wave for the on-board RFID reader.
* Input Pin Capture timing of de-modulated RFID data.
It might be possible to let the carrier wave and the timeout share a
timer somehow...
CAN is starting to look pretty good.
Lokkju Brennr
ATmega**M1 in stock...
Loki // brainsilo.org
Flemming Frandsen
> It isn't really important, but if you want to be able to support any RFID
> card, you have to think about it, and you should definitely not assume
> that all readers will only send 26bits.
Sure, as long as an external wiegand reader is used then any tag it
will read can be used, it's a very simple matter to simply hash
whatever data comes in from the reader.
... but so far I've seen two kinds of tags:
* EM4100 standard tags that work everywhere.
* Site-specific tags that don't work with anything other than the site
they were supposed to work with.
We were unlucky enough to buy some site-specific HID readers by
mistake and were not able to get any tags that work with them, so I'm
a bit put off by non-standard tags.
You are right though that the shiny new firmware for a door controller
ought to be able to handle any kind of tag length as long as it comes
in over wiegand.
Lokkju Brennr
to support the full range of cards, I'll ship you one... give me an
address off-list and I'll drop it in the mail.
Loki // brainsilo.org
Flemming Frandsen
> That is the one I first looked at, but no one has any of the
> ATmega**M1 in stock...
Oh? really?
http://dk.mouser.com/Semiconductors/Integrated-Circuits-ICs/Microcontrollers-Microprocessors/Microcontrollers-MCU/_/N-6j768?P=1z0y146&Keyword=ATmega32M1&FS=True
http://avnetexpress.avnet.com/store/em/EMController?action=products&catalogId=500201&storeId=500201&N=0&langId=-1&slnk=e&term=ATMEGA32M1-AU&mfr=ATL&hrf=http%3A%2F%2Foctopart.com%2Fpartsearch%2F&CMP=KNC-Octopart_VSE
A good solution might also be to switch out the Ethernet bits on my
Version 3.0 with MCP2551+MCP2515 and call it a day.
To sum up, these are the designs that are in play:
* Version 2.1: ENC28J60+ATmega328: Unobtainium, expensive due to
Ethernet, but debugged and ready to roll.
* Version 3.0: ENC28J60+ATmega324: Expensive due to Ethernet, but
debugged and well-stocked.
* Version 4a: MCP2551+MCP2515+ATmega324: Cheap, has all the timers and
is in stock, locally even.
* Version 4b: AT90CAN64: Kinda expensive (costs slightly more than
MCP2551+MCP2515+ATmega324), still cheaper than Ethernet, but very
beefy and well-stocked.
* Version 4c: ATmega32M1: Cheaper, but missing a timer, not
well-stocked, but still better than ATmega328.
I'll whip up a quick comparative BOM with prices for the major parts
soon, but I really like the flexibility of 4a, because the
MCP2551+MCP2515 combo is only about $4 and is easy to use with a lot
of different MCUs for other things that need controlling around a
'space.
Lokkju Brennr
show some in stock, cool!
Either way, CAN sounds like it may be a viable solution, that should
dramatically decrease the cost of the unit.
Loki // brainsilo.org
Flemming Frandsen
> Huh, the first link says non-stocked for me... but the second does
> show some in stock, cool!
wtf? I could have sworn I saw a couple of hundred in stock earlier...
I must be going insane.
> Either way, CAN sounds like it may be a viable solution, that should
> dramatically decrease the cost of the unit.
I'm getting kind fond of the MCP2551+MCP2515+ATmega324 combo, because
that way the MCU can be replaced with any other MCU beefy enough to do
the job and if it's only something simple like being a light
controller, then a really cheap ATtiny can do the job and still ride
the big CAN bus.
The power consumption of the CAN chips is much lower (more like 20mA
than the 200mA that the ENC28J60 sucks down), but the MCP2551
transceiver, wants 5V like most other CAN transceivers.
There are 3.3 V parts, Maxim makes one (the MAX3051) so we know that's
unobtainable, but TI makes the other one I found and that's in stock:
http://dk.mouser.com/ProductDetail/Texas-Instruments/SN65HVD232D/?qs=sGAEpiMZZMutXGli8Ay4kMj2H7jHcXU%2fZ1RCQHdPxvc%3d
... and there are tons of similar parts from that family at mouser.
It's starting to look like SN65HVD232D+MCP2515+ATmega324 could be a
winning combo.
Interfacing the CAN bus to the master server also needs a bit of
thought, an easy solution is to use one of the boards, hooked to the
PC with an FTDI cable an let it run a special CAN master firmware that
allows the PC to talk to the different boards via the usb-serial port,
it's not as portable as Ethernet, though.
An easy solution would be to put all the connections needed to run the
Ethernet interface on a header and make a daughter board with the
Ethernet interface on it, it would only cost one GPIO pin for the CS
signal, the rest of the SPI bus would be shared with the MCP2515.
Those daughter boards actually exist, they they are crazy expensive
and don't allow PoE: http://www.olimex.com/dev/enc28j60-h.html
Flemming Frandsen
>> Either way, CAN sounds like it may be a viable solution, that should
>> dramatically decrease the cost of the unit.
>
> I'm getting kind fond of the MCP2551+MCP2515+ATmega324 combo, because
> that way the MCU can be replaced with any other MCU beefy enough to do
> the job and if it's only something simple like being a light
> controller, then a really cheap ATtiny can do the job and still ride
> the big CAN bus.
If I wasn't already tooled up for AVR, then there are some seriously
nice, and well-stocked, ARMs around, like the LPC1768 used in mbed,
which has both Ethernet, USB host, USB device and CAN as well as the
nice, cheap parts from ST, like this one:
http://www.st.com/internet/mcu/product/221022.jsp
Sigh...
Lokkju Brennr
is ~$3.50. Right now STM is giving away free dev kits, if you jump
through a few hoops: http://www.stm32challenge.com/
Loki
Patrick Callahan
is the
cheapest!
Subject to available quantities on hand. Hurry up!
RFID Reader Module (Serial version only) comes with two 54x85mm
Rectangle
Tags.
Parallax price $39.99
http://www.parallax.com/StoreSearchResults/tabid/768/txtSearch/RFID/L...
Radio Shack price $8.47
http://www.radioshack.com/product/index.jsp?productId=2906723
On Dec 1, 5:44 am, Lokkju Brennr <lok...@gmail.com> wrote:
> That is sweet - part cost on the STM32F105R8 (slightly smaller flash)
> is ~$3.50. Right now STM is giving away free dev kits, if you jump
> through a few hoops:http://www.stm32challenge.com/
>
> Loki
>
>
>
>
>
>
>
Patrick Callahan
Parallax price $39.99
http://www.parallax.com/StoreSearchResults/tabid/768/txtSearch/RFID/List/0/SortField/4/ProductID/114/Default.aspx
On Dec 3, 9:20 am, Patrick Callahan <pmcall...@gmail.com> wrote:
> Stumbled into these today...For a bizarre change of pace Radio Shack
> is the
> cheapest!
>
> Subject to available quantities on hand. Hurry up!
>
> RFID Reader Module (Serial version only) comes with two 54x85mm
> Rectangle
> Tags.
> Parallax price $39.99http://www.parallax.com/StoreSearchResults/tabid/768/txtSearch/RFID/L...
Flemming Frandsen
> Stumbled into these today...For a bizarre change of pace Radio Shack
> is the cheapest!
For 125 kHz EM4100 tags a reader will cost under $2 in jellybean
components, provided you already have an AVR with a spare couple of
timers, so I'd advice against any sort of module for that.
My door controller includes the RFID reader: http://dc.osaa.dk
Craig
Flemming Frandsen
> I'm thinking something like this $25 keychain from sparkfun
Yeah, that's insanely expensive, not to mention huge.
> This could transmit additional lookup data.
The right way to solve that problem would be to use cheap r/w RFID
tokens, but those are still not nearly as easy to find,
well-documented and as cheap as the read-only tags.
Flemming Frandsen
> Either way, CAN sounds like it may be a viable solution, that should
> dramatically decrease the cost of the unit.
I've been doing some more research and it seems that modbus on RS-485
is the absolutely cheapest way to go.
Modbus is is basically a master/slave protocol, where the master
always initiates traffic by polling all slaves in turn, for something
like engine management or anti lock breaking where CAN is used that
would be terrible, but for our use it's quite ok.
The really nice thing about modbus is that there is a Free C
implementation that works on AVR and a ton of other platforms:
http://freemodbus.berlios.de/index.php?idx=32
RS-485 allows for 100kb/s out to 1200m which is plenty for a
lock-management system.
The RS-485 transceiver is the only piece of hardware needed for modbus
and those are pretty damn cheap and well stocked:
http://dk.mouser.com/Search/Refine.aspx?Keyword=SN65HVD11&Ns=Pricing|0&FS=True
I still think it's a good idea to use CAT5 and RJ45 cabling for modbus
and power as that will make it possible to reuse existing cabling for
Ethernet and it makes termination much easier.
There should probably be two RJ45 connectors connected in parallel to
allow easy loop-though of the bus, but those are cheap enough on ebay,
certainly right now:
http://cgi.ebay.com/60-pcs-RJ45-Modular-Network-PCB-Jack-56-8P-w-LED-Lamp-/260620022885?pt=LH_DefaultDomain_0&hash=item3cae29f465
I think I may be able to fit modbus onto the the board where I already
have Ethernet, but I may have to switch away from EAGLE to do that,
because it limits me to 10x8 cm, but PCB shop (itead) will do up to
10x10 cm at the same price, with the extra 2x10 cm I'll certainly have
plenty of space for both.
Royce Pipkins
The real problem is not whether machines think but whether men do.
B. F. Skinner
Simon Clark
http://www.maxim-ic.com/products/ibutton/ibuttons/
The North American Sales rep is somewhat open to supporting the community in some way if anyone is intrigued. And, if we buy 1000 ibuttons as a group, the price goes down to about a buck a piece.
Craig
Craig
Flemming Frandsen
> Funny, I've been using RS-485 on the Milwaukee Makerspace system and am now
> trying to incorporate Ethernet.
Yeah, there are many nice advantages to Ethernet, there are a few
downsides though:
* Cost (Ethernet transformer and ENC28J60 mainly)
* MCU Resources (Flash and RAM both gets gobbled up quite fast)
As RS-485 is so cheap and easy to support I'll probably just add it to
my door controller and let the user choose between Ethernet and
RS-485.
I have an ulterior motive for wanting to get into RS-485; We have
inherited a lot of alarm sensors in our space that aren't hooked up to
anything any more and it's a dream of mine to make a small RS-485
interface board that can be deployed in the existing sensors on the
existing bus, there are at least 8 sensors spread all over the place,
so it would get much too expensive and too much trouble to rewire each
one, to say nothing of the cost of getting all of them on the network.
> I used a simple home-brew protocol rather than Modbus. My experience from my
> time in the HVAC controls business is that there is that there in enough
> "tweaking" of that protocol that in practice it is not all that
> plug-and-play.
Yeah, I noticed that, I'm not entirely sure that using modbus rather
than an adhoc protocol has any advantages, because for this
application I'd never want to do anything other than exchange the same
16 byte datagrams that I currently transport on UDP.
> I run at 9600 to keep pesky termination issues to minimum. Its still plenty
> fast for a multi-door system. It will also take more of an EMI pounding.
That's a good point.
> I love your $2 jellybean RFID circuit, btw. I'd like to steal for my
> system. https://github.com/roycepipkins/MakerAccessControl
> http://milwaukeemakerspace.org/taxonomy/term/9
Please do, notice that there's still some performance to be had by
tuning the amplifier and the schmitt trigger, so remember to optimize
the amplifier gain to give the best result in your environment.
Flemming Frandsen
> We're building our system on iButtons. They fit on a keychain, very durable, contact read, and the hardware is pretty cheap. The seem like a better technology for the application at hand.
Yeah, we considered iButtons, but rejected it because we couldn't find
good, cheap out-door reader sockets.
... and it's a Maxim product, so I'm worried about being able to
actually buy any of them:)
... but, yeah, being r/w is pretty nice.
Spenser
communication. But... the chip below is only $9 available from
everywhere and has an open source tool chain. It will be painful to
solder but it gives us wireless, a keypad interface, and two serial
ports. If its decided that wireless is important, this may be the
chip to target.
http://www.newark.com/jsp/search/browse.jsp?N=500003+1001919&Ntk=gensearch_001&Ntt=mc1322&Ntx=mode+matchallpartial
Additionally, here is the tool chain and a dev board supplier.
http://mc1322x.devl.org/
http://www.redwirellc.com/store/ ~ $45
Spenser
On Nov 30, 6:08 am, Lokkju Brennr <lok...@gmail.com> wrote:
> That is the one I first looked at, but no one has any of the
> ATmega**M1 in stock...
>
> Loki // brainsilo.org
>
Katy Levinson
191 active members currently, so if the standard is set to only
support 100, we're not going to be able to participate.
On Nov 30, 4:08 am, Lokkju Brennr <lok...@gmail.com> wrote:
> That is the one I first looked at, but no one has any of the
> ATmega**M1 in stock...
>
> Loki // brainsilo.org
>
Lokkju Brennr
chip to one that has larger eeprom will fix the problem anyway.
Loki
Katy Levinson
Lokkju Brennr
will be stored on the actual device. When we talk about storing tags
on the device, it is in the context of a multi-tiered system:
1) RFID reader/door controller - microcontroller based, one per door,
cheap as possible, with some form of networkability (CAN, ethernet,
RS-485, etc). This is designed to store some (local) access token
hashes within it's own memory in case the network goes down.
2) an access/authorization server, 1 per location, that is just a
software app. This will manage pushing updates to the individual
microcontrollers, as well as handling A/A requests from the
microcontroller network, and either service them, or forward to other
(configured and enabled) authorization servers at other
locations/hackerspaces.
3) potentially, some form of peer-to-peer hackerspace authentication
network, that the server in step (2) can talk to.
Loki
Flemming Frandsen
> Can we please assume there will be more than 100 tags? Hacker Dojo has
> 191 active members currently, so if the standard is set to only
> support 100, we're not going to be able to participate.
My door controller design uses an external EEPROM for just this
reason, I started out with an 8 kB chip, but they come much larger
than that and can easily be stacked.
8 kB of EEPROM means that I have room for 2000 keys, so I don't expect
a lot of people will ever need to expand that.
Info about the different versions is here: http://dc.osaa.dk
I'm currently in the process of re-implementing the design in kicad,
to get beyond EAGLEs 8x10cm board size limit, that will allow me to
stick both Ethernet and RS-485 on the board.
The reason to use RS-485 is that it's much cheaper than Ethernet which
makes up around 30% of the component cost of a finished board.
Flemming Frandsen
standalone, cheap and reliable.
I also want to support keys that don't always have access, so I can do
things like allow the 15-17 year olds access only on week days or when
there are other members around, that sort of complexity is best
handled by a central server, so I want to make it possible to have an
on line mode as well.
The server that talks to the door controllers would not be the actual
member database system, at least not in my system, because that system
will need to talk directly to the door controllers and will sit in the
actual building, while the member database will live on a real server
in a datacenter somewhere else.
My tiering goes something like this:
* A number of door controllers
* connected via RS-485
* To a single space server, which handles logging and complex access
control rules.
* connected via REST on https via the Internet
* To a single user database which is located in a proper datacenter
with good connectivity.
Splitting the "space server" from the user database will also allow
you to have several space servers, if you have multiple locations or
if there are several different hackerspaces that share the user
database.
> 3) potentially, some form of peer-to-peer hackerspace authentication
> network, that the server in step (2) can talk to.
I'd much rather have either:
3a) A really well-run central user administration system which handles
payments via Paypal, VISA/MC and user-supplied plugins.
or
3b) An OpenID based data exchange protocol that allows one member to
easily copy his data into a new user administration system.
The use case of hopping between spaces is not something I'd expect to
be used a whole lot, so 3b will be hard to make work right.
Not having to deal with setting up a merchant account would be hugely
useful for everybody right away, so the 3a approach could take off big
time.
Lokkju Brennr
applicable. It might be interesting to look into using coova.net - it
is normally used for access points, but no reason it couldn't be used
for this. In fact, if we just made the per-location server support
RADIUS, you would have a wealth of options.
Loki
ducksauz
> I also want to support keys that don't always have access, so I can do
> things like allow the 15-17 year olds access only on week days or when
> there are other members around, that sort of complexity is best
> handled by a central server, so I want to make it possible to have an
> on line mode as well.
Along the same line, I think it makes sense to define a dictionary of
user attributes/authorizations. This could be used to specify what
pieces of equipment a member is trained on and ready to use. This way
you could control access to expensive and/or dangerous tools with the
same system.
Add an RFID controller to your laser cutter and it only turns on for
folks who have been trained on it. Such a system would also allow for
automated usage accounting.
If you don't want to be so draconian with access control to the gear, at
a bare minimum a monitor page could display all the users in the space
and notes as to what they can use.
/ducksauz
Flemming Frandsen
> Along the same line, I think it makes sense to define a dictionary of user
> attributes/authorizations. This could be used to specify what pieces of
> equipment a member is trained on and ready to use. This way you could
> control access to expensive and/or dangerous tools with the same system.
>
> Add an RFID controller to your laser cutter and it only turns on for folks
> who have been trained on it. Such a system would also allow for automated
> usage accounting.
Yes, that would be a good idea for certain tools, like the laser
cutter which will have a non-zero cost for every minute of operation.
It would be very cool to be able to save up for the new laser tube as
the machine is used.
We're certainly also going to build a cash-register application that
will allow us to sell sodas, chips and beer and accept payment from
the members account in the system, rather than mess around with cash.
> If you don't want to be so draconian with access control to the gear, at a
> bare minimum a monitor page could display all the users in the space and
> notes as to what they can use.
Yeah, I'm not a great fan of getting in peoples way without a really
good reason, but I could certainly see that a table saw might be
dangerous enough to restrict its use to only those who are trained or
at least to keep it locked down for the 15-17 year olds.
Ron Bean
>cheap as possible, with some form of networkability (CAN, ethernet,
>RS-485, etc). This is designed to store some (local) access token
>hashes within it's own memory in case the network goes down.
I find it intersting that people think it's important to store codes
locally in the door controller. My take on this is that if the
controller works without the server, and the server goes down, it might
not get noticed for a while. But if the door controller depends on the
server being up, and it goes down, someone *will* get a phone call, and
it *will* get fixed ASAP. This is also a good way to find out if your
server code has any bugs in it (as we found from our experience).
Flemming Frandsen
But I don't want to get a phone call and I don't want to fix anything ASAP.
... but seriously, distributed boards with local key storage have
several huge advantages over a centralized server, no matter how good
your server code is:
* Power usage is much lower (on the order of half a Watt), so it's
practical to have SLA batteries enough for a week of UPS operation,
even a Soekris net4801 will eat 20 times more power than that.
* If the (network|server|power|software) is broken, then the access
control system will keep working, the only thing that will break is
logging and key updates.
* Every door is controlled by a stand-alone controller, which means
that the only single-point-of-failure is power and at those power
levels it's entirely possible to have a a battery at every door.
Checking local EEPROM at the door is very, very easy and reliable, so
it's just plain silly not to get the massive advantages it brings.
It's not as though anyone is advocating running servers without
monitoring, but there is a huge difference between getting an alarm
for a server which can be fixed next weekend because the lock system
will keep working and getting an alarm that means having to rearrange
dinner plans to go scare up a mechanical key to fix things ASAP.
Katy Levinson
I do think some storage of the keys locally is pretty important though. One of the worst problems we have is an intermittent internet connection to the space. When the network goes down, somebody has to fix it right away, and adding more steps to them getting in the building to fix it is not a good idea for us.
Craig
ducksauz
I'm in the embedded controller camp, mainly because you might have more
than one door or piece of equipment to which you want to control access.
It seems a real waste, in hardware and power, to have to dedicate a
whole PC for each of those. However, the system should be extensible
enough to allow for either option.
The core of OpenDoor should be the member manager that will associate a
member with their access card and assign permissions to them.
Plugins should allow for a variety card readers:
* HackerDojo's simple USB reader machine (realtime)
* RS-485 bus networked readers (stored list)
* Ethernet/zigbee readers (stored or realtime)
On the other side of the system should be an API for integrating
OpenDoor with a member management system such that a member can pay
their expired dues via paypal on their phone when they get locked out
for forgetting to pay. :)
That's my $0.02 worth on where I see this project going.
-j
Katy Levinson
Flemming Frandsen
> We did the whole portion that this hackathon is about for less than 50 bucks.
Well Version 2 of the door controller boards cost $35 per door, but
that's with Ethernet, v4 is going to use RS-485 to bring the cost per
controller down to around $25.
... and that's a fully custom, one-off, programmable, compact,
standalone controller with local EEPROM storage for 2000 members,
using only commonly available parts.
The only difference in our approaches is that I stick $5 worth of AVR
and EEPROM on the relay board to allow it to work reliably, no matter
what the PC is doing, I see that as very cheap insurance against
getting locked out.
Craig
Mike Putnam
Though you cannot go to your local hardware store and get copy made
of a magnetic card, RFID tag, or memory of a sequence of numbers.
Mike Putnam
> Flemming Frandsen - YAPH - [4]http://dren.dk/
>
> References
>
> Visible links
> 1. http://dren.dk/
> 2. http://gmail.com/
> 3. mailto:katyle...@gmail.com
> 4. http://dren.dk/
Flemming Frandsen
> So is a key
Yes, but a mechanical key does not leave an audit trail and it's crazy
expensive, so only the board actually has keys and because we're only
one tenant in a larger building, only two members in total have keys
for the outside door.
... which means that for us, any frequency of failures that mean
having to fall back to keys is too high.
Flemming Frandsen
> Though you cannot go to your local hardware store and get copy made
> of a magnetic card, RFID tag, or memory of a sequence of numbers.
Any hacker worth his salt will be able to do that:)
... that's why our software also wants a pin code to go along with the RFID.
--
Flemming Frandsen - YAPH - http://dren.dk/
Katy Levinson
Lokkju Brennr
It is also uses less power, which means it is more feasible to have on
a long-term battery backup. It also uses less space...
As for the "international passport system", if you think that you are
going to be storing a dump of my hackerspace's keys (or even key
hashes) at your location, you are sorely mistaken. Any multi-space
system should be based on delegation of authorization - OpenID is one
example, multiple RADIUS servers, or a RADIUS proxy, is another.
Loki
On Fri, Dec 10, 2010 at 1:35 PM, Katy Levinson <katyle...@gmail.com> wrote:
> You are free to use whatever you like, and I'll respect that, but your logic
> for why people should use that solution upsets me :( What added benefit does
> putting the AVR in the middle serve, if the machine it is connected to
> caches all the logins locally on disk and has the maglock program as part of
> the startup sequence in case it falls down? Is an AVR somehow less likely
> to malfunction than the machine next to it? It just looks to me like more
> moving parts, and the 2000 logins as a scalability limit for the
> international passport system.
>
> On Fri, Dec 10, 2010 at 1:04 PM, Flemming Frandsen <dre...@gmail.com>
Rhys Rhaven
method of federated access control to which hardware, any kind of
hardware, will work, and can be extended to work with new hardware.
Kerberos seems like a prime canidate, as we can easily tie our
membership to KDCs under our own realm (domain. @pumpingstationone.org
in our case). The problem is its rather hard for any embedded controller
to have a kerberos library. Identity management and AAA are not concepts
to quickly reinvent in a weekend and still have a secure/working system.
I think a better task is to
1) Pick how we are going to store user information. LDAP? (pleeeease let
there exist something thats -not- LDAP).
2) Decide how to federate/namespace that information between all the
different hackerspaces
3) Figure out how to identify a user of another space based on their key.
Number 3 is huge I think. For example, say we use RFID like all the
hardware people here are suggesting. Its just a string of numbers, and
regardless that its sent over the air in the clear, how does the
authentication system know where that string of numbers is authorised
at? Does 0373428195412 need to be queried against PS1 or Hacker Dojo or
... infinity? I think that makes RFID a bad candidate off the bat.
So let me throw this out there:
We create a standardised text file much like a x509 certificate. Hell,
we could even use an x509 cert and add our own hackerspace extensions to
it. This will designate name, hackerspace, tools they are verified in,
expertises, etc etc. It is then signed by the users private key. We can
then either use network systems to verify the user, or we could have a
hackerspace key also sign it to approve it. Then the only thing a
hackerspace would have to federate would be the Certificate Revocation
List.
This file could be stored on a flash drive and read to be let in. Or
when Near Field Communication becomes more popular, we could used
standard RFID readers to send the file. Or however else you can think to
send the file. Almost completely implementation agnostic.
Ideas?
--
Rhys - SysAdmin
Ron Bean
>It's not as though anyone is advocating running servers without
>monitoring, but there is a huge difference between getting an alarm
>for a server which can be fixed next weekend because the lock system
>will keep working and getting an alarm that means having to rearrange
>dinner plans to go scare up a mechanical key to fix things ASAP.
If your server crashes more than a couple of times per year (after the
initial shakedown period), you're doing it wrong.
Also, our system was designed to use event-specific keypad codes that
only work on a certain day during certain hours, and then expire. The
local storage would have to accomodate that as well. These get used
quite a bit for events that are open to the public (this would be a
minor issue for spaces that don't have a lot of public events).
(And we're not worried about the network going down, because we use
RS485 and there's nothing else on it.)
Flemming Frandsen
> You are free to use whatever you like, and I'll respect that, but your logic
> for why people should use that solution upsets me
You are taking this way to seriously, lighten up:)
> Is an AVR somehow less likely to malfunction than the machine next to it?
Yes, very, very much.
Do you have:
* Your watchdog enabled on the PC?
* Several days of UPS power?
* Mirrored storage?
* ECC RAM?
* Redundant PSUs?
A whole lot goes into making a PC reliable and that usually takes it
right out of the "junk PC I got for free" category.
I have a PIC running in my car (steeringwheel remote interface, see:
http://dren.dk/lacetti-blaupunkt.html ) that has been running non-stop
without failure the last 7 years or so, none of the other machines I
own or work with have been as reliable as that.
> It just looks to me like more moving parts,
It's actually fewer *critical* moving parts, as the added intelligence
at the edge of the system means that the hugely complex PC at the
center is no longer critical.
If you doubt my reasoning, count the number of components in the PC
and the number of lines of code that need to work, then we can compare
that to the number of components on my board (about 50) and the LOC in
my firmware (about 1900).
> and the 2000 logins as a scalability limit for the international passport system.
No, that's just the number of keys that always allow access through
that particular door, not the full number of users in the system.
If you have more than 2000 paying members at your hackerspace, then
you can probably afford exchanging the 8kB EEPROM with a $2 64k
EEPROM.
Flemming Frandsen
> 1) Pick how we are going to store user information. LDAP? (pleeeease let
> there exist something thats -not- LDAP).
Anything that has to do with standards with names that start with x.
should be ignored, LDAP is part of that mess.
I'd much rather spec out a simple REST API that the space-server can
use to poll the user database for things like:
* Get status of a single key.
* Get list of key changes (add/delete) since a certain transaction number
* Log event (door opened with key, door opened with exit button).
> 2) Decide how to federate/namespace that information between all the
> different hackerspaces
I think something based on OpenID with extra attributes would do
nicely, because as a user of a space I'd certainly never want my
details shared with other entities, unless I specifically allow it.
> 3) Figure out how to identify a user of another space based on their key.
>
> Number 3 is huge I think. For example, say we use RFID like all the
> hardware people here are suggesting. Its just a string of numbers, and
> regardless that its sent over the air in the clear, how does the
> authentication system know where that string of numbers is authorised
> at? Does 0373428195412 need to be queried against PS1 or Hacker Dojo or
> ... infinity? I think that makes RFID a bad candidate off the bat.
No, credentials must never be broadcast in that way, because then it's
easy to track people.
I think we need to think about the use cases here.
You would never have a random person showing up at a random door,
expecting to be let in with his key.
What would have to happen, every time someone wants access to a
"foreign" space is:
1) The user creates an account with the target system, which uses
OpenID to authenticate the user against his "home" space and also uses
attribute exchange to pull over his keys.
2) The administrators of the foreign space must then give the user
access to unlock doors, either because the user has paid dues at the
foreign space, because there is a hacker-exchange program between the
two spaces or something completely different.
3) If the authentication token the user already has cannot interface
with the system in use, then he'll have to be issued a new token that
works.
#1 is needed to allow the user to have complete control over where his
personal infomation goes, as a user I don't want to do without that
step.
#2 is needed to allow the hackerspace (or its board) complete control
over who gets access to the space, as a member of the board of my
hackerspace, I'd certainly never want to allow random people access,
just because they happen to have an account somewhere.
#3 Could be optimized away if we agree on a common token, my money is
on 125 kHz EM4100 RFID tokens, because they are so cheap and outdoor
readers are easy to get.
Ron Bean
>Do you have:
>* Your watchdog enabled on the PC?
>* Several days of UPS power?
How often does your power go out for days at a time?
(And wouldn't you use a generator for that kind of outage?)
I know it varies by neighborhood-- some places around here lose power
for a couple of hours, once a year or so. But not days.
(I once received a letter of apology from the power company, because
we'd had several brief outages that year. They replaced an underground
cable and we had no more outages for the rest of the decade or so I
lived there.)
Royce Pipkins
The real problem is not whether machines think but whether men do.
B. F. Skinner
Flemming Frandsen
<bucke...@rbean.users.panix.com> wrote:
> Flemming Frandsen <dre...@gmail.com> writes:
>>Do you have:
>>* Your watchdog enabled on the PC?
>>* Several days of UPS power?
>
> How often does your power go out for days at a time?
Never, but one of the other tenants might stick their tounge in a
power outlet that takes out the same GFI that we're on, that will stay
off until someone shows up to switch the GFI back on.
If there is a day of UPS, then we have to show up and fix the power
within that day, if there is an entire week, then we have much more
flexibility in when we fix the problem.
So far we have not had any power outages that we didn't cause
ourselves, but I'd really like to be able to have a couple of days
worth of battery backup.
> (And wouldn't you use a generator for that kind of outage?)
Yeah, well, the point where you have to switch from SLA to a genny is
several weeks with half a watt of MCUs and a few hours with a 50W PC.
iow: yes, I'd like to have a couple of days worth of UPS, but not bad
enough to invest in a generator.
> I know it varies by neighborhood-- some places around here lose power
> for a couple of hours, once a year or so. But not days.
The country average in .dk is 10 seconds a year, iow: we don't see
power outages every year, so I'm not worried about city power being
out, it's those neighbors I'm worried about.
Flemming Frandsen
> One question: You mention space-server and user database. Wouldn't there
> potentially be categories of servers running around?
Yes, the box that controls access to a space (the space server) and
the user database which could serve several different spaces.
The space-server only talks to the individual door-controllers
(currently over Ethernet, but I'll be moving to RS-485) and the
central user database.
The space-server is not user accessible at all, all it does is to talk
grown-up Internet (REST over https is my favorite) to the user
database system which does have a web interface for members and
administrators.
In my setup the central user database site keeps track of the key
changes in a table, which simply has a list of add and delete
transactions, each with a serial number, that makes it easy to keep
the individual door controllers in sync, simply by asking the door
controller which transaction number it's at and sending it all the
transactions with a higher serial number.
I didn't think about letting a third party OpenID provider do the
authentication, but I guess that could be made to work.
Slide 2 of this presentation has an overview of the setup we're using
now: http://dren.dk/dl/cerberus-h2-t3.odp
The box I've been calling "space-server" here is labeled ITBM and our
user database is called "HAL 900" (it lives over here, btw:
https://hal.osaa.dk, but there is not much to see until you create an
account.
I rsync encrypted database backups to osaa.dk which is our main web
server, but that's not actively involved in member administration.
> Does that sound about right or were you thinking of something different?
Yeah, more or less, the main points are that:
1) The member has to do something to manually release his personal
details and his hashed(rfid+pin) information to the user database that
serves the foreign space.
2) It's entirely up to each space to figure out if they want to allow
the user or not.
Having a hacker-exchange program between local spaces would mean
automatically setting the door-bit for new members from the
participating space, but you could easily have other schemes.