You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
200 lines
10 KiB
200 lines
10 KiB
\chapter{Wireless Interface} \label{sec:wireless}
|
|
|
|
Four methods of a wireless connection have been considered: Bluetooth (perhaps with the Texas Instruments CC2541), WiFi with the Espressif ESP8266, a 868\,MHz long range radio link with the Semtech SX1276, and a 2.4\,GHz radio link with the nRF24L01+. Bluetooth was dismissed early for its complexity, and the ESP8266 for its high power consumption, although both solutions might be viable for certain applications and with more development time.
|
|
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=.7\textwidth]{img/nrf-testing.jpg}
|
|
\caption{Test setup with a GEX prototype controlling two nRF24L01+ modules}
|
|
\end{figure}
|
|
|
|
\section{Modulations Overview}
|
|
|
|
A brief overview of the different signal modulation techniques is presented here to aid the reader with understanding of \cref{fig:nrf_sx_comparison} and the rest of the chapter.
|
|
|
|
\subsection{On-Off Keying (OOK)}
|
|
|
|
In \gls{OOK}, the carrier generator is switched on and off to transmit ones and zeros.
|
|
|
|
\subsection{Frequency Shift Keying (FSK)}
|
|
|
|
\Gls{FSK} uses a change of the carrier frequency to transmit data. The simplest form of \gls{FSK} is \gls{BFSK}, which uses a pair of alternating frequencies to transmit ones and zeros.
|
|
|
|
\subsection{Gaussian Frequency Shift Keying (GFSK)}
|
|
|
|
\Gls{GFSK} is an improvement over basic \gls{FSK} which does not switch between the different frequencies instantaneously, but uses a Gaussian filter to make the changes less abrupt, which reduces the side-band interference otherwise generated by the sharp edges. This scheme can be imagined as sending the binary waveform through a Gaussian filter and then modulating a \gls{VCO} with its output, rather than changing the \gls{VCO}'s control voltage discretely. \Gls{GFSK} is used in the Bluetooth standard.
|
|
|
|
\subsection{Minimum-Shift Keying (MSK)}
|
|
|
|
\Gls{MSK} is another \gls{FSK}-based modulation scheme. In \gls{MSK}, the frequencies representing different symbols are chosen such that there are no sharp changes in the phase of the output waveform, the modulation is \textit{phase-coherent}. This is another way to reduce side-band interference.
|
|
|
|
\subsection{Gaussian Minimum-Shift Keying (GMSK)}
|
|
|
|
\Gls{GMSK} is a variant of \gls{MSK} which uses a Gaussian filter to shape the digital signal before sending it to the oscillator. The principle is similar to \gls{GFSK}, and it is a yet another way to reduce side-band interference and increase spectral efficiency. %\gls{GMSK} is used in the \gls{GSM}. this is on wikipedia, but cant find a source
|
|
|
|
\subsection{LoRa Modulation}
|
|
|
|
LoRa uses a direct sequence frequency hopping spread spectrum modulation scheme and can achieve very long range transmission. A higher-level specification defines how the devices using LoRa should behave in a large area network, though the modulation may be used for point-to-point connections as well.
|
|
|
|
LoRa is a proprietary technology developed by Semtech; it is free to use, but is available only with transceiver \glspl{IC} produced by the company.
|
|
|
|
\section{Comparing SX1276 and nRF24L01+}
|
|
|
|
The SX1276and nRF24L01+ transceivers have both been tested using the first GEX prototype, proving its usefulness as a hardware development tool, they proved capable of fulfilling the requirements of the GEX radio link use-case. We compared them in \cref{fig:nrf_sx_comparison} using data from their datasheets~\cite{semtech-manual,nrf-manual}. It is apparent, after inspecting the table, that each has its strengths and weaknesses and the choice depends on the particular application's needs.
|
|
|
|
\begin{table}[h]
|
|
\centering
|
|
\begin{tabulary}{\textwidth}{lLL}
|
|
\toprule
|
|
\textbf{Parameter} & \textbf{SX1276} & \textbf{nRF24L01+} \\
|
|
\midrule
|
|
\textbf{Connection} & SPI (4 pins) + up to 6 IRQ & SPI (4 pins), CE, IRQ \\
|
|
\textbf{Frequency band} & 868\,MHz or 433\,MHz & 2.4\,GHz \\
|
|
\textbf{Data rate} & up to 300\,kbps & 250--2000\,kbps \\
|
|
\textbf{Modulation} & (G)FSK, (G)MSK, OOK, LoRa & GFSK \\
|
|
% \textbf{Bandwidth} & 7--500\,kHz per channel & 0.7--2\,MHz per channel \\
|
|
\textbf{Range (est.)} & over 10\,km & up to 1\,km \\
|
|
\textbf{Consumption Rx} & 10.8--12\,mA & 12.6--13.5\,mA \\
|
|
\textbf{Consumption Tx} & 20--120\,mA & 7--11.3\,mA \\
|
|
\textbf{Idle power (max)} & 1\,$\mu$A sleep, 2\,mA stand-by & 0.9\,$\mu$A sleep, 320\,$\mu$A stand-by \\
|
|
\textbf{Max packet size} & 300 bytes & 32 bytes \\
|
|
\textbf{Software reset} & NRESET pin & not available \\
|
|
\textbf{Extra} & LoRa FHSS, packet engine & ShockBurst protocol engine \\
|
|
\textbf{Price} & \$7.3 & \$1.6 \\
|
|
\bottomrule
|
|
\end{tabulary}
|
|
\caption[Comparison of the SX1276 and nRF24L01+ wireless transceivers]{\label{fig:nrf_sx_comparison}Comparison of the SX1276 and nRF24L01+ wireless transceivers, using data from their datasheets (price in USD from DigiKey in a 10\,pcs. quantity, recorded on May 6th 2018)}
|
|
\end{table}
|
|
|
|
The SX1276 supports additional modulation modes, including the proprietary LoRa scheme that can be received at long distances. The power consumption required to achieve this long-range communication makes it impractical for continuous operation on battery or solar power.
|
|
|
|
The nRF24L01+ provides higher data rates at short distances. Its power consumption is comparable or lower than that of the SX1276. It lacks a dedicated reset pin, but that can be worked around using an external transistor to momentarily disconnect it from the power supply.
|
|
|
|
Both devices implement some form of a packet engine with error checking; that of the nRF24L01+, called ShockBurst, is more advanced, as it implements acknowledgment responses and automatic re-transmission, leading to potentially more robust communication without additional overhead in the control software.
|
|
|
|
|
|
\section{Wireless Link with the nRF24L01+}
|
|
|
|
The nRF24L01+ was selected to be integrated into GEX thanks to its inclusion of the ShockBurst engine, higher possible data rates and significantly lower price. The SX1276, nonetheless, remains an interesting option, should the need for a long range communication arise.
|
|
|
|
A pair of these radio modules can form a bidirectional data connection, functionally replacing \gls{USB} or \gls{UART} as a communication interface. However, we need to connect the second module to the \gls{PC} to control GEX through the radio link. A separate \gls{USB} device, a \textit{wireless gateway}, was developed for this purpose; its hardware will be presented in \cref{sec:rfgateway}.
|
|
|
|
\subsection{The Wireless Gateway}
|
|
|
|
\begin{wrapfigure}[18]{r}{0.38\textwidth}
|
|
\vspace{-1em}
|
|
\centering
|
|
\includegraphics[scale=0.9]{img/rf-gw.pdf}
|
|
\caption{Wireless connection block diagram}
|
|
\end{wrapfigure}
|
|
|
|
The gateway presents itself to the host as a \gls{CDCACM} device, much like the GEX modules themselves (here called \textit{nodes}) when connected over \gls{USB}. However, the standard GEX communication protocol cannot be used directly, as the gateway itself needs to be managed through the interface, and it can connect to more than one GEX module at once, necessitating an addressing scheme. This problem could be solved by adding a side channel, additional \gls{USB} endpoints, to interact with the gateway itself; that option was not explored further, but it is clear that it would compromise our ability to use the simple virtual COM port \gls{USB} driver.
|
|
|
|
|
|
The gateway has a 4-byte \textit{network ID}, a number derived from the \gls{MCU}'s unique ID number. The network ID must be entered into the system settings file of all nodes that wish to communicate with the gateway. Additionally, each module is assigned a 1-byte number serving as its address in the network. These addresses are loaded into the gateway by the user application, and are used to configure the nRF24L01+ to listen to messages from the corresponding nodes. The nRF24L01+ uses 5-byte addressing; the full node addresses are composed of the network ID and the one additional address byte.
|
|
|
|
\subsection{The Gateway Protocol} \label{sec:gw_protocol}
|
|
|
|
The gateway protocol, when used to communicate with a node, encapsulates the raw binary data sent to or from connected nodes; the wrapped TinyFrame protocol remains unchanged.
|
|
|
|
All messages sent to or from the gateway are a multiple of 64 bytes long, padded with zeros if shorter. A message starts with a control byte determining its type, as summarized in the following table, listing the structure of all supported messages.
|
|
|
|
\newpage
|
|
{
|
|
\tabulinesep=5pt
|
|
\begin{longtabu} to \textwidth {P{5em} X[5] X[4,l]}
|
|
\toprule
|
|
\textbf{First byte} & \textbf{Function} & \textbf{Structure} \\
|
|
\midrule
|
|
\endhead
|
|
|
|
\bottomrule
|
|
\endfoot
|
|
|
|
`r' (114) &
|
|
\cname{RESTART}
|
|
Restart the gateway, disconnecting all nodes. This is functionally equivalent to re-plugging it to the USB port.
|
|
& \\
|
|
|
|
`i' (105) &
|
|
\cname{GET\_NET\_ID}
|
|
Read the unique 4-byte network ID. This command has no side effects and may be used as ``ping'' to verify the USB connection. &
|
|
\begin{cmdresp}
|
|
\cfield{0x01}
|
|
\cfield{u8[4]} network ID
|
|
\end{cmdresp}
|
|
\\
|
|
|
|
`n' (110) &
|
|
\cname{ADD\_NODES}
|
|
Configure the gateway to listen for messages from the given nodes.
|
|
Nodes may be removed using the RESTART command.
|
|
&
|
|
\begin{cmdreq}
|
|
\cfield{u8} count
|
|
\cfield{u8[]} node addresses
|
|
\end{cmdreq}
|
|
\\
|
|
|
|
`m' (109)&
|
|
\cname{SEND\_MSG}
|
|
Send a binary message to one of the connected nodes. The message may span multiple 64-byte frames; the subsequent frames will contain only the payload bytes, or zero padding at the end of the last one.
|
|
& \begin{cmdreq}
|
|
\cfield{u8} node address
|
|
\cfield{u16} length
|
|
\cfield{u8} checksum (inverted XOR of all payload bytes)
|
|
\cfield{u8[]} payload
|
|
\end{cmdreq} \\
|
|
|
|
0x02 &
|
|
\cname{INCOMING\_MSG}
|
|
A message was received from one of the configured nodes. This is an event frame sent by the gateway to the host.
|
|
& \begin{cmdpld}
|
|
\cfield{u8} node address
|
|
\cfield{u8} message length
|
|
\cfield{u8[]} payload
|
|
\end{cmdpld} \\
|
|
|
|
\end{longtabu}
|
|
}
|
|
|
|
\subsection{Gateway Initialization Procedure}
|
|
|
|
A host program connecting to a node or nodes through the gateway should follow the following procedure to initialize and configure the gateway:
|
|
|
|
\begin{enumerate}
|
|
\item Send the ``GET\_NET\_ID'' command to test if the gateway is connected (and obtain its network ID as a side effect)
|
|
\item Restart the gateway using the ``RESTART'' command to clean any possible previous configuration; this is not needed when the gateway was restarted or freshly connected to the \gls{USB} port.
|
|
\item Add the node address(es) using the ``ADD\_NODES'' command.
|
|
\item Ping the connected node(s) through the GEX communication protocol to test the connection. Note that GEX will not use the radio module if \gls{USB} is connected and enumerated, as it has lower priority.
|
|
\end{enumerate}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|