Skip to content

Henry's Notes

Jump to bottom Edit New page
Henry Crute edited this page Apr 8, 2015 · 114 revisions
Table of Contents
# TODO
  • Weekly Reports
  • Pic32 real-time computations in incoming data samples. Format, and send to esp in ~1Hz interval.
# 4/7/15 * Tried debugging Bryan's new API, but things aren't connecting properly. # 4/6/15 * Fixing http post message for python dictionary # 4/2/15 ##Things to consider for the Spring 2015 quarter: ###High Priority * Change the ESP firmware to package and send multiple messages at the same time, conforming to Bryan's new API. This should lower the overhead of http messaging. We were having problems sending messages at a high frequency, with relatively no data. This would make the ESP reset, and lose connectivity. * Create a standardized way to flash the new ESP chips (we need it to be better than SHEMP).

###Low Priority

  • Develop pic32 firmware for SEAD lite (RMS wattage, and RMS current. We have current right now only).
  • Use the RTC on the pic32, and send that as a timestamp for the ESP to handle offset.

###ESP8266-03 Flashing To start into flashing mode

  • CH_PD to VCC
  • GPIO00 to GND
  • GPIO15 to GND

To start regularly

  • CH_PD to VCC
  • GPIO15 to GND
# 3/11/15 * Added function call on a timer set to every single second to check to see if we have data to send. * Tested consistency overnight, module held up the whole time (for around 13 hours). # 3/10/15 * Added featre that if it can't find a wifi network after 30 seconds, the ESP will reset into AP mode for wifi reconfiguration. # 3/9/15 * ESP8266 stress testing. Found a few connection bugs, and network configuration logic bugs. # 3/6/15 * Looks like the ESP uses the SSL3 cipher. It is outdated, and it would be better to have no ssl encryption on data. # 3/5/15 * Fixed compiler problems with the 0.9.5 SDK and our project. # 3/4/15 * Encountered ssl problems with Bryan's API. * Successfully updated the SDK to version 0.9.5 to avoid crashing when trying to do the ssl handshake. # 3/3/15 * Modified acquire script to send config in the form of a struct over ftdio # 3/2/15 * Added options to the acquire script for configuration of the DAQ. # 2/27/15 * Finished writing the nmea message packing protocol for uart communication to the ESP. # 2/26/15 * Started writing the nmea message packaging protocol for uart communication to the ESP. * TODO: Experiment with window sizes and sample rates to see the deminishing returns of the OSR, implement the fixed point FFT. * TODO: Add an automatic optimal configuration of the OSR and PRESCALAR, for the bandwidth we want. Also add configuration for how many channels we want to use. (getopt on Acquire script, and change DAQ firmware to support that) # 2/25/15 * Confirmed that our RMS calculations were correct. Crosschecked the data with Matlab. * Took a few recordings and graphed them corresponding to what we measured and what was expected. The measured values seemed to be off by a uniform scalar from the ranges of 1A to about 8A. * Finally ready to build the uart packaging and checksum library for the PIC32, so we can send correct stuff over to the ESP! # 2/24/15 # 2/23/15 # 2/20/15 * I believe that the way we are mathematically converting the voltage to current from the current transformer is wrong, as we still aren't getting correct numbers, and that's the only thing I'm iffy about. # 2/19/15 * Continued trying to get a logical reading out of the ADC and translating it into real units. # 2/18/15 * Added averaging on the PIC32, calibrated channel 1. * Found out that the average typically equals 0 +- 10 when the lamp is on, or off, except for when we capture the inrush current. * The RMS of just noise (standard deviation of noise) is pretty large, ~30000 to ~36000. These are all in bin calculations, and not yet translated into current or voltage. Translating these numbers into actual corresponding voltages and current is TODO. # 2/17/15 * Added offset configuration for the MCP ADC. * Fixed the way we read bytes from the samplebuffer, and the offset config is scaling correctly. # 2/13/15 * Added true RMS code to the PIC32, and learned how the USB Uart, Uart, and SPI interact for data flow on the DAQv2 design. # 2/12/15 * Implemented device creating handshake for the ESP8266 to the server. This creates the device, if it's not already in the system based on the serial number written in the firmware. # 2/11/15 * Fixed ESP8266 circular buffer bug of tail index going out of bounds. # 2/10/15 * Implemented the smaller state machine. The firmware is able to receive, store, and send messages faster now as a result. * There are no more hangups from testing as I can see so far. # 2/9/15 * Learned more about the PIC32 firmware, and introduced to more ideas to keep in mind about the PIC datasheet. * Started to simplify the wifi state machine process, and optimize performance. # 2/5/15 ESP8266 Power Consumption Report:

The objective is to determine if it is better to maintain a TCP connection to the server, or connect and disconnect every time there is information to send from the ESP8266. My predictions were that it would be faster to send and receive the data when not having to re-establish the connection and disconnect it every time. The power consumption of the ESP8266 when idling with the connection open would probably be greater than it idling with the connection closed. The idea is that the ESP8266 isn't going to be idle a lot of the time, and is always going to be packing, and sending data. This rules out the hypothetical benefits of connecting and closing a connection each time.

What I found that throughput did indeed increase when maintaining the connection. We are able to send and receive messages faster (on average). Time to send

This is the time that it took to send and receive messages for 10 different messages. I timed the start and end using a stopwatch, and watched the outputs on my terminal to see when things started and stopped.

Current draw while staying connected to the server and being idle was on average 10mA more than what the current draw was when idling without being connected. Current draw idling

The current draw was around 20mA without being connected, and 30mA while being connected when idling. It randomly spikes when idling, which I think is due to being connected to the access point. The spikes happen more often, with higher amplitude when we are connected on the extra TCP link. The recordings happened with my uniformly reading current draw every half of a second from a power supply.

Current draw while sending http requests was lower while sending http requests and staying connected, than establishing a connection each time. The chip seems to be using more current when trying to establish a connection, and when it disconnects, as well as the duration is longer (our first graph), so it would use draw that current for longer. Current draw sending http requests

As you can see on the graph, because sending while maintaining the connection is faster, the module draws less current because the sending duration is shorter (due to not having to configure callback functions for different link states, and other overhead, etc).

I believe it is best to keep the link open on the module rather than disconnecting and reconnecting like a curl command. There is an additional timeout period, where the connection times out if there is nothing sent or received for about a minute.

It takes an average of 95mW when sitting idle and connected to the server, and it takes an average of 73mW when idling and not connected to the server. It takes an average of 100mW when we are already connected and sending data to the server, it takes an average of 175mW to connect and then send, and then disconnect.

It doesn't seem like disconnecting will save that much power when we are talking on this kind of scale, and the most important thing we need is throughput, so we are going to stick with continuous connection to the server.

# 2/4/15 * Recorded information on the ESP8266 about how long it takes to send/receive http requests, as well as how much current it is using during that time, as well as idle. * Created an iteration of the firmware that maintains connection with Bryan's server. More to be done to fix speed, and optimize the protocol. * Trying to open and close the connection takes more power, and is slower. There are tradeoffs. TODO: Make a report about the tradeoffs and observed behavior. # 2/3/15 * Looking into power computations with the pic32, as well as fft. * Theoretically computed how many cycles the pic32 would take to make a RMS calculation on 130 points. Given 130 data points, we square all of them and add them. This would be around 6600 cycles from using [this website](http://hades.mech.northwestern.edu/index.php/PIC32MX:_Benchmarking_Mathematical_Operations). It is assumed we will take around 1 cycle per addition, 100 cycles for a division, and 700 cycles for the square root. This is estimated out to be around **_7530_** total cycles with a 130 window size. # 2/2/15 * Looking into how I can get the current unix timestamp from a http request so we can have accurate timestamps. * Will look at RMS calculations, real power, apparent power for power factor, and fft on the pic32. # 1/30/15 * Finished second iteration of ESP8266 firmware, integrated into Bryan's web firmware for configuring the wifi. * Able to configure the wifi module to connecto to a specific access point via the web, and then will send http messages on an established tcp link with Bryan's server * Learned memory mapping of the ESP module, should have enough space for code now, buffers were taking up too much RAM space. * Fleshed out ESP8266 FSM a bit more (see picture) ![Image](http://i.imgur.com/8ESlsln.png) # 1/29/15 * Found out my circular sending buffer was taking up tons of RAM space. Trimmed down the code, and now have tons of space to work with. * Fixed circular buffer code. Have acceptable input output formatting currently implemented for UART drivers. * The only thing left to do is to establish a TCP connection with Bryan's server, and then try to send data to him that way. # 1/28/15 * [found a different smaller esp webserver firmware, planning on developing on that instead](https://github.com/IOCare/esp8266GUI) * [esp memory layout and linking](http://www.esp8266.com/viewtopic.php?f=5&t=9&start=40) * [this is a potential fix](http://www.esp8266.com/viewtopic.php?f=9&t=1001) # 1/27/15 * Will need to figure out a way to remove bloat from the firmware. There is currently too much code involved. * Merged the two projects, having the same code bloating issue as before, there isn't enough memory to fit the text. * Ram is overflowing # 1/26/15 * Created the merged project for Bryan's firmware and my firmware # 1/23/15 * Encountered firmware bloat, not being able to fit text on the ESP's flash. * Trimming down the firmware, and going merging with Bryan's httpd server firmware # 1/22/15 * Planning on merging my ESP project with Bryan's ESP project for a fully function wifi configuring, uart receiving, wifi sending firmware. * Integration of the two projects will be hard. * Must also test test test the different buffer libraries created, as there are most likely bugs. * Currently implemented NMEA message talker ID's: * SE * Currently Implemented NMEA message type: * DAT * Example command: $SEDAT,1776,1283945892000[*checksum]\n # 1/22/15 * Finishing up implementation of circular storing buffer, having problems with not enough space in the flash or memory mapping for the ESP compiler. # 1/21/15 * State machine finished, and can use a little bit of work, currently only supports simultaneous receiving, and sending as well as receiving and storing. Could do all three in some cases but I'm not sure how to do it (something like mutex) * Finished up NMEA protocol libraries for the ESP, including checksum. * Added two semiphores for the uart receive buffer for simultaneous read and store as well as read and send # 1/20/15
  • Started writing buffer libraries for uart, as well as data to be packaged and sent out.
  • Added uart receive, buffer store, and tcp send state machine.
# 1/16/15
  • Debugged the 400 bad request response from Bryan's server
  • Required a special sequence of characters documented under ESP8266/Bryan's API
# 1/15/15
  • Unsuccessful debugging the 400 bad request response from Bryan's server
# 1/14/15 ## Sending data to a website * Immitate the way curl works and use that on the ESP8266

Notes

  • Documenation of the AT command located here, and learning how to send data.
  • Figuring out how to communicate between seads.brabsmit.com and the ESP.
  • Previously used:
curl -X POST seads.brabsmit.com/api/event-api/ -d '{"device": "/api/device-api/2/", "wattage":"100", "timestamp":"1203950300"}' -H "Content-Type: application/json" -H "Authorization: Token 0d1e0f4b56e4772fdb440abf66da8e2c1df799c0"
  • seads.brabsmit.com
# 1/13/15 ## AT Flashing Notes * Default communication parameters are 115200bps, 8N1 for older version and 9600bps, 8N1 for 0.9.2.2 ctrl-j for lf

ESP8266 Progress

  • Correctly compiled and flashed the AT demo, continuing UART demo communication.
  • Forked the AT demo into our repository
  • Left the demo to play around with, and created a copy to modify and start on the uart send/receive, http send/receive drivers
# Week of 1/5/15 ## ESP8266 Progress: * Built the ESP8266 [toolchain](https://github.com/esp8266/esp8266-wiki/wiki/Toolchain), and successfully tested sample programs * Wrote a script to automatically build the esp8266 [toolchain](https://github.com/esp8266/esp8266-wiki/wiki/Toolchain) * Forked the esp-httpd project webserver into our repo * Ordered 6 new ESP8266 ESP-03 simple serial wifi

ESP8266 Goals:

  • Set up firmware to configure an internet connection if there is none.
  • With internet connection, be able to send some garbage data to the server via UART
  • Server hardcoded for now, that isn't configured
  • Doesn't establish a connection, just sends garbage, and receives the http response
  • What this entails: UART send/receive drivers, TCP send/receive drivers
  • Starter code began with esp webserver http://git.spritesserver.nl/esphttpd.git/, and AT example

ESP8266 Version Layouts

The newer ESP-03
Image

The older ESP-V091
Image

Add a custom footer
Add a custom sidebar
Clone this wiki locally