[chbot] Bluetooth tags

Charles Manning cdhmanning at gmail.com
Thu Oct 1 08:07:40 BST 2020


https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=8443321


On Thu, Oct 1, 2020 at 7:51 PM Charles Manning <cdhmanning at gmail.com> wrote:

> 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.
>
> With BLE three (IIRC) channels are reserved for advertising (which is what
> beaconing is) and other data is hopped through other channels.
>
> This has the advantage of leaving advertising channels relatively clear
> (unless 100 covid cards turn up :-).
>
> 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.
>
> 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..
>
> You could never do anything like that with regular BT.
>
>
>
> On Thu, Oct 1, 2020 at 6:43 PM Helmut Walle <helmut.walle at gmail.com>
> wrote:
>
>> 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?
>>
>> Kind regards,
>>
>> Helmut.
>> On 1/10/2020 17:39, Charles Manning wrote:
>>
>> That's an interesting data point. I suppose a monte carlo statistical
>> model would give consistent results.
>>
>> 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.
>>
>> 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:
>> * 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.
>> * Reduce beacon interval to 5 seconds. That reduces collisions.
>> * Goal is now to scan, say, up to 20 devices in, say, 1 minute.
>> * There is now way less interference which cuts down on the collisions so
>> more beacons get through.
>> * Run radio at 2% duty cycle, thus stretching out power to many months.
>>
>> On Thu, Oct 1, 2020 at 12:53 PM Stephen Irons <stephen at irons.nz> wrote:
>>
>>> 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.
>>>
>>> I had the opportunity to set up a test, and now have some actual data.
>>>
>>>    - 104 devices operating as BLE beacons, transmitting an
>>>    iBeacon-format signal every 1.5 s
>>>    - CR2032 battery, plastic housing
>>>    - all bundled together in a plastic bag
>>>    - my PC with a USB BT adaptor acting as a monitor
>>>    - using Python 'beacontools' to monitor beacons
>>>    - with a filter to receive only the BT address prefix that I am
>>>    interested in
>>>
>>> *Results*
>>>
>>>    - In 20 scans, the monitor has heard all tags, every time.
>>>    - It takes ~100 ms for the system to report the first tag.
>>>    - It takes 8--10 seconds for the system to report up all 104 tags.
>>>    - In 60 s of scanning, each device is heard an average of 22.8
>>>    times.
>>>    - Each device transmit 60/1.5 = 40 times, so we hear just over 50%
>>>    of the transmissions.
>>>
>>> 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.
>>>
>>> The system works better than I imagined it would...
>>>
>>> Stephen Irons
>>>
>>> _______________________________________________
>>> Chchrobotics mailing list Chchrobotics at lists.ourshack.com
>>> https://lists.ourshack.com/mailman/listinfo/chchrobotics
>>> Mail Archives: http://lists.ourshack.com/pipermail/chchrobotics/
>>> Meetings usually 3rd Monday each month. See http://kiwibots.org for
>>> venue, directions and dates.
>>> When replying, please edit your Subject line to reflect new subjects.
>>
>>
>> _______________________________________________
>> Chchrobotics mailing list Chchrobotics at lists.ourshack.comhttps://lists.ourshack.com/mailman/listinfo/chchrobotics
>> Mail Archives: http://lists.ourshack.com/pipermail/chchrobotics/
>> Meetings usually 3rd Monday each month. See http://kiwibots.org for venue, directions and dates.
>> When replying, please edit your Subject line to reflect new subjects.
>>
>> _______________________________________________
>> Chchrobotics mailing list Chchrobotics at lists.ourshack.com
>> https://lists.ourshack.com/mailman/listinfo/chchrobotics
>> Mail Archives: http://lists.ourshack.com/pipermail/chchrobotics/
>> Meetings usually 3rd Monday each month. See http://kiwibots.org for
>> venue, directions and dates.
>> When replying, please edit your Subject line to reflect new subjects.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ourshack.com/pipermail/chchrobotics/attachments/20201001/5a1f8fe7/attachment-0001.html>


More information about the Chchrobotics mailing list