WiFi_Train_SSE: Server Send Events

Source Code

Abstract/Summary: This project will combine two projects (i) WiFi_SSE that simulated a train sending HTML messages about its location as it transversing a block of track, and (ii) Track_Train_ESP_Class that used physical sensors to determine the actual location.

Possible Audience: Model railway enthusiasts interested in displaying the train location on a smartphone. Since the project combines two existing projects there is only minimal programming required.

Test Hardware: The project was developed using an ESP8266 with 74LS02, 74LS164 and 74LS165 chips as interface to LDR (Light detecting resistors 4 off) and 4 sets of RED, AMBER, GREEN LEDs acting as signals. Four 4K7 and four 1K0 resistors to act as pull up and current limiting required. Also screw terminals (32?). A Smartphone was used for testing

Keywords: ESP8266, Serial to Parallel, Parallel to Serial, C++ Library/Class, WiFi, Service Send Events

Required Libraries: ESP8266WiFi.h, ESPAsyncTCP.h, ESPAsyncWebServer.h and Track_Train_ESP_Class.h -This library inherits Signals3_Serial_Class.h and LDR_Serial_Sensor_Class.h.

Background/Introduction

I have a model railway layout that consists of multiple blocks of track. One such block is illustrated:

The following circuit monitors the sensors and controls the signals:

This project will combine two previous projects:

(i) Track_Train_ESP_Class that detected the position of the train using LDR sensors, controlled the signals (LEDs) in response and generated a signal train_loc that defined the train location/state {waiting, coming0, approaching0, arriving0, station0, departing0, leaving0, going0, coming1, approaching1, arriving1, station1, departing1, leaving1, going1}**;

(ii) WiFi_SSE that simulated the train location and send HTML messages.

The project description will assume that readers have undertaken both projects so will have the ESP8266 Arduino Add-ons and will have the necessary libraries.

** Definitions assume the train can enter the block of track from either direction - hence coming0 and coming1 etc

The Prototype

The prototype was constructed on two boards. The first board consisted of a parallel too serial converter 74HC165 that could handle up to 8 inputs (only 4 were used). For testing on the bench LDRs were wired to the screw terminals - only one shown. In the final train layout the LDRs were mounted under the tracks and wired back to the screw terminals**.

The wires out to the right go to the second board. This board contains the ESP8266 plus the 74HC02 and 74HC164 to generate the signals. For initial testing LEDs are used.

** The design uses 4K7 ohm pull up resistors with the LDRs. This may need to be adjusted for other environments.

Merging the Code

The Track_train_ESP_Class will be merged into the WiFi_SSE project:

1. Open WiFi_SSE and save as WiFi_Train_SSE. Check it still compiles and runs.

2. Change WiFi_SSE to WiFi_Train_SSE in 4 places (i) name of file, (ii) ssid (iii) in index.h the title and (iv) heading H2. Smartphone will now link to "WiFi_Train_SSE"

3. Include library #include <Track_Train_ESP_Class.h> and create instance. In my design Track_Train_ESP_Class train_obj(D0,D5,D6,D2,D1); where the arguments correspond to the wiring -ie ser_in, load, clk_in, ser_out, clk_out.

It will need to necessary comment out the line //enum where_is_train {waiting,coming0,.... but leave the definition. enum where_is_train train_loc; //location of train

4. As part of the setup( ) include train_obj.begin( ); Note witout parameters this defaults to train_obj.begin(1,1,4); External gate used (the NOR), positive logic and 4 sets of signals

5. Replace train_loc = simulate( ); with train_loc = train_obj.monitor_train( );

6. Since they are redundant comment out save_time, sample_time, and the simulate routine.

Testing

Covering any sensor and its corresponding signal should turn RED and go through the RED, AMBER GREEN sequence when the sensor is uncovered.

To test the WiFi it will be necessary to start at either of the "coming" sensors and work through the sequence. One state is shown below.

Performance

With all embedded systems its important to take some basic measurements to gain some understanding of the system performance. In many systems it is also worthwhile overloading the input to determine when the system fails and also to observe how it fails. In the case of the model train does the system just miss some input changes, lag significantly behind the input changes or does it become confused and fall over entirely if an express train passes down the section of track.

For this project measurements of the foreground (the loop( )) and background operations will be performed.

To profile the time performance the pin D8 was toggled at the start and end of the program loop and the result observed on a Mixed Signal Oscilloscope. The typical response was

As illustrated the loop takes 932uSec. As shown by the very narrow "glitches" in most cases the program leaves the loop and immediately jumps back in.

As illustrated the program is in general only spending 7.8uSec outside the program loop.

However, by triggering on pulses greater than 10uSec it was found that the system frequently performed background activities that took greater than 10uSec to execute. The longest was 68uSec. One must assume that many of these background activities would be related to the WiFi.

A more critical situation was when the train status changed and the WiFi SSE needed to send a new WiFi message. As shown below the program loop is now "interrupted" for 730uSec.

Assuming for this project we were not involved in developing the underlying libraries. On state changes these libraries send messages to the serial monitor and control the signals. This would all occur in the program loop prior to first cursor - approximately 3.5 divisions or 1.75 mSec where as the loop after the second cursor none of this extra activity occurs so the loop is only taking approximately 2 divisions or 1mSec.

These times are insignificant compared with the times involved with the model train so can be ignored. Prior to profiling the system we could only assume that the times would not be critical. After taking the measurements we can be more confident.

------------------------