commit - 1326a350eeb81fd2c165261a9f6d511b6c3bdaed
commit + d8ac1fef52df7f108dc065e85cdc0e2476acb972
blob - f2d6f79a48af2c216cf51c20a81a528c7dca925b
blob + 480b4d14b8276f3ace869f0fbf66b7a60f99ed0b
--- src/chapters/background/ble/ble_vs_bc.tex
+++ src/chapters/background/ble/ble_vs_bc.tex
Bluetooth Classic, also known as \ac{bredr}, is an alternative implementation of
Bluetooth that has existed longer than \ac{ble}. In fact, \ac{ble} was developed
-because \ac{bredr} isn't fit for devices with a small battery since the power
+because \ac{bredr} is not fit for devices with a small battery since the power
consumption is too high to use it on these devices. This improvement in \ac{ble}
is a trade-off in terms of throughput, as Bluetooth Classic supports a higher
maximum data rate of 2100 \ac{kbps}, compared to \ac{ble} which only supports a
blob - aeb080f9c0198732888122232aa546433cb0c3cd
blob + 6550963d8de3c8ddaf9631e3b5ffbe8981752117
--- src/chapters/background/ble/use_cases.tex
+++ src/chapters/background/ble/use_cases.tex
\subsection{Use-Cases}%
\label{sub:ble_use_cases}
-Due to \ac{ble}'s low energy cost (and accompanying lower bandwidth) it
-is often used in low-power devices that can't afford to use \ac{bredr}
-or don't need a lot of bandwidth in the first place.\\
-This includes devices \enquote{which run off small, coin-sized batteries
- for days or weeks or more.}\cite{bluetooth_le_primer}
+Due to \ac{ble}'s low energy cost (and accompanying lower bandwidth) it is often
+used in low-power devices that cannot afford to use \ac{bredr} or do not need a
+lot of bandwidth in the first place.\\
+This includes devices \enquote{which run off small, coin-sized batteries for
+days or weeks or more.}\cite{bluetooth_le_primer}
-Additionally, \ac{ble} also supports sending data to multiple receivers
-at once and is able to communicate with other devices in a mesh
-topology.
+Additionally, \ac{ble} also supports sending data to multiple receivers at once
+and is able to communicate with other devices in a mesh topology.
\todo{Expand on BLE Use-Cases}
blob - 6c7a300fed0c39620a83c7c2a1bc187d6e67a8d1
blob + ff399a95596ce0b3ed77d6f5f5c27b37538bd4a1
--- src/chapters/background/hardware/esp32_c3.tex
+++ src/chapters/background/hardware/esp32_c3.tex
less powerful hardware, in terms of CPU core count and speed, and RAM, in terms
of size, should be used to closer match the hardware specifications that would
be used in the production device. Doing this avoids developing for hardware that
-is too powerful and risking that the software ultimately wouldn't be able to run
+is too powerful and risking that the software ultimately would not be able to run
on the production device.
Other than the hardware specification of the ESP32-C3, the software and tooling
blob - 0e159de136e8c662f047305fc5ad87dc056d0e9e
blob + f63cb836a6d5d6abe4283d9de5bafa8622f8ea11
--- src/chapters/background/rust/reasons.tex
+++ src/chapters/background/rust/reasons.tex
Nevertheless, a separate library was created by the same maintainers, though it
is still a work in progress\cite{esp_wifi}. Due to it being work in progress as
well as not running on the development kit used here (see Section
-\ref{sub:esp32_c3}), it wasn't used.
+\ref{sub:esp32_c3}), it was not used.
Instead, I extended and used a separate library prototyped by FreshX for
internal use, called \enquote{ble-esp32c3}. It is a proof of concept library to
blob - 27f488b50979ff6b26390e0f349adc00226b35ce
blob + 67a6521b804dcb08032b6bfbdd75e8f236b84a5b
--- src/chapters/background/rust/use_cases.tex
+++ src/chapters/background/rust/use_cases.tex
The natural flow of creating a \textit{safe} interface around unsafe operations
by leveraging the type system to ensure that calling a function in a given
context is, in fact, safe, makes designing a low-level system easier as the
-programmer doesn't have to worry about the memory safety of interfaces to
+programmer does not have to worry about the memory safety of interfaces to
lower-level code. Unsafe code is isolated and can be reasoned about easier than
-if it wasn't isolated and potentially the whole program needs to be inspected to
-reason about the memory safety of it.
+if it was not isolated and potentially the whole program needs to be inspected
+to reason about the memory safety of it.
These features also make Rust a good fit for the software developed for this
thesis, not only because there is unsafe code to be written which can be
blob - 4c8728f6591664cfaf245939ef3efdfd5b148c9a
blob + a25e1a9364dfa64a7af27ff51281d8a9b0e550de
--- src/chapters/closing/conclusion.tex
+++ src/chapters/closing/conclusion.tex
the actual throughput of {\textasciitilde}1200 \ac{kbps}. Whether the device
that is used for sending the data supports the required parameter settings needs
to be evaluated per device, and given that a 2M \ac{phy}, 251 byte \ac{dle}, and
-a 517 byte \ac{att} \ac{mtu} aren't \textit{required} by the Bluetooth
+a 517 byte \ac{att} \ac{mtu} are not \textit{required} by the Bluetooth
specification it is possible that a device does not support all of these
parameters. The throughput surplus of {\textasciitilde}400 \ac{kbps} makes it
-possible that a device doesn't have to support all these settings, though.\\
+possible that a device does not have to support all these settings, though.\\
If the device does support these parameters it is, from a technical standpoint,
imaginable that audiometry procedures can be performed at home by the patient
themselves without the need for high quality equipment and professional
time, also difficult to develop in Rust as potentially important pieces of the
software stack are missing that Rust can interact with. The case here is made
for the Bluetooth interaction with the esp-idf, something that is implemented in
-C/C++ but doesn't yet have an interface developed in Rust. This is a
-\textit{crucial} part of the stack used, but it isn't yet available to use in
+C/C++ but does not yet have an interface developed in Rust. This is a
+\textit{crucial} part of the stack used, but it is not yet available to use in
Rust without further time spent on developing it first.\\
-This doesn't mean Rust is inadequate for this type of development; it means that
+This does not mean Rust is inadequate for this type of development; it means that
some initiative has to be shown in order to get the ecosystem to a point where
Rust is a perfectly viable choice for developing software with, eventually
rivalling C and C++ in this space.
blob - c2de6cc969ba67a3130e1b65dc55671a1caf7e40
blob + 1afb3c5e87d612d5c900cd4596c88a180801303e
--- src/chapters/closing/further_topics.tex
+++ src/chapters/closing/further_topics.tex
more places to improve the throughput of \acl{ble}. For instance, the \ac{l2cap}
layer supports a payload size of up to 65535 bytes\cite[p.
1734]{bluetooth:spec50}, minimizing the overhead of sent headers, but this
-hasn't been tweaked at all. Similarly, instead of using \ac{att} and \ac{gatt},
+has not been tweaked at all. Similarly, instead of using \ac{att} and \ac{gatt},
\ac{l2cap} sockets with data streams can be used directly if features of the
above layers, like services, characteristics, notifications, or permissions for
-access aren't needed, eliminating the overhead of \ac{att} headers completely.
+access are not needed, eliminating the overhead of \ac{att} headers completely.
Before doing this, though, there should be a case made for giving up the ease of
use of abstractions against a slight increase in throughput to avoid premature
optimization\cite[p. 208]{knuth:structure_programming_using_goto}.
blob - b5aeb900f3a0bac92dff73ba7c2d7fdf144dfb12
blob + 03d4fa437308227a1682ab6fdcae0e6fc568e510
--- src/chapters/improving_throughput/link_layer.tex
+++ src/chapters/improving_throughput/link_layer.tex
\label{table:parameters_dle}
\end{table}
-Compared to the previous test in Section \ref{sec:phy} the throughput didn't
+Compared to the previous test in Section \ref{sec:phy} the throughput did not
change and stayed at {\textasciitilde}190 \ac{kbps}.\\
This is because \ac{dle} allows the upper layers of the Bluetooth stack to send
more data in one Link Layer packet. So because no packet lengths in upper layers
blob - e555fe9530857a1c0087d1a02080a5bf6545f3e8
blob + 60e614cb81c63a4aea6f80c52c8ddaf4f8e4d3dc
--- src/chapters/improving_throughput/physical_layer.tex
+++ src/chapters/improving_throughput/physical_layer.tex
packet directly\cite[p. 2681]{bluetooth:spec50}.
Despite the 2M \ac{phy} operating at double the amount of bytes per second
-compared to the 1M \ac{phy} it doesn't double the throughput. The reason for
+compared to the 1M \ac{phy} it does not double the throughput. The reason for
this is the \ac{tifs}, \enquote{the time interval between two consecutive
packets}\cite[p. 2604]{bluetooth:spec50}. It is defined as 150 microseconds
and specifies the amount of time that a receiver of a packet needs to wait
With this improvement, the throughput measured improved from
{\textasciitilde}170 \ac{kbps} to {\textasciitilde}190 \ac{kbps}. The reason
-this doesn't immediately double the throughput is that not only the data but
+this does not immediately double the throughput is that not only the data but
also header information as well as empty packets in between the data packets
are sent.\\
The parameters for this test are defined in Table \ref{table:parameters_phy}.
blob - a026d5acb16779b016fb920a1fd04a6655a57dab
blob + dfbc2baccdf0ff3521aaf6dbaeb2c7630c8c3f8f
--- src/chapters/improving_throughput/setup.tex
+++ src/chapters/improving_throughput/setup.tex
which is defined as a global variable guarded by a mutex. The \lstinline{recv}
method keeps track of the bytes and sequence number received.\\
Allowing the Clippy lint \lstinline{needless_pass_by_value} is required because
-Clippy sees that the parameter is owned by the function even though it doesn't
+Clippy sees that the parameter is owned by the function even though it does not
need to be; nowhere is the ownership needed as the value is only read, so a
non-owned type is suggested instead. This lint cannot be satisfied as the
signature for the callback method is \textit{required} to be the one shown, so
blob - 298872f81b0ababfea82c228498d53980806a6cb
blob + 7765969970e449b6fa5090a4cb4827f686226a4b
--- src/chapters/improving_throughput/write_command.tex
+++ src/chapters/improving_throughput/write_command.tex
server and the server responds with a Write Response, indicating that this write
was successful\cite[p. 2201]{bluetooth:spec50}. This, of course, trades speed
for correctness, something that an application that transmits audio might not
-always care about. Instead the Write Command is used which doesn't expect a
+always care about. Instead the Write Command is used which does not expect a
response from the server after being written to. It not only avoids the
-bandwidth cost of the response but the client also doesn't have to wait for a
+bandwidth cost of the response but the client also does not have to wait for a
response before sending more information.\\
This is the first optimisation of the throughput as it is the most simple one.
\label{fig:write_command_wireshark}
\end{figure}
-The observed improvement in speed is realistic as the client doesn't have to
+The observed improvement in speed is realistic as the client does not have to
wait for a response but can just send another command again immediately.
blob - 6a35a27d9d33a13802fa13c31b6c42b9064bb425
blob + 1ad846b2efb226b90cad37c18db78942d47e4580
--- src/chapters/likely_mistakes/ble_link_layer_procedure_collision.tex
+++ src/chapters/likely_mistakes/ble_link_layer_procedure_collision.tex
In \ac{ble} the earlier mentioned procedures, like updating the used \ac{phy}
and \ac{dle}, are defined and have to be executed in sequence, not in parallel.
-This isn't immediately obvious when looking at the Bluetooth specification as
+This is not immediately obvious when looking at the Bluetooth specification as
this is mentioned in a separate section dedicated to \enquote{Procedure
Collisions}\cite[p. 2685]{bluetooth:spec50}.\\
This section defines that when a device receives a procedure it cannot initiate
blob - 925fa7928d444eed3bbf1eac14ae00be31ba63f9
blob + dd2d003d321ce36daf1e70864ee23673c9bf6faf
--- src/chapters/likely_mistakes/bluez.tex
+++ src/chapters/likely_mistakes/bluez.tex
sets the value of the \ac{att} \ac{mtu} to 517 bytes and the value of \ac{dle}
to 251 bytes. This is the reason that the \enquote{Exchange MTU Request} seen in
Figure \ref{fig:exchange_mtu_request_wireshark} has a \ac{mtu} of 517 bytes set,
-as this is sent from BlueZ. The reason that \ac{dle} isn't set to the maximum
+as this is sent from BlueZ. The reason that \ac{dle} is not set to the maximum
251 bytes in the \lstinline{LL_LENGTH_RSP} sent from BlueZ is that the nRF52840
Dongle had a maximum \ac{dle} of 27 bytes configured. Even though these
parameters are set to their maximum by default, the 2M \ac{phy}, for instance,
blob - f4c8acc30b75adf2467e4e44e392f7e210e62c7b
blob + 7afd5c631157361fe0db8b22acff1be82e0ab475
--- src/chapters/likely_mistakes/default_settings.tex
+++ src/chapters/likely_mistakes/default_settings.tex
The initial assumption was that the computer is automatically setting the
\ac{dle} to the maximum of 251 bytes, but, as Figure
\ref{fig:length_req_slave_wireshark} shows, it turned out to be the ESP32-C3
-setting this value instead. Meanwhile, the computer didn't activate \ac{dle} at
+setting this value instead. Meanwhile, the computer did not activate \ac{dle} at
all, which turned out to be the case because of the nRF52840 Dongle not
supporting \ac{dle} by default, making the ESP32-C3 (esp-idf) and the nRF52840
Dongle (Zephyr) have completely opposite defaults.
Even though the esp-idf sets the default of a 251 byte \ac{dle} by default this
-shouldn't be assumed to be the default, so setting this explicitly is preferred.
-For that, the esp-idf supports the \lstinline{esp_ble_gap_set_pkt_data_len}
-function\cite{espidf:gap_api}.
+should not be assumed to be the default, so setting this explicitly is
+preferred. For that, the esp-idf supports the
+\lstinline{esp_ble_gap_set_pkt_data_len} function\cite{espidf:gap_api}.
Another source of error for default settings is that the settings for Zephyr
running on the nRF52840 Dongle are not set correctly. Both the 2M \ac{phy} as
