<html><head><meta name="color-scheme" content="light dark"></head><body><pre style="word-wrap: break-word; white-space: pre-wrap;">\documentclass[onecolumn,letterpaper,11pt]{article}

%===================================================================
\input{common_latex/common_latex_packages}
\input{common_latex/common_latex_definitions}
\input{common_latex/common_latex_help_format}
%===================================================================

\begin{document}

\begin{labcover}
\labtitle{pComms - A Wifi-based Communications Application}
\vspace{0.1in}
\labdate{Spring 2018}
\vspace{0.1in}
\labauth{Oliver MacNeely, oliverm@mit.edu}
\labauth{Department of Mechanical Engineering}
\labauth{MIT, Cambridge MA 02139}
\labtoc{small}
\end{labcover}

% Wikifile naming convention:
% prefix=PavLab.
% suffix is app name with first letter uppercase
\wikidoc{file=PavLab.PComms}
\wikidoc{bugz=pComms}
\wikidoc{auth=oliverm@mit.edu}

%====================================================================
\section{pComms Overview}
%====================================================================
\label{sec_pComms}
\index{pComms}

When experimenting on the water, the lab uses radios extensively for communication. While these are generally very easy to use, they also come with a variety of problems. Firstly, the sound quality through them is quite low and we have no way of recording it for post-experiment analysis. In addition, the radios are another piece of equipment that can become damaged from water or be in short supply when large experiments are being run. Lastly, they require that the users be well-versed in correct radio protocol. This leads to longer experiments because of the necessary orientation time for subjects who have never used a radio before. It also theoretically distracts users from the intended use of radios - communiction, as they might be distracted by the need to maintain protocol.

In response to this, pComms provides communication over wifi that is independent of radio usage. Furthermore, it will integrate with iButtonBox to provide the ability to record audio for post-experiment analysis. In addition, since it hands communications control over to the experimenters, it allows modificaiton of experiments to include customized communications. 

%====================================================================
\section{Using the pComms Application}
%====================================================================
\label{subsec_using_pComms}

Since pComms primarily runs in the background, there is very little interaction required. One note, whenever "pComms" is used in any terminal input or configuration file, it is understood that one must subsitute pComms\_server or pComms\_client, depending on which application is being edited or used by the reader.

%====================================================================
\subsection{Mail Handled by pComms}

On the server side, there is no mail handled by pComms. It runs entirely in the background and doesn't actually interact with the MOOSDB. On the client side, the only mail handled by pComms is that which is produced by iButtonBox. This is because the ability to send audio is controlled by the Button Box.

%-------------------------------------------------------------------
\subsubsection{The iButtonBox Mail Message}
\label{sec_pComms_setup_mail}

The mail genereated by iButtonBox will typically be of the form of a variable with a value of true or false. This value is then read once it is received and will control the ability to send audio to the server. 



%====================================================================
\subsection{Configuration Parameters of pComms}

Currently the only configuration parameters are CommsTick and AppTick. These control the speed at which the iterate loop iterates. However, there are several parameters that will be implemented. These will be port and ip parameters, where once can enter the ip addressses and ports of the client computer and server computer as well. In addition, after further testing, it will be determined whether the iterate loop can support audio. If not, then the app will fork a thread to handle audio and the CommsTick and AppTick parameters will not directly affect the apps audio abilities.

%===================================================================
\section{Configuration Parameters for pComms}
\label{sec_pComms_params}
% The index info is included if this document becomes part of a larger work
\index{pComms!Configuration Parameters}
\index{Configuration Parameters!pComms}

The \app{pComms} application may be configured with a configuration
block within a MOOS mission file, typically with a \var{.moos} file
suffix. Currently no configuration parameters aside from the default ones are defined.

%\vspace{0.15in}
%\begin{listing}{Configuration Parameters for iM200}
 % \label{lst_mtwo_params}
 % \renewcommand{\arraystretch}{1.1}
 % \begin{longtable}{rp{0.76\textwidth}} 
    
 %   \pvar{ip\_address}: &amp; The IPv4 address of the front-seat computer
 %   that is being interfaced with. Default value is \pvar{localhost},
 %   which implies that the \app{pExample} application is being run on
 %   the front-seat vehicle itself. See Section
 %    \ref{sec_pex_ipaddr_param}. \\
    
 %   \pvar{port\_number}: &amp; At the defined \pvar{ip\_address}, this is
 %   the port number to communicate with the vehicle. Default is Port
 %   9000.  See Section \ref{sec_pex_port_param} \\
        
 %  \end{longtable}
%\end{listing}

%====================================================================
\subsection{An Example MOOS Configuration Block}

An example MOOS configuration block is provided  below. This can also be obtained from a terminal
window with:

\vspace{0.1in}
\begin{consoleverb}
$ pComms --example or -e
\end{consoleverb}
\vspace{0.1in}

\vspace{0.25in}
\begin{listing}{Example configuration of the pComms application}
\label{lst_pComms_econfig}
\footnotesize
\begin{verbatim}
1   ============================================================================
2   pComms Example MOOS Configuration
3   ============================================================================
4
5   ProcessConfig = pComms
6   {
7     AppTick        = 10
8     CommsTick      = 10
9   }

\end{verbatim}
\normalsize
\end{listing}

%=============================================================
\section{Publications and Subscriptions for pComms}
\index{pComms!Publications and Subscriptions}
\index{Publications and Subscriptions!pComms}
\label{sec_pComms_interface}

The interface for \app{pComms}, in terms of publications and
subscriptions, is described below. This same information may also be
obtained from the terminal with:

\vspace{0.1in}
\begin{consoleverb}
$ pComms --interface or -i
\end{consoleverb}
\vspace{0.05in}

%---------------------------------------------------------------------
\subsection{Variables Published by pComms}
\label{sec_pComms_pubs}

Since both the client and server side of pComms runs in the background and only interact with the MOOSDB minimally, neither publishes any data to the MOOSDB.

%------------------------------------------------------------------
\subsection{Variables Subscribed for by pComms}
\label{sec_pComms_subs}

The \app{pComms} application only subscribes to a variables on the client side. In this case, the app subscribes to whichever variable the iButtonBox app publishes. This is decided in the iButtonBox configuration file. 

\end{document}

</pre></body></html>