<div id="geary-body" dir="auto"><div>This test was done in the EPIC building in Manchester Street. It is a fairly noisy 2.4 GHz environment, with 20+ WiFi APs visible, 4 people in my office with active BT headphones, cardboard walls and ceiling, with plenty of geeky types with BT devices in surrounding offices, including upstairs.</div><div><br></div><div>Testing was during normal office hours.</div></div><div id="geary-quote" dir="auto"><br>On Thu, Oct 1, 2020 at 18:43, Helmut Walle <helmut.walle@gmail.com> wrote:<br><blockquote type="cite">
  
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  
  
    <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>
  

</blockquote></div>