Interacting nrf51822 Beacon to simulate spreading of disease / record social network

[Tobias Hofbaur]

Hello, I would like to simulate the spreading of a disease using the nrf51822 beacons. My question is if my envisioned project is possible as I'm completly new to nrf51822.

The beacons should communicate with each other and send their data to a central node (probably a NRF51822 dongle). I see two options how to realize my project.

1. The beacons record contacts which are below a certain distance and this data can then be read with the central node. The disease would then only be simulated on a PC.

2.) (preferred) Each beacon transmits its status and upon being "close" (TBD) and for at least some time (TBD) to an infectious beacon, becomes infectious itself and changes its transmitted status. Bonus here would be the recording of the infect time and source.

Do you think this can be achieved using the nrf51822 beacons? Can I use the nrf51822 dongle as central reader and use it to programm the beacons?

Thanks for your help in advance. Tobias

[tesc]

Hi Tobias,

This sounds like a fun project, and yes it would be possible with nRF51822 Beacons.

It would be possible both with Bluetooth Low Energy (BLE) or by using a simple proprietary protocol. Which one to use depends on what are your requirements and how much "help" you want from using ready-made features already existing for BLE.

Since the beacons have two states (healthy and diseased) you could let the diseased ones transmit ("broadcast" in BLE terms) and the healthy ones receive ("observe" in BLE terms). When the RSSI of the received disease broadcast is above a given threshold for a given period time, then the healthy node changes state from healthy to diseased (i.e. switches from receiving to transmitting).

You can record the source address (for the disease) and a timestamp at the point of switching, provided that you have code in place to keep track of time. You can also for instance broadcast the timestamp and the source as part of the disease broadcast, so that it can be read using a central node not part of the disease network. If you use BLE you can even have a smartphone app listening to those broadcasts and show the details, graphs and whatnot, on the phone.

To reset the beacon (or to toggle the disease status) you can use the buttons, and the rgb led can indicate disease status.

For reprogramming the beacons you can for instance use over-the-air direct firmware update (OTA DFU). In that case programming could also be done using Android and iOS phones, as well as by using an nRF dongle connected to a PC.

Again I think this sounds like a fun project, and I do hope to hear more about it along the way.

Regards, Terje

[Tobias Hofbaur]

Hi Terje, thank you for your answer, which was exactly what I had hoped for. As I am completly new to BLE I will probably have a lot of questions and it would be great if I could post them here. So far I have the following questions to clarify my understanding:

• As hardware then I only need the beacons and the dongles, unless I want to do the original flashing via the DK?

• Does the box beacon have the correct bootloader needed for OTA DFU?

• Can the beacons operate in receiving and transmitting mode simultaneously (or be blind only for the time needed to send)? I would like to have the possibility to "cure" the beacons by sending a signal (either to restart or as the cure for the disease)

• To programm I would only change the application, leaving SoftDevice and bootloader untouched?

• the maximal message size is 20 byte. but I could split larger messages over notifications?

[tesc]

You ask a lot of questions. I will try to give some answers, but the best would be for you to have a look at our online resources, to search for questions that may have been asked before, and to post a new question if noone has posted the same question before.

• It would be a good idea to have a DK, even though the beacon does come with a suitable bootloader. This is both because the DK offers better opportunities for development, such as a UART or RTT debug connection, and because it will be quicker to program the beacon using a DK and a TagConnect cable than by using DFU.

• The radio can only be used for either RX or TX at the same time. For BLE it toggles between the two modes to communicate both ways, according to the BLE protocols.

• Depending on your solution and your needs you may want another SoftDevice than the one preprogrammed on the beacon.

• Notifications is one way to send longer messages than a few bytes. I suggest you have a look at our BLE tutorials to get familiar with BLE and concepts such as peripheral and central before deciding how BLE would fit your needs. The nature of your project may or may not fit nRF OpenMesh, due to the distributed nature of nodes rather than a Broadcaster-Observer pattern, but there are other possibilities within BLE or other protocols as well. In any case I would recommend doing some studies on BLE to get to know what concepts are there and what could be used for what purpose on your project.

[Tobias Hofbaur]

Thank you for the reply Terje. I am digging through the documentation and examples (which I find great btw) but they are quite enormous. I wanted to make sure I was off in the right direction. I will post an update on what I achieve.

[tesc]

Yes, there is a lot of information around, and BLE is a complex field, the Bluetooth specification a behemoth of 2700 pages. I am still hoping to find a simple yet comprehensive introduction to BLE one day, but so far I have been mostly out of luck. Personally I learned most of the BLE basics from the book Getting Started with Bluetooth Low Energy (2014, O'Reilly Media), you may want to check it out.