<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt'>
<p>Fully agree.</p>
<p>TX => COTS parts can do this.</p>
<p>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.</p>
<p>RX => Well, there's the crux.</p>
<p>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.</p>
<p>Mike</p>
<p>On 30.08.2020 22:37, Stephen Irons wrote:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->
<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> </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> </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> </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> </div>
<div>Stephen Irons</div>
<div> </div>
</div>
</blockquote>
</body></html>