MATLAB Answers

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

12 ビュー (過去 30 日間)
Tijl Goens
Tijl Goens 2020 年 5 月 6 日
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,

  0 件のコメント

Sign in to comment.

回答 (0 件)


Translated by