What may I assume regarding 2-channel "keeping up" in time?
Quote from morten_schousen on 28/04/2024, 14:58Hello there,
I am working on an application, which reads Rx1 and Rx2. I need to read them as simulations as possible due to a later need to time align samples. I have noticed that although packages in one channel usually are completely aligned, that is, startTime id a package equals endTime of the package immediately preceding it. I therefore assume that there is no time gap and no samples are lost (although there seem to be two samples overlapping at pachage1.ensTime = packeg2.startTime).
I have hover observed that, on occasion, a package has a startTime which precedes the endTime of the immediately preceding package. That is, it seems as if a package begins before the previous package ends. Also, I have seen a package, which begins and ends before the preceding package ends. It is completely overlapped by the preceding package.
Such behavior makes it very difficult to write algorithms which depends on sequence of samples. Is it somewhere documented what I can expect with respect to time sequence of packages? Do you have some advice concerning how to handle this problem?
Your kind assistance is greatly appreciated.
Br, Morten
Hello there,
I am working on an application, which reads Rx1 and Rx2. I need to read them as simulations as possible due to a later need to time align samples. I have noticed that although packages in one channel usually are completely aligned, that is, startTime id a package equals endTime of the package immediately preceding it. I therefore assume that there is no time gap and no samples are lost (although there seem to be two samples overlapping at pachage1.ensTime = packeg2.startTime).
I have hover observed that, on occasion, a package has a startTime which precedes the endTime of the immediately preceding package. That is, it seems as if a package begins before the previous package ends. Also, I have seen a package, which begins and ends before the preceding package ends. It is completely overlapped by the preceding package.
Such behavior makes it very difficult to write algorithms which depends on sequence of samples. Is it somewhere documented what I can expect with respect to time sequence of packages? Do you have some advice concerning how to handle this problem?
Your kind assistance is greatly appreciated.
Br, Morten
Uploaded files:Quote from DevUS on 29/04/2024, 13:13The sampling clock is slowly adapted to stay in synch with the apllication/system clock, thus you may see some roughness at packet boundaries. It is possible to use the device clock instead of the system clock using the "Stream Clock = Oscillator" config.
Even better for your case might be the "Receiver Channels = Rx12" which splits the two IQ streams late in the processing chain, guaranteeing sychronous time stams in both streams.
The sampling clock is slowly adapted to stay in synch with the apllication/system clock, thus you may see some roughness at packet boundaries. It is possible to use the device clock instead of the system clock using the "Stream Clock = Oscillator" config.
Even better for your case might be the "Receiver Channels = Rx12" which splits the two IQ streams late in the processing chain, guaranteeing sychronous time stams in both streams.
Quote from morten_schousen on 29/04/2024, 15:09Hello again,
Thanks for your swift response. I believe you understand my problem very well, but I still have problems. Perhaps I should clarify that I access the Spectran via the C-API, not the RTSA suite. I know there are some additional features in the RTSA Suite not available from the API, but I am hoping there is a way to follow your suggestions:
When I set the "device/receiverchannel" to value to "Rx12", as you suggest, I get error code 8000000c (AARTSAAPI_ERROR_VALUE_INVALID). According to the config listings, as per the RawIQ2RX sdk sample I have the options of "Rx1;Rx2;Rx1+Rx2;Rx1/Rx2;Rx Off;auto". I currently use "Rx1+Rx2" as you do in the RawIQ2RX sdk sample.
Am I missing something?
Br, Morten
Hello again,
Thanks for your swift response. I believe you understand my problem very well, but I still have problems. Perhaps I should clarify that I access the Spectran via the C-API, not the RTSA suite. I know there are some additional features in the RTSA Suite not available from the API, but I am hoping there is a way to follow your suggestions:
When I set the "device/receiverchannel" to value to "Rx12", as you suggest, I get error code 8000000c (AARTSAAPI_ERROR_VALUE_INVALID). According to the config listings, as per the RawIQ2RX sdk sample I have the options of "Rx1;Rx2;Rx1+Rx2;Rx1/Rx2;Rx Off;auto". I currently use "Rx1+Rx2" as you do in the RawIQ2RX sdk sample.
Am I missing something?
Br, Morten
Quote from mm_dev on 29/04/2024, 15:38Quote from morten_schousen on 29/04/2024, 15:09Am I missing something?
That setting is not yet available in the current release version. You can get the current beta version here: https://downloads.aaronia.com/software/V6_RTSA_Suite_PRO/beta/Aaronia_RTSA_Suite_PRO_3.0.1.15473_Setup_64bit.exe
Quote from morten_schousen on 29/04/2024, 15:09Am I missing something?
That setting is not yet available in the current release version. You can get the current beta version here: https://downloads.aaronia.com/software/V6_RTSA_Suite_PRO/beta/Aaronia_RTSA_Suite_PRO_3.0.1.15473_Setup_64bit.exe
Quote from morten_schousen on 29/04/2024, 21:00Awsome! I will download the beta and upgrade once it is officially released. How will I know when it is finally released? Will the RTSA software tell me?
Once again, many thanks for your prompt and very helpful responses. Truly appreciated.
Br, Morten
Awsome! I will download the beta and upgrade once it is officially released. How will I know when it is finally released? Will the RTSA software tell me?
Once again, many thanks for your prompt and very helpful responses. Truly appreciated.
Br, Morten
Quote from Sune_Horlyck on 08/07/2024, 14:03I am working on the same Aaronia V6 API access to 2 channel raw IQ at 122MSamples/sec that Morten wrote about earlier. We are working towards co-analysis of the 2channel raw IQ. Separate channel-wise analysis is ill-suited for our application. We are changing between operation with and without
device/sclksource=Oscillator
In Oscillator Sync mode - the channels stay aligned for the first 10min-3hours (after a few hickups in the first 5-10 sec of operation). Subsequently the feed jumps into a state where the pairs of 65536 sample packages for the 2 channels are constantly 44 microseconds misaligned - and stays there.
If we run the same sampling SW WITHOUT sclksource set to Oscillator, the package-pair alignment seems to switch forth and back between good alignment and 44 microsecond misalignment (8.3% of package length) for varying periods of 50millisec to ~30 seconds.
Analysis of not perfectly aligned packages for the 2 channels is challenged by the API use of double (float64) epoch-second timestamps which has a de facto time resolution limit of ~>200 nanosecond or 30+ samples (we are looking for data features with short duration so that is not good.)
Ideally I would like to reboot the Aaronia V6 to see if it helps. Unfortunately we are working with a remotely deployed V6 a few hours drive away.
Does anyone have tips on how to avoid or "reset" this bi-stable 44microsecond package pair misalignment issue?
I am working on the same Aaronia V6 API access to 2 channel raw IQ at 122MSamples/sec that Morten wrote about earlier. We are working towards co-analysis of the 2channel raw IQ. Separate channel-wise analysis is ill-suited for our application. We are changing between operation with and without
device/sclksource=Oscillator
In Oscillator Sync mode - the channels stay aligned for the first 10min-3hours (after a few hickups in the first 5-10 sec of operation). Subsequently the feed jumps into a state where the pairs of 65536 sample packages for the 2 channels are constantly 44 microseconds misaligned - and stays there.
If we run the same sampling SW WITHOUT sclksource set to Oscillator, the package-pair alignment seems to switch forth and back between good alignment and 44 microsecond misalignment (8.3% of package length) for varying periods of 50millisec to ~30 seconds.
Analysis of not perfectly aligned packages for the 2 channels is challenged by the API use of double (float64) epoch-second timestamps which has a de facto time resolution limit of ~>200 nanosecond or 30+ samples (we are looking for data features with short duration so that is not good.)
Ideally I would like to reboot the Aaronia V6 to see if it helps. Unfortunately we are working with a remotely deployed V6 a few hours drive away.
Does anyone have tips on how to avoid or "reset" this bi-stable 44microsecond package pair misalignment issue?
Quote from DevUS on 08/07/2024, 18:34If you use the interleave mode:
if (AARTSAAPI_ConfigFind(&d, &root, &config, L"device/receiverchannel") == AARTSAAPI_OK)
AARTSAAPI_ConfigSetString(&d, &config, L"Rx12");you will get alternative IQ pairs from Rx1 and Rx2 in the same packet. It is not recommended to use decimation in this mode.
If you use the interleave mode:
if (AARTSAAPI_ConfigFind(&d, &root, &config, L"device/receiverchannel") == AARTSAAPI_OK)
AARTSAAPI_ConfigSetString(&d, &config, L"Rx12");
you will get alternative IQ pairs from Rx1 and Rx2 in the same packet. It is not recommended to use decimation in this mode.
Quote from jakubsrna on 15/07/2024, 17:06Thank you for your quick reply.
I'm working on the project together with Morten and Sune. I'm currently facing an issue with release 3.01. When trying to use SDK, it fails on missing the paths file during init. When going back to version 2.5 everything still works.
Thank you.
Thank you for your quick reply.
I'm working on the project together with Morten and Sune. I'm currently facing an issue with release 3.01. When trying to use SDK, it fails on missing the paths file during init. When going back to version 2.5 everything still works.
Thank you.
Quote from jakubsrna on 16/07/2024, 14:17Excuse me for posting one extra question, but when moving to the Rx12 mode, does it mean the data is actually alternating? I do not see any growth in packet lengths.
To illustrate what I mean.
Sample 1: IQ pair channel one (No data for channel two for specific timestamp)
Sample 2: IQ pair channel two (No data for channel one for specific timestamp)
Excuse me for posting one extra question, but when moving to the Rx12 mode, does it mean the data is actually alternating? I do not see any growth in packet lengths.
To illustrate what I mean.
Sample 1: IQ pair channel one (No data for channel two for specific timestamp)
Sample 2: IQ pair channel two (No data for channel one for specific timestamp)