Scheduling the data sampling

Scheduling the data sampling

For any data logging system the ability to sample data on a regular basis with consistent time intervals between samples is essential for any time-based system. The periodicity needs to be consistent so that the time aspect of the data is not skewed. For example if the logged data was wheel speed then this data is only accurate when the time period between the samples is known. If this is not known, or is subject to variation then the resulting derived information such as distance travelled or acceleration will also be inaccurate.

The easiest way of collating data is let the data collection routines to free run and then calibrate the time interval afterwards against a known time period. The periodicity of the sampling rate is now determined by how long it takes to collect the data, which in turn is determined by the ability of the source to send the data. While this is simple to engineer, it is subject to several errors and problems:

•                                                                        The time period will vary from system to system depending on the system’s processing and which serial port controller is used.

•                                                                        The time taken to execute the sample collection may vary from sample to sample due to caching and other hard to predict effects. This means that the periodicity will show jitter which will affect the accuracy of any derived data.

•                                                                        It is difficult for any data display software to display the sampling rate without being supplied with some calibra-tion data.

For a system that provides data about how a car accelerates and behaves over time, these restrictions are not really acceptable. They will give an approximate idea of what is going on but it is not consistent. This also causes problems when data sequences are compared with each other: is the difference due to actual variation in the performance or due to variation in the timing?

Given these problems, then some form of time reference is needed. The PC provides a real-time clock that can be accessed by a system call. This returns the time in microseconds and this can be used to provide a form of software timing loop. The loop reads the system time, compares it the previous version and works out how long has elapsed. If the elapsed time is less than the sampling time interval, the loop is repeated. If it is equal, the program control jumps out of the loop and collects the data. The current time is stored as the previous time and when the data collection is completed, the timing loop is re-entered and the elapsed time continually checked.

This sounds very promising at first. Although timing loops are notorious for being inaccurate and inconsistent from machine to machine due to the different time taken to execute the routines, this software loop is simply measuring the elapsed time from a hardware-based real-time clock. As a result, the loop should synchronise to the hardware derived timing and be consistently accurate from system to system. The data sampling processing time is automatically included in the calculations and so this is a perfect way of simply synchronising the data sampling.

While in general, these statements are true, in practice they are a very simple approximation of what goes on in a PC. The first problem is the assumption that the system time is accurate down to microseconds. While the system call will return the time in microseconds, you do not get microsecond accuracy. In other words, the granularity of any change is far higher. While the design might expect that the returned time would only vary by a few microseconds if the call was consecutively called, in practice the time resolution is typically in seconds. So if the test condition in the software loop relies on being able to detect an exact differ-ence of 100 microseconds, it may miss this as the returned system time may not be exactly 100 microseconds. It might be 90 on the first loop and 180 on the second and so on. None of these match the required 100 microsecond interval and the loop becomes infinite and the system will appear to hang.

This problem can be overcome by changing the condition to be equal to or greater than 100 microseconds. With this, the first time round will cause the loop to repeat since 90 is less than 100. On the second time round, the returned difference of 180 will be greater than 100, the exit condition will be met and the loop exited and the data sample taken. The previous value will be updated to 180 and the loop repeated. The next value will be 270 which is less than the 100 difference (180 +100 = 280) so the loop will repeat. The next returned value will be 360 which exceeds the 100 microsec-ond difference and cause the loop to be exited and the data sample to be taken.

At this point note that when the data samples are taken, the required time interval is 100 microseconds. The first sample is taken at 180 microseconds followed by a second sample at 360 microseconds giving a sample interval of 180 microseconds. Com-pare this with what was intended with the software timing. The software timing was designed to generate a 100 microsecond interval but in practice, it is generating ones with a 180 microsec-ond interval. If the calculations are carried through what does happen is that one of the intervals becomes very short so that over a given time period, the possible error with the correct number of samples and the respective intervals between them will reduce.

However, this timing cannot be described as meeting the periodic-ity requirements that the design should meet. This approach may give the appearance of being synchronised but the results are far from this.

So while the system time is not a good candidate because of its poor resolution, there are other time-related functions that are better alternatives. One of these are the oft neglected INT 21 calls which allow a task to go to sleep for some time and then wake up and continue execution or wait for a certain time period to expire. The time resolution is far better than used by the system clock and there is no need for a software loop. The process is simple: collect the data sample and then make the INT 21 call to force the process to wait or sleep for the required time period.

The value for the time period needs to be calculated for each system. The sampling time is now part of the interval timing and this will vary from system to system. This provides us with the first problem with this technique in that the wait period will also vary from system to system. The second issue is that the time to collect the samples may also vary depending on the number of cache hits, or when a DRAM refresh cycle occurs and so on. So again, what appears to be a good solution suffers from the same type of problem. The sampling rate will suffer from jitter and will require calibration from system to system.

This system calibration problem is made worse when the software is run on laptop PCs that incorporate power saving modes to control power consumption. This will alter the clock frequency and even power down parts of the circuitry. This results in a variation in the time taken to collect the data samples. Any variation from the value used to calculate the INT 21 wait or sleep delay will cause variations in the sampling periodicity. These differences are never recovered and so the data sampling will be skewed in time.

It seems on this basis that using a PC as an embedded system is a pretty hopeless task. However there is a solution. Ideally what is required is an independent timing source that can instruct the data sampling to take place on a regular basis. This can be constructed by using one of the PCs hardware timers and its associated interrupt mechanism. The timer is programmed to generate a periodic interrupt. The interrupt starts an interrupt service routine that collects the data and finishes. It then remains dormant until the next interrupt is generated. The timer now controls the data sample timing and this is now independent of the software execution. Again, the standard PC design can be ex-ploited as there is an 18.2 Hz tick generated to provide a stimulus for the system clock. This again is not as straightforward as might be thought. The system clock on a PC is maintained by software counting these ticks even though a real-time clock is present. The real-time clock is used to set up the system time when the PC is booted and then is not used. This is why PCs that are left on for a long time will loose their time accuracy. The tick is not that accurate and the system time will quickly gain or lose time compared to the time maintained by the real-time clock. Each time the PC is rebooted, the system time is reset to match the real-time clock and the accumulated error removed.

There is an already defined interrupt routine for this in the PC. By programming the timer to generate a different time period tick and then intercepting the interrupt handler and passing control to the data sampler software, accurate timing for the data sampling can be achieved. This is the basic method used in the design.