Project Logs

Collapse

• ESP-Gzip Webpage compression

  Cristian Dobre • 02/24/2016 at 14:54 • 0 comments

  I finally took the time this week to refine my ESP-Gzip utility which I use to minify the website which will represent the user interface of the AirCore module. I have removed the 7za dependency and the compression is now done using node's own zlib API.

  Reducing payload

  The purpose of this utility is to reduce the website payload as much as possible by minifying and then compressing webpages using gzip. For example, the source website has 3712 bytes which the compressed file reduces to 1629 bytes. That means it's size has been reduced by more than 60 percent.

  First served webpage

  Even though I plan to develop a one page app to configure the ESP8266, I hate writing CSS and JS inside a single HTML webpage. That's why the utility supports inlining the resources at generation time, by including the #inline directive. This also minimizes the number of HTTP requests.

  <link href="css/styles.css#inline" rel="stylesheet">
  <script src="js/script.js#inline"></script>

  There are of course, disadvantages of using this method:

  • website is static, ESP8266 is blindly sending bytes
  • dynamic behavior requires WebSockets or AJAX
  • tool infancy, you will probably find bugs when using this extensively

  For HTTP interactions, I've published the esp_http library on GitHub. For now, it only supports HTTP requests.

• Market analysis

  Cristian Dobre • 02/03/2016 at 12:34 • 0 comments

  Before starting any of the posts regarding the development process, some research needs to be done in order to see if the product is really needed by anyone. Spoiler: this will be quite a long post.

  Market analysis is an insight tool

  Most projects here focus just on the implementation of the idea they're based upon. Even so, the target audience can have important leverage on what your product should behave. Without a client for your product, you're left with an object in which you invested precious development time. It's important to gather feedback from similar products so we can know what to improve.

  As for this module, I want it to be connected to a fast moving robot, but other people may need it for totally different reasons. It's easy to be selfish and optimize the hardware for your own usage, but it will reduce the number of potential customers.

  Problem solving while finding your audience

  Let's say you have one of the popular WiFly module on hand, and with the help of an Arduino you want it to transmit data with as less delay as possible to a screen. Making an event based, simple HTTP request seems to be hard because of the examples provided and the number of lines of code you have to write. Let's list the major drawbacks and see where the AirCore module needs to improve:

  • Confusing hardware interface and setup
  • Programming is complex and time consuming
  • Overhead: microcontroller manages most of the protocol connection
  • Compatibility depends on the protocol you use

  Similar implementation using Bluetooth. Image courtesy of Adafruit
  

  Confusing hardware interface and setup
  

  Anyone who's got an Arduino knows what an UART or serial connection and has probably used an FTDI or CP210x module before. This has the advantage of being mainstream and straightforward because its used to program the Arduino Pro Mini's. There are only six pins on this interface, so it makes it a perfect candidate as the AirCore connector. Also, shiny breadboard friendly.

  Programming is complex and time consuming

  To program the Arduino and WiFly to fit your needs, you need to have a knowledge base about microcontrollers, WiFi, HTTP and TCP. This is pretty much overwhelming just for sending some data, and I don't know a lot of people which can do it. So, the module needs to manage that overwhelming part in order to win some points. Familiarity is the key here: the module should be configured like a WiFi router.

  Overhead

  Image courtesy of O'Reilly

  Overhead is the most frustrating thing you encounter when using a WiFi module. You have to handle the protocol connection on your microcontroller, and it's often hard to do and not easily portable to another platform. Let's say I wrote my code and it works great on an Arduino, but if I wanted it on an ARM or Edison board, I need to rewrite. That's no a simple solution.

  Removing this overhead is the main purpose of the AirCore module. What if we can handle all the protocol details on the WiFi module and leave the microcontroller in peace because it has other things to do. This way, the only thing you need to worry about on your Arduino is spitting and receiving data from the serial pins solving the portability problem.

  Compatibility depends on the protocol you use

  Whenever you have incoming data over the internet, it needs to decode and process that information. TCP or UDP are raw connections, and if you didn't care about them when connecting AirCore module to your microcontroller, you certainly don't want to hear about them now.

  To be as Plug And Play as possible, the AirCore will use WebSockets. They're great and they have tremendous support. Every browser supports them, and you have a browser on your phone, computer and tablet.

• Getting started

  Cristian Dobre • 01/28/2016 at 11:06 • 0 comments

  Some time ago, I had to build a wireless timer which had to display current time and lap times on a screen nearby. I've accomplished this back then using an WiFly RN-XV from Sparkfun, but the amount of coding required for the networking part was ridiculous. Especially because I had to read most of the RFC6455 in order to write a proper implementation. For another project, the library was updated to support multiple concurrent connections.

  The idea for a module like this came to my mind when I saw other people doing TCP transparent bridges using cheaper ESP8266 modules. Even though free, Espressif's SDK had a generous amount of bugs back then, so the idea was put on hold.

  The streaming protocol of AirCore relies on WebSockets implemented over a TCP connection. WebSockets have numerous advantages in terms of latency, communication speed and compatibility across different platforms. A WebSocket connection is a full duplex, persistent connection which has lower latency and less overhead compared to plain HTTP. And the protocol is supported by (almost) all modern Web browsers.

  Supressing bootloader output

  An annoying thing discovered while using the ESP8266 is the bootloader output which can't be disabled. You can swap the UART pins, but the TX remaps to MTDO which has to be held low during booting, so it would generate noise on the line. I have used a BSS138 Logic Level Translator on my board to toggle the ROM output, even though this occupies another GPIO pin.

• Hello Hackaday

  Cristian Dobre • 01/25/2016 at 18:42 • 0 comments

  As this is my first project log, I'll try to make a proper introducement, then go into the details of why I chose Hackaday.io community to showcase my project.

  My name is Cristian, I am an undergraduate CS student. In the past two years, I've been heavily involved in the hobby robotics field here in my country. Along with my robotics team, we've managed to accomplish great things, like winning the 2015 Linefollower contest at RobotChallenge Vienna. I am big a fan of HaD and I've watched the blog for about half an year now.

  As any EE enthusiast, I am trying to make my own PCB for the ESP8266 chip which will complement the software and make it more attractive for end users in terms of usability. This project is more about designing a fully functional product from the feet up, than it is about software and hardware.

  As the project is going on, I'll try to explain every decision I make regarding usability, marketing, software and hardware and hopefully I'll receive great suggestions from experienced guys here in the Hackaday community.
  

View all 4 project logs