> > It can be handled the same as meat/cheese etc, where it is weighed, 
> > wrapped and has a custom label applied.  If you look, 
> you'll see the 
> > bar code will start with '22', and you'll find the weight 
> (sometimes 
> > price) of the item somewhere in the rest of the number.
> >
> > For RFID, this means you need to be able to provide 
> programmable (one 
> > time) ones in the form of a label.  Price (of the labels) 
> is the holdup here.
> >
> > Another option is to have split checkouts, RFID & non-RFID. 
>  You take 
> > the fruit & veg out of the cart, they get priced (by a human), push 
> > the cart thru the scanner to handle any RFID stuff, toss 
> the rest in 
> > and head for the car park.
> >
> > More likely is to have the cart weighed & priced.  If there's a 
> > mismatch (caused by fruit) you go to a normal checkout, and 
> handle the 
> > non-RFID (as well as errors) there.
> >
> > Tony
> >
> >   
> why try and encode all that information in the first place?
> its rf ID not rf encyclopedia.
> 1024bits worth of ID should probably cover every possible 
> product that could be sold You then have a database with the 
> product ID's against the items. Fruit+veg etc go into the 
> bag, the sales person says this bag has carrots in it. The 
> computer takes the weight of carrots, and the fact that it is 
> carrots and sticks that item in the database.
> When you get to the checkout your cart is read, That ID is 
> pulled out and the fact you have 12.2354435kg of carrots is 
> added to your total.
> You aren't going to make something programmable cheap enough to work.
> I'd wager a coke that any time somebody says they are 
> "programming" a rfid tag when they wave it near the same 
> device that reads the tag, that that is what is actually 
> happening. They are just reading the tags value and telling 
> the computer to associate this ID number with entity X.


You're over-complicating things.  It's just a number.  While more data
stored on the tag is nice, it's not necessary.

You have few classes of tags depending on purpose, just like bar codes.

You have your standard bar code replacement.  Every product is identified by
a unique number.  No matter where you are in the world, 9300650653214 is a
jar of Vegemite.  That's probably 40 bits or so there.  It would be cool to
add product name, weight, dimensions, mgf date, expiry date etc in there
too.  I can think of a lot of uses for that, from they 'smart kitchen' to
calculating postage (who needs scales?).  

In this case, every product gets the same RFID, just like a bar code.

Next is field programmable tags.  A programmable RFID tag it just like a
PROM.  Initial all 0's (or 1's), you burn the appropriate number into it.
This will be more expensive than a plain sticker (thermal paper at present)
but economies of scale will bring it down soon enough.

Even the current labels are more expensive than a human peeling off a price
tag & writing a price on it.  Or are they, if you consider the full chain?

Like I said in previous post, a tag that can be partially programmed can be
very useful.  The product id part is set, and a serial number or other
information can be added.  For example, the tag is placed on the milk carton
when it is made, and the expiry date burnt into it when it is filled.  From
that point on, an old carton of milk becomes easy to find.

However, the relentless march of technology and all that means RFID will
become cheap, will become programmable, will become commonplace, and you
will be assimilated.

Tony

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