ATC_MiThermometer
ATC_MiThermometer copied to clipboard
pvvx
Bluetooth5.0+ PHY (LE 1M/2M/LongRange:500K/125K), CSA1/CSA2 (Channel Selection Algorithm)
Can you explain a bit more about this?
Is this implemented on the sensors from version 3.7? Even if the sensors are Bluetooth 4.2?
Are they now broadcasting on multiple channels so a BT chip capable of CSA can pick up more readings?
Thanks in advance, just trying to understand it.
These options relate only to BLE Сonnection. Advertising packages are still broadcast on 3 typical channels, regardless of BT version. In new versions BT, the advertising package may indicate an additional channel, but in this case it is not used.
Is this a limitation with the hardware/runtime libraries, or would it be possible to make it advertise over, for example, S8 coded PHY? The, probably obvious, use case beeing able to monitor the device using the BLE 5 long range features which I suppose would greatly increase the current, rather limited, range(?)
BLE standard: Only Extended Advertising come in other formats.
In the current version, "Extended Advertising" is not supported. Strongly increases consumption and does not make sense, because. the main advertising channels should still work on PHY 1 Mbps. And to find out on which channel "Extended advertising" is possible only after receiving on a typical channel (PHY 1 Mbps).
Coded PHY requires a special device to receive advertisements. Regular adapters and smartphones do not work with advertising on shared channels on an Coded PHY.
Coded PHY is possible only after negotiation in connection mode on 1M PHY. A connection request is always executed at 1 Mbps... Then you can switch the PHY format.
Ah, I see, so what you're saying is that there's no standard for (optional) coded advertisements(?) Essentially making BLE long range per se practically useless since a peer always needs to be able to receive the standard mandatory 1M advertisements anyway, in order to negotiate a coded connection or learn about coded "extended" advertisements?
I know that coded PHY is an optional feature not supported by most devices today. The target audience here is obviously those of us that do have a long range capable adapter and need the extended range.
I know that coded PHY is an optional feature not supported by most devices today. The target audience here is obviously those of us that do have a long range capable adapter and need the extended range.
TLSR825x supports ZigBee and has a ZigBee SDK from Telink. OTA for the BLE variant does not have the ability to download the ZigBee version. ZigBee has a larger firmware code size. Dual OTA solves ZigBee firmware. The first block is to change the Flash markup for OTA with ZigBee ... The second is the ZigBee code itself. But I don't want to support the ZigBee version.
Will the LongRange setting allow me to use the thermometer over longer distances?
Will the LongRange setting allow me to use the thermometer over longer distances?
No, because manufacturers ignore this feature in Bluetooth 5.0 on user devices. Long Range provides a tenfold increase in distance. Some newer BT5.2 adapters on Linux can be forced to receive ads in LongRange. But then they won't accept standard BLE. There are also only a few implementations in smartphones that automatically accept standard BLE advertisements on different PHYs. Those. There is no implementation of Bluetooth 5.0 (6 December 2016) yet, although this is just a software solution.
Read the two posts above for more details. PS: It is quite possible that this was done in order not to displace ZigBee.
According to the data from the nRF Connect Android application, my device, i.e. the Samsung Galaxy S20, supports extended BLE range.
In this case, will setting a greater range from the thermometer allow me to connect over greater distances?
According to the data from the nRF Connect Android application, my device, i.e. the Samsung Galaxy S20, supports extended BLE range.
It doesn't say anything. All modern smartphones are capable of accepting "Extended Advertising" in any PHY format, but typical (for connection and polling) advertising is only on 1M PHY. You didn't read the comment above:
Essentially making BLE long range per se practically useless since a peer always needs to be able to receive the standard mandatory 1M advertisements anyway, in order to negotiate a coded connection or learn about coded "extended" advertisements
First understand the standards... The custom firmware supports LongRange on 1M PHY connection request and transition to LongRange.
I'm very sorry. I read the comments but I just didn't understand them. I just don't understand why there is no long range support for standard advertising. It makes little sense to me not being able to connect with just a standard advertising. This is probably due to my lack of very good knowledge of the Bluetooth standard.
The use of long-range Bluetooth has a lot of sense and applications.
Almost every cheap smartphone from last year has the following options:
But that doesn't mean it will accept standard advertisements in different PHY formats.
To connect, you must accept standard advertisements on the 1M PHY. Only after a connection is established on the 1M PHY is it possible to switch the PHY format.
"Extended Advertising" is the transmission of a header on the 1M PHY that indicates on which channel and in what format the data itself will be transmitted. Those. without receiving on the 1M PHY, you will not know where and how to receive the LongRange message. Reception of standard advertising on the main channels in the longRange format is not implemented on most devices. And apparently this was done on purpose so as not to force ZigBee out of the market or for some other corporate purposes...
Even to receive "Extended Advertising" with LongRange in the "nRF Connect" program, you need to switch the options in the settings.
Work in BLE Long Range is programmatically limited on all user devices, including BT-USB adapters. And the point is not in the hardware implementation, but in ignoring the standard.
Enabling the BLE5.2 options in the custom firmware allows you to support "connection" on all PHY encoding options that your adapter requests. But the transmission of advertising on other than 1M PHYs in the current version is not implemented due to the lack of support from the reseived side.
Thanks for the clarification. Is there any leaks or indications that bluetooth over longer distances will work better?
https://novelbits.io/bluetooth-long-range-how-to-achieve-results-over-1km/ https://www.youtube.com/watch?v=w4PbxVwg83M
After digging deeper into the subject, I do NOT agree that advertising on primary channels is limited to 1M PHY. BLE 5.0 permits the ADV_EXT_IND PDU to be sent on the primary advertising channels using Coded PHY. So it is true that it requires the use of extended advertising.
https://novelbits.io/bluetooth-low-energy-advertisements-part-1/
I also agree that it would significantly impact power requirements. Because S=8 requires 8x the radio time for the same volume of data, because of the overhead of extended advertisement, and because it still needs to do legacy advertisement i parallel.
Nevertheless, I'm tempted to try to cook up a proof-of-concept to explore this further, although I'm not sure I will be able to.
If you managed to do something, please share it. Personally, I hope that bluetooth in the new versions will enable long range without extended advertising.
Experimenting with the inclusion of LongRange for "Extended Advertising" on the main channels show that none of the available adapters in the application for 'HA' does not accept this option. Also checked dozens of smartphones in nRFConnect released that year - the situation is similar. "Extended Advertising" transmitte with header on 1M PHY and data on S8 is successfully received by most (BT5.0+ adapters).
Further, the 'coded PHY' advertising option cannot be used immediately for connection and scannable.
And second: Available SDK versions from Telink do not support multiple "Extended Advertising"
This is a BLE Spec standard interface，used to enable/ disable Extended Advertising，please refer to <Core_5.0> (Vol 2/Part E/7.8.56 “LE Set Extended Advertising Enable Command”), and understand it in the context of the SDK’s enumeration type definitions and demo usage. However, currently the SDK only supports 1 Adv Sets, so this API is not supported for the time being and is only reserved for multipleAdv sets in the future. However, the Telink SDK has written a simplified API based on this API function to operate on/off 1 Adv Sets for more efficient execution. The simplified API is shown below, with the same input parameters and return values as the standard API, but is only used to set 1 Adv Set.
Using the library reverse, I got the ability to embed "Extended Advertising" into the "custom firmware" option. But such a version cannot support all current options and requires a separate implementation. Also, the implementation of "Extended Advertising" in closed SDK libraries leads to unstable operation of the device as a whole. A normal implementation of the libraries or their open source is required.
As a result, the only option available to users to increase the range of reception and transmission remains the option of using not BLE, but the ESB protocol. ESB (Enhanced ShockBurst) - in the common people it is "RF24". With settings on the BLE protocol...
If you managed to do something, please share it. Personally, I hope that bluetooth in the new versions will enable long range without extended advertising.
This has not happened since the release of the BT5.0 standard in December 2016, although the hardware of 90% of the BT controllers already allowed it. :P
I do not know for sure. I can only guess... The hardware of the chips does not care what synchronization to accept, since the modulation is the same for different PHY. The transmission frame header contains all the necessary information, and then the program's business. And the message in the Coded PHY is simply discarded, since it does not match the software detector of the correct frame. Perceived as noise.
Are there any open source drivers (I mean mostly Linux here) that have a patch made to make this work?
On Linux, no patch is needed. You need to switch the adapter to encoded PHY and it will accept ads on LongRange. But others, standard BLE, will not be accepted.
Nobody is engaged in patches of internal software of adapters. It's easier to make your own BLE advertising message receiver or use a full-fledged sniffer.
If I run an encoded Bluetooth PHY in Linux and then connect to a thermometer with your software, will I get a greater range? Of course in your firmware I will choose LongRange BLE.
I found such a way to run an encoded PHY. Do you think he is good? I can't find anything better on Google on this topic, but I'm probably looking in the wrong place. https://github.com/apache/mynewt-nimble/issues/893
If I run an encoded Bluetooth PHY in Linux and then connect to a thermometer with your software, will I get a greater range? Of course in your firmware I will choose LongRange BLE.
Nothing will work - the program will switch the BT adapter to standard mode.
Wariant : primary BLE_PHY_1M, secondary BLE_PHY_CODED
blc_ll_setExtAdvParam(ADV_HANDLE0,
ADV_EVT_PROP_EXTENDED_CONNECTABLE_UNDIRECTED,
adv_interval, adv_interval + 10,
BLT_ENABLE_ADV_ALL, // primary advertising channel map
OWN_ADDRESS_PUBLIC, // own address type
BLE_ADDR_PUBLIC, // peer address type
NULL, // * peer address
ADV_FP_NONE, // advertising filter policy
TX_POWER_0dBm, // TODO: advertising TX power cfg.rf_tx_power
BLE_PHY_1M, // primary advertising channel PHY type
0, // secondary advertising minimum skip number
BLE_PHY_CODED, // primary advertising channel PHY type
ADV_SID_0,
0); // scan response notify enable
// debug!!! Fix CodedPHY channel
blc_ll_setAuxAdvChnIdxByCustomers(20); // auxiliary data channel, must be range of 0~36
(Random T & H for test)
Wariant : primary BLE_PHY_CODED, secondary BLE_PHY_CODED
Not accepted on standard adapters.
nRF Sniffer:
As a result, if LongRange is enabled, then it will be impossible to connect to this thermometer. Switching format options on the fly does not allow the SDK and a lot of problems arise. Especially for ordinary users. It will raise a lot of questions and dissatisfaction :)
Similarly not accepted in 'HA'.
I also agree that it would significantly impact power requirements. Because S=8 requires 8x the radio time for the same volume of data, because of the overhead of extended advertisement, and because it still needs to do legacy advertisement i parallel.
More than 8 times - advertising remains on the main channels + data, on another channel.
Full LongRange (Coded PHY S8, Coded PHY S8):
Legacy (1M PHY)
