Electronic badges

[Dave Cramer]

The company I work for is visible assets. We make a unique RFID tag  
which is active and can store information on the card.It is unique in  
that it operates at 132KHz.

I may be able to get a few hundred tags, and a reader or two for the  
show. I will provide how instructions on how the card/reader works if  
anyone is interested.

Complete disclosure here... my aim would be to expose this technology  
to some innovative people for a new application. FWIW we already have  
most of what you need working.

Dave
On 8-Jul-07, at 11:08 PM, Colin McGregor wrote:

> --- phiscock-g851W1bGYuGnS0EtXVNi6w at public.gmane.org wrote:
>>> As noted in my posting about the Ontario LinuxFest
>> I
>>> am opening up the electronic name badge can of
>> worms
>>> again. So, with that in mind let note the
>> strengths
>> (snip)
>>
>> To anyone considering a single-chip microprocessor
>> project using the PIC,
>> I would strongly recommend looking at the Atmel AVR
>> series of
>> microprocessors. The Microchip PIC is arguably more
>> popular, but - based
>> on my experience implementing code on it and the AVR
>> - it has some serious
>> architectural deficiencies.
>> - limited number of instructions leads to opaque
>> assembly language code
>> - bank-switched registers and paged memory make for
>> convoluted code and
>> complex debugging environment
>>
>> Anyone who challenges this is invited to write a
>> routine that simply pumps
>> out a section of memory to a host computer. On the
>> AVR, it's about three
>> lines of code. On the PIC, it's an ugly,
>> non-intuitive hack.
>
> On the BASIC Stamp the oddities of the PIC chip is
> hidden behind a BASIC interpreter. So, I have not
> written any PIC code...
>
> Oddly enough the LCD name badge problem is a variation
> on what you describe. The LCD module has some limited
> smarts, so we don't have to worry about dealing with
> individual pixels (well, subject to conditions we can
> if we want to...). We want to walk through a block of
> memory, feeding information out to the controller in
> the module, toggling two control lines, and we want to
> do a lot of waiting (even the BASIC Stamp could update
> the display so fast as to make the display a blur, so
> waits are a must).
>
>> A compliler can hide many of the architectural warts
>> of the PIC, but there
>> are good reasons for projects of this type to work
>> in assembly language.
>> The code size is smaller and C tends to hide certain
>> types of bugs.
>>
>> Comparable IC's and development systems are
>> available for both devices.
>> Prices are similar.
>
> I have an old PIC programmer, not sure how many
> current devices it supports. But regardless I suspect
> that if this is all a one person show it may not get
> done. So this is why I got a kick out of:
>
>  www.instructables.com/id/E5H5UDWB5UEUKIKV8V/?ALLSTEPS
>
>
> A very bare bones AVR development system for about $10
> (U.S.). Even that modest sum can be slashed if one say
> has a parallel printer cable they are willing to cut
> up. In other words a development system cheap enough
> that building 2-3 (or more) will not be an issue :-) .
>
>
> Beyond that just add Linux, a PC with a parallel port,
> and some free development tools.
>
> Colin McGregor
>
>> Peter
>>
>> -- 
>> Peter Hiscocks
>> Syscomp Electronic Design Limited, Toronto
>> http://www.syscompdesign.com
>> USB Oscilloscope and Waveform Generator
>> 647-839-0325
> --
> The Toronto Linux Users Group.      Meetings: http://gtalug.org/
> TLUG requests: Linux topics, No HTML, wrap text below 80 columns
> How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists

--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists