Long range coexistence

RE: Long range coexistence

MartinBL — Tue, 12 Dec 2017 08:40:59 GMT

No, unfortunately there is no migration guide for S140 6 alpha (there are usually no migration guide or specification for alpha releases), but I suppose you have seen the readme.md file and sdk_patch.diff file that comes with the download? They help you migrate the throughput example, but migrating all the other BLE examples in the SDK is still a pain. Anyway, as far as I know SDK 15 will be released when the S140 is in production version, and the S140 production version will be released when the nRF52840 SoC goes to production version sometime in Q1 next year.

RE: Long range coexistence

damien5606 — Mon, 11 Dec 2017 17:08:25 GMT

Martin,

When I tested with S140 v6, it was with the ble_app_att_mtu_throughput example. I'd like to test it with a uart_example (because I'm more familiar about how it works) provided with SDK v14 but unfortunately it seems they're only compatible with S140 v5.2 and I've trouble understanding the SDK migration guide S140 v5.2 to S140 v5.3, and it seems there's not migration guide from s140 v5.3 to v6.

I'll test again with the ble_app_att_mtu_throughput example S140v6, power 9dBm, and send you the results soon, in the meantime, do you have any idea when'd be the release date for a new SDK compatible s140v6 ?

Thank you for your time. -Damien

RE: Long range coexistence

MartinBL — Mon, 11 Dec 2017 15:24:15 GMT

The main files in your link seem to be compiled with S140 v5 alpha which has a known bug that possibly affects throughput on long range. You say that you can see the same on S140 v6 alpha though, so can you share the code you used for that too? As I mentioned in my edit above I'm not able to reproduce it with S140 v6 alpha, so maybe the issue is in your application.

RE: Long range coexistence

damien5606 — Mon, 11 Dec 2017 10:00:43 GMT

Actually It'd be interesting to see the results with the 3 peripherals side by side in one room, and the 3 centrals in an other room side by side.

RE: Long range coexistence

damien5606 — Fri, 08 Dec 2017 18:48:20 GMT

First thank you a lot for all those efforts to try to solve my case.

Yes that make sense but I don't have the same results, maybe It'd be different with more than 3 links and further ?
I don't think so
I'm using a mix with 0.91, 0.92 and 0.93

I did a test with the uart exemple phy coded, 1kBytes/s 10 links (CI 12.5ms, ATT_MTU payload 23, dle off, phy coded), I tried at my office everything was fine (every central was receiving 1kB/s) then I went to a football field, I set up 10 centrals at one point: link text 70m from the peripherals https://ibb.co/mprQKb when I use only 2-3 links, everything is fine but when I use 10 links I see huge data rate variation (see at the bottom left : https://ibb.co/nvTi5G) (SD140 V0.5.2) and I observe similar behavior with SD 140 V0.6.

Here is my main.c : www.dropbox.com/.../AAC-knx-D7AeQZhgq-TCrgMRa

RE: Long range coexistence

MartinBL — Fri, 08 Dec 2017 17:55:47 GMT

I have done some testing on my own and I am not able to reproduce your problem. I used:

SDK: 14.0.0
Example: \examples\ble_central_and_peripheral\experimental\ble_app_att_mtu_throughput with S140 v6.0.0-6.alpha patch. Here is the example hex file that I used.
Softdevice: s140_nrf52840_6.0.0-6.alpha_softdevice.hex

Throughput test parameters:

MTU [bytes] 23
CI [ms] 50
DLE yes
Conn evt ext yes
Phy coded (S8)
Data transfered per test 256kB

Kit versions:

Link 1: 0.9.0 & 0.9.0
Link 2: 0.9.2 & 0.9.0
Link 3: 0.9.0 & 0.9.0

I did the tests in the office after working hours, so the probability of significant interference from other BLE devices were low (but there is wifi of course). I manually started each measurement using a serial terminals, but all links usually started the throughput tests within seconds from each other. I.e. most of the time, they transferred data at the same time. I transferred 256Kb per test, which typically took 50 seconds to complete.

I have 6 kits which I have configured as 3 peripherals and 3 centrals, all connected in pairs (3 sepparate links). I did 20 tests with the kits placed in various positions. The first three tests were with all of the kits laying on at my desk, and the fourth with two of the kits in a separate room (“long range test”). Four setups with 5 tests in each. All three links transferred data at the same time. I also tried several tests with only a single link transmitting at the time to compare. As you can see below, the speeds are about the same in all tests when the kits are at my desk. When I moved two of them away, their respective throughputs naturally went down, but the important thing to notice is that they performed consistently. I am not able to reproduce what you report regarding links that changes performance significantly from test to test.

Here are the results:

Here is the spreadsheet I made.

And here are the test setups:

Does this make sense to you?
Have I forgotten something of importance?
What kit versions are you using?

EDIT 11.12.17

I did some more tests today:

Same software and link parameters as yesterday, but I reduced the TX power to -30 dBm to simulate long range, and used 10 kits to make 5 links. I am still not able to find anything out of the ordinary. There were some variations from link to link, but each link performed fairly consistent between all tests:

RE: Long range coexistence

MartinBL — Thu, 07 Dec 2017 13:06:36 GMT

Still looking into this. Here is a relevant case: devzone.nordicsemi.com/.../

RE: Long range coexistence

damien5606 — Mon, 04 Dec 2017 13:51:42 GMT

Hi Martin, Thank you again for this answer, I did some tests at my office (6 tests for 2links, 6 tests for 3links) link text I did not put the result for one link because it's always between 39,5 and 40,5kbps so the speed is ok. Note: For the 3 links setup, at some point (after the test n°4) I thought it could come from the serial link, so I plugged 2 links to my computer, and one link to an other computer (without changing the boards location or placing some object between the links), the results are even worse.

Ok, I'll try this option
I'd like to receive (notification only) from 50 devices (sending 0,5KBytes/s each) in long range mode, so I planned to use 10 centrals, each one connected to 5 peripherals, I'm not sure if I understand the end of your N°2.
I'm basing it by the fact that when a link stop communicating, the other increase their speed.

Regards, -Damien

RE: Long range coexistence

MartinBL — Mon, 04 Dec 2017 12:56:22 GMT

Hi,

I have talked with the Softdevice team and we don't think there is anything wrong with the hopping algorithm itself.

However it could be interesting if you tried to use an individual channel map on all centrals. For example, configure link 1 to use channel 0-5-10-15-20-25-30-35, link two to use channel 1-6-11-16-21-26-31-36, and so on.
The second thing I would like to ask is whether it is possible for you to use fewer centrals? It is possible to have more than 5 concurrent links, so unless your use case prohibits it, you can e.g. have three centrals with 16, 17, and 17 links each.
You say that "it looks like all the links are using the same one". What are you basing this on? Do you have any other reason to believe this than the varying throughputs?

RE: Long range coexistence

damien5606 — Tue, 28 Nov 2017 15:09:00 GMT

I'd have difficulties to run test again in the near future
I use serial communication to my computer & putty to run those test, so there're a few seconds between I type "run" on each of my terminals but I every times run the tests in this order link 5 then link4 then 3 then 2 then 1.
from the test I did in my office, the results were: link1) 250.146seconds, link2) 290.205 seconds, link3) 308.410 seconds, link 4) 282.760 seconds, link 5) 332.64 seconds.

If I understand well how Bluetooth work, there're 37 communication channels, and on my test, it looks like all the links are using the same one, I thought the frequency hoping would avoid that, or maybe there're an issue with the throughput_example_connecting_on_long_range I'm using

RE: Long range coexistence

MartinBL — Tue, 28 Nov 2017 13:33:06 GMT

Hi Damien. I'm still looking into it.

Would it be possible for you to provide some statistics? Could you e.g. run 10+ tests and provide the results in a table of some sort?
Do you make sure to start all the tests on the 5 links at the same time? If you e.g. start one of the links significantly later than the others I would assume it will avoid interference from the other devices at the end of the test and achieve a higher average throughput.
You are transferring 1MB of data in each test right? How long does each test take?

RE: Long range coexistence

damien5606 — Tue, 28 Nov 2017 09:33:48 GMT

Hi Martin, I'd be really grateful if you can give me any updates on this case. Thank you, -Damien

RE: Long range coexistence

damien5606 — Fri, 24 Nov 2017 13:22:10 GMT

Thank you for your answer Martin, Q1) yes, each Central connect every time to the same peripheral. Q2) No, sometime it changes, an other link can be faster. Q3) I mean that the connection speed of each link is steady, the only thing that can make it faster is the "end of communication" of an other link and the only think that make it slower is a new communication. Q4) https://ibb.co/gLmWSm https://ibb.co/mR69DR

I put the devices side by side following this order : From the left C1,C2,C3,C4,C5 (see attached picture) and at the peripheral location from the left P1,P2,P3,P4,P5.

Note: this is a test in my office (board 1m from each other :1) 33,53Kbps. 2) 28,9Kbps. 3) 27Kbps 4)29,6Kbps 5)25,26Kbps

When I connect only one link I reach 40Kbps.

RE: Long range coexistence

MartinBL — Fri, 24 Nov 2017 12:32:52 GMT

Start part 2/2:

Maybe e.g. P1 and C1 coincidentally have better or worse radio performance than e.g. P2 and C2. Or maybe it depends on P1 and C1 positions relative to P2 and C2? Maybe you have the devices mounted in a rack and that the devices in the middle consistently perform worse than the devices at the ends?

If one link consistently performs better than the others that would be really strange, unless the issue is caused by poor antennas or positioning of the devices. Because, as @endnode mentions, BLE utilizes frequency hopping mechanisms, meaning that each link hops between radio channels in a pseudo random pattern. In the long run this should even out any issues with interference between your devices or other radio sources in the vicinity.

RE: Long range coexistence

MartinBL — Fri, 24 Nov 2017 12:32:25 GMT

Hi Damien,

I have a few questions regarding your test setup.

Q1: Are the devices always connected in the same configuration? Like this:

Peripheral 1 <-- Link 1 --> Central 1
Peripheral 2 <-- Link 2 --> Central 2
Peripheral 3 <-- Link 3 --> Central 3
...
...

Or is it random which devices connect from test to test?

Q2: You mention further up that e.g. link 2 is 11 kbps and link 4 is 28 kbps. Is link 4 consistently performing better than link 2 in every test?

Q3: You say that usually when a connection starts fast, it stays fast. This implies that sometimes it happens that the speed drops during a test?

Q4: Do you mind uploading a picture of your test setup?

End part 1/2

RE: Long range coexistence

endnode — Thu, 23 Nov 2017 21:41:58 GMT

This is interesting however I cannot help further. You can either wait if some Nordic support person will pick this up or (because we have diverted from original question) submit new query with specifically all these details (maybe some more inputs like screenshots from metering app or photos of your set-up would help). Alternatively ask through MyPage portal (closed support ticketing system) on main Nordic web page.

RE: Long range coexistence

damien5606 — Thu, 23 Nov 2017 14:53:10 GMT

Yes (for you first question). Usually when a connection is fast (on this example the link 4) it stays fast during all the exchange. When I do my tests, I use the throughput_example_connecting_on_long_range provided with the S140 V6, so when It sent the 1024KByte, the central disconnect, and I can notice that when the fastest links (link 4, link1, link5 here) disconnect, the data rate of the remaining slow connection increase a lot.

RE: Long range coexistence

endnode — Thu, 23 Nov 2017 14:00:13 GMT

You mean that by operating 5 independent links at the same time and measuring the throughput on them leads to various values from 10 to 30kbps? And how these values vary in time on each link? Are they steady for seconds/minutes or they fluctuate randomly on each of them?

RE: Long range coexistence

damien5606 — Thu, 23 Nov 2017 11:14:19 GMT

I was in open air environment. I had no problem with one link, I've tested it many times and the result were as good as expected by Nordic and the repeatability was great. The problem appear when I had the 4 other links, the data rate drop by 3 or 4, and a weird thing is that some links are way faster than the others (while the receivers are all at the same place and the emitter are all at an other place, 50m further, the antennas are facing the same direction, at the same distance from the ground)

Link 1) 15.78 Kbps Link 2) 11.31 Kbps Link 3) 10.30 Kbps Link 4) 28.22 Kbps Link 5) 13.22 Kbps

I've done many tests, and the results were similar to this one, and changing a lot from one test to an other. Thank you for your help.

RE: Long range coexistence

endnode — Thu, 23 Nov 2017 11:02:04 GMT

(2/2) In case you really see some strange behavior and you have this use-case as core then you might need to invest into radio analyzer (BLE sniffer). And because you use latest BT5 features you would need one of latest commercial analyzers (because free tools like nRF Sniffer are not ready for air-speeds different to 1Mbps) so we are speaking about 10-20k USD investment. Are you sure your problem is so serious and blocking?:)

RE: Long range coexistence

endnode — Thu, 23 Nov 2017 10:37:45 GMT

First of all what is your environment? The fact that you use long range air-speed doesn't mean you will beat interference in difficult environments, 2.4GHz radio is nasty thing which behaves counter intuitive sometime. Then you can debug this on several levels: normally link (HW) capabilities are tested by DTM which now is released (as far as I understand) innRF5 SDK with BT5 features such as different air-speeds. This would test nicely that both devices at that distance have on given channel naturally low packet error rate. If this fails you already have problem in "simple" case meaning either your environment is too difficult for current BLE technology or your HW faulty. If this is OK then you can go to more high-level tests like having throughput demo on single link and again carefully get statistics on tests (not running it once;). An finally do it with multiple links.

(1/2)

RE: Long range coexistence

damien5606 — Wed, 22 Nov 2017 22:15:44 GMT

Thank you endode for this answer.

I tested the throughput demo on long range today (throughput_example_connecting_on_long_range provided with the S140 V6) with 5 links (5 nRF52840 peripheral sending to 5 nRF52840 central, softdevice S140v6.alpha), the peripherals were 50m from the centrals. I've run the example one by one following those parameters (PHY 250kbps, conn interval 50ms, no dle, ATT_MTU 23)

And I saw huge perturbations, the data rate was divided by 3 or 4 at each of my tests when the links were exchanging data all together. I was thinking that they ended up on the same channel and they disturbed eachother, but you told me it's not really possible so I'm confused. I'm not sure how to check the channel map but if more than one channel is selected it shouldn't really happen...

Any idea ?

Thank you, -Damien

RE: Long range coexistence

endnode — Tue, 21 Nov 2017 14:41:30 GMT

Hi Damien,

The problem of shared channels is only on 3 advertising channels but once the connection link is established all remaining 37 channels (unless devices restrict some of them through channel map) are used through frequency hopping mechanism. Since BLE is based on timed events and most of the time there is silence the capacity of whole 37-channel spectrum is enormous and even if some collisions happen here and there the link is ready to handle it transparently (so applications on top don't even notice except small drops in actual data throughput). Normally you can have hundreds or even thousands of active links with very little interference in the spectrum.

On advertising channels again devices use different timing (and there is mandatory jitter added so even if they meet on few events and interfere for few packets they will drift quickly to different timings and problem is solved) but in certain situations you might experience more crowded situations and interference. But that's when you have hundreds or rather thousands of active broadcasters or dozens of very active scanners vs. few low-frequency advertisers. So far you should be fine (and maybe some refresh about how BT LE PHY and Link Layer work would help;)

Cheers Jan