It's been quite some time since my last post and I'm sorry about that. Real Life took some time away and the rest was spent fiddling with the new IMU and WiFi modules. I'll talk about the IMU in a later post and the WiFi module now since that's the thing killing me.
I've been working with the ESP8266 module for WiFi support for three or four weeks now. I'll split this up into 3 "phases".
Phase 1 - Features
The ESP8266 module has been around for a little while in the hobby market. It comes in a variety of form factors and I'm using the ESP-1 version for prototyping. I'll probably use the ESP-12 form factor in the final version of the project though, since it's RF shielded, FCC approved, and provides more pins for control. In either form, it's a nice little toy and has a decent feature set. It took some time playing with it to finally settle on what features I wanted to use. In short, I decided to use pretty much all of them. That means I'm targeting the follow features for the data collector with respect to WiFi:
Can function in Access Point and/or Station mode
Can accept multiple incoming TCP connections (acts as a TCP server)
Can open multiple outgoing TCP connections (acts as a TCP client)
Can provide DHCP services (DHCP server)
Can accept a DHCP address (DHCP client) or use a static address
Any data collector data can be sent over any of the TCP connections (client or server), including the ability use the desktop app to manage the device over WiFi
I'm not going to do anything with UDP for now but I could someday.
Once I settled on the features, I could implement the user interface for configuration in the desktop client and add appropriate support in the emulator for testing purposes. I won't bother to include screenshots of the configuration dialog now but suffice it to say, it's the most complicated configuration window in the application so far.
Phase 2 - Library
The next thing to do was add to the firmware to make the module do the tricks I needed it to. I looked around at a variety of ESP8266 libraries I found online but I wasn't happy with any of them. I needed something more robust which provided access to all the capabilities of the ESP8266's AT command set. I ended up writing my own and in the process discovered I didn't really like the AT command set that comes with the ESP8266 from the factory. The interface is somewhat inconsistent in places and I couldn't find any documentation on the version of the command set my chip was running since it appears to be newer than anything I found.
But I got it working anyway. After some debugging and some head scratching, it's fully functional. However...
Phase 3 - OMFG, this thing is slow!
I discovered the throughput on this device, using it the way I am, is terrible. It's unusable for even the simplest things. I whipped up some test code and was able to determine I'm getting about 1.28 kB/s of data pumping as fast as the MCU can, through a single TCP connection, to a WiFi access point 3 feet away which is dedicated to this test, over gigabit ethernet to my desktop where I have a simple python TCP server running and displaying a data rate. I made some changes to the testing code and was able to run the same test over the USB port and the BT module:
USB: 960 kB/s
BT: 16 kB/s
WiFi: 1.28 kB/s
With the normal project firmware loaded and configured to send everything over each of these connections, it looks like I need about 30 kB/s to be able to handle the maximum data collection/reporting rate. I should note, the BT number above is suspect because the BT module has been able to handle the 30 kB/s requirement in previous, unrelated tests. So I have to look into that, but I have to do some work on the BT module later anyway.
While I don't expect the WiFi module to handle the amount of data the full speed USB interface can, I'd like to see at least 50 kB/s on all the radio interfaces, and close to 4 times that on WiFi since the module should be able to have 4 TCP connections at the same time. That gives me a bit of cushion for future additions, especially since I doubt anyone in their right mind would want to send all the data everywhere at once.
So, what to do? I've started by making some small changes to the prototype, like connecting the ESP8266 to one of the MCU serial ports that has a hardware FIFO (duh). That didn't help though and I quickly realized why not: I was already pushing data as fast as the Teensy could go so the FIFO would be full all the time anyway, which is effectively like not having a FIFO at all. I've now started playing with the library I wrote in an attempt to cut out some inefficiencies, but I don't believe that will have the impact I need.
After some more online research into the problem, I discovered some posts and threads about throughput and way to increase it. They mostly have to do with turning off Nagle's algorithm and changing MTU sizes. If you're not familiar with networking stuff, that won't mean anything to you. What it means for me, however, is that I need to reprogram the ESP8266 module itself since those features aren't made available through the AT command set. So now I have to go on an adventure and learn much more about the ESP8266 than I really wanted to know. On the upside, I'll be able to change the AT command set into something more streamlined, built just for the project's needs, which should help with performance itself.
I don't know when the next post will be. I prefer to post when I have something useful to say and I don't know when that will be since I'm getting into entirely new territory. And while I just took a vacation recently, I'm starting to feel like I need another one, but who doesn't?