commit - 02693033b84a56190c7f39984bae224a43b37be8
commit + ade75177b66054ce43c47e5c79901284da33dd69
blob - c6dc207e59c46fa782377c27435d204210304486
blob + ef1324fed8bca184a4d394a4effaeddb609226fe
--- src/chapters/background/hardware/esp32_c3.tex
+++ src/chapters/background/hardware/esp32_c3.tex
\subsection{ESP32-C3}%
\label{sub:esp32_c3}
-The ESP32-C3 is a Single-Core RISC-V \ac{soc} for use in \ac{iot}. It supports
-\ac{ieee} 802.11b/g/n for Wi-Fi as well as Bluetooth 5 Low Energy. The \ac{ram}
-is 400 KB large, and the \ac{cpu} can operate at a frequency of up to 160
-MHz\cite{espressif:esp32c3data}. This should be sufficient for a close-enough
-development and usage experience that will emulate the production hardware in
-the future.\\
+The ESP32-C3 is a Single-Core RISC-V \ac{soc} for use in \ac{iot}, developed by
+Espressif. It supports \ac{ieee} 802.11b/g/n for Wi-Fi as well as Bluetooth 5
+Low Energy. The \ac{ram} is 400 KB large, and the \ac{cpu} can operate at a
+frequency of up to 160 MHz\cite{espressif:esp32c3data}. This should be
+sufficient for a close-enough development and usage experience that will emulate
+the production hardware in the future.\\
The development board used is the ESP32-C3-DevKit-RUST-1.
Previously it was planned that the hardware used would be a Raspberry Pi. The
blob - 420aa40215201f8b78fee9463e61d34fb33c202f
blob + 01a04666547ce7d9fb373b20e79e64d4d1726473
--- src/chapters/closing/conclusion.tex
+++ src/chapters/closing/conclusion.tex
\section{Conclusion}%
\label{sec:conclusion}
-While a unidirectional throughput of {\textasciitilde}1250 \ac{kbps} has been
-measured in Chapter \ref{cha:improving_throughput_of_bluetooth_low_energy} with
-every optimization applied, there are other source which suggest a different
-maximum throughput is possible\cite{bluetooth:paper:throughput_iot}, although a
-notably higher throughput of {\textasciitilde}1550 \ac{kbps} might mean that
-testing was performed in \textit{both} directions, adding the two separate
-throughput numbers into a possibly confusing higher number. Additionally, in the
-achieved alternative throughput given in
-\citetitle{bluetooth:paper:throughput_iot}\cite{bluetooth:paper:throughput_iot}
-the exact settings used are missing, making it nearly impossible to achieve
-these findings in a reproducible manner.
-
For the context of hearings aids, hearing tests, and audiometry procedures,
\acl{ble} version 5.0 has proven to be more than enough for the transmission of
data with a quality given by lossless audio codecs. The minimum required
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} are not \textit{required} by the Bluetooth
-specification it is possible that a device does not support all of these
+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 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
-oversight.
+oversight.\\
+While this thesis views the throughput in the context of audiometry procedures,
+the achieved maximum throughput can, of course, also be achieved in other
+contexts.
+While a unidirectional throughput of {\textasciitilde}1200 \ac{kbps} has been
+measured in Chapter \ref{cha:improving_throughput_of_bluetooth_low_energy} with
+every optimization applied, there are other sources which suggest a different
+maximum throughput is possible\cite{bluetooth:paper:throughput_iot}, although a
+notably higher throughput of {\textasciitilde}1550 \ac{kbps} might mean that
+testing was performed in \textit{both} directions, adding the two separate
+throughput numbers into a possibly confusing higher number. Additionally, in the
+achieved alternative throughput given in
+\citetitle{bluetooth:paper:throughput_iot}\cite{bluetooth:paper:throughput_iot}
+the exact settings used are missing, making it nearly impossible to achieve
+these findings in a reproducible manner.\\
+Considering this, the work done here shows a major improvement in \ac{ble}
+throughput optimisation and serves as a proof of concept for demanding use cases
+such as audiometry.
+
Rust as the choice for the development of the software for this thesis is
difficult to judge. Having high-level langauge features available in a use case
which is close to the hardware is beneficial as it keeps the developer thinking
about the project in terms of logic, not in terms of hardware restrictions while
-still making it \textit{possible} to think about the hardware. It is, at the
-same 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 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 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.
+still making it \textit{possible} to think about the hardware. These aspects
+were hugely beneficial for the development of applications for this thesis. It
+is, at the same time, also difficult to develop in Rust as potentially important
+pieces of the software stack could be 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 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 does not mean Rust is inadequate for this type of development, though; 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. With the rise in popularity of
+Rust in recent years, it is only a matter of time until Rust is fully mature for
+development in embedded systems.
\todo{mention ble-types library}
blob - 139f1e7fa231a7751771f16f10fb8001b5cb1706
blob + c26ddb8ba0bcd4f734311cb5fdff7e63103dd7ee
--- src/chapters/improving_throughput/att.tex
+++ src/chapters/improving_throughput/att.tex
\ac{att} also defines \acp{pdu} that have a header and a payload. Similar to the
Link Layer \ac{pdu} and \ac{dle}, which was used in Section \ref{sec:dle} it can
also define the length of a \ac{pdu} and thus the size of the payload. This is
-referred to as the \ac{att} \acl{mtu}\cite[p. 2177]{bluetooth:spec50}.
+referred to as the \ac{att} \acl{mtu}\cite[p. 2177]{bluetooth:spec50}. Not every
+device supports a higher \ac{att} \ac{mtu}, and if it does the lengths it
+supports can vary greatly.
In order to manipulate the size of the \ac{mtu} both client and server have to
communicate their preferred sizes and agree on the smallest size both support.
blob - ac428f6e0fa0aafc90937f40c17dae1e75c99462
blob + 80263a2fdbd9f7b00fb719a56993b55a17ddaa1f
--- src/chapters/improving_throughput/packet_sizes.tex
+++ src/chapters/improving_throughput/packet_sizes.tex
\label{table:parameters_packet_sizes}
\end{table}
-With this result in throughput the transfer of data for audiometry purposes is
-not a problem, given the estimated minimum needed throughput of
- {\textasciitilde}800 \ac{kbps}.
+With this result in throughput we can see that the transfer of data for
+audiometry purposes is easily obtainable, given the estimated minimum needed
+throughput of {\textasciitilde}800 \ac{kbps} has been surpassed by
+ {\textasciitilde}400 \ac{kbps}, half of the minimum required throughput.
blob - f4249e3aaa07064ad67d2f428d153bf05bf12bd1
blob + 42585592f7c23d8020e921f12268f56b4a0ae822
--- src/chapters/improving_throughput/write_command.tex
+++ src/chapters/improving_throughput/write_command.tex
When using the Write Request command, the client writes a characteristic on the
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 may not
-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 does not have to wait for a
-response before sending more information.\\
+was successful\cite[p. 2201]{bluetooth:spec50}. 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 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.
With this simple change of how a write is issued, an increase in speed from
blob - a31260e43ba5e763bfd786d047af8297943440d4
blob + 39729afaa036ecbd034bfb1322b1b5c7e1d04566
--- src/chapters/likely_mistakes/att_notifications.tex
+++ src/chapters/likely_mistakes/att_notifications.tex
\end{figure}
Originally, as can be seen in Figure
-\ref{fig:rough_overview_connection_original}, each time a buffer is written to,
-a notification should be sent to the client notifying it that (1) the write was
-successful, and (2) that the client can write new data to the characteristic.
-This turned out to be unnecessary as the Link Layer already partially handles
-this. \enquote{During a connection event, the master and slave alternate sending
- and receiving packets}\cite[p. 2638]{bluetooth:spec50}, meaning that the client
-has to receive a packet from the server before sending another write, so if the
-server does not send a reply it is either still busy or did not receive the
-packet. The downside of this is that not sending a packet means, for the Link
-Layer, that the packet which was sent from client to server might not have been
-received, so the packet is retransmitted. Depending on how high the load of the
-server is, this could result in packets being sent unnecessarily. The upside,
-however, is that the application does not need to handle retransmission of
-packets since the Link Layer is already doing this. In fact, this is what can be
-seen during testing in Figure \ref{fig:retransmission_link_layer}, and this is
-also why when trying to see lost packets in the application layer, no lost
-packets can be observed.
+\ref{fig:rough_overview_connection_original}, each time a buffer is written to
+by the client, a notification should be sent to the client telling it that (1)
+the write was successful, and (2) that the client can write new data to the
+characteristic. This turned out to be unnecessary as the Link Layer already
+partially handles this. \enquote{During a connection event, the master and slave
+ alternate sending and receiving packets}\cite[p. 2638]{bluetooth:spec50},
+meaning that the client has to receive a packet from the server before sending
+another write, so if the server does not send a reply it is either still busy or
+did not receive the packet. The downside of this is that not sending a packet
+means, for the Link Layer, that the packet which was sent from client to server
+might not have been received, so the packet is retransmitted. Depending on how
+high the load of the server is, this could result in packets being sent
+unnecessarily. The upside, however, is that the application does not need to
+handle retransmission of packets since the Link Layer is already doing this. In
+fact, this is what can be seen during testing in Figure
+\ref{fig:retransmission_link_layer}, and this is also why when trying to see
+lost packets in the application layer, no lost packets can be observed.
\begin{figure}[htpb]
\centerline{\includegraphics[scale=0.72]{retransmission_link_layer.png}}
blob - 2715d2b86d1a63c2906c5fec2b0e1b94207a4fd1
blob + da8ba4f250ebbe720296e3b70b912613ba18bc69
--- src/docinfo.tex
+++ src/docinfo.tex
\newcommand{\hsmaabstractde}{
Bei der Durchführung von Audiometrieverfahren müssen Patienten mit Hörgeräten
einen Spezialisten aufsuchen, wobei das Durchführen der Audiometrieverfahren
- dem Patienten sowohl Zeit als auch Geld kostet. Idealerweise sollte ein
+ den Patienten sowohl Zeit als auch Geld kostet. Idealerweise sollte ein
Patient die Tests Zuhause ohne Spezialisten durchführen können.\\
- Ob eine solche Anwendung mit verlustfreier Audioübertragung möglich ist wird
+ Ob eine solche Anwendung mit verlustfreier Audioübertragung möglich ist, wird
in dieser Thesis durch Erforschung des Datendurchsatzes von Bluetooth Low
Energy und dessen Konfiguration ermittelt. Zusätzlich wird gezeigt, dass
die Entwicklung von Embedded Software mit Rust realisierbar ist und wie sie
