Figure 1. Terminal screen displaying live data being transmitted and demo Plot.ly graph
For a while now I have been thinking about the ability to remotely monitor what is going on environmentally in a location. I have thought about this with regards to the summer, with a cottage more than an hour away it would be nice to know what the weather pattern is for the cottages location (not the general city or county) to decide if it is worth the long drive. I have also thought about this with regards to parts of my house, such as the attic, basement etc, to help determine how well the insulation is working or what is going on in parts of the house where people may not often frequent. Lastly it has come up in many conversations with storekeepers who want to know how their fridges are performing and to know when there may be an issue. With all these usage cases I decided I should come up with a solution.
When TI came out with their CC3000 I thought I would give that a try. I spent a few weeks working with this BoosterPack in conjunction with a Stellaris (Tiva C) and MSP430G2553 launchpad but had a good few issues that just didn't seem easily resolvable as well as some limitations that hinder the usability of the system, besides by then TI had come out with the CC3100 that was supposed to resolve a lot of issues as well as be some what easier to use.
Figure 2. CC3100 layout and pin assignment
At the same time I was introduced to Plot.ly, an online graphing tool that allows for real time plotting of almost any form of data. After looking over how Plot.ly works I decided these two tools together would make a good start to resolving my real time remote data logging problem.
As I have a decent background with TI devices the use of TI products was a natural and convenient choice.The MSP430F5529LP was chosen as the brains behind the system and as previously stated the CC3100 was chosen for the Wi-Fi connection. The MSP430F5529LP was chosen do to the wide availability of example code and wide usage of this launchpad with the CC3100.
Figure 3. MSP430F5529 pin assignment for use with BoosterPacks
The Wi-Fi connection is a CC3100 Boosterpack that contains an integrated TCP stack and is interacted via SPI. One of the important features about this BoosterPack is its conformity to the BYOB (build your own board) standards.
Figure 4. Build Your Own Board pin assignment layout
This means that all the pin connections are in predetermined locations allowing for ease of use with other BoosterPacks. The sensor chosen is a MPL3115A pressure sensor from Freescale and was integrated using the Xtrinsic sensor board from Element14 and Freescale. Lastly as this needs to be able to work in a remote location I decided to add a local power source, for this the Fuel Tank BoosterPack from Element14 was chosen. This choice however does present its own issue. The Fuel Tank BoosterPack does not conform to the BYOB standard. With some connections in contention this board was connected via jumper leads and for now only provides power, the power monitoring ability of the BoosterPack has not been implemented but hopefully will be in a later iteration of this project.
Figure 5. Fuel Tank BoosterPack pin assignment (non-conforming)
The project is based on the TCP_Socket demo for the CC3100. This demo has the basics needed to connect to an access point (AP), open a socket and send data, this provides a very substantial start for the project. This code was modified one step at a time. The first step was to allow for data of my choosing to be transmitted. This was tested and verified using a piece of software from HW-Group called Hercules. This software allows you to have a server running on your PC and to easily receive and see incoming data. One this was done the code needed to be further modified to allow for one connection to be made and multiple packets of data to be transmitted. This was done by splitting the BSDclient function into two distinct functions. The first function would take care of creating a socket and connecting to it. The second function packetTx would then take care of transmitting the desired data. Once this was done (with some difficulty, see forum posts for details), it was time to start transmitting data to Plot.ly.
The website for Plot.ly origanly did not provide a lot information if you were not using one of there standard platforms (Arduino, Matlab, etc) or one of there chosen languages (Python, R, Arduino), I therefore had to take the Arduino code (the easiest to understand) and parse it so it could be used in the format needed by the CC3100. From this code (Plotly’s Arduino code) I was able to create a graph using the REST API commands. These commands in their most basic form look like this:
POST /clientresp HTTP/1.1
Host: 107.21.214.199
User-Agent: MSP430F5529/0.5.1
Content-Length: 243
where the IP address “107.21.214.199” is the address of Plot.ly. The content length is the length of the following string in bytes that actually creates the graph (Note each line is terminated with a carriage return as well as a new line (“\r\n”)):
version=2.2&origin=plot&platform=Stellaris&un=Kas&key=ABCDEFGHI&args=[{"y": [], "x": [], "type": "scatter", "stream": {"token": "1234567890", "maxpoints": 500}}]&kwargs={"fileopt": "overwrite", "filename": "test plot", "world_readable": true}
I will explain this string briefly. Platform is the platform or language being used, from what I can tell changing this has no effect on how the graph behaves. “un” is the username, mine is Kas. “key” is your unique identifier key that allows access to your account. “args” is used to set up the individual traces, in this case I have only one trace so there is only one set of args. if you wanted more than one trace you would use something like this:
version=2.2&origin=plot&platform=MSP430F5529&un=Kas&key=ABCDEFGHI
&args=[{"y": [],"x": [],"name": "Temperature","type": "scatter", "stream": {"token": "1234567890", "maxpoints": 500},"yaxis":"y1"}, {"y": [],"x": [],"name": "Pressure","type": "scatter", "stream": {"token": "1a2b3c4d5e", "maxpoints": 500}, "yaxis": "y2"}]
&kwargs={"filename": "Temperature and Pressure", "fileopt": "overwrite", "style": {"type": "scatter"}, "layout": {"title": "Temperature and Pressure vs. Time", "xaxis": {"title": "Time (s)"}, "yaxis": {"title": "Temperature (Celsius)"}, "yaxis2": {"title": "Pressure"}}, "world_readable": true}
for a full listing of commands you can look at this documentation. “kwargs” is the settings for the overall graph such as the title, public/private access as well as others. At this point I had a graph created and was able to see it in my workspace on the Plot.ly website. I now needed to stream data, using the Arduino code for this however did not appear to help very much. I will again show the commands to open a stream and stream data and then explain them.
POST / HTTP/1.1
Host: stream.plot.ly
User-Agent: Python
Transfer-Encoding: chunked
Connection: keep-alive
plotly-streamtoken: 1234567890
In this code the main command that you need to edit is “plotly-streamtoken”. This line is used to specify the specific trace that this data should be posted to, it is the same as the token in the args passed to create the graph. Note each line is terminated with a carriage return as well as a new line (“\r\n”). Once the stream is open data can be sent to tos graph and trace specified this is done by the following line:
3134
{"x":1,"y":5}
3134
{"x":2,"y":5}
This is where it gets confusing, the 3135 appears to be meaningless but is is infact hex for 14. There are 14 bytes transmitted here including a new line. The “X” value here can be seen to be 1, 2 and the “Y” value is 5. The order of the “X” and ”Y” does not appear to matter. Data must be transmitted once per minute or Plot.ly closes the stream, you can choose to reopen the stream (Plot.ly would prefer you don’t consttly open and close sockets) or preferably send a heartbeat (“\r\n”) if it will be longer then a minute before your next data transmission. Now that we can open a connection with Plot.ly using the CC3100, stream data to plot in reat time its time to get the data from the desired sensor.
I chose to use the MPL3115A as it is a relatively simple sensor to use and I had one laying around. The MPL3115A uses I2C to communicate and once set up to take a reading every second there is not much to do other than poll for data. This will eventually be changed to an interrupt based system which would ideally allow for the MSP430F5529LP to sleep for approximately 95% of the time (back of the envelope calculation) increasing the units life by orders of magnitude.
Figure 6. Xtrinsic Sensor Board and pin assignment configuration
This code was initially developed separately from the TCP_Socket code and was slowly merged allowing for issues to be easily resolved. The main issue encountered was the “Error: "Program will not fit into" after adding interrupt handler” this was eventually resolved by simply removing the interrupt handler for “USCI_B1_ISR” in board.c. Once the data is read in it needs to be changed to a string and assembeled as message that Plot.ly can interpret. This is all done in the “plotlyPlotString” function, two integers are passed in as well as a pointer to a char array. The integers are converted to chars and inserted into the string ready to be sent to Plot.ly (this function in its entierty can be confusing so if anyone would like more clarification I would be happy to further exlpain it below). One integrated and tested the system performed pretty well.
Figure 7. MSP430F5529 with CC3100 BoosterPack mounted and connected to the Xtrinsic Sensor Board (P4.1, P4.2) and Fuel Tank BoosterPack (3.3V, 5V, GND)
Next Steps
Moving forward there are a number of improvements that need to be made. As of now the system disconnects from Plot.ly after ~530 data points (this does not happen with the Hercules server), this issue will need to be resolved and is currently under further investigation. There is also the issue of inadvertent disconnections from the AP that for a robust system will need to be taken care of, this will involve checking that the connection has not been closed and if it has, to reconnect. There is also the need to check that the socket has not been closed and again if it has to reopen it before continuing to send data. Lastly for complete robutness the system should be able to check for error messages from Plot.ly and react to them in a meanigfull manour.
Besides for these steps the inclusion of pressure data on a separate “Y” axis would allow for a better use of the chosen sensor. Also the full implementation of the Fuel Tank BoosterPack with power monitoring and plotting time remaining, battery voltage and possibly other metrics would be a useful addition.
I will update this post as the project evolves. If you have any questions or comments I would be happy to address them in the comments below.
For those who would like to try this and may run into the same issues I have, I have included a link to the issues I had and how TI helped me resolve each of them
CC3100
