<div dir="ltr"><div>The Silabs parts use a bit less power and there are some with a very interesting "wake on RF" mode which can extend the life of a CR2032 to something life 5 years.<br></div><div><br></div><div>However the "wake on RF" needs pretty high RF levels to trigger.<br></div><div><br></div><div>The actual manufacturing cost per se can be low, but the engineering cost and logistics of trying to roll out , say, 3 million units in less than a year precludes many of the cheaper options (eg. the sub-$ micros used in the tags).</div><div><br></div><div>I still think the easiest way to achieve the basic goal is to use a phone app that sends and listens for BLE beacons. This might mean you need to charge your phone twice as often. For the 10% of adults that don't have cell phones it would be cheaper to buy them $50 phones than it would be to develop a CV card.</div><div><br></div><div>That could all be rolled out in less than 3 months.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 31, 2020 at 10:11 AM hamster <<a href="mailto:hamster@snap.net.nz">hamster@snap.net.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div 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:0px 0.4em;border-left:2px solid rgb(16,16,255);margin:0px">
<div id="gmail-m_2988450981576248262geary-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>

</div>
_______________________________________________<br>
Chchrobotics mailing list <a href="mailto:Chchrobotics@lists.ourshack.com" target="_blank">Chchrobotics@lists.ourshack.com</a><br>
<a href="https://lists.ourshack.com/mailman/listinfo/chchrobotics" rel="noreferrer" target="_blank">https://lists.ourshack.com/mailman/listinfo/chchrobotics</a><br>
Mail Archives: <a href="http://lists.ourshack.com/pipermail/chchrobotics/" rel="noreferrer" target="_blank">http://lists.ourshack.com/pipermail/chchrobotics/</a><br>
Meetings usually 3rd Monday each month. See <a href="http://kiwibots.org" rel="noreferrer" target="_blank">http://kiwibots.org</a> for venue, directions and dates.<br>
When replying, please edit your Subject line to reflect new subjects.</blockquote></div>