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

Stephen Irons stephen at irons.nz
Sun Aug 30 11:37:19 BST 2020


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 
locationBattery life, due to receive power consumption, because the 
receiver must be always-onBattery life, because it must be powered by a 
coin cell if it is credit-card sizedData 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


On Sat, Aug 29, 2020 at 01:11, Bevin Brett <bevin_brett at hotmail.com> 
wrote:
> Assuming that it is
> Bluetooth is its only radioOne USB connection is its only other 
> connectionThe s/w has only to
> listen continually for nearby devices and remember just their 
> presence - no geolocation neededbroadcast once per minute its own ID 
> and nothing elsekeep track of one month's worth of ID'ssupply its own 
> ID when requested by the USB connectionsupply the recorded ID's when 
> requested by some password-secured request over the USB connection
> 1 - what do you think the cost per device should be?
> 2 - approximately how long should it take to develop open-source h/w 
> and s/w for it?
> 
>  Given the availability of $1 USB Bluetooth adaptors, it seems to me 
> the main problem is a little s/w and an adequate battery...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ourshack.com/pipermail/chchrobotics/attachments/20200830/398fbc68/attachment.html>


More information about the Chchrobotics mailing list