Improving timing accuracy by only using single advertisement channel?

[Florian Echtler]

Hi everyone,

thanks for this discussion - this question addresses almost exactly a potential use case I've been looking into.

I'd like to try and implement something this using just BLE advertising first, without using the timeslot API; the only thing I could not figure out how to do is in MartinBL's reply:

MartinBL said:

• Configure it to advertise on a single advertising channel.
• Have all your other nodes scan continuously on the same channel.

How do I do that? I'm currently using SD130 on nRF51 platform, and I have already tried something along the following lines:

ble_gap_opt_ch_map_t foo;
foo.conn_handle = 0;
foo.ch_map[0] = 0;
foo.ch_map[1] = 0;
foo.ch_map[2] = 0;
foo.ch_map[3] = 0;
foo.ch_map[4] = 0x10;
sd_ble_opt_set(BLE_GAP_OPT_CH_MAP,(const ble_opt_t*)(&foo));

That should disable all channels except 37, but as far as I can tell, it doesn't have any effect.

I've already done a first experiment for measuring the latency (just toggle a pin as soon as an advertisement has been received, and compare across several boards with logic analyzer), but I'm still seeing something around 2-4 ms of difference, so I'm assuming the advertisement channel scan is still happening...

Best regards, Florian

[Florian Echtler]

To illustrate my question in a bit more detail, here's my sampled data. Test setup was as follows:

• two observers running softdevice S130 v2.0.1 on a single channel (using the parameter hack mentioned above)
• note: both observers use the RC clock source due to board limitations (no 32 kHz crystal)
• one nearby advertiser (~ 50 cm) with 450 ms advertising interval
• one logic analyzer with 100 kHz sampling rate, measuring a pin on both observers that gets toggled immediately when the correct advertisement was received

The plot shows the time differences between the pin toggles. It's quite apparent that there is a peak at ~ 700 µs and a second one at ~ 1400 µs.

Can anyone venture an explanation? Maybe Audun, who seems to know a lot about the timing intricacies of the softdevice?

[AmbystomaLabs]

As Audun stated, you can't do anything in software with pin toggles and expect accurate timing.  There is no way to infer or anticipate delays.  The ISRs are just created, queued and processed as they come.

You would have to do this with radio events and PPI.  Also, since you don't use the crystal 32768 your devices can be up to 500usec apart in just one second and that assumes you are actually running the cal routine.  So either you will have to sync a lot or use LF_synth.