[chbot] CovidCard implementation - how expensive should it be to manufacture 1M of them?

[hamster]

Fully agree. 

TX => COTS parts can do this. 

Contact Storage => mildly challenging. You you would timestamp every
minute (for 1440 timestamps per day, 5760 bytes per day), and keep a
least recently seen table of 127 entries, keeping recurring contacts to
one bytes, and new contacts to once byte + ID. 

RX => Well, there's the crux. 

All of the low power RX parts I've looked at consume somewhere between
10mA -> 25mA when active, and with approximation 720 hrs in a month it
starts requiring batteries with many AHrs of battery capacity - a coin
cell is ~250mAhr,, only enough for 10 to 20hrs of RX per coin cell. 

Mike 

On 30.08.2020 22:37, Stephen Irons wrote:

> These are the technical challenges that I see: 
> 
> * Clever transmit/receive protocol to ensure that every card manages to capture the contact data for every other card in its vicinity in a busy location
> * Battery life, due to receive power consumption, because the receiver must be always-on
> * Battery life, because it must be powered by a coin cell if it is credit-card sized
> * Data storage, because it must provide enough storage for the people who make many contacts during a day, not only the average person
> 
> I have no idea how you can coordinate transmission and reception between nodes in continuously changing, overlapping clusters of 10s of nodes, such as would happen in a shopping mall. Mall-trackers work because they don't actually care if they only identify a small fraction of the actual people there. The CovidCard, on the other hand, should collect all. 
> 
> I did some power-consumption estimates for a client: 
> 
> * A transmit-only BLE beacon will operate for a year or two on a CR2032 cell, transmitting for about 4 ms every 1.5 s, giving an average transmit current of about 4 uA. This is based on the measured power consumption of a real implementation using a TI CC26xx part, with cell capacity from the Panasonic CR2032 datasheet.
> * (Wikipedia has a description of BLE beacons.)
> * Receive will kill the battery, drawing about 5--6 mA continuously (datasheet).
> 
> Data storage might be an issue, especially for people in a customer-facing job (eg. the guy who sprays goop on your hands when you enter the supermarket)
> 
> * Assume that a busy person makes 1 contact per minute for his 8-hour working day, for a total of 480 contacts per day, or 14400 contacts over 30 days.
> * Assume you store a 64-bit ID (BLE MAC or other unique ID) and a 32-bit for a timestamp, you need to store 12 bytes per contact.
> * This gives a total of 173 kbytes to store this data.
> * That TI part has 128 K of flash; there might be other parts with more flash.
> * Alternatively, those SPI flashes give unlimited storage, but they add to the cost.
> 
> That TI part has enough grunt to do the BLE stuff and to run some application stuff -- it is pretty simple. I don't think you would need a separate processor. 
> 
> That TI part on a PCB with a CR2032 in a key-ring housing costs a few dollars in 10K quantities. A credit-card form-factor would be much the same. A separate flash chip will add a bit more. 
> 
> Personally, I think the 300-person trial in Rotorua is much too small. Contacts between CovidCards will be rare, and it will not test operation in crowded malls, restaurants, and other busy locations. 
> 
> Stephen Irons
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ourshack.com/pipermail/chchrobotics/attachments/20200831/79192194/attachment.html>