<div id="geary-body" dir="auto"><div>These are the technical challenges that I see:</div><div><ul><li>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</li><li>Battery life, due to receive power consumption, because the receiver must be always-on</li><li>Battery life, because it must be powered by a coin cell if it is credit-card sized</li><li>Data storage, because it must provide enough storage for the people who make many contacts during a day, not only the average person</li></ul><div>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.</div></div><div><br></div><div>I did some power-consumption estimates for a client:</div><div><ul><li>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.</li><li>(Wikipedia has a description of BLE beacons.)</li><li>Receive will kill the battery, drawing about 5--6 mA continuously (datasheet).</li></ul></div><div>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)<br><ul><li>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.</li><li>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.</li><li>This gives a total of 173 kbytes to store this data.</li><li>That TI part has 128 K of flash; there might be other parts with more flash.</li><li>Alternatively, those SPI flashes give unlimited storage, but they add to the cost.</li></ul><div>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.</div></div><div><div><br></div></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Stephen Irons</div><div><br></div></div><div id="geary-quote" dir="auto"><br>On Sat, Aug 29, 2020 at 01:11, Bevin Brett <bevin_brett@hotmail.com> wrote:<br><blockquote type="cite">

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>


<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Assuming that it is</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<ol>
<li>Bluetooth is its only radio</li><li>One USB connection is its only other connection</li><li>The s/w has only to </li><ol style="list-style: lower-alpha;">
<li>listen continually for nearby devices and remember just their presence - no geolocation needed</li><li>broadcast once per minute its own ID and nothing else</li><li>keep track of one month's worth of ID's</li><li>supply its own ID when requested by the USB connection</li><li>supply the recorded ID's when requested by some password-secured request over the USB connection<br>
</li></ol>
</ol>
<div>1 - what do you think the cost per device should be?</div>
<div>2 - approximately how long should it take to develop open-source h/w and s/w for it?</div>
<div><br>
Given the availability of $1 USB Bluetooth adaptors, it seems to me the main problem is a little s/w and an adequate battery...</div>
</div>


</blockquote></div>