CS452 - Real-Time Programming - Winter 2017

Lecture 17a - Calibration II.

Public Service Annoucements

  1. Exam schedule is out; 12.30, Tuesday, 7 April is the date the registrar gave us. Please bring your exam schedule to class on Friday, 17 February on which day we will choose the time for our examination.
  2. First Train control milestone, Tuesday, 7 March.
  3. PDF documents containing mathematics.


Calibration is hard. The essence of its hardness is the inevitability of uncertainty in


Getting a sensor report indicating a sensor hit occurs at the end of a process requiring two sensor readings. On the first reading the sensor has not yet set; on the second reading the sensor has set. Here is the sequence in detail

  1. Request leaves user code.
  2. Final byte of request accepted by train controller.
  3. Train controller gets sensor values, sensor bit is unset.
  4. Final byte of sensor report arrives at ARM.
  5. Sensor report is time-stamped, t0.
  6. Sensor report arrives at user code.
  7. Second request leaves user code.
  8. Final byte of second request accepted by train controller.
  9. Train controller gets sensor values, sensor bit is set.
  10. Final byte of second sensor report arrives at ARM.
  11. Second sensor report is time-stamped, t1.
  12. Second sensor report arrives at user code.
The sensor was hit between step 3 and step 9. The application gets two times, t0 and t1. What should the the application conclude?

We will work this out in class, based on one thing we can measure fairly precisely and several things we can estimate quite precisely.


Once we know where a train is and how fast it's travelling we can calculate when we want things to happen in the train set, such as a change in a train's speed or the change in direction of a switch. In doing so we need to take into account transaction lag, the time between when user code issues the command and the time when the train or the switch carries out the command. The sequence is more simple than with sensors.

  1. Command leaves user code.
  2. Final byte of command accepted by train controller.
  3. Command received by train or switch.

Other complications

Velocity is controlled by changing the train's speed, BUT, the mapping between speed and velocity is not simple.

Important . Some of these effects matter; some don't. It's part of your task to find out which effects matter and which don't. (If you don't figure out which is which you will spend an unlimited amount of time.)

Furthermore, things can go wrong, such as

Avoiding such failures, or responding sensibly to them, is possible only if you have a `good enough' velocity calibration. (You get a perfect calibration only in the limit t->infinity, and the train you are calibrating falls over dead long before that.)

Such failures like these also pollute your attempt to acquire reliable data for your calibration.

1. Calibrating Stopping Distance

Being able to stop the train at a specific point is a very good warm-up exercise. The easiest case is to stop the train immediately after getting a sensor report. Here's what happens.

    The sensor report reaches user code.
  1. The stop command leaves user code.
  2. The final byte of the stop command arrives at the train controller.
  3. The train receives the stop command, and starts stopping.
  4. The train stops.
  5. You measure the distance from the sensor to the fiducial mark you have chosen. The distance you measure is the stopping distance for that sensor and speed.

Questions you need to answer. First, one big question