- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear BCM
We found out one serious issue that, BCM20736 work in master/slave mode
Work in Master, it has it's connection event of Anchor point, here we call it Anchor_point_1
Work in slave, its master has the connection event of Anchor point, here we call it Anchor_point_2
At the beginning, the Anchor_point_1 and Anchor_point_2 is far apart, about over 6~7 ms. and the data transmit between this BCM20736 and its master is right.
But due to the crystal accuracy(10PPM) or other influence, the Anchor_point_1 & Anchor_point_2 might shift left or right and the two might be closer and closer. We checked in our test that, in one 30ms interval, the Anchor_point_1 & Anchor_point_1 would be 250ns closer to each other. In such conditions, Anchor_point_1 & Anchor_point_1 would continue closer until be overlap, and the data transmition would be error when Anchor_point_1 and Anchor_point_2 as close as +/- 2ms.
Though the connection would not break down (because we set the timer out as long as 5s), but in fact, the data is hard to be transmitted between this BCM20736 and its master.
Of cause that, the data transmition would get right after Anchor_point_1 & Anchor_point_2 apart over 2ms. but it would take nearly 10 minutes, and it would happen again after several hours.
How to solve this issue ?? or is there any good suggestion about this ???
Many thanks...
Solved! Go to Solution.
- Labels:
-
MasterSlave
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Leman,
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear Boont,
We are not working with tag3 board, and we using our own APPs.
Our network structure is cluster tree, built with BCM20736, such as:
Suppose:
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
tks...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the detailed explanation. Is this some kind of a mesh network?
Does BCM20737S support BT standards 4.1 and 4.2, Mesh, Thread
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear Boont,
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: caiyi9904@163.com
But, the issue of Anchor points overlap is the most headache one we are debuging now.
Could U pls help us ? tks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear Boont,
Could you help check if some one could help us ? tks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear Kevin,
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...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you very much for your suggestion.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Another question:
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)?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have found the code about update.
whether controller can select a suitable interval to avoid the problem when the connection is established?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
With clocks drifting on both piconets, there can never be a suitable interval to avoid overlap. Like ehoffman 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Leman,
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.