> > You're over-complicating things.  It's just a number.  
> While more data 
> > stored on the tag is nice, it's not necessary.
> >
> >   
> Thats what i just said lol, its a rf *ID* not a rf 
> *usermanual* There is no need to ever program a device *if* 
> the scale that does the weighing (by the deli staff) is 
> networked to the checkout.
> You just say that this label is attached to 12.324 kg of 
> carrots. The deli staff member bagged them up for you and 
> said they were carrots.
> (perhaps in something resembling a traditional checkout?) Yes 
> there is an additional employee there, but you get them back 
> by not needing them on checkouts.
> Buying pre-bagged carrots works out cheaper for the consumer 
> because you don't need to pay for that staff member.
> 
> To my way of thinking all ID's in a given range (say 1 billion
> possibilities) would be allocated to that kind of "temporary 
> data" and would have a life span of say 2 days. So the 
> chances of you having a valid tag coming back into the store 
> or a tag generated in another store that is valid in the one 
> you are currently in would be minimal.


Oh, I see.  You want something like how day pass or ticket systems work.

You have a bunch of serialised RFID tags, that is 1, 2, 3 etc.  No
duplicates.

When I get my carrots bagged, the next available tag is stuck on it (&
printed with carrots, $, kg).  The POS system now knows tag #1 is active and
that it's 12kg of carrots, worth $25.  The checkout picks up the tag, and
adds $25 to your bill (& print carrots on the receipt).  The tag is marked
as inactive in the system to reduce double counting, mixups from other
stores etc.

Yep, that'll work.

Some supermarkets do have staff in the fruit & veg section to do this.  Not
many in Australia though, they expect the checkout staff to do that.  It's
not too hard to imagine it happening again.

Tony

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist