TimeSlot API high frequency sampling

RE: TimeSlot API high frequency sampling

Ole Bauck — Fri, 17 Jun 2016 14:14:04 GMT

You can't avoid this problem when using timeslot with a concurrent BLE connection.

RE: TimeSlot API high frequency sampling

Jong yoon lee — Fri, 17 Jun 2016 14:09:00 GMT

Yes!Do you have any clear solution for this problem?

RE: TimeSlot API high frequency sampling

Ole Bauck — Fri, 17 Jun 2016 09:24:44 GMT

Ok, then I understand better what you are trying to do. BLE will interfere with timeslot so you will have timeslot that will not be granted if they collide with already scheduled SoftDevice events (like advertising or connection). I highly recommend to read the schedule chapter in the SDS. If you want to have timeslots every 2ms you can be rejected multiple times because a connection or advertising interval usually takes longer than 2ms.

RE: TimeSlot API high frequency sampling

Jong yoon lee — Thu, 16 Jun 2016 17:01:23 GMT

Hello, I am usingThis example.

the synchronization method seems promising. I have one more question. How do I make sure BLE does not interfere with the timeslot. I thought BLE event had the highest priority so timeslot will not initiate until BLE event is finished.

RE: TimeSlot API high frequency sampling

Ole Bauck — Thu, 16 Jun 2016 08:58:49 GMT

So the problem is that the master is not listening sometimes when the slave sends data?

You can synchronize the chips over the air, this is what is done in BLE: The two devices are communicating at a certain interval and wakes up based on the time from the last time they communicated. The timing is done with the RTC clock and the device that is listening at the start of the interval has to wake up a bit before to cope with inaccuracies in the clock, which is called window widening. When it receives a packet it will synchronize the clock.

Another question: what is "UART timeslot API" you are talking about?