<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>All very good points. This raises one further question: how well
would this work in high-noise environments? I am thinking of the
typical office, where BT performance between 9am and 5pm is often
somewhat less than great, but if you work early before everyone
else arrives with all these wireless devices in their pockets, or
late after everybody else has gone home, BT performance noticeably
picks up... I like the suggestion of running in energy-saving mode
to achieve both long battery life and a reduction of interference.
But would that work equally well in environments that are fraught
with a lot of noise from other (non-covid tracing) sources in the
same band?</p>
<p>Kind regards,</p>
<p>Helmut.<br>
</p>
<div class="moz-cite-prefix">On 1/10/2020 17:39, Charles Manning
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAE21AQowS4kM-iTLDOvC+H0qQB9r=n+hYOfxbCxZn4AGGZ4yWw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>That's an interesting data point. I suppose a monte carlo
statistical model would give consistent results.</div>
<div><br>
</div>
<div>Here your scanning is being done by a PC which, I assume,
is scanning hard all the time. On most devices that's going to
be chomping the power. eg, Silabs SOC is around 12mW in RX
IIRC which would kill a CR2032 in about 50 hours. so clearly
hard scanning is not a winner.<br>
</div>
<div><br>
</div>
<div>If you're prepared to take a much more relaxed statistical
approach and, say, only worry about people being close for
more than a couple of minutes then you can come up with
something a bit more reasonable:</div>
<div>* Set the TX power lower so that devices more than, say, 5
metres away do not interfere. That makes it unlikely that you
will have more than 5 or so devices close enough. That reduces
collisions.<br>
</div>
<div>* Reduce beacon interval to 5 seconds. That reduces
collisions.<br>
</div>
<div>* Goal is now to scan, say, up to 20 devices in, say, 1
minute.<br>
</div>
<div>* There is now way less interference which cuts down on the
collisions so more beacons get through.<br>
</div>
<div>* Run radio at 2% duty cycle, thus stretching out power to
many months.<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Oct 1, 2020 at 12:53
PM Stephen Irons <<a href="mailto:stephen@irons.nz"
moz-do-not-send="true">stephen@irons.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 id="gmail-m_7573316535122382703geary-body" dir="auto">
<div>Some weeks ago, we spoke about Covid tracking and using
Bluetooth tags. I wondered about what would happen if
there were many tags in a close proximity. </div>
<div><br>
</div>
<div>I had the opportunity to set up a test, and now have
some actual data.</div>
<div>
<ul>
<li>104 devices operating as BLE beacons, transmitting
an iBeacon-format signal every 1.5 s</li>
<li>CR2032 battery, plastic housing</li>
<li>all bundled together in a plastic bag</li>
<li>my PC with a USB BT adaptor acting as a monitor</li>
<li>using Python 'beacontools' to monitor beacons</li>
<li>with a filter to receive only the BT address prefix
that I am interested in</li>
</ul>
<div><b>Results</b></div>
<div>
<ul>
<li>In 20 scans, the monitor has heard all tags, every
time.</li>
<li>It takes ~100 ms for the system to report the
first tag.</li>
<li>It takes 8--10 seconds for the system to report up
all 104 tags.</li>
<li>In 60 s of scanning, each device is heard an
average of 22.8 times. </li>
<li>Each device transmit 60/1.5 = 40 times, so we hear
just over 50% of the transmissions.</li>
</ul>
</div>
</div>
<div>I know that there are other BLE beacons in the area, as
well as many WiFi networks, BT phones, headphones, TVs,
etc in the vicinity.</div>
<div><br>
</div>
<div>The system works better than I imagined it would...</div>
<div><br>
</div>
<div>Stephen Irons</div>
<div><br>
</div>
</div>
_______________________________________________<br>
Chchrobotics mailing list <a
href="mailto:Chchrobotics@lists.ourshack.com"
target="_blank" moz-do-not-send="true">Chchrobotics@lists.ourshack.com</a><br>
<a
href="https://lists.ourshack.com/mailman/listinfo/chchrobotics"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.ourshack.com/mailman/listinfo/chchrobotics</a><br>
Mail Archives: <a
href="http://lists.ourshack.com/pipermail/chchrobotics/"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.ourshack.com/pipermail/chchrobotics/</a><br>
Meetings usually 3rd Monday each month. See <a
href="http://kiwibots.org" rel="noreferrer" target="_blank"
moz-do-not-send="true">http://kiwibots.org</a> for venue,
directions and dates.<br>
When replying, please edit your Subject line to reflect new
subjects.</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Chchrobotics mailing list <a class="moz-txt-link-abbreviated" href="mailto:Chchrobotics@lists.ourshack.com">Chchrobotics@lists.ourshack.com</a>
<a class="moz-txt-link-freetext" href="https://lists.ourshack.com/mailman/listinfo/chchrobotics">https://lists.ourshack.com/mailman/listinfo/chchrobotics</a>
Mail Archives: <a class="moz-txt-link-freetext" href="http://lists.ourshack.com/pipermail/chchrobotics/">http://lists.ourshack.com/pipermail/chchrobotics/</a>
Meetings usually 3rd Monday each month. See <a class="moz-txt-link-freetext" href="http://kiwibots.org">http://kiwibots.org</a> for venue, directions and dates.
When replying, please edit your Subject line to reflect new subjects.</pre>
</blockquote>
</body>
</html>