Add 'Things to Do' section

Makefile

@@ -1,11 +1,14 @@
 archive.pdf: intro.pdf requirements.pdf design-doc.pdf \
     binary/techreview-ryan.pdf techreview-daniel.pdf binary/techreview-matt.pdf \
     binary/blog-ryan.pdf blog-daniel.pdf binary/blog-matt.pdf \
-    readme.pdf resources.pdf reflection.pdf listings.pdf review.pdf
+    readme.pdf resources.pdf reflection.pdf listings.pdf review.pdf todo.pdf
 	pdfjam --no-tidy --outfile archive.pdf -- intro.pdf requirements.pdf design-doc.pdf \
 	    binary/techreview-ryan.pdf techreview-daniel.pdf binary/techreview-matt.pdf \
 	    binary/blog-ryan.pdf blog-daniel.pdf binary/blog-matt.pdf \
-	    readme.pdf resources.pdf reflection.pdf listings.pdf review.pdf
+	    readme.pdf resources.pdf reflection.pdf listings.pdf review.pdf todo.pdf
+
+todo.pdf: todo.tex
+	pdflatex todo.tex
 
 listings.pdf: listings.tex
 	pdflatex listings.tex

intro.tex

@@ -125,7 +125,7 @@ above) would be to add to the collar a physical indication of whether or not it
 boundary (see the Design Document below for an idea of what that is). This physical indication can be
 an LED light, but the final goal would be to have that indication be a buzzer or an eletric shock.
 
-The gateway software is capable of receiving and configuring a single collar device (See Appendix 1
+The gateway software is capable of receiving and configuring a single collar device (See Appendix 4
 for an explanation of why only a single device is currently supported). The next step for the 
 gateway software, then, is to add support for multiple collar devices. Additionally, the gateway
 software currently uses the Things Network to decode and process LoRaWAN packets. This is less

todo.tex

@@ -0,0 +1,105 @@
+\documentclass[10pt, draftclsnofoot,onecolumn, compsoc]{IEEEtran}
+
+\def\changemargin#1#2{\list{}{\rightmargin#2\leftmargin#1}\item[]}
+\let\endchangemargin=\endlist
+
+\usepackage{setspace}
+\usepackage{listings}
+\linespread{1}
+
+\title{Appendix 4: Work to be Done}
+
+\begin{document}
+\maketitle
+
+\section*{Android Application}
+The Android application requires only some minor touch-ups. In particular,
+it would be good to add more graphs / visualizations of the collar data.
+The majority of the data processing should be done on the server;
+the application should merely display this data. Thus, implementing
+this feature would have to be done in tandem with adjusting
+the server to generate more statistics.
+
+The application could also use some custom icons. The icons
+used on the map for collars and polygon vertices are the default
+ones provided by the \texttt{OSMDroid} library, and look pretty bad.
+Consider replacing with custom SVG graphics.
+
+It might be a good idea to allow the user to configure their API
+URL rather than hardcoding it in \texttt{resources.xml}. Perhaps
+the login screen should present a third input box which the user
+can fill with their system's API URL. This means a single
+Android application will work for several independent grazing systems.
+
+\section*{API Server}
+The gateway server should be modified to generate some more statistics,
+and send these statistics to the Android application. It could
+be useful to rewrite the Flask module using the application factory
+pattern, but this would not add to functionality and should be 
+considered low priority.
+
+Some thought could be put in into how the server handles authentication
+tokens. Currently, they only contain the user ID, and thus, assuming
+the same ``secret passphrase", a user will always have the same API
+token. It's not uncommon for these tokens to be leaked; most
+systems deal with this by allowing the user to invalidate their
+access token and generate a new one. This can be achieved in the Fenceless
+Grazing System by adding a ``generation" field to the JSON body
+of the JWT token, and tracking the ``valid generation" in the database.
+This would greatly improve security.
+
+\section*{Gateway Software}
+The gateway software should be updated to use the SQLAlchemy model
+definitions used in the API Server. This would remove the need
+for writing raw SQL queries, and thereby simplify the code.
+
+Although The Things Network is used in this iteration of the project
+to decode LoRaWAN packets, we do not think this solution is ideal.
+First of all, this requires the server to be connected to the Internet,
+and makes the server unable to decode incoming transmissions from
+the collars when network connection drops. Furthermore, this
+makes our project forward data through The Things Network,
+which can be a security or privacy concern. We understand that many
+users do not want their data to be piped through a third-party system.
+This change is rather difficult, however, due to the fact that there
+is (at the time of writting) little support for LoRaWAN. It might
+be necessary to follow the LoRaWAN spec and implement a custom packet
+decoder and handler, as well as custom LoRaWAN Network Access Point software.
+
+The Gateway's current interaction with the with the collars is done
+by pushing data to The Things Network's API endpoints. The Things Network
+requries that the project manually defines an endpoint for every client
+device (in our case, for every collar). Since we only have one collar,
+we only defined one endpoint. This means that there is currently no logic
+to translate a collar identifier (internal to our system) to an API endpoint
+(used by TTN). Since this system aims to support many concurrent collar connections,
+such a translation layer should be added, perhaps in the form of a database table.
+Note that this is specific to The Things Network, and moving away from TTN would
+make this change pointless.
+
+\section*{Collar Firmware}
+The collar is currently pushing its underlying hardware quite far; the ATmega chip
+used by the LoRa hardware does not have a lot of application memory, and our
+use of LoRaWAN, GPS, and Protobuf has put a significant strain on it. We have already
+struggled with including libraries on the collar (our generated HEX file was too big);
+even now, the collar is succeptible to stack overflows even on small call stacks.
+On embedded hardware, these stack overflows lead to a hard crash, and make
+the collar non-functional.
+
+We recommend that a more robust chip be used for the collar, at the cost of increased
+power consumption. Though there exist models of the ATmega (or other AVR controller)
+that have more memory, it could be fruitful to use an ARM processor instead. Doing so,
+though, will likely require the reimplementation of the collar firmware from scratch.
+
+Additionally, a goal of the Fenceless Grazing System is to be able to redirect
+animals back into a ``valid grazing area". This is to be done with an auditory
+stimulus (a loud beep, for instance) or an electric shock. Currently, the
+collar is capable of determining whether or not it's inside the valid
+grazing boundary, but doesn't have the hardware to influence its host animal.
+To make this work in a field, the collar will probably also require
+a case. We suggest laser cutting one, since 3D printing at the size of the current
+prototype would simply take too long and have a high chance of failure. Note
+that the GPS and LoRa antennas should be outside of the case, so as to
+be able to communicate with the rest of the world.
+
+\end{document}