Official bladeRF forum

Hi,

given that I connect a 1Hz GPS Disciplined Oscillator to the board: How do I find out where in the received I/Q stream the 1 Hz pulse occurred. Is it possible to correlate at all?

Thanks in advance,

Parazoa

That's a great question. Currently there isn't a mechanism to do that.

You could hijack some of the higher order bits on the sample stream coming in if you wanted to just get it done quickly, but that might not be the best solution in the end.

In the end we would probably need to generate some context message of some type, noting the timestamp that the 1pps pulse happened, and send that up to the host.

The other option would be to have a 'reset count on next pps' followed by a streaming of the samples. Or maybe even a 'gate until next pps'. Then the 1pps signal should happen every samplerate samples since that would be 1 second.

Does this make sense? Just curious, what application are you thinking of?

Brian

Hi Brian,

bpadalino wrote:... Just curious, what application are you thinking of?

I think I might help here. I asked Parazoa two weeks ago if my project would be possible with BladeRF.

As a "hobby" I work on a Distributed Ground Station Network (DGSN) which I want to use for tracking satellites by their beacon signals. Tracking other beacons like weather balloons or also Meteorite Burst would also be possible. For DGSN we use pseudo-ranging and trilateration, which is basically the reverse method GPS is already doing. For this, we need 5 or more of such stations to be able to calculate the beacon signal's origin. This is done by correlating the precise reception time of the signal at each ground station.

That is why we need to combine the GPS 1pps driven sub-second counter to the received rf-data stream in BladeRF. So whenever there is a "beep" in the reception stream of BladeRF, we need to find the corresponding time in the GPs driven counter stream. And we do that at each ground station by finding the same "beep" in all of them.

So it is required to have
a precise counter driver, which is the GPS driven counter
a stream of timestamps, which is used for correlation to the rf-data stream
a rf-data stream, which is used for processing and alignment to the stream of timestamps
all streams must be align-able and shall not diverge from each other
and everything must be deterministic to allow repeated measurements.

So, it sounds simple, but we haven't found a suitable solution for DGSN so far and that is why I asked Parazoa before. He was so fine in asking here .

So, what do you think? Is it feasible? I hope so! I would order one right away!
And I am not frightened to code some stuff for it, if it is not YET implemented.

Best,

Andreas

Sounds like a cool project.

I thought it over for a little bit and I will explain my concerns with what we have on board versus what you need.

hornig wrote: So it is required to have
a precise counter driver, which is the GPS driven counter
a stream of timestamps, which is used for correlation to the rf-data stream
a rf-data stream, which is used for processing and alignment to the stream of timestamps
all streams must be align-able and shall not diverge from each other
and everything must be deterministic to allow repeated measurements.

Lets start with the bottom one since that is the one that will cause the most trouble. Determinism in the system will not be available for at least one area which is the RXPLL in the LMS6002D. Essentially what will happen is the phase at which it will lock will be arbitrary with reference to the input clock.

The next place where an arbitrary relationship can occur is the Si5338 clock generator chip which is used for sampling the data. This clock, on the other hand, has a capability to slide the phase of the sampling clock up or down with a pretty absurd amount of granularity.

Working our way backwards in the system, we finally meet the VCTCXO which feeds the Si5338 and what we can control with the trim DAC. The approach I was going to take with getting timing correct was to count clock ticks between the 1pps signal. The problem with this approach is that the phase information is lost. At the time of the 1pps (which has some variance to it), I don't think the current system has a phase alignment which would be able to figure out, feeding into the Si5338, the relationship of when the rising edges occurred with respect to each other.

As for the divergence, I believe the 1pps method should provide a pretty good way of keeping them locked with each other, but I am sure there will still be some drift on the order of 1ns/sec at the best (1ppb with respect to each other). At a 40MHz sample rate, giving a 25 ns clock width, that's about 25 seconds before you have slipped a single sample.

The rest, having the GPS disciplined sample counter and the stream of timestamps with the data, that should not be an issue.

Now that I have stated all my concerns, there may be ways to combat some of them. I can understand why you haven't met a system that will meet your requirements just yet. Maybe I am being a little too cautious about where the determinism comes in, but I'll let you respond to my concerns to see if they are problematic or if you can work around them.

Sounds like a fun project no matter what.

Just curious - how distributed are you? Tens/hundreds/thousands of meters?

Brian

bpadalino wrote:Sounds like a cool project.

Yes, I also think so and some other liked the idea, and it's about space, which is my favourite application
Here you can watch my presentation on the IAC 2013 http://www.youtube.com/watch?v=e8KySj2wH64 that will give you some more insight.

bpadalino wrote:I thought it over for a little bit and I will explain my concerns with what we have on board versus what you need.

Thanks, that is why I am here and asking .

bpadalino wrote:Lets start with the bottom one since that is the one that will cause the most trouble. Determinism in the system will not be available for at least one area which is the RXPLL in the LMS6002D. Essentially what will happen is the phase at which it will lock will be arbitrary with reference to the input clock.

The next place where an arbitrary relationship can occur is the Si5338 clock generator chip which is used for sampling the data. This clock, on the other hand, has a capability to slide the phase of the sampling clock up or down with a pretty absurd amount of granularity.

Working our way backwards in the system, we finally meet the VCTCXO which feeds the Si5338 and what we can control with the trim DAC. The approach I was going to take with getting timing correct was to count clock ticks between the 1pps signal. The problem with this approach is that the phase information is lost. At the time of the 1pps (which has some variance to it), I don't think the current system has a phase alignment which would be able to figure out, feeding into the Si5338, the relationship of when the rising edges occurred with respect to each other.

As for the divergence, I believe the 1pps method should provide a pretty good way of keeping them locked with each other, but I am sure there will still be some drift on the order of 1ns/sec at the best (1ppb with respect to each other). At a 40MHz sample rate, giving a 25 ns clock width, that's about 25 seconds before you have slipped a single sample.

The GPS jitter for the 1pps is 10ns for what we have right now. And we also want to have a satellite tracked/positioned in a 100^3 m^3 box, so all behaviour of the hardware should be inside this determinisitc range. And for small errors, we can still use the magic of "math and statistics". That is why a distributed system with more than 5 stations per measurement is great .
But what we experienced so far is that some hardware jittered so much that the offset wasn't constant with 1 or 2 clocks of a 40mhz counter quarz as wanted, but with 50 clocks and all clocks in between. So with this, the measurement wouldn't be possible (or at least I don't know how ). So when there is "sub clock" jitter, meaning <25 ns, I would be happy .

Concerning measurement of rising edge of one bit, we already put that aside and will send out a bit-code, like in cdma or other bit spreading techniques. So that is why I asked if and how it is possible to just record the gps driven counter and use some markers from the rf-data stream or perhaps vice versa to "anchor" them together. if each x out of n samples this will lose or skip one of the counter tags, that would be okay, because the majority of tags will still work. But the important thing here is how to anchor both streams together.

bpadalino wrote:The rest, having the GPS disciplined sample counter and the stream of timestamps with the data, that should not be an issue.

... how would you do that with BladeRF?

bpadalino wrote:Now that I have stated all my concerns, there may be ways to combat some of them. I can understand why you haven't met a system that will meet your requirements just yet. Maybe I am being a little too cautious about where the determinism comes in, but I'll let you respond to my concerns to see if they are problematic or if you can work around them.

We experienced during testing hardware, that some jittered to hard, that we couldn't use them. We sent out a signal (and started the counter) and received it (which stopped the counter) some 20 cm's away, and we had variations of 1500-1550 clocks of a 40 MHz quarz. So even with an offset of 1500closk, the jitter of 50 clocks was still way to much. So we couldn't use it for real "ranging". We think it was the automatic gain control in our rf modules and the oscillating circuit, which had to start oscillating, which caused this. If both were constant and not jittering as hard as mentioned (perhaps 1 clock maximum), that would be preferred. So that is why I said it. The analogue and mostly the digital parts on the modules were considered to influence here, so I asked how bladerf behaves .

bpadalino wrote:Sounds like a fun project no matter what.

Just curious - how distributed are you? Tens/hundreds/thousands of meters?

Brian

Thanks!
Both, locally for covering an acre, and globally. First is for testing and if a user want to set up his/her own tracking system. And we want to have it globally to track satellites world wide AND permanent. The setting most effected by jitter and errors it the local one, of course, because distances are so short and speed of light is so fast . The global network is there, we just need to plug hardware to these PCs .

Best, Andreas

Before going to bed last night I was thinking about this problem along with the long term time slipping.

You had asked how the bladeRF would make a GPS disciplined counter. The idea is that the VCTCXO would be GPS disciplined. This feeds the Si5338 PLL which would generate the RXCLOCK for ADC sampling as well as the REF for the RXRFPLL. The RXCLOCK would be used to count samples against the 1pps signal coming into the FPGA as well. Basically the FPGA has clock-to-clock granularity that would be able to be exploited for your precise timing you require.

As for the long term time slip against units, what if every sampleset started at the next 1pps? That way every time the GPS was locked and a 1pps went off, you would get a new sampleset for that next second. You could stitch together seconds against different observations, but over long term collection, you would get a bunch of samplesets with one less or one more sample than the nominal value, but you could at least be guaranteed that each second was started exactly.

Would that be helpful? Could that help solve some of your issues? Being within 10ns of UTC sounds pretty good for a 1pps. Which GPS unit are you using with that? I just bought myself some Trimble Resolution T's and they claim 15ns I believe, which I thought was spectacular.

To test the system's group delay through the chain, you could hook up both the bladeRF and an RF generator (Agilent E4438C Arb?) to the 1pps signal from the GPS. And have that 1pps trigger a known data sequence to be transmitted. Then when the bladeRF thought sample 0 was coming out, you could try to correlate for your known transmission. Subtract off the length of the sequence transmitted, and you have the delay of the system from the antenna port to the ADC with reference to the 1pps. That delay should be constant between units or at least very close. The major differentiating factor would be the low-pass filters in the LMS6002D. Those change over bandwidth.

What do you think of those ideas? The code hasn't been written for the 1pps disciplining yet, but now that I have my Trimble's, it should hopefully not be too long before that is handled.

Let me know your thoughts and if all of this made sense. If not, I can try to clarify.

Brian

Hi Brian,

bpadalino wrote:Before going to bed last night I was thinking about this problem along with the long term time slipping.

You had asked how the bladeRF would make a GPS disciplined counter. The idea is that the VCTCXO would be GPS disciplined. This feeds the Si5338 PLL which would generate the RXCLOCK for ADC sampling as well as the REF for the RXRFPLL. The RXCLOCK would be used to count samples against the 1pps signal coming into the FPGA as well. Basically the FPGA has clock-to-clock granularity that would be able to be exploited for your precise timing you require.

I am not yet that deep into BladeRF, so I will always ask straight ahead; the RXClock can count the samples, which are recorded signals, does it? For me it is not yet obvious how bladerf does things and what can be "accessed" before the however changed signals will be sent via the usb to a PC. So, it is possible to access the signal stream during some points/pins in the signal chain? Or is the counting only triggered by the same clock as is the sample rate?

I hope I didn't keep you awake with my stupid project!

For me it is also important not only to drive a counter, but also to readout this counter to store those values in between a 1pps period, so that I can do sub second measurements. But for this, I need to get this "time stream" and it has to be anchored to the data stream.

bpadalino wrote:As for the long term time slip against units, what if every sampleset started at the next 1pps? That way every time the GPS was locked and a 1pps went off, you would get a new sampleset for that next second. You could stitch together seconds against different observations, but over long term collection, you would get a bunch of samplesets with one less or one more sample than the nominal value, but you could at least be guaranteed that each second was started exactly.

That would be a work around, as long as it keeps both streams, the rx stream sample and the time stream sample, referenced, somehow. But for better file management, longer streams would be better . And of course even with a 1 second sample, it should also contain sub second time tags.

bpadalino wrote:Would that be helpful? Could that help solve some of your issues? Being within 10ns of UTC sounds pretty good for a 1pps. Which GPS unit are you using with that? I just bought myself some Trimble Resolution T's and they claim 15ns I believe, which I thought was spectacular.

I bought this http://www.adafruit.com/products/746 but they basically resell a version 3 MTK3339. We bought it, because it served our current needs .

bpadalino wrote:To test the system's group delay through the chain, you could hook up both the bladeRF and an RF generator (Agilent E4438C Arb?) to the 1pps signal from the GPS. And have that 1pps trigger a known data sequence to be transmitted. Then when the bladeRF thought sample 0 was coming out, you could try to correlate for your known transmission. Subtract off the length of the sequence transmitted, and you have the delay of the system from the antenna port to the ADC with reference to the 1pps. That delay should be constant between units or at least very close. The major differentiating factor would be the low-pass filters in the LMS6002D. Those change over bandwidth.

I don't have access to an Rf generator, yet. But when the last questions are answered, I think I will have to find one .

bpadalino wrote:What do you think of those ideas? The code hasn't been written for the 1pps disciplining yet, but now that I have my Trimble's, it should hopefully not be too long before that is handled.

Let me know your thoughts and if all of this made sense. If not, I can try to clarify.

Made sense. I still need to get more information, what and how I can access the signal (still analogue intensities for one center frequency)or already digitized). I would like to help here, but I am stil not sure how to "merge" both streams I need to have.

Thanks a lot so far!

I will just try to give a sketch, what I intend.

A) 0,1,2,3,4,5,6,7,8,9,...
B) 0,1,0,1,1,0,1,0,0,1,...
C) -,x,-,-,o,-,-,x,-,-,x,-,-,o,-,-,x...

There are three streams we have to consider.
A) is your sampling of the signal. The sampling rate shall be constant (for the given scan). It can be locked to an external GPS or other synch clock. That would be beneficial.
B) is the received signal stream. here, it is binary, but it could also be analogue. it is the sampled signal, so that is why stream A is important to know.
C) is the time stream. x's are the sub second tags stored in it. the time tags don't need to be stored with every sample in A) because it has a linear behaviour and we can interpolate it and fill the gaps. the o's are time tags of the 1pps by gps. so they are also stored, but they are the most accurate, because the sub second tags are provided by the counter which can be considered less precise. Further more the GPS can provide the fill UTC time with YYYY.MM.DD. hh-mm-ss, which is need for later data processing. but this can be stored else where and only the ss and perhaps mm parts are important here. It also allows to have another rate of the stream than the sample rate, because samling is done with at least twice as high frequency as what had been received. The only thing to be sure here is that the time stream sampling rate is also a full factor and having the same start time of one (out of x samples) as stream A). This avoids strange drifting.

So, if you have B) and C) as independent streams stored somewhere, it is required that they can still be correlated, so for example, that for sample 6, is is bit 1 and a sub second x. So it would be great to use some output pin of the bladerf for perhaps registering what B) stream value was there in this sample, or perhaps already inject stream C) into stream B) and multiplex it, so that both are kept together even during the usb transfer.
This is why I want to do as much as possible on the board to reduce strange hick-ups by the PC.

Is there a documented pin layout?

Best regards,


Andreas