Is Matlabs BLE CSA#2 implementation skipping eventCounter 0 for a reason?

2 次查看(过去 30 天)
Hello,
csa = bleChannelSelection('Algorithm', 2);
csa.AccessAddress = '8E89BED6';
csa.UsedChannels = (0:36);
numConnectionEvents = 10;
for i = 1:numConnectionEvents
channel = csa();
fprintf('Event Counter: %d, selected Channel: %d\n', csa.EventCounter, channel);
end
This generates the following output
Event Counter: 1, selected Channel: 20
Event Counter: 2, selected Channel: 6
Event Counter: 3, selected Channel: 21
This is because the following code is in the matlab source code [classdef bleChannelSelection < matlab.System] starting at line 226
function channelIndex = nextHop(obj)
% Initialize
channelIndex = 0;
% Increment the event counter
obj.EventCounter = obj.EventCounter + 1;
% Wrap around
if (obj.EventCounter > intmax('uint16'))
obj.EventCounter = 1;
end
% Based on algorithm
switch (obj.Algorithm)
% Algorithm #1
case 1
% Calculate unmapped channel
unmappedChannel = mod((...
obj.pLastUnmappedChannel + obj.HopIncrement), 37);
% If the unmapped channel is an unusable channel, map to
% one of the usable channels from the remapping table
if ~obj.ChannelMap(unmappedChannel + 1)
% Construct the remapping table containing usable
% channel indices
remapTable = find(obj.ChannelMap) - 1;
% Calculate the remapping index. Add 1 since remapTable
% indexing starts from 1.
remapIndex = mod(unmappedChannel, nnz(obj.ChannelMap)) + 1;
% Map the unmapped channel to a usable channel using
% remapping table
channelIndex = remapTable(remapIndex);
else
% If the unmapped channel is a usable channel,
% remapping is not required
channelIndex = unmappedChannel;
end
% Retain the last unmapped channel and current channel
% index
obj.pLastUnmappedChannel = unmappedChannel;
obj.ChannelIndex = channelIndex;
% Algorithm #2
case 2
% Convert hexadecimal to binary
binAccessAddress = comm.internal.utilities.de2biBase2RightMSB(...
hex2dec(obj.AccessAddress), 32);
% Calculate channel identifier from the given Access
% Address
channelID = xor(binAccessAddress(1:16), binAccessAddress(17:32));
% Generate a pseudo random number as specified in Bluetooth
% Core Specification v5.0 | Vol 6, Part B, Section
% 4.5.8.3.3.
randomNumber = obj.generatePseudoRandomNumber(...
comm.internal.utilities.de2biBase2RightMSB(...
obj.EventCounter, 16), channelID);
% Calculate unmapped channel using the pseudo random number.
unmappedChannel = mod(randomNumber, 37);
% If the unmapped channel is an unusable channel, map to
% one of the usable channels from the remapping table
if ~obj.ChannelMap(unmappedChannel + 1)
% Construct the remapping table containing usable
% channel indices
remapTable = find(obj.ChannelMap) - 1;
% Calculate the remapping index. Add 1 since remapTable
% indexing starts from 1
remapIndex = floor(...
(nnz(obj.ChannelMap)*randomNumber)/(2^16)) + 1;
% Map the unmapped channel to a usable channel using
% remapping table
channelIndex = remapTable(remapIndex);
else
% If the unmapped channel is a usable channel,
% remapping is not required
channelIndex = unmappedChannel;
end
% Retain the current channel index
obj.ChannelIndex = channelIndex;
end
end
In this implementation the event counter is immediately incremented. I think this is not exactly conform to the Bluetooth core specification Version 5.2 from (https://www.bluetooth.com/specifications/bluetooth-core-specification/). You can look at the bluetooth core spec pdf and go to Vol 6, Part C to section 3.1 (page 3085) and there you see that given these exact starting parameters the generated sequence is supposed to be starting at event counter 0.
Event Counter: 0, selected Channel: 25 <= I think this should be in the output of the first code snippet in this question
Event Counter: 1, selected Channel: 20
Event Counter: 2, selected Channel: 6
Event Counter: 3, selected Channel: 21
Is there a reason for the immediate incrementation in the source code? Should it not start at event counter 0?
Sincerely,

回答(1 个)

Vamsi Manthini
Vamsi Manthini 2020-7-24
The event counter can have values from 0 to 65,535, and we considered the default value as 1. However, the event counter must wrap from 65,535 to 0, which is not happening in this case. The development team is aware of it and will fix it in the future releases.
For now you can modify the code by incrementing the counter at the end.

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by