[Feature Request] Receive temperature and display them

[X-Ryl669]

Let's say you have 2 sensors node. Would it be possible that each node synchronize (somehow) and receive each other measurement to display them sequentially ?

For example:	Time	Sensor 1	Sensor 2
0s	Display: 23°C	Display: 12°C
1s	Broadcast its temp	Broadcast its temp
2s	Display: 12°E	Display: 23°E (E used to mean external)
3s	Display: 23°C	Display 12°C

This way, one wouldn't need to have/run a gateway to see the exterior temperature. I know that BLE advertisement are randomly emitted to avoid collision, but is there a way so have a pseudo random instead, so that the seed is known and the sensor can wake up and listen when the other sensor is advertising ?

[pvvx]

This is possible only with the implementation of "Bluetooth Basic Specification version 5.4" ("Periodic Advertising with Responses (PAwR)" functionality). But this standard is not supported by third-party systems. Linux and Windows does not yet fully support Bluetooth ver 4.2 either.

A "PAwR" or alternative implementation requires a more powerful power supply than the CR2032...

The tests (an alternative method compatible with bt4.2..5.0) showed a consumption of 20..45 µA in the mode after successful synchronization and 3..6 mA before synchronization. Synchronization due to collisions on the air may be disrupted, and a new synchronization requires dozens of ms with the receiver always on. Old Test

---

Another method is possible when using an external device, by connecting to a thermometer and transmitting third-party readings to the screen. https://github.com/pvvx/ATC_MiThermometer#interface-for-receiving-and-displaying-data-on-the-lcd https://github.com/pvvx/ATC_MiThermometer#primary-service-uuid-0x1f10-characteristic-uuid-0x1f1f : 0x22 - Get/Set show LCD ext.data 0x60 - Get/Set LCD buffer

[X-Ryl669]

I'm not sure I understand. In PAwR, you still need an host IIUC, since it's the host that's (triggering an) answering to the multiple devices at once.

I don't understand what the "old test" was, but it seems it's closer to the request. I'm probably wrong, but let's say:

1. We know the same firmware runs on both device
2. Each device advertise as usual (with their respective configuration, let's say 30s to save battery)
3. On boot, a device listen during the advertisement interval (or is instructed by a BT host, like your phone when it's advertising to avoid wasting battery). If it receives a advertisement from another device, it reply with some (new) message: 0xWhatever - Sync me
4. The other device, receiving this message, reset it's advertisement interval => starting from now on, both device are time synchronized
5. After the first device replied, it sleep for the advertisement interval
6. Upon wakeup, it advertises its sampling + listen to other device sampling that will come next (maybe a small constant delay is required to avoid collisions). It then display them both on its screen
7. The other device does the same thing too=> they are both synchronized.

Both are then cycling on the screen with external sensor's sampling.

Or, in step 7, the other device could use 0x22 to set the screen of the former, I don't know if it's possible.

[pvvx]

PAwR allows the server to transmit any readings to the thermometer for display.

"Old Test" is the implementation of the similarity of "PAwR", but with synchronization to another device. Almost according to your description.

An external device transmits a typical advertisement. The receiving device must accept this advertisement, but also transmit its own. This requires synchronizing the transmission of ads from both devices. Otherwise, there will be reception issues during transmission.

According to the standard, the advertising period should contain an additional random delay. Not a jitter, since the new period begins with the end of the transmission of the past.

The available SDKs from Telink (and many others) do not allow you to turn on the receiver for a given time without synchronizing with the transmission. But by redesigning, it was possible to make a suitable option - the transfer of advertising with switching to reception and completing reception through a timeout or receiving the necessary package of advertising.

The response reception window has a fairly long time interval (usually 15 ms) with a consumption of 6 mA. The probability of receiving a response is not equal to 100%, since collisions occur in radio communication. And the longer the advertising period, the greater the additional delay -> a larger reception window is required.

As a result, if everything is already configured and synchronized, there is an increase in consumption by 7.5 ms * 6 mA.

Upon receiving the desired packet, the reception is interrupted and the advertising period is counted from it with a small deduction (-5..7 ms), since we do not know the real period of the transmitting device. But if there was a loss (there was no reception in the window), then a new synchronization cycle is required. A missed reception will give an unknown time shift and will already require an increase in the reception window of 30 ms. Etc. Further, if the advertisement is received, then the reception window is gradually reduced to 15 ms (or less, until the next disruption).

The initial, primary synchronization cycle requires an acceptance window of more than 1 advertising period.

All this introduces quite a large expense and the CR2032 is not suitable.

When connected, the periods of a working receiver are up to several hundred us. BLE timings are gated to 1 us, and when they leave, the connection may be lost. Therefore, in connection mode, we have significantly lower consumption than with the scheme described above. With a "connection interval" of N seconds, the consumption is less than with an "advertising interval" of the same N seconds, due to the operation of the transmitter on one channel, and not duplication of advertising on three, followed by a window of ~ 500 microseconds to receive a "connect" message or request additional information.

With PAwR, everything happens synchronously, clearly, and there is no loss of synchronization. That is, this has already been implemented during the transmission of typical advertising - always after each transmission on each channel, the receiver works out with fixed periods to receive a connection request or additional advertising information. But the BLE advertising standard before the introduction of "PAwR" was limited only to these requests.

[X-Ryl669]

Ok, I understand better now. Thanks for explaining.