I’ve been trying out the gr-sounder code to see if I can use it for
some research. I modified it slightly and graphed the output in
realtime. At the portion of the code where it would write the incoming
complex numbers to file, I have:
for cn in [rec[x:x+8] for (x,y) in enumerate(rec) if x%8 == 0 ]:
r,i = struct.unpack(‘ff’, cn)
tmparray.append(abs(complex(r,i)))
maxvalue = max(tmparray)
highestpoint = [x for x,y in enumerate(tmparray) if y == maxvalue][0]
tmparray = tmparray[highestpoint-1:] + tmparray[:highestpoint-1]
rcontrol.plot(tmparray, ylab=‘’, type=‘l’, )
The above code uses the rpy library to plot the data. The results I
received are as follows:
Is something wrong with my setup or code? I’m not even sure if the
gr-sounder isn’t ready to be used through the USRPs, if so are the
results consistent with my own?
I've been trying out the gr-sounder code to see if I can use it for
some research. I modified it slightly and graphed the output in
realtime.
Let me work with you offline on this. The code does work over the
air, but it is probably not giving you what you expect.
Unfortunately, I’m tied up for a day or two.
I've been trying out the gr-sounder code to see if I can use it for
some research. I modified it slightly and graphed the output in
realtime.
Let me work with you offline on this. The code does work over the
air, but it is probably not giving you what you expect.
Unfortunately, I’m tied up for a day or two.
I have been working with the sounder-code too.
WHat I found is that since the clocks of the USRP boards are not
synchronised you have two problems.
The LO’s of the RFX boards are not phase-coherent so you have an RF
frequency offset between the boards of a few kHz.
This results in not getting a spike but a kind of smeared out
LF-modulated wave.
This problem should be much less with basicRX/TX or LFRX/TX boards
The other problem is that the 64 MHz clocks are not synchronised.
This produces a little smearing of your results but is much less a
problem.
Both problems get bigger as you lengthen the peudo-random codelength.
You could solve this by using very precise (GPS-tamed) external 64 MHz
clocks on both sides.
You can also solve it by giving one USRP a clock-out and the other a
clock-in and connecting them together (so they run of the same 64 MHz
clock)
This requires a clock-cable between the two USRPs so this is only
feasable for short distances.
An other solution I see is to extend the code with some PLL which
recovers the symbol clock and uses that to compensate for both problems.
I don’t know what solutions Jonathan has, but I would like to know them
too.
Not sure if you’ve had a chance to take a look at this yet. I’ve been
trying to figure out what’s going on, but even with Martin’s advice I
still havent had much luck. Could you tell me what the slip rate is on
the sliding correlator? Whenever you have some free time.
Martin’s description of the issue is very accurate. Due to frequency
offset, the impulse response peaks do not come at the proper
intervals. What is worse, is that the algorithm in the FPGA is using
an n-squared algorithm to calculate the impulse response, so it is
extremely sensitive to frequency offset.
You can adjust the frequency manually on either side to accomodate,
but simple drift will soon cause the clocks to diverge. You may also
be able to post-process the impulse response records by estimating the
frequency offset using an FFT and then resampling/interpolating them
to the proper time base.
Unfortunately, the only true way to correct this is with a PLL on the
receive side, inside the FPGA, after the despreading occurs.
Fortunately, I am developing one of these as part of another project.
This is a direct sequence spread spectrum transceiver, and is really a
superset of and replacement for gr-sounder. With the proper frequency
and PN-code phase locked loops, you will be able to get channel
impulse responses with much greater accuracy than the open-loop
gr-sounder code does today.
I normally wouldn’t have “announced” this until there was working code
people could try out.