From: "Dick Roy" <dickroy@alum.mit.edu>
To: "'dan'" <dandenson@gmail.com>, "'Dave Taht'" <dave.taht@gmail.com>
Cc: "'Network Neutrality is back! Let´s make the technical aspects
heard this time!'" <nnagain@lists.bufferbloat.net>
Subject: Re: [NNagain] [Starlink] bluetooth occupancy sensing
Date: Mon, 13 Nov 2023 20:07:44 -0800 [thread overview]
Message-ID: <B6147CA4DC3E4C8398D5241E01260AD2@SRA6> (raw)
In-Reply-To: <CAA_JP8Wtco=1x1fRG4ak2JBt3XiC7jMhB6cQzKYopwi4WvSEnA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3361 bytes --]
_____
From: Starlink [mailto:starlink-bounces@lists.bufferbloat.net] On Behalf Of
dan via Starlink
Sent: Monday, November 13, 2023 3:50 PM
To: Dave Taht
Cc: Dave Taht via Starlink; Network Neutrality is back! Let´s make the
technical aspects heard this time!
Subject: Re: [Starlink] bluetooth occupancy sensing
I also have bluetooth occupancy sensors lol. We have a lab test going of
triangulated bluetooth tag locating. So you put a BLE tag on a device and
*3* or more receivers in a space at different locations and heights which
are documented and then BLE tags are triangulated based on RSSI.
[RR] This only works if ALL the sensors are synchronized. Adding more
sensors does not help either, because for every sensor you add thats not
synchronized, you need to estimate a time bias/offset. And if the
oscillators are not synchronized (in frequency), then you have another
parameter to estimate
the frequency offset. It can get out of hand really
fast! The way this is normally done is to calibrate the area around the
sensors. What that really means is that array manifold vectors are
collected during a calibration phase then used during the measurement phase
to locate the transmitters and even that is a tricky problem. Check out
MUSIC!!! Its a half-century old!
Having sensors at various heights allows for tracking even the 'z' axis.
These tags are very cheap, you can buy complete tags for a couple of bucks,
don't even have to build your own, and you can get them built into cutable
(or non-cuttable) wristbands. You can also do short-term tracking of cell
phone beacons, though privacy mode means that you only get a short 'session'
with a phone (because of privacy mode on newer phones) that isn't paired
with something but if you have a phone with a bluetooth headset, the 'locks'
the bluetooth mac address and now you can track the phone anywhere that the
bluetooth headsets follow. You can also track cars which don't scramble the
mac, but you get cars with wifi mac as well.
We can get bluetooth to within inches accurate when it's line of site.
[RR] This requires sub-nanosecond synchronization
remember its a
nanosecond/foot (the inverse of the speed of light that is!) :-):-)
In a pocket or something it's about a meter because bodies/clothes etc
reduce RSSI unevenly. The purpose of this is a couple of things, 'patient
tracking' in any sort of a facility like nursing home or hospital, and
device tracking, again in a facility with shared hardware like portable EKGs
and handheld XRays etc that get 'misplaced' and staff has to go on a hunt
for. It's also much cheaper than lorawan as BLE transmits many times a
second and runs for years while lora is built for more range and only
transmits intermittently, usually 10-60 minutes to preserve battery.
We're testing mainly on dragino and milesight devices. I'm also having
decent enough luck with mikrotik's knot which can track BLE beacons with
high enough precision. Mikrotik has their own somewhat expensive BLE
beacons also but these are basically universal.
[RR] If you are getting inch accuracy without addressing the synchronization
problem, Id love to hear how, especially when there are lets say 10 BT
transmitters to locate simultaneously. :-):-):-)
[-- Attachment #2: Type: text/html, Size: 7719 bytes --]
next prev parent reply other threads:[~2023-11-14 4:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-13 12:44 [NNagain] the real state of "smart agriculture"? Dave Taht
2023-11-13 13:10 ` Frantisek Borsik
2023-11-13 13:31 ` [NNagain] [Starlink] " Nathan Owens
2023-11-13 14:08 ` [NNagain] " David Bray, PhD
2023-11-13 14:23 ` [NNagain] Fork: Future of Work, Sensemaking, and Co-Existence … was previously: " David Bray, PhD
2023-11-13 18:19 ` [NNagain] " dan
2023-11-13 23:22 ` [NNagain] bluetooth occupancy sensing Dave Taht
2023-11-13 23:50 ` dan
2023-11-14 4:07 ` Dick Roy [this message]
2023-11-13 21:10 ` [NNagain] [Starlink] the real state of "smart agriculture"? Dotzero
2023-11-13 23:31 ` [NNagain] " Rohan M
2023-11-16 18:11 ` Frantisek Borsik
2023-11-16 18:44 ` Jack Haverty
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/nnagain.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=B6147CA4DC3E4C8398D5241E01260AD2@SRA6 \
--to=dickroy@alum.mit.edu \
--cc=dandenson@gmail.com \
--cc=dave.taht@gmail.com \
--cc=nnagain@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox