I have some difficulty in understanding the description of your anchor points. Can you elaborate that a little? Any logs?
Let's take a step back... Are you working with our tag3 board? Are you using one of our apps or your own?
Do you have any issue realising the below scenarios?
We are not working with tag3 board, and we using our own APPs.
Our network structure is cluster tree, built with BCM20736, such as:
1. Master A's 1st connection is with SlaveB
2. Master B's 1st connection is with SlaveC
3. BCM20736_B work in Master/Slave mode
When master A has its 1st connection with B, the anchor point of master A is the time point of 1st data package transmit between A & B in connection event, it's called anchor point in BT spec4.0. Here we call this as Anchor_point_1. The interval of A & B is start at this Anchor_point_1. It means that, start at Anchor_point_1, A & B must have data transmition in each interval.
The same as above,
When master B has its 1st connection with C, the anchor point of master B is the time point of 1st data package transmit between B & C in connection event. Here we call this as Anchor_point_2. The interval of B & C is start at this Anchor_point_2. It means that, start at Anchor_point_2, B & C must have data transmition in each interval.
At Anchor_point_1, B must transmit data with A
At Anchor_point_2, B must transmit data with C
When Anchor_point_1 & Anchor_point_2 is as close as <2ms, it's difficult for BCM20736_B to maintain the two transmition successful both with A & C. Also, it's impossible for BCM20736_B to transmit with A & C at the same time when Anchor_point_1 overlap with Anchor_point_2.
Hope above of my description is clear enough
About Anchor point, pls refer to bluetooth specification version 4.x, (4.5.7 Window Widening), and 5.1 LINK LAYER CONTROL PROCEDURES
Similar, might be...
But we do not develop it as mesh, we choose net type of cluster tree.
Details pls contact with me via my mail: email@example.com
But, the issue of Anchor points overlap is the most headache one we are debuging now.
Could U pls help us ? tks
Could you help check if some one could help us ? tks
We have this on the list of questions to run past the developers tomorrow when we meet.
At this point, nobody is familiar with the application you are trying to create, so we need to determine if it is supported.
Thanks for your help...
Hope it could be good supported by BCM developers.
We have customers already who has kicked off serveral projects based on our solution, but the Anchor_point issue is the only one might make everything tough in the future without any improvement.
Thanks again for that, help us put this issue into the list...
This is expected behavior because two connections cannot be scheduled at the same instant (including any overlap and scheduling time). The Bluetooth scheduler in the FW will try to schedule connection events in a mostly round-robin based on the amount of data and supervision timeouts. At same time, it will try to nudge its slave away from its master by deliberately moving its clock at a faster rate than the drift so the overlap time is shortened, but the amount per connection interval is limited because large changes will cause the slave to get out of sync very quickly.
2 of 2 people found this helpful
I have a suggestion for you. I'm not sure if I fully understand your situation, but I think I understand enough to be able to say it is likely that your connection interval between A/B is the same (within clock tolerance) as the connection interval between B/C. Since they are very close to being the same but not exactly the same due to clock differences they will slowly shift in phase until the connection A/B is in phase with B/C and then you have trouble because events are trying to happen simultaneously and it may take considerable time ... several connection events... to move back out of phase... meanwhile you've probably had a disconnect and maybe worse.
The way I solved a similar issue is by making the interval A/B different from B/C's interval. For example if you make A/B interval 90 milliseconds and B/C's interval 110 milliseconds, then they will be 'in phase' roughly only once every least common multiple of 90 and 110 or approximately once every 990 milliseconds. Furthermore, the in-phase portion will be very brief and you will miss maybe only one or two connection events... not enough to drop the connection if your slave latency and timeout are set large enough.
Does this make sense?
Thank you very much for your suggestion.
We set the interval a range to creat a connection.But we find the controller always creat a connection with a fixed interval.That's the problem we met.
Why controller does not select a suitable interval like you said to avoid this problem ?
If I use lel2cap_sendConnParamUpdateReq() on slave side to update the connection parameter,shall I need to call some register function to register a callback to handle the requeset and call which function to update ?
or the BT stack will handle it automatically(accept and update)?
I have found the code about update.
whether controller can select a suitable interval to avoid the problem when the connection is established?
With clocks drifting on both piconets, there can never be a suitable interval to avoid overlap. Like userc_7511 suggested, you could try to use (almost) mutually prime connection intervals on the two connections, but the clock drift on one or the other will eventually cause an overlap. The connection will not drop, but the throughput on both connections will reduce because there is no way to service both connections at the same instant in time.
I am working with BCM20736S as peripheral and iPhone as central. When we send the connection parameter update request to the iPhone the parameters requested must meet iOS rules or the phone will simply ignore the request and continue with whatever it considers to be the optimal set of connection parameters. I don't know what the rules are for a BCM2073x as the central as you seem to have in your network project. I would suggest connecting a scope to your system so you can watch the connection events on the screen and see if the master is accepting the parameters your slave is requesting.