<div dir="ltr"><div>I once did some statistical modelling on RF throughput and the results were not what you would have originally thought. The chance of collisions is not linear and it is easy to get to a point where more is less.<br></div><div><br></div><div>With BLE three (IIRC) channels are reserved for advertising (which is what beaconing is) and other data is hopped through other channels.</div><div><br></div><div>This has the advantage of leaving advertising channels relatively clear (unless 100 covid cards turn up :-).</div><div><br></div><div>Note too that BLE is nothing like BT Classic and they do not interfere except in the general sense of occupying the same RF spectrum. It is quite crazy giving them the same name - very confusing.<br></div><div><br></div><div>BLE is much faster at setting up connections. A few year I did a joystick remote using BLE using the low level transport - not the GATT stuff. The connection between the remote and the device was negotiated within 70 milliseconds. This meant we basically negotiated the connect and then dropped it again if the joystick was idle for more than half a second. THe fast set up time made it completely invisible to the user with no lag at all..<br></div><div><br></div><div>You could never do anything like that with regular BT.<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 1, 2020 at 6:43 PM Helmut Walle <<a href="mailto:helmut.walle@gmail.com">helmut.walle@gmail.com</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>
<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>On 1/10/2020 17:39, Charles Manning
wrote:<br>
</div>
<blockquote type="cite">
<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" target="_blank">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_99024533258174736gmail-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">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>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
Chchrobotics mailing list <a href="mailto:Chchrobotics@lists.ourshack.com" target="_blank">Chchrobotics@lists.ourshack.com</a>
<a href="https://lists.ourshack.com/mailman/listinfo/chchrobotics" target="_blank">https://lists.ourshack.com/mailman/listinfo/chchrobotics</a>
Mail Archives: <a href="http://lists.ourshack.com/pipermail/chchrobotics/" target="_blank">http://lists.ourshack.com/pipermail/chchrobotics/</a>
Meetings usually 3rd Monday each month. See <a href="http://kiwibots.org" target="_blank">http://kiwibots.org</a> for venue, directions and dates.
When replying, please edit your Subject line to reflect new subjects.</pre>
</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>