Forum
Please or Register to create posts and topics.

How to get the new GPS Time Sync/Validation features to work

Apparently the most recent FPGA firmware 2.8.0 is required for the gps time validation to work.

If you don't see 2.8.0 listed as FPGA version in the Spectran V6 block in the RTSA, you can update it with the following steps:

  • In the RTSA-Suite PRO, shut down the Spectran V6 device (power button is not active) 
  • In the Spectran V6 block settings, in the section "Device Manager" -> "FPGA Update", press the button "FPGA update" and wait for the procedure to complete
  • In the same section, press the button "RF FPGA Update" and wait for the procedure to complete   
  • Reconnect the Spectran V6 in the RTSA-Suite PRO (press the "Start" button)

To check the GPS time received:

  • In the Spectran V6 block, in the section "Board Config" change the setting "GPS Mode" to "Location and Time".If that setting is not available (only "Disabled" is enabled) then you are currently missing the Spectran V6 GPS license key, please contact our support in that case.

Now, assuming you have a GPS antenna connected and receive a GPS signal, the values for "GPS Sats", "GPS Time" and "GPS dTime" should display corresponding values (it may take a few seconds). "GPS dTime" is the delta between the received GPS time and the current stream time (system time by default).

If you want to use the GPS time as stream time you can do so by changing the setting "Stream Clock Source" to "GPS". If that setting is not available you are missing the Spectran V6 GPS Stream Clock license key, please contact our support in that case.

With that setting, the value of "GPS dTime" should start decreasing toward 0ms.

 

Sofon has reacted to this post.
Sofon

We want to obtain the correct GPS time stamping at the data packets through SDK/API. Could you help check the following snap-shot? I don't know what I am doing something wrong.

Yes, there seems to be a mismatch between the GPS time and the IQ packet timestamps when using the DLL. We'll need to investigate why that is showing up.

Turns out that there are two issues at work here:

There is a bug in the DLL that prevents the GPS Stream Clock license key from being activated when used with the SDK (doesn't affect the RTSA). This causes the call to 'AARTSAAPI_ConfigSetString(&d, &config, L"GPS Provider")' to fail, which due to not checking the return status went unnoticed. That has been fixed in version 10134 forward.

Second, because you're dumping every single packet to the console you have a significant processing delay, causing packets to be buffered. So the packets you are processing have actually been collected quite some time ago (can be >10 seconds). To avoid this buffering you should only analyze and dump a fraction of the packets like this (note: this requires the call to ConsumePackets() to be moved behind the if-condition block):

 

...

int counter = 0;
while(true)
{
AARTSAAPI_Packet packet = { sizeof(AARTSAAPI_Packet) };
AARTSAAPI_Result res;

while ((res = AARTSAAPI_GetPacket(&d, 0, 0, &packet)) == AARTSAAPI_EMPTY)
Sleep(5);

if (res == AARTSAAPI_OK && counter++ % 1000 == 0)

{

...

I'd also recommend that when dumping timestamps to the console you output a delta value rather than the absolute value (e.g. 'packet.startTime - gpsTime' instead of just 'packet.startTime' ), helps quite a bit in understanding the output.

AdminTC and Sofon have reacted to this post.
AdminTCSofon

Maybe there is some bugs in the DLL, it will take a long tine to adjust the data time match the GPS time. and the data doesn't output fluently.

It does take a while to synchronize after gps time has become valid, that's normal. Though I'm quite irritated by that huge change in your dataTime output (that's almost factor 1000 difference, so many years ahead), that's clearly wrong and we haven't observed such behavior here.

For reference, this is the streamIQ() function we've used for testing (note that we're not casting variables to integer datatypes):

void streamIQ(AARTSAAPI_Device d)
{
// Prepare a line buffer

wchar_t buff[102];
for (int i = 0; i < 101; i++)
buff[i] = ' ';
buff[101] = 0;

// Receive up to 10 packets

int counter = 0;
while(true)
{
// Prepare data packet

AARTSAAPI_Packet packet = { sizeof(AARTSAAPI_Packet) };
AARTSAAPI_Result res;

// Get the next data packet, sleep for some milliseconds, if none
// available yet.

while ((res = AARTSAAPI_GetPacket(&d, 0, 0, &packet)) == AARTSAAPI_EMPTY)
Sleep(5);

// If we actually got a packet

bool gpsTimeWasValid = false;
if (res == AARTSAAPI_OK && counter++ % 100 == 0)
{
AARTSAAPI_Config health, config;
if (AARTSAAPI_ConfigHealth(&d, &health) == AARTSAAPI_OK)
{
int64_t v;

bool gpsTimeValid = false;
int gpsNumSats = 0;
double gpsTime = 0, gpsTimeOffset = 0;

// Number of visible GPS satellites

if (AARTSAAPI_ConfigFind(&d, &health, &config, L"gpssats") == AARTSAAPI_OK)
{
AARTSAAPI_ConfigGetInteger(&d, &config, &v); gpsNumSats = v;
}

// Time stamp provided by GPS is valid and second tick is precise

if (AARTSAAPI_ConfigFind(&d, &health, &config, L"gpstimevalid") == AARTSAAPI_OK)
{
AARTSAAPI_ConfigGetInteger(&d, &config, &v); gpsTimeValid = v != 0;
}
if (gpsTimeValid && !gpsTimeWasValid) {
//AARTSAAPI_StopDevice(&d);
//AARTSAAPI_StartDevice(&d);
gpsTimeWasValid = true;
}

// Current GPS time in seconds since the start of the epoch

if (AARTSAAPI_ConfigFind(&d, &health, &config, L"gpstime") == AARTSAAPI_OK)
AARTSAAPI_ConfigGetFloat(&d, &config, &gpsTime);

// Time offset between GPS time and stream time

if (AARTSAAPI_ConfigFind(&d, &health, &config, L"gpstimeoffset") == AARTSAAPI_OK)
AARTSAAPI_ConfigGetFloat(&d, &config, &gpsTimeOffset);

double t = 0.0;
AARTSAAPI_GetMasterStreamTime(&d, t);

std::wcout << "Counter: " << counter / 100 << ", "
<< "Sats: " << gpsNumSats << ", "
<< "gpsTimeValid: " << gpsTimeValid << ", "
<< "gpsTime: " << gpsTime << ", "
<< "gpsTimeOffset: " << gpsTimeOffset << ", "
<< "master Time delta: " << t - gpsTime << ", "
<< "data start delta: " << packet.startTime - gpsTime << ", "
<< "data end delta: " << packet.endTime - gpsTime << ", "
<< "sysTime delta: " << time(nullptr) - gpsTime << std::endl;
}
}
// Remove the first packet from the packet queue
AARTSAAPI_ConsumePackets(&d, 0, 1);
}

}

Sofon has reacted to this post.
Sofon

Now using the newest version RTSA, it almost take me twenty minutes to synchronize completely after GPS time has become valid. I donot think it is normal. Moreover, the data time will be see complete wrong occasionally, such as data time is "12313582688" and no data time update sometimes. In this case, I multiple run the program which are combining with GPS time and Raw IQ  sample all from the SDK.

Quote from Sofon on 11/01/2022, 08:07

Now using the newest version RTSA, it almost take me twenty minutes to synchronize completely after GPS time has become valid. I donot think it is normal.

Your system time is more than one hour off compared to the GPS time. In that case it is normal that synchronization can take a while to avoid large jumps in the timestamps, as that could cause all kinds of problems. If you adjust your system clock synchronization should finish much faster.

Sofon has reacted to this post.
Sofon

Here attached the test result data logging that it is outputted from the sample program. it almost take 1 second time to adjust every second data time for matching the GPS time.

So is it solved from your side now?