UPDATED: October 09, 2015: Part 2 will list client-side UDP listener to implement time/date decoding of datagram.
ArduinoIDE 1.6.7 users should read my post here.
IoT is a hot spot in technology right now; however, the "I" stands for Internet and maybe you do not wish to have your IoT toys logging into your SOHO access point and accessing the Internet router. I recently published an ESP8266 project that goes off to NIST over the Internet through your AP and displays the current time and date on an OLED. This process is convenient, but does require that you supply the ESP8266 with your Access Point SSID and password. Change your AP password and the ESP8266 must also be changed to maintain password synchronization.
In considering the above (potential) security, I decided to utilize a rather inexpensive GPS serial module and an ESP8266 configured as an independent Access Point. The AP appears on any WiFi enabled device and can be connected to easily; in this project, the AP is not passworded, so the connection is very simple from notebook, PC, tablet, or smartphone.
The AP of the ESP8266 is configured to be a captive portal from a DNS perspective, which is explained in more detail in my recent hackster project: here. However, for this Proof-Of-Concept Project, I have not implemented a HTTP listener; therefore, no webpage will be served. It would be trivial to add the code for the webserver and to define a webpage that will output the time and date when a browser connects.
Eventually, the concept is to utilize a second (or more) ESP8266 as UDP receivers which will be placed throughout the house where traditional clocks are now located. The ESP8266 with the AP persona along with the connected GPS will be in the attic and powered from an existing 120V AC outlet using a 5V wall-wart. A DC-DC converter will be utilized to take the 5V to 3.3V for the GPS and the ESP8266.
Note: I have noticed that if the ESP8266 is too close to the GPS module, the GPS will shut-down (a phenomenon often referred to as "swamping". Therefore, some distance or some shielding must be utilized to block the ESP's radiation from the GPS antenna. On my breadboard setup, I utilize a MuMetal(R) foil shield to separate the GPS from the ESP8266. It may look "funky" but it is very effective! Pix below: GPS module to near center top of shield and ESP8266 to the bottom of shield - dangling off the breadboard.
Below is an old XP PC running Processing 3.0 alpha and a sketch to listen for UDP broadcasts. The PC is connected to the ESP8266 which is configured as an Access Point with the SSID of TardisTime. After connecting the PC WiFi to TardisTime, the ESP8266 will supply an IP address for the PC from the DHCP server being run on the chip. When the Processing Sketch is compiled and run, the console display should start showing the GPRMC sentence being broadcast once-per-second. I have circled the sections of the NMEA sentence that indicates the time and the date, UTC (what I used to call GMT.) As of 10:00E on 2015/09/22, this unit has run for 142 hours without incident (or reboot)... At this time, I am going to call the circuit stable; I am getting a consistent 26648 Bytes of free memory displayed on the serial console. I have 2 UDP listeners on separate floors of the house: both are WiFi connected to the ESP8266-01 AP 10.10.10.1 network for DHCP and UDP services. I am concluding the POC today and listing it as a success.
After the ESP8266 is programmed using a serial-USB converter, you will need to disconnect the URXD (Rx) jumper from the ESP8266 module and connect the GPS 9600 BAUD signal to this connection on the ESP826. On the PC, open a serial console for 9600 BAUD and connect to the serial port that is occupied by the serial-USB module (or, if you still have the Arduino IDE open, you can use the Java console provided by the IDE. Just double-check that the console is at 9600 BAUD. Resetting the ESP8266 will show the following on the console:
2015 Ray Burnette
Tardis Time Portal Version 0.20150915
Visit my project web page on http://www.hackster.io/rayburne
Setting pin#2 to Output mode
The "Free=" is a diagnostic message output once every 10,000 iterations through the loop() code. This number represents the amount of Free SRAM for various operations.
Note that Pin #2 is set for Output. I use that pin to blink a LED (use a suitable current dropping resistor - I am using 1K Ohm with a generic red LED.) In final use, the serial output will be disabled.
For the ESP8266 firmware sketch which is compiled by Arduino 1.6.6 (beta), please refer to my article esp8266-01 using arduino ide for software configuration. In addition, you will need the Streaming library and the Utility library (the .h and .cpp). The sketch code is shown lower down this page, just before the Comment section. The Streaming library is installed in your Arduino Library folder as it is usable for all Arduino models. The two Utility files are installed in the sketch folder as they are specific to this project.
For a remote PC to test the UDP broadcast, you will need Processing 3 alpha. After installing Processing on the PC, you need to copy and run the following sketch. Please note that you will need to also install a library named hypermedia.net and the source of the library is shown in the source file.
The project runs at 3.3V with a current of 140mA but the ESP866 has been known to have high peaks of current requirements upwards to 500+ mA. Therefore, a very high quality, low noise power supply must be used. I am using a 5V 1A wall wart from an old Blackberry device and using a 5V to 3.3V DC-DC switcher to regulate the final voltage. These switching units are often under $1 from Chinese vendors. My unit is 92% - 94% efficient, but more efficient units are available for a higher price tag.
With the ambient temperature of the air at 74F (23.3C) the ESP8266 is registering 105F (40.5C). I have no benchmark readings for comparison, but I feel this is in the normal operation area. The chip is rated for -40C to 125C but these are the extreme points in the hardware guide and the Chinese breakout boards have no provisions for heatsinking.
In addition, the DC 3.3V must have a ripple of less than 200mV: reference ESP826 Hardware User Guide, section 2.3.3. If operated in "N" mode, the ripple must be less than 120mV. When purchasing or designing the DC-DC converter please keep this factor in mind. I can personally attest to issues with poor power conditioning. The hardware guide recommends a 10uF high-quality filter capacitor from Gnd to Vcc as close to the microcontroller as possible.
While pondering how I was going to install the prototype in my attic for further testing and to use as a signal source as I finished the "UDP receiver" design, my attention was drawn to an empty steel coffee can that I had saved to use for putting paint in for a small painting job. The steel bottom, the plastic top all seemed to be a great enclosure; the DC-DC buck power supply could be housed inside the can to ensure it would not short. The ESP8266 could be affixed to the bottom of the can such that the "top end" of the strip antenna was oriented toward the bottom of the can - thus, this would be the small-signal endpoint of the antenna and the torus representing the majority of the electromagnetic signal should be minimally attenuated . The GPS could easily be mounted on the snap-plastic top with Velcro dots. The coffee can could be temporally mounted using elastic bands.
It resulting prototype is not pretty, but it is in the attic, out of sight, and performing wonderfully: the entire main floor and the associated basement floor are receiving a good signal. I will look into an optimum design later. For now, an AC 9V 1 Amp wall wart is being used to power the DC-DC (buck) converter which is stated 92% efficient. The output of the DC-DC was adjusted to be 3.30V fully loaded and then the voltage "rise" tested by removing the GPS and then the ESP8266. In both cases, the lower current did create a small rise in the output DC voltage, but none over 3.45V; therefore all is within the safety guidelines of both voltage sensitive components.
This section and associated code is utilized to connect to the transmitter and listen to the UDP datagram. The software then decodes the NMEA stream into UTC time (Zulu or GMT) and also decodes the date into European format (YY/MM/DD).
There are two ways to use the receiver output. The raw $GPRMC sentence can be serially output to any Arduino running standard GPS libraries; in this way, the ESP8266 appears as a remote GPS device and the Arduino software and display should require minimal changes. In "DEMO" mode which is set by a variable early on in the source code, only the Time and Date are sent to the serial output. Unless changed, the BAUD is 9600.
The source code provided here will compile and run and provide the output as described above; but the functionality may be unstable. By unstable, I mean the receiving process may lock (hang). I have put 3 lines of code into the sketch which seems to alleviate some of the issue - but, the additional lines to send a datagram should not be necessary, in theory. In any event, the receiver sketch should be considered "alpha" class. At present, anyone that elects to use this code must assume their own support of same.
The sketch is titled TardisTimeReceive.ino and is downloadable from the Software Section as a ZIP file.
Those of you wishing to have a more "formalized" output with leading zeros may wish to incorporate a little technique I learned from Rob Tillaart here:
Serial << (F("Time: ")) << ((hour<10)?"0":"") << hour << ":" ;
Serial << ((minute<10)?"0":"") << minute << ":" ;
Serial << ((seconds<10)?"0":"") << seconds << endl;
Serial << "Date: " << ((month<10)?"0":"") << month << "/" ;
Serial << ((day<10)?"0":"") << day << "/" << "20" ;
Serial << ((year<10)?"0":"") << year << endl;
Now, the output is a very nicely formatted numeric string:
This section and associated ZIP code titled TardisTimeReceive_OLED.zip are for a portable 3.3V battery driven ESP8266 with an I2C OLED display.
The exact same code will also work on the 128x64 display without any changes.