- This topic has 15 replies, 4 voices, and was last updated 7 years, 10 months ago by
.
- Posts
BB60C–external trigger–bbFetchRaw(buffer, triggers)
I use GPS to 1PPS to fetch external trigger.
I call bbFetchRaw() Continuously.
And every 76~ times triggers[0] have a non-negative value, like 739915,1048099,307706…
So I want to know what does these numbers mean?
Means the start posiontion of external trigger?
Like this: triggers[0] == 307706, so buffer[307706*2] and buffer[307706*2 + 1]?
But bufferLen is 16384(sample rate: 625000)…I decided not to start another thread because the problem I have just discovered is related. The setup is 100% identical.
There is spurious trigger event occurring on the first ever call of bbInitiate with trigger input enabled, after opening the receiver, even if the trigger input is hardwired to ground. Subsequent bbInitiate calls do not cause spurious trigger events.
If the first ever bbInitiate call is with trigger input disabled there is no spurious event when later enabling the input.
The spurious event is always in the first ever received buffer at sample 572 with 64-bit APIs and at sample 1144 with 32-bit APIs. Tested with 32-bit and 64-bit API 3.0.11 (bbFetchRaw) and 64-bit API 3.0.14 (bbGetIQ).
Catalin
Hello sszqdz,
I apologize for the confusion. The bbFetchRaw function, before the last API version, returns trigger values relative to the full 40MS/s rate. To convert to values relative to the IQ data you received, simply divide the trigger values by the decimation rate, 64 in the example you provided. In the latest API version with the bbGetIQ function, we are performing the calculation for the user.
Regards,
A.J.I might reply to this one!
First of all, the buffer length is in I/Q samples, not in 32-bit floating point values. So, the 16384 I/Q samples in each buffer actually means 32768 (2*16384) 32-bit floating point values. Considering that, the index that you reported in the example, 26666, is mostly correct.
But there is a well hidden problem in how you determined it. The API manual states that the trigger position is in I/Q samples number. So you must first convert the trigger position to the I/Q sample number before multiplying it by 2.
So you have SamplePos=TrigPos/DecimRatio (integer math!) and then go at 2*SamplePos in the received buffer to get the samples after the trigger.
The way you estimated the sample position is not correct because for many trigger position values, when using integer math, 2*Pos/Decim is different from 2*(Pos/Decim) and you end up accessing the Q1/I2 instead of I1/Q1 (the samples are considered I1/Q1, I2/Q2 etc.).
Catalin
Hi sszqdz,
Divide the trigger value by (decimation * 2) instead of decimation. This will give you the result you are looking for. I realize it is not documented as well as it should be. I misspoke before, the trigger values are relative to the 80MS/s IF data, which is converted to 40MS/s IQ (before decimation), so this additional factor of two still needs to be accounted for. The trigger values returned should always refer to the data just received, never for some future call to bbFetchRaw.
Regards,
A.J.Hello sszqdz,
Can you provide more information about your setup? How are you using the external triggers? What are you measuring? What are you correlating? Have you made successful measurements with both receivers? Does the data look good on both receivers? I’m not sure what you mean with the question “Using external trigger to collect IQ data can’t make sure collecting at the same time?” The presence of an external trigger does not synchronize the receivers, you still need to write code to use the trigger locations to synchronize the data streams.
I look forward to your response.
Regards,
A.J.It looks like maybe the phase of your I/Q data doesn’t match up. Is this what you are seeing?
You should not expect the phase of two demodulated signals to line up. Even if the BB60s use the same external trigger and external time base, there is still a fractional-N PLL that can lock to several different phases each time you change the LO frequency.
Multi-channel phase coherent receivers exist, but they are generally more expensive.
If you need to make phase coherent measurements with two BB60Cs, generally you would:
1) Use a common external 10 MHz reference to align frequency
2) Use a common trigger to align time within 50 ns.
Now, all that is missing is phase alignment, and this is where it gets tricky.
3) Select your frequency on both devices, and begin streaming I/Q data. Do not change frequencies or interrupt the I/Q data stream for the next steps.
4) Send a known signal to both devices to calculate a phase offset (and possibly amplitude offset if needed) between devices
5) Connect your unknown signal. You can now measure relative phase between the two streaming devices, until you change frequency or the I/Q stream is interrupted.Hello Lee,
If you have additional questions, you may email justin @ signalhound dot com. The previous response from Justin described how you would use an external trigger and 10MHz reference to phase correlate two streaming receivers. If you need dual channel phase locked receivers without going through this much effort there are several receivers on the market which can do this for you. If you have more specific questions about your application, it would be helpful to know more about your setup and what you have accomplished so far. We look forward to your email.
Regards,
A.J.
You must be logged in to reply to this topic.