Windows jitter

[Ether]

(I moved the following post to this new thread so as not to hijack Dr Joe's thread on CAN)

Originally Posted by Greg McKaskle

Since I don't happen to have a scope, or a PC with a serial port for that matter, does anyone have a screen to share, or a description of the effect?

I don't have a digital storage scope either, but here's a graph showing the timing jitter of 10,000 samples I just collected of a 20ms period task running on an XP machine.

Looks pretty good, but 10,000 samples at 50Hz is only 3.3 minutes, and I didn't have anything else running.

I'll post more detail later tomorrow how I acquired the data if there's interest.

[Ether]

Originally Posted by Ether

...and I didn't have anything else running.

See attached graph of samples collected while surfing the web. Yikes!

[Hugh Meyer]

Ether,

Now you are starting to see what I was talking about!

I hope to get your code and test it on a classmate in a FRC driver station. There is no serial port, so I was planning to use an output pin on the cypress board that we use for driver station IO. It may be a few weeks before I get this done.

Can you describe how you are collecting and plotting this data. As I recall, in a previous thread, you said you didn't have a scope? I do have a scope and will see the jitter as a vertical line smeared on the horizontal scale.

-Hugh

[Ether]

Originally Posted by Hugh Meyer

Ether,

Now you are starting to see what I was talking about!

I hope to get your code and test it on a classmate in a FRC driver station. There is no serial port, so I was planning to use an output pin on the cypress board that we use for driver station IO. It may be a few weeks before I get this done.

Can you describe how you are collecting and plotting this data. As I recall, in a previous thread, you said you didn't have a scope? I do have a scope and will see the jitter as a vertical line smeared on the horizontal scale.

-Hugh

Hugh,

Keep in mind that the data I generated was from a small app I wrote in which I made no attempt to optimize the realtime behavior. I don't know what steps were taken in the Driver Station app to make its realtime behavior more stable and accurate.

To collect the data shown in my previous two posts, I wrote a simple 32-bit Windows console app (different from this) which allowed me to run a test and grab the data all on one machine. It basically does this (pseudo-code):

first collect the samples:

samples=10000;

for(i=0,i<=samples,i++){
sleep(20);
// grab RDTSC1 here
}

then write them to a file:

for(i=1,i<=samples,i++){
// write i and (sample[i]-sample[i-1]) to the output file
}

So basically, I am sampling the time at each start of a 20ms periodic task. The difference in start times between consecutive periods is what I plotted.


To plot the data:

- import the data into Excel

- plot the data and locate the "quiescent" value

- go back and multiply each data point by 20/quiescent

- re-plot the data

Then I realized I have an old DOS machine in the basement which could easily be used to make a poor-man's scope of sorts. Old DOS machines are great for data acquisition and other time-critical tasks because DOS is not multitasking, and it lets you work directly with the hardware. The MC146818 realtime clock chip can be programmed to generate interrupts up to 8092Hz. I use this interrupt to increment a 32-bit counter, and that gives me a counter that increments every 123.5 microseconds that I can use for timing measurements. I wrote a small program that basically does this:

while (1) if(CTS_has_changed_state) readCounter;

That will capture the timing of the rising and falling edges of the changes at the CTS pin (pin8 of the RS232 port). No logic is necessary to detect CTS_has_changed_state; it can be read directly from bit0 of the Modem Status Register.

I haven't had a chance to do this yet, but my plan is to make an RS232 cable to connect the DOS machine's COM1 port CTS pin to the RTS pin of my machine-under-test (XP) which is running the RTS toggler I posted here.


Since you want to run a test on the Driver Station on a machine that does not have an RS232 port, there's really nothing in the RTS toggler app that would be of any use to you (all it does is toggle the RTS pin). Is the source code available for the Driver Station? If so, I suppose what you could do is edit and re-compile the Driver Station to toggle the output pin of the Cypress board like you said. Raise the pin at the start of the task and lower it at the end, then either measure the waveform with an oscilloscope or use some other test equipment (like my DOS machine discussed above) to capture the timings of the transitions of the pin.




¹the RDTSC is a screaming fast read-only 64-bit hardware counter that can be latched and read "bare metal" with only 1 assembly instruction (Windows allows you to read it directly from the hardware; no API required). On the XP machine I ran it on, it ticks at about 3GHz. Note: there are some issues with RDTSC on newer machines so YMMV.

[Hugh Meyer]

Ether,

You know you can still do this all in assembler... If you don't already know about this, you might like this link.

http://masm32.com/

I often use lines on the parallel ports for stuff like this. There is less "junk" in the way. :-)

-Hugh

[Greg McKaskle]

If the point is to measure the jitter of the DS, why not do what Marshall did and measure it at the robot? After all, the jitter would include that introduced by the DS, by the networking code of the DS laptop, each network switch, router, AP, or other appliance, and finally the network code on the robot. All contribute, so measuring only the DS is measuring only a portion of the jitter.

Greg McKaskle

[Ether]

Originally Posted by Greg McKaskle

If the point is to measure the jitter of the DS, why not do what Marshall did and measure it at the robot? After all, the jitter would include that introduced by the DS, by the networking code of the DS laptop, each network switch, router, AP, or other appliance, and finally the network code on the robot. All contribute, so measuring only the DS is measuring only a portion of the jitter.

Greg McKaskle

All very true indeed.

Can't speak for others, but I did what I did because I wanted to put something together that could very easily be replicated in the classroom as a teaching tool for students to show them (seeing is believing) what happens to a program in a preemptive multitasking environment.

Rookie teams don't have a robot yet, and may not have access to one.

[Ether]

Originally Posted by Ether

I haven't had a chance to do this yet, but my plan is to make an RS232 cable to connect the DOS machine's COM1 port CTS pin to the RTS pin of my machine-under-test (XP) which is running the RTS toggler I posted here.

OK I did it:

XP machine running a process which toggles the COM1 RTS pin at 50Hz 25% duty cycle (5ms ON, 15ms OFF).

Null modem cable connects the COM1 port of the XP machine to COM1 of a Gateway 9550 laptop booted to FreeDOS and running an app which timestamps* the rising and falling edges of the signal on its COM1 CTS pin.

Attached is a plot of a portion of the data.


*with a 1.13 GHz counter

[kamocat]

Hey folks,
Glad to see you're still creating tools to quantify the quality of communication between the Driver Station and robot.
On that note, I wanted to thank Greg for the new "Charts" tab in the driver station this year, which indicates when packets are dropped. (I haven't tested that it works, but I'm assuming). This serves as a basic diagnostic tool during competition. I've seen a number of matches where a robot lost communication and was temporarily disabled, but the team didn't have enough data to convince the referees it was a communication error. (It usually tends to be blamed on the positioning of the radio within the robot, or an Ethernet cable, or the power connector on the radio).