Login Page - Create Account

Home >> Support Board

Support Board

Date/Time: Fri, 20 Sep 2024 00:55:58 +0000

How to Post a Message for Support

Post From: Timing problems

[2014-04-08 17:35:50]
[Go To First Post]
Hendrixon - Posts: 130
Just look on the picture.

On a 1 Tick chart like this, the milliseconds (top study) should be all over that place, very random... but they don't... they just orderly go from 0 to 999.
on a 2000ms chart update interval (like in the picture) it takes two and a half minutes for the milliseconds to go from 0 to 999.
See the bottom study showing seconds... going from 0 to 59 normally... and see how you can almost fit 3 MINUTES in how long it takes the "milliseconds" to do their thing there...
Sorry I can't explain this better cause I can't make any sense why SC behaves like that. its too weird.


For local seconds time stamp use this:
int& IndexFollow = sc.PersistVars->i1;
  
  if (IndexFollow < sc.Index)
  {
    SYSTEMTIME systime;
    GetLocalTime(&systime);
    IndexFollow = sc.Index;
    Second[IndexFollow] = systime.wSecond;
  }

For milliseconds use this:
int& IndexFollow = sc.PersistVars->i1;
  
  if (IndexFollow < sc.Index)
  {
    SYSTEMTIME systime;
    GetLocalTime(&systime);
    IndexFollow = sc.Index;
    Millisecond[IndexFollow] = systime.wMilliseconds;
    
  }


Remarks:
1.
Don't use sc.CurrentSystemDateTime cause its wrong, it rounds "seconds" instead of truncating so I don't trust it on anything.
For example you report ticks timestamp like this:
00:00:05.450 is rounded to 00:00:05 (five)
00:00:05.550 is rounded to 00:00:06 (yes SIX)
Those are real milliseconds from the feed... not your counter.

2.
use sc.OnExternalDataImmediateStudyCall = true;

3.
you need to make sure your local time is spot on cause even with Meinberg's NTP client you could get +/-150ms from real time based on your system quartz frequency drift.
Date Time Of Last Edit: 2014-04-08 17:37:49