Jekyll2023-02-20T09:09:28+00:00https://heraldprox.io/feed.xmlHerald ProjectThe home for our research in to low level mobile phone Bluetooth capabilities, issues, workarounds, and testing.Herald Project ContributorsVersion 2.2.0 Released2023-02-19T06:00:00+00:002023-02-19T06:00:00+00:00https://heraldprox.io/blog/version-220<h1 id="herald-version-220-released">Herald Version 2.2.0 Released</h1>
<p>It’s been a busy few months for the Herald team. So busy in fact we didn’t announce the previous version 2.1.0!
So in this post we’ll walk you through all the recent improvements in Herald.</p>
<p>We’ve moved to a small release schedule whereby each time a feature, or feature and a few associated bugs, are fixed
we test and push out a release immediately. This should make upcoming releases every 1-3 months rather than 12-15 months.
This also allows us to get ahead of mobile operating system releases and perform compatibility testing on the latest iOS and
Android releases. Expect to see more frequent releases and updates from the team in future!</p>
<p>Since v2.2.0 (Released 19 February 2023):-</p>
<ul>
<li>Tested on the latest iOS and Android OS versions for reliability and compatability</li>
<li>Improvements in detection (including one way detection) on both iOS and Android, with connect back on iOS working well</li>
<li>iOS now connects much less often to Android devices, reducing workload on Android and improving battery use on both platforms</li>
<li><strong>BREAKING CHANGE:</strong> A more explicit way for app developers to specify a custom Bluetooth Service UUID either alongside or instead of Herald’s default mode (See BLESensorConfiguration for details)</li>
<li>Added production of graphs about all other phones seeing a target phone (the ‘observation’ charts when you run the script) in the Analysis Scripts which ‘zoom in’ to a small time window of interest to help to pinpoint specific phone issues</li>
<li>Added an anomaly detection Java app to the Analysis scripts repository which allows the creation of issue scenarios and root cause analysis over many phones across many days, to aid anomaly detection, prioritisation, and resolution</li>
</ul>
<p>Since v2.1.0 (Released 14 January 2023):-</p>
<ul>
<li>Healthcheck routines on both platforms to correct any local bugs or reliability issues</li>
<li><strong>BREACKING CHANGE:</strong> Herald now using the official, registered Linux Foundation Bluetooth Service UUID (which we share with the <a href="https://zephyrproject.org/">Zephyr Project</a>). We’re keeping detection of the previous ID in place, but not advertising it by default since v2.1.0.</li>
<li>Various security primitives and options, and the use of a new hashing function</li>
</ul>
<p>For a full list of changes please see the release notes:-</p>
<ul>
<li><a href="https://github.com/theheraldproject/herald-for-ios/releases/tag/v2.2.0">iOS Release Notes</a></li>
<li><a href="https://github.com/theheraldproject/herald-for-android/releases/tag/v2.2.0">Android Release Notes and library download</a></li>
<li><a href="https://github.com/theheraldproject/herald-analysis">Analysis Scripts</a></li>
</ul>
<p>The releases are available here:-</p>
<ul>
<li><a href="https://cocoapods.org/pods/Herald">Cocoapod for iOS</a></li>
<li><a href="https://central.sonatype.com/artifact/io.heraldprox/herald/2.2.0">Library for Android</a></li>
</ul>
<p>You can also build the Herald test app by cloning our repositories and building the app locally.</p>
<h2 id="get-involved">Get Involved</h2>
<p>The Herald Project thrives on community participation. If you want to get involved, or have a great idea for improving healthcare, please get in touch. Visit the <a href="/community">Herald Community Page</a>.</p>Herald Project ContributorsHerald Version 2.2.0 ReleasedIntroducing the Herald Bluetooth MESH API2022-04-23T06:00:00+00:002022-04-23T06:00:00+00:00https://heraldprox.io/blog/mesh-api<h1 id="introducing-the-herald-bluetooth-mesh-api">Introducing the Herald Bluetooth MESH API</h1>
<p>The Herald Bluetooth MESH API will allow Smart Hospital use cases, improving the experience of clinical staff, patients, and visitors.</p>
<p>The Herald Project contributors have been looking at how we can take what we’ve learned during COVID-19 about
Bluetooth Low Energy and apply it to a wider healthcare context.
<a href="/mesh">Herald Bluetooth MESH</a> is a new API that facilitates easy creation of a secure MESH network
within a hospital. This can drive many use cases, including:-</p>
<ul>
<li>Navigation without a hospital, with downloadable and searchable map and gazetteer</li>
<li>Locating hospital equipment by staff when they urgently need it</li>
<li>Replacing pagers with a secure, in-hospital, self healing data network, providing more patient context in messages</li>
</ul>
<p>The Herald Bluetooth MESH API is currently under development with the technology already running on a variety
of devices and communicating between computer servers running the RabbitMQ reliable messaging technology,
and a set of Herald MESH applications including a MESH Modem, MESH network Relay Nodes (which also support
the Herald Venue Beacon functionality), and MESH and Bluetooth Low Energy ‘tags’ for equipment.</p>
<p>We hope to release a first Beta demonstration build of applications with a video explainer in May 2022.</p>
<h2 id="get-involved">Get Involved</h2>
<p>The Herald Project thrives on community participation. If you want to get involved, or have a great idea for improving healthcare, please get in touch. Visit the <a href="/community">Herald Community Page</a>.</p>Herald Project ContributorsIntroducing the Herald Bluetooth MESH APIBluetooth RSSI proximity self calibration enhancements2022-03-11T06:00:00+00:002022-03-11T06:00:00+00:00https://heraldprox.io/blog/self-calibration<h1 id="herald-announces-working-approach-to-bluetooth-phone-rssi-proximity-self-calibration">Herald announces working approach to Bluetooth phone RSSI proximity self calibration</h1>
<p>Today The Herald Project, part of LFPH, announces a promising new approach to
measuring phone-to-phone proximity accurately using Bluetooth Low Energy on
consumer mobile phones.</p>
<p>A problem since the start of the SARS-CoV-2 pandemic has been accurately measuring
proximity using mobile phones. The most prevalent sensor available is your phones Bluetooth
chip and antenna.</p>
<p>The Herald Project has researched the variability of RSSI signal strength data and published
millions of rows of datasets down to 1cm resolution between different phones to research the
possibilities here.</p>
<p>We have recently completed this research by creating a mechanism allowing for phones to self-calibrate</p>
<ul>
<li>removing the variation from how different people store and use their phones by calibrating based
on their behaviour - their close contacts with other people and how humans socialise with each other.</li>
</ul>
<p>When you talk to your close friends you adopt a particular distance. For acquaintences slightly further, and so on.
Using this information for a subset of your most prolonged ‘contact events’ (where your phone detects others)
has enabled us to devise a way for your phone to calibrate to a standard scale, allowing proximity to be calibrated
to your behaviour over time.</p>
<p>This works by correcting for Transmit Power from remote phones and filtering real interactions over a period of time (2.5 days should be sufficient) and then
spotting peaks in corrected data to infer ‘close/personal space’ and ‘near/acquiantance space’ using Proxemics, and calibrating
a proximity scale to those human behavioural zones.</p>
<p>Once the data is calibrated, epidemiologists can create risk algorithms that use this standard
proximity scale.</p>
<p>Using two different phones on test subjects that live together and have very different jobs and working hours showed that
calibrating on all other Bluetooth contact events, then applying each phones own calibration results to their mutual contact events,
gave very similar risk scores - to within 7.5% of each other. (More accurate than your step counters when you go walking with a friend!)</p>
<p>We have also provided a file - heraldrisk.R - under an Apache 2.0 license allowing others to use our Herald demo app
or these functions independently to calibrate their own devices.</p>
<p>More can be read about this on our GitHub site: https://github.com/theheraldproject/herald-analysis#phone-self-calibration-scripts</p>
<p>The Herald Project will now work to incorporate this into our next release of the Herald Risk and Exposure API,
allowing Public Health Authorities to build this new accurate risk model with 7 second resolution into their
COVID-19 Digital Contact Tracing apps, and to provide for the first time a ‘Social Mixing Score’ feedback to
a user.</p>
<p>Providing social mixing scores on apps will allow people to measure and track their own social mixing
in much the same way as people monitor their daily step counts. They’ll be able to have a consistent
points score per day for mixing with other people, and choose how to modify their own behaviour
to minimise their risk of contracting disease.</p>
<p>This crucially allows them to prevent themselves being notified of exposure rather than wait
to be told they may have received too much exposure over the past few days. This should
reduce the spread of disease and do so by reducing the number of people we ask to self
isolate via COVID-19 apps.</p>
<h2 id="get-involved">Get Involved</h2>
<p>The Herald Project thrives on community participation. If you want to get involved, or have a great idea for improving healthcare, please get in touch. Visit the <a href="/community">Herald Community Page</a>.</p>Herald Project ContributorsHerald announces working approach to Bluetooth phone RSSI proximity self calibrationSingapore’s GovTech donates OpenTrace to Linux Foundation Public Health’s Herald Project2021-08-24T06:00:00+00:002021-08-24T06:00:00+00:00https://heraldprox.io/blog/opentrace-donation<h1 id="singapores-govtech-donates-opentrace-to-linux-foundation-public-healths-herald-project">Singapore’s GovTech donates OpenTrace to Linux Foundation Public Health’s Herald Project</h1>
<p>GovTech Singapore (<a href="https://tech.gov.sg">https://tech.gov.sg</a>) has signed an agreement to donate the OpenTrace code and name to Linux Foundation Public Health (<a href="https://lfph.io/">https://lfph.io/</a>) (LFPH)’s Herald Project (<a href="https://heraldprox.io/">https://heraldprox.io/</a>). Open sourced in April 2020, OpenTrace was one of the first Digital Contact Tracing (DCT) systems published for use around the world. It received strong interest from many nations in early 2020 seeking to adopt similar solutions.</p>
<p>Adam Fowler, The Herald Project’s TSC Chair, had this to say:</p>
<p>“The Singapore Government’s GovTech team were the true trailblazers of practical Digital Contact Tracing. Their efforts spurred on other teams throughout the world to pursue this life saving risk screening technology. Their success in proving the viability of Digital Contact Tracing in Singapore inspired me to continue to pursue research creating a reliable Bluetooth communication system to further improve this technology, and resulted in the creation of The Herald Project. I’m very proud to work with the GovTech team and carry on the baton of open source Digital Contact Tracing as part of Project Herald.”</p>
<p>The Herald Project was formed in the summer of 2020 to investigate and create a method for reliable, privacy-preserving Bluetooth communication and range finding across multiple devices, including phones, wearables and beacons. Created as a VMware originated open source project, Herald was donated to LFPH in February 2021. The Herald Protocol is the most reliable protocol with the widest device support in the world, supporting phones back to 2010 and a wide range of inexpensive wearables. The Herald project even has its own open source wearable design which should eventually be manufactured at USD 15 per wearable and is currently undergoing testing.</p>
<p>Since its launch, Herald has been adopted by those looking to improve their DCT systems including the COVID-19 apps of Australia and Alberta, Canada, and is deployed on over 7.5 million devices worldwide. The Herald Project has developed a vibrant community since joining Linux Foundation Public Health.</p>
<p>Jenny Wanger from LFPH had this to say:</p>
<p>“GovTech’s donation of OpenTrace demonstrates exactly the kind of global collaboration between technologists and public health authorities that open source software enables and leads to better products overall. Because LFPH is dedicated to making sure everything we do happens in the open, public health authorities around the world trust us and the software we host, like Herald, to help them in the fight against COVID-19.”</p>
<p>The Singapore Government’s own TraceTogether system was built on OpenTrace and is tightly linked to the national healthcare and disease outbreak response systems in Singapore. By donating OpenTrace to Herald and assisting the team on the future direction of Herald, the hope is to create a white-labeled software suite for Digital Contact Tracing incorporating mobile apps, wearable devices, DCT backend services, and epidemiological outbreak analytics that any government can use to help protect their residents.</p>
<p>Jason Bay from GovTech Singapore had this to say about their hopes for the OpenTrace code and name joining Herald:</p>
<p>“My team and I built TraceTogether and OpenTrace because we believed in the potential for a novel application of consumer technology to support public health responses to COVID-19 and other disease outbreaks – not only in Singapore but globally too. In our March 2020 manifesto, we wrote that ‘viruses do not respect national boundaries, (and) neither should humanity’s response.’ Herald’s vision of an end-to-end white-label system that public health authorities can adopt is ambitious, but worthy of our support. We hope that by aligning our efforts around an open, interoperable framework like Herald, humanity will collectively be better able to respond to this and future pandemics.”</p>
<p>In the coming weeks The Herald Project will release a new version of OpenTrace to provide an end-to-end DCT system that leverages both the OpenTrace and Herald innovations. The OpenTrace name and brand will be used for all DCT tools within the project; the Herald name will be applied to the broader protocol technology which has potential future health use cases such as:</p>
<ul>
<li>Replacing hospital pagers with a system that provides more context about a required consultation</li>
<li>Locating urgently required hospital equipment such as syringe drivers</li>
<li>Securely tracking important samples in hospitals</li>
<li>Ultra Wide Band (UWB) enabled devices for very accurate distance estimation in worker safety</li>
<li>Wayfinding inside complex buildings using a series of Herald-enabled beacons</li>
</ul>
<h2 id="find-out-more-about-opentrace">Find out more about OpenTrace</h2>
<p>You can visit our <a href="/opentrace">OpenTrace section</a> on this website for further details.</p>
<h2 id="get-involved">Get Involved</h2>
<p>The Herald Project thrives on community participation. If you want to get involved, or have a great idea for improving healthcare, please get in touch. Visit the <a href="/community">Herald Community Page</a>.</p>Herald Project ContributorsSingapore’s GovTech donates OpenTrace to Linux Foundation Public Health’s Herald ProjectWhy Digital Contact Tracing is still needed2021-06-25T08:00:00+00:002021-06-25T08:00:00+00:00https://heraldprox.io/blog/dct-still-needed<p>We’re now over a year since the first national lockdowns due to SARS-CoV-2 (COVID-19). In this post we look to the
continued need for Digital Contact Tracing (DCT), and where the technology is going next.</p>
<h3 id="the-need-for-dct">The need for DCT</h3>
<p>SARS-CoV-2 was unique due to having several features in a single disease:-</p>
<ul>
<li>High number of asymptomatic carriers (People spreading without showing signs of disease)</li>
<li>Even once disease onset, symptoms were mild, but some succumbed to sudden deterioration</li>
<li>Treatment of the seriously ill involved specialist equipemnt (ventilators) and took many days to recover before being released from hospital</li>
<li>Long period of time until the onset of symptoms (mean of ~4.5 days, 95 percentile of 14 days)</li>
</ul>
<p>These features in one disease meant that cases could slowly build over time and that manual contact tracers
had their work cut out to trace a person’s activities for up to two weeks rather than a couple of days.</p>
<p>It also meant that there was a very large burden placed on hospitals. Once hospital critical care beds
were filled it would mean an uptick in the number of deaths through the lack of specialist care.
Maximising those self isolating at home who had become ill became key to preventing onward spread.</p>
<p>This means that automated proximity measurement, exposure notification, and their linking to
manual contact tracing systems were needed in a way not required for previous pandemics.
This is where Digital Contact Tracing has emerged from.</p>
<p>A year later we’re now seeing an onset of a Delta variant, and as I write this a new
<a href="https://www.bbc.co.uk/news/world-asia-india-57564560">‘Delta-Plus’ (AY.1)</a> variant
is currently being tracked too - one which early indications show may be both more virulent and
resistent to vaccines.</p>
<p>Hopefully this early data will be proved wrong and vaccines will continue to provide a way out
of this pandemic, but we should take this opportunity to prepare and perfect our DCT approaches.</p>
<p>Whether in this or future pandemics, an approach will be needed to allow humanity to
respond to new emerging diseases or variants and respond quicker, minimising the impact on
both health services’ ability to respond and the day to day freedoms of individuals.</p>
<h3 id="putting-contact-tracing-back-into-dct">Putting Contact Tracing back into DCT</h3>
<p>Due to the fast onset of SARS-CoV-2 many application teams sought a fully automated
DCT solution as manual teams were overwhelmed with the volume of cases.</p>
<p>Whilst useful in the peak of a pandemic, fully automated control without human
intervention is not the default approach of contact tracing teams.</p>
<p>Contact Tracers use epidemiological knowledge and experience to tailor their
recommendations to individuals. Each decision is based upon a conversation
and understanding of an individual case.</p>
<p>This has not been the case for automated Exposure Notification systems. Instead
they have operated, in most instances, as either a ‘black box’ - being allowed
to fully automate and recommend self isolation, or as a ‘fill the gaps’ solution
to an individual’s contact sheet where they don’t know the name of who they were near to,
say on public transport.</p>
<p>The Black Box Exposure Notification (EN) approach has been viewed with scepticism by
manual contact tracing teams as they do not have access to the basis of calculation
for individuals’ decisions. It effectively operates as a system outside and separate
from the standard public health contact tracing approaches which have been honed
over the past 100 years.</p>
<p>A Black Box approach also means no data is available to make decisions from until
a disease is understood, so that thresholds and policies can be set for self isolation
advice. This means at an emergence of a new pandemic these solutions will not
be enabled for full automation as they are not trusted, and they won’t provide early
warning data to contact tracing teams and epidemiologists.</p>
<p>The ‘fill the gaps’ approach of Digital Contact Tracing has proved useful. In many
cases contacts that would have never been reached through manual contact tracing have
been reached through supplementing personal memories with automated contact matching.</p>
<p>The downside to this approach is that a person in advance has to share their identity
with the contact tracing system provider (typically a public health authority), and
so strong legal safeguards are often added to prevent abuse of this data by governments.</p>
<p>In addition, although rich exposure risk measurement data is now possible through
proximity detection mechanisms, such as Herald, this data has not been made available
to the manual contact tracing teams. They just see a list of extra contacts, and perhaps
an approximate number of 5-minute windows these individuals were near each other.</p>
<p>What is needed is a blending of these rough edges of privacy, data accuracy, and providing
public health experts with enhanced data. With this new diseases or strains can be
identified early, enhanced data can be provided to public health teams, and trust
can be built into the analyses of DCT systems prior to enabling any automated
exposure advice.</p>
<p>This approach is Digitally Assisted Contact Tracing (DACT) and is something we’re actively
seeking to develop in The Herald Project alongside our Project Advisory Group, which includes
PHAs and experts in DCT.</p>
<h3 id="how-the-herald-project-will-drive-this-effort">How the Herald project will drive this effort</h3>
<p>Over the course of the summer of 2021 The Herald Project will look to create
a white-labled end-to-end DCT/DACT and Exposure Notification system built on top
of the Herald Proximity library.</p>
<p>Those countries and states without such systems will be able to quickly take our
opensource software and use it, to the benefit of their communities. This helps
protect countries who cannot afford a hundred person application development team.</p>
<p>Those with existing systems will be able to take individual modules and plug them
into their existing DCT system - no matter which Bluetooth protocol they are
using between devices. Interoperability will be key.</p>
<p>We will also publish the reference implementation of the
<a href="/specs/payload-interop">Herald Interoperability Protocol</a>
allowing countries running the same or separate systems to exchange exposure information
in a privacy preserving way once borders re-open.</p>
<p>Our first step in this journey will be to complete the first version of our wearable
opensource hardware to provide reliable DCT and, optionally, biomonitoring to individuals
who cannot afford the latest thousand dollar smartphones that are currently required to
run many DCT applications today.</p>
<p>After this we’ll create an whitelabled DCT mobile app and a DCT healthcare
backend, allowing PHAs to rapidly publish their own applications and systems based on
this well developed and tested foundation.</p>
<h3 id="how-you-can-help">How you can help</h3>
<p>We’re community driven,
so please come and <a href="/community">join the Herald community</a> and help us with deciding the
future of the Herald project!</p>Herald Project ContributorsWe’re now over a year since the first national lockdowns due to SARS-CoV-2 (COVID-19). In this post we look to the continued need for Digital Contact Tracing (DCT), and where the technology is going next.Version 2.0.0 released2021-06-23T10:00:00+00:002021-06-23T10:00:00+00:00https://heraldprox.io/blog/version-200<p>Version 2.0.0 of Herald is now available!</p>
<p>This version features a breaking change, hence the major version bump. This is due to moving to our own domain name heraldprox.io.</p>
<p>Key features in this release include:-</p>
<ul>
<li>BREAKING change - moved to io.heraldprox.herald for the library</li>
<li>Full Continuous Integration (CI) via GitHub Actions</li>
<li>Now publishing artifacts to Maven Central and CocoaPods, as well as GitHub Packages</li>
<li>Support for Swift package manager</li>
<li>Added Nullable and other Kotlin flags for improved Kotlin app developer productivity and ease of use</li>
<li>Using main instead of master for releases</li>
<li>Website change to heraldprox.io, and all documentation updated with this link</li>
<li>Code review, documentation fixes</li>
<li>Baked in a workaround to a known older Android OS security gap in Bluetooth not fixes in the OS. Eases the burden on app developers</li>
<li>Using a new approach to Pseudo Device Address generation that is both non blocking on older phones and prevents prediction of future addresses</li>
</ul>
<p>For a full list of changes please see the release notes:-</p>
<ul>
<li><a href="https://github.com/theheraldproject/herald-for-ios/releases/tag/v2.0.0">iOS Release Notes</a></li>
<li><a href="https://github.com/theheraldproject/herald-for-android/releases/tag/v2.0.0">Android Release Notes and library download</a></li>
</ul>
<p>We’re community driven,
so please come and <a href="/community">join the Herald community</a> and help us with deciding the
future of the Herald project!</p>Herald Project ContributorsVersion 2.0.0 of Herald is now available!Why measuring Distance and Risk accurately is important2021-05-17T09:00:00+00:002021-05-17T09:00:00+00:00https://heraldprox.io/blog/distance-risk<p>Herald allows for very regular Bluetooth RSSI readings. These can be used to estimate distance. In this blog we discuss
why this is important, and what this information can be used for, and how we provide an accurate way of doing this in Herald.</p>
<h3 id="uses-of-distance-estimation">Uses of distance estimation</h3>
<p>The Herald Proximity API is designed to do two things very well:-</p>
<ul>
<li>Provide regular information on the presence of other local devices (E.g. those running Herald services, or a DCT app)</li>
<li>Reliably exchange payload (application data) between these devices</li>
</ul>
<p>Up until version v1.3 Herald has only provided low-level information on nearby devices. For Bluetooth Low Energy this
is the regular, raw RSSI (Signal Strength) information calculated by your device about other nearby devices.
From v1.3, the Analysis API allows you to choose from a variety of algorithms to convert this data to a distance estimate.</p>
<p>Beyond simple ‘nearby’ proximity information, ‘Distance’ estimation is useful in a variety of applications:-</p>
<ul>
<li>Triangulating a device’s position within a fixed-beacon or Bluetooth MESH environment to facilitate accurate in-building navigation</li>
<li>Attaching Bluetooth beacons to high-value devices, such as in a hospital setting, to locate valuable and urgently needed equipment</li>
<li>Measuring an employee’s exposure in terms of distance and duration to a risky work environment, such as exposure to chlorine or excessively noise in an industrial setting</li>
<li>Digital Contact Tracing - to more accurately calculate ‘exposure risk’ between people in complex environments as they move around</li>
</ul>
<h3 id="important-aspects-for-distance-estimation">Important aspects for distance estimation</h3>
<p>Much research has been done on using occassional RSSI samples to perform distance estimation.
Many of these studies have - incorrectly - concluded that Bluetooth RSSI cannot be used for accurate distance estimation, as we’ll show below.</p>
<p>There are a variety of reasons for these conclusions:-</p>
<ul>
<li>Many studies used occassional RSSI samples rather than every advertisement’s RSSI value across every advertising channel (this makes the RSSI value appear to ‘jump around’)</li>
<li>Many existing distance conversion algorithms use ‘device calibrated at a single fixed distance’ approaches</li>
<li>No current mechanism takes advantage of the fact BLE advertisements are required to be done on all three channels, which have different frequency separations</li>
</ul>
<p>The Herald Project team have discovered that a reliable RSSI value can be achieved if you take every RSSI from every advertisement of a nearby device. There is a clear modal value for a device at a fixed distance once a few samples are taken.</p>
<p>What about moving devices, and devices with very different transmit powers? Interestingly, we have discovered that at ranges between 25cm and 800cm - the ideal range
for Digital Contact Tracing - the shape of the RSSI chart is consistent between devices, even if the RSSI value ranges are different.
The interference pattern across the three advertising channel frequencies has a dominant effect on RSSI calculations at ranges below 8 metres.</p>
<p>This chart does fluctuate rather than follow an exact linear or log scale, but the pattern of fluctuations is always consistent at these ranges. We’ve measured a set
of devices at 1cm intervals to determine this.</p>
<p>We’ve also determined that the fact that the three advertising channels have different frequency separation - and the fact we know that each advertisement is always
given on all three channels - allows you to construct a multi-variate algorithm to determine where you are on that curve. So long as the two devices are not introduced at a static distance and never move, and they move by at least 7cm, you can determine at what distance the phones are at. You don’t even need to perform this separation though - the fact it happens predictably can be used with a simple linear model at short distances to give a good distance estimate.</p>
<p>We’ll provide more information on these aspects in a full section of the website, but for now you just need to know this: In order to provide accurate distance estimation in Bluetooth Low Energy you need to:</p>
<ul>
<li>Take every BLE Advertisement packet for each nearby device and their RSSI values - don’t use an occasional single sample (most devices advertise between 1 and 5 times a second on all three channels)</li>
<li>Use a set of recent RSSI values to calculate a distance estimation</li>
<li>For risk measurements derived from this, make the time slices for risk ‘slice’ calculation as small as possible</li>
</ul>
<h3 id="the-herald-analysis-api">The Herald Analysis API</h3>
<p>In v1.3 we are providing a fixed-memory use streaming Analysis API. This maintains a fixed size sample list for each measurement for each nearby device. The output from one analysis algorithm can become the input of another. (Note: We use the term ‘sample list’, but remember - we provide ALL raw RSSI values, we don’t sample them.)</p>
<p>So for Digital Contact Tracing (DCT), for example, we expose the raw RSSI data to a distance conversion algorithm.
New raw samples are taken as they arrive from Herald’s Bluetooth layer and added to this fixed size ‘sample list’ which maintains the last X most recent samples.
This size is configurable by app developers. This produces a Distance value added to a distance sample list which is in turn exposed to a risk calculation algorithm.</p>
<p>(Remember too, that Herald is transport independent. Whilst our reference implementation today is Bluetooth Low Energy, in future we’ll support other transports, including Ultra Wide Band (UWB) radio).</p>
<p>Every so often the Analysis API’s algorithms will be invoked over the current sample lists. This will produce a new distance value from the several recent RSSI values which is added to the distance list. The recent distance values then are used to calculate risk exposure ‘slices’.</p>
<p>In a default implementation we’ll carry out new analysis runs every 5 seconds - giving a very small ‘slice’ to be added to a Risk exposure value. Application developers can customise this time interval to produce even thinner risk slices if they wish.</p>
<h3 id="what-this-means-for-accuracy">What this means for accuracy</h3>
<p>Herald now provides in v1.3 the most accurate and efficient way of calculating both distance and risk through its API of any Digital Contact Tracing or Proximity system for Bluetooth Low Energy. Epidemiologists can provide their own risk algorithms or simply change the configuration parameters of the sample ones we provide. The Logarithmic risk algorithm provided, for example, would allow you to use the UK’s Oxford Risk Model for COVID-19 with the Herald API given the right parameters.</p>
<p>In our testing we have found that using a self-calibrated distance mechanism provides accuracy of around 10cm at ranges between 25cm and 800cm. When you consider that dedicated technologies like Ultra Wide Band (UWB) radio has an accuracy of 5-7cm, and most existing BLE distance approaches are accurate to between 50-200cm, Herald provides quite an upgrade to distance estimation!</p>
<h3 id="where-to-go-from-here">Where to go from here</h3>
<p>You can take one of the existing distance and risk conversion algorithms and trial it yourself. Our demonstration app for iOS and Android now shows both raw RSSI and distance estimate values for the basic smoothed linear model. This is a self-calibrating model that becomes more accurate over time when used in a real environment with other phones. The model assumes a phone is carried by the user, therefore it should experience the full range of distances over time for calibration.</p>
<p>The default parameters assumes a typical phone will spends 8 hours/day within 3.7m of other phones (i.e. at work), and up to 5 minutes/day within 0.5m of other phones (i.e. passing in the street). As such, a quick test with two static phones on a desk will show wildly incorrect absolute distance estimates (e.g. 0.2m showing as 3m), however the relative estimates shall remain valid for detecting whether the phones have moved closer or further apart.</p>
<p>This model gets more accurate the more the phone is used with more other phones - so use it with your friends, family, and colleagues for a day or so in real world conditions before exclaiming about it’s accuracy!</p>
<p>The Analysis API is fully pluggable though, so feel free to come up with your own distance and risk algorithms and try them out. The API is very simple, and we’ll provide an Analysis API developers guide in v2.1.</p>
<p>v2.1 will also include a new Exposure API. This will be built on top of the Analysis API as a consumer of its ‘Risk’ samples, but also provide a pluggable mechanism to talk to Public Health Authority backends in order to exchange decentralised or centralised exposure token information. Importantly, this will include support not only for Herald tokens, but also BlueTrace (OpenTrace) and GAEN (Google-Apple EN API). This means that even if your national app uses another protocol like GAEN, plugging in the Herald API will allow you to use your own more detailed algorithms for your epidemiological needs.</p>
<p>v2.1 will also support multiple diseases and strains and multiple risk models for Exposure alerts for Infection Prevention and Control (IPC), with configurable ‘risk thresholds’ and advice triggering rules for each. We want to ensure that humanity is prepared for a future pandemic, and want to also provide something useful to stop other outbreaks, such as Ebola.</p>
<h3 id="get-involved">Get involved</h3>
<p>We’re community driven, so please come and <a href="/community">join the Herald community</a>
and help us build the future of the Herald project!</p>Herald Project ContributorsHerald allows for very regular Bluetooth RSSI readings. These can be used to estimate distance. In this blog we discuss why this is important, and what this information can be used for, and how we provide an accurate way of doing this in Herald.Code repositories migrating soon2021-03-24T08:00:00+00:002021-03-24T08:00:00+00:00https://heraldprox.io/blog/migrating-soon<p>As part of Herald’s formal adoption by the Linux Foundation we’re about to start migrating
our code repositories, website, and communication channels. This blog gives you a ‘heads up’
on the changes coming soon.</p>
<h3 id="by-the-end-of-march-2021">By the end of March 2021</h3>
<ul>
<li>Code repositories move to <a href="https://github.com/theheraldproject">our new GitHub org</a></li>
<li>Slack channels created on the <a href="https://slack.lfph.io">LFPH Slack instance</a>, and our own Herald one shut down for new content contributions</li>
</ul>
<h3 id="by-mid-april-2021">By mid-April 2021</h3>
<ul>
<li>Website moved from vmware.github.io/herald to https://theheraldproject.github.io/ but soon on our new domain of https://heraldprox.io/</li>
</ul>
<p>We hope these changes help build a
We’re community driven, so please come and <a href="/community">join the Herald community</a>
and help us build the future of the Herald project!</p>Herald Project ContributorsAs part of Herald’s formal adoption by the Linux Foundation we’re about to start migrating our code repositories, website, and communication channels. This blog gives you a ‘heads up’ on the changes coming soon.Website redesigned2021-03-22T08:00:00+00:002021-03-22T08:00:00+00:00https://heraldprox.io/blog/website-redesign<p>The Herald website has been redesigned to make it easier to find and consume relevant information.</p>
<p>We hope this will make the website easier to use, Herald easier to understand, and get you to the right place
more quickly.</p>
<p>Changes include:-</p>
<ul>
<li>Personae based top level navigation to make finding the right section easy</li>
<li>High level explainers to Herald and its applications to better explain the project to non contact tracing experts</li>
<li>Full width screen support to facilitate better readability</li>
<li>Section-only second level navigation to make it quicker to get to the information you need</li>
<li>Branding and license changes to get ready for the migration to the Linux Foundation Public Health soon</li>
<li>Kept existing link URLs the same so as not to break external websites/papers linking to our site</li>
</ul>
<p>New sections:-</p>
<ul>
<li><a href="/about">About Herald</a> - High-level project information explaining the value simply</li>
<li><a href="/reference">Reference</a> - If you quickly want our published data, information, or API docs you can get to them at this central point</li>
<li><a href="/research">Research</a> - Our background detail on Bluetooth conformance issues and scientific data publishing, analysis, and paper writing has a new home</li>
</ul>
<p>We’re not web development or information architecture experts.
If you have time why not help us out? We’re community driven,
so please come and <a href="/community">join the Herald community</a> and help us with deciding the
future of the Herald project!</p>Herald Project ContributorsThe Herald website has been redesigned to make it easier to find and consume relevant information.Version 1.2.0 released2021-02-16T08:00:00+00:002021-02-16T08:00:00+00:00https://heraldprox.io/blog/version-120<p>Version 1.2.0 of Herald is now available for iOS and Android!</p>
<p>Key features in this release include:-</p>
<ul>
<li><a href="/applications/ct#venue">Automated visit check-in and check-out</a> - Alternative to manual QR code system, and privacy preserving!</li>
<li>Improved performance, stability, and reliability between Android and iOS devices (including iOS 14.4 testing)</li>
<li>API changes to make adoption easier</li>
<li>Battery usage tweaks - we’ve reduced battery consumption by 30% again!</li>
<li>Initial release of the Simple Payload for Digital Contact Tracing</li>
</ul>
<p>For a full list of changes please see the release notes:-</p>
<ul>
<li><a href="https://github.com/theheraldproject/herald-for-ios/releases/tag/v1.2.0">iOS Release Notes</a></li>
<li><a href="https://github.com/theheraldproject/herald-for-android/releases/tag/v1.2.0">Android Release Notes and library download</a></li>
</ul>
<p>We’ve gained new developers and adopters recently. We’re community driven,
so please come and <a href="/community">join the Herald community</a> and help us with deciding the
future of the Herald project!</p>Herald Project ContributorsVersion 1.2.0 of Herald is now available for iOS and Android!