Clock correction using SMB connector and GPS PPS on 9012, 9104

[rex1030]

I am trying to set the system time on my 9012 RT cRIO using a GPS string and then correct any drift using the SMB connector and the pulse-per-second from the GPS unit. I want the system time to be synced to the GPS time, accurate to the millisecond if possible.The only articles I have found on this subject refer to the article Using the SMB Connector for Digital I/O on cRIO-901x Controllers . This article claims to give code that "You can use the SMB connector of cRIO-9012/9014 controllers to connect a digital device to the controller. For example, if you connect the pulse-per-second (PPS) output of a GPS device to the SMB connector of a cRIO-9012/9014, you can use the GPS device to correct for drift of the system clock of the controller." However, the code posted only reads the SMB pin.

So, I wrote code that receives a time stamp from either a GPS device or a shared variable over the network amd sets the system time to that. If SMB correction is enabled, it waits for the state of the SMB connector (which is receiving PPS output from the gps) to go from true to false (rising edge) and then reads the system time, rounds it up to the next whole second and sets the time. (See the attached screenshot). Why round up? When I set the time I had received a timestamp from somewhere (gps or shared variable). I am always going to receive this time stamp late so the system clock will be set to a time that is earlier than it actually is. So since I have to decide which whole second is occuring when the rising edge of the PPS occurs, it will always have to be the next one (rounding up). Sounds confusing, but it makes sense.

I want the system clock to be synced to the GPS time and accurate to the millisecond. So in order to measure what I have I simply plugged the GPS PPS output into my 9215 Analog module and plotted the square wave over the system time at 10 kHz. Unfortunately there is still a little bit of drift, which is unacceptable.

What I am asking is, what do you guys think of what I have done? Am I doing something wrong here that is resulting in the drift I am receiving? Is my SMB loop inefficient? Should I not be using the 9215 to test it? I just don't know.

Has anyone come up with code that corrects the system clock using the SMB connector and PPS and been happy with the results?

edit-------------
the screenshot of the code doesnt seem to be showing up after I attach it, how do i do that. (sorry about all the edits, trying to get the screenshot to work)


Message Edited by rex1030 on 03-20-2008 02:27 PM

Message Edited by rex1030 on 03-20-2008 02:30 PM

Message Edited by rex1030 on 03-20-2008 02:32 PM

[Bassett_Hound]

Hi Rex,

Just for everyone else, your referring to the article: Using the SMB Connector for Digital I/O on cRIO-901x Controllers correct?  To be clear the SMB pin on the cRIO-901x can be used for two purposes:

1.  A general purpose DIO line

2.  As an input for a PPS signal to help correct for drift of the system clock.

The general purpose DIO line requires the code attached to the above article.  To use the SMB input to help correct for drift of the system clock you only need to configure the ni-rt.ini file and you do not need to implement any software/VI code yourself as the 901x controllers have the drift correction code already built into the software.  You are just required to enable it by configuring the ni-rt.ini file with the following keys:

Time Sync]
source.rtc.enable=True
source.dio.enable = True
source_priority=dio;rtc;
source.dio.hz = 1.0

I haven't looked at your VI above yet, but if your using the SMB read/write VIs you should remove those as you must either use the SMB line as a General purpose DIO or as an iput for the PPS signal.  Doing that may help you control the drift better.  I do think that application is interesting and I would be interested to see what you come up with.  How is the GPS serial stream coming to the controller?  I would think you should be able to wait on a read and set the RT clock in the msec range.

Hope that helps.  Let me know how it goes after updating the VI.

Basset Hound

Message Edited by Bassett Hound on 03-20-2008 06:06 PM

[Bassett_Hound]

Oh by the way,

An easy ( relative ) way to post an image of your code is:

1. You can attach the image to your post and allow the image to use National Instruments' servers. To insert the image into a post do the following:
2. Write your post as you would like it to be in its final form.
3. Attach the image that you would like to have appear in your post. Please use GIF or JPG files as they are smaller. GIF images are best if you are wanting to show LabVIEW code or Message Boxes as they are better at maintaining sharp lines.
4. Once your post appears copy the URL for your attachment.
5. Firefox: Right-click on the attachment and Copy Link Location
   Internet Explorer: Right-click, Open in a New Window, copy URL from the New Window
6. Go to Options » Edit Message.
7. Now you can click the 'Insert an Image' button and paste the URL for the attachment as the source. The image should now appear in your post. Preview the post to make sure it appears as you would like it to.
8. Finally, resubmit your post and the image should appear.

Basset Hound

[rex1030]

I don't really want to use the SMB to correct the drift of the system clock over time. I want to correct the system time to reflect the absolute time from a gps source.

The system will be set up as follows: We are going to be using a network of 4 cRIO devices. Before aquiring data the devices will go through a synchronization step.  We will be distributing a pulse-per-second signal from a GPS unit to all of the devices. Only one of them will recieve a gps sentence (timestamp) via serial port and write that time to a shared variable and send a trigger to the rest to set their time. The other units will see the trigger, set their time to the time from the shared variable. However, due to the fact that it will take time for them to recieve the trigger and for the timestamp to propogate over the network and so on, they will be recieving the timestamp late. That means that the time they set their clocks to will be earlier than it actually is (in absolute time), but by no more than a second. They will use the pulse-per-second signal to correct their system clocks. I want them all to reflect the correct time within 5 milliseconds. They will be recieving the pulse per second the whole time so there is no reason why they won't be correcting the drift.

But you see the difference right? I want all the system clocks to reflect the same, correct time, at any given instant.

What I really need is a method of checking the SMB that is faster than polling. Are there software interrupts I can use? Is there anything faster than what I am doing? I wish I didn't have to do all that bundling and unbundling because I know that slows down RT stuff.

I did enable the high precision correction in that file like the code you posted by the way.





Message Edited by rex1030 on 03-25-2008 02:41 PM

[Bassett_Hound]

Rex,

I think I understand what your trying to do.  First couple of things to make clear: the SMB pin can only be used as either a general DIO pin OR for drift correction, not both at the same time.  What this means is you cannot use it both as a DIO line and also use it to help correct for drift by inputing a PPS as you've described.  Basically, if your going to use it as a general DIO then the lines in the ini file are not going to do anything for you.  Also, if your inputing a pps signal into the the SMB pin ( and not using as a DI input ) it will just correct for drift, and will not give you synchronization between different the different RT systems. The drift correct will not be setting the time in any way at all.

Currently there is not an interrupt method you can use with the SMB pin and polling is the fastest way of checking the pin.   I wouldn't recommend the SMB pin to be used for synchronizing systems especially if your using it as just a general DIO line.  The is mainly because its just software timed when used as a general DIO.  However, you can write/read the pin in the range of 100 usec per write/read.

For synchronizing multiple cRIO systems I would normally recommend adding a DIO module (9401, 9403) to the cRIO to allow synchronization of the FPGA by sharing a start trigger or scan clock. This solution provides synchronization down to microsecond levels.

If your looking for synchronization in the usec level the a DIO module is the way to go.  If you need in the 10 of ms range, a NTP time sever will work.  If in the seconds range, then normal ethernet communication should be sufficient.

Let me know if that helps at all.

Basset Hound

[rex1030]

Thanks for your reply Bassett,

I know using the SMB for system synchronization is not recommended. However, in the same paragraph you said that I can read from the pin with an accuracy around 0.1 milliseconds. That is more than plenty. So I still feel that I can use it for system synchronization. We need all the slots we can have in our crio-9104 module. So it would be really nice to be able to do it this way. I have read all those articles on synchronizing multiple crio systems. I still want to try to get this to work for a little bit first before we buy more modules and move in a shared clock/ trigger direction.

So if i need timing within 3 or 4 ms, isn't it practical to say that I can use the SMB trigger for this?
What if i did this:
1 Set the time by gps string
2 Recorded the system time at the rising edge of the PPS pulse
3 Calculated the difference between rising edge and system time
4 set the time at the correct moment.

I have not been able to figure out how to set the millisecond value of the time. Does anyone know how to do this?

[CarlaU]

Hi rex1030,

I'm not sure what you mean by setting the millisecond value of the time? Can you post a simplified example that will explain your question a bit more or can you elaborate a bit on the question. Hopefully, with a bit more information, we can help you out.

[Bassett_Hound]

If all you were doing was reading the SMB pin and then setting the system time then you might be able to use the SMB pin.  It is just a software timed DIO pin so you will get some jitter with the reads.

However, as you currently noticed the LabVIEW RT Set Date and Time does not allow you to set the time with ms resolution.  I ran into this a while back and after some investigation I found VxWorks does allow setting the time with a function call called :  clock_settime()

The time format is:
U32 seconds and  nanoseconds since midnight UTC of January 1, 1970, not counting leap seconds.
in the following struct:
struct timespec
    {
    long      tv_sec;         /* seconds */
    long        tv_nsec;        /* nanoseconds (between 0 and 1,000,000,000) */
    };

You can call this with a Call Library Node in LabVIEW provided you'll need to make a fake (stub) LabVIEW.dll on the host that defines this function so the CLN will configure properly. It will only work on the RT target (VxWorks or 901x targets), not on the host, since the host has a stub.

A little more on a Stub: "Compile a stub DLL using the same function prototypes as those exported by the *.out shared library. A stub DLL typically only contains the function prototype themselves without any implementation (ie, empty functions.) This stub DLL will only be used on your Windows host machine, and must have the same name as the original *.out shared library -- for example: foo.dll and foo.out. "

 Hope that helps,

Basset Hound

Message Edited by Bassett Hound on 03-28-2008 09:54 AM

[rex1030]

Hey CarlaU,

I guess I explained it better on this thread: http://forums.ni.com/ni/board/message?board.id=280&thread.id=3662&jump=true

I opened it up because the clock setting was a more specific question than the topic of this thread

[CarlaU]

Hi rex1030,

Thanks for the information! It seems like you have all your questions answered.Good luck with the application!