"Ben Nunn" wrote in message ...
"Gareth Davis" wrote in message

Performing all the calculations required to get the 'instant' capping
to work (based on your last few journies) in the time you have your
card over the reader then to write back the refund to the card while
it is still in range is a non-trivial exercise - and is limited by the
length of the journey record kept on the card. This record needs to
hold every journey over the capping period for the calculation to be
correct.


This seems like poor design to me - surely all the card needs to contain is
a unique ID, and all the other information could be contained within a
centralised database?

BTN

Which would require all card readers to be perminantly connected to
the central database. While this is easy with the fixed station
readers it is far more difficult to do with the bus ticket machines,
or the hand held terminals in use on the DLR or by the RPIs -
especially given they are often underground well out of range of the
GSM networks. I would expect (although I'm only guessing since I don't
work for LT or Cubic) that the mobile readers will store details of
all transactions then offload them to the central database when they
are docked at the end of each working day. Hence working it all out
retrospectivly is much easier (and likely to be more accurate) than
working in real time.

It is for the same reason that you cannot (and never will) be able to
buy a travelcard over the internet from home then use it on a bus
straight away - the bus won't know you have purchased it. Depending on
how large the drivers memory cards are in the bus readers it may be
possable to download the _entire_ list of _all_ online purchases into
them every 24 hours so you could pick up your travelcard on the bus
first thing - provided you purchased it the previous day. IMHO that is
the best that could be achieved with the current hardware without
installing some kind of mobile data link to each bus.

Unless someone 'on the inside' knows better....

--
Gareth Davis