TDOA application

I would like to propose a project to find the location of a transmitter using multiple LimeSDR-based receivers.

I actually find someone who did similar projects using rpi3 and rtlsdr. I think if it’s realized by limesdr, it should work better as the frequency offset should be lower.

Is there anyone who’s also interested in this activity?

1 Like

I was until I discovered that it is impossible to align RX1 to RX2. Not to mention alignment with pps.
It seems Lime Microsystems is ignoring this problem for quite a while.
Its funny that projects like this: https://www.crowdsupply.com/fairwaves/xtrx are designed to use 8 LMS7002d to achieve 16x16 MIMO, regardless of the misalignment issue.

1 Like

I heard about this problem before, so I am now trying to bypass it by using only 1 channel per limesdr.

I am measuring the distance from transmitter to receiver, instead of the angle of arrival.

Are you also looking for location application? I think even if Rx1 and Rx2 are aligned well, a 2-channel device might still not be enough to measure the angle of arrival precisely, maybe 4-channel or 8-channel would be better.

If your base(distance between receivers) is big enough it might work. ±0.5 sample error is introduced in LimeSDR hardware. So TDOA between two receivers is ±1sample. That gives ±16ns for 60MSps(maximum) that gives 4.8meters. If you have receiving antenna separation of 1km it might work. If 10meters not so much.

I am working on similar TDOA application,
but on my side so farr LimeSDR is only acting like “rabbit” (dummy cell base station)
TDOA is performed by SDRplay RSP1.
BRG

Thanks for the insight.

I will try to make the distance as big as I can, to see if I could get a good result, but for 1km separation, I might need LTE dongles to send back data…

Do you think the QPCIe board would perform better in the sense of channel alignment? I saw a video on youtube the DOA resolution is much higher on X310 than on B210. So I ordered the QPCIe board because it’s the only 4 channel device I can afford…

There are some people who modified rtlsdr hardware to synchronize them to do DOA, I think their precision is good enough. Will it be possible we do similar thing to the LimeSDR? So we can synchronize the channels outside the chips?

You are using several SDRplay to measure the distance from the LimeSDR to the receivers?

How long is the average distance between them you are working at? I think for large distances, the data acquirement can be difficult. IQ data are too massive to send through commercial LTE network.

The misalignment is inside LMS7002D chip. So QPCIe is also affected. Of course you can calibrate to common external signal(maybe even GPS) and measure referred to this common source. But this adds extra external hardware and you would need to calibrate each restart.

The xtrx octopack has an onboard GPS oscillator that might be able to solve this problem.

For the case without GPS signal (indoor or for LimeSDR), maybe we can use a common source connected to those 2 rx port every time we power on the device? But they won’t change randomly during the measurement right? This is not very convenient, but I saw similar process written in the documents of the gr-doa repository.

This is what I found in the documents of gr-doa using X310.

They used another N210 to do the calibration for X310 before measuring. Does that suggest that X310 also have a similar problem as LimeSDR? So this is common for all multi-channel devices?

It seems like there are two independent receivers. Probably sampling clock is common. And usually if sampling clock is common then sampling time is the same(not in LimeSDR). If so they only need to correct phase offset of LOs. In Lime however there is time shift(sampling time). Still it can be corrected but external signal needs to be applied. Similar but different offset. In LimeSDR case it could have been mitigated in IC design(maybe it still is possible but no comment from Lime).

Distance from 300 m and more… at the moment doing TDOA in post processing,
time markers with GPS…
Ma application is Search and Rescue on open. Therefore distances of 1 km to 5 km
with 10 m average errors are acceptable. (must be within GSM 35 km total timing limit)
Later may go with UrbanSAR and there 4,5 m error is to much.

@9a4db - Djani,

Is there a work-around on this issue of phase locking the LimeSDR receive and transmit channels? Let me know at your soonest - thanks,

73 de Marty, KN0CK

@martywittrock
Marty,
according to my knowledge, so far no solution to lock phase difference, with Lime.
Hope in future someone may find some kind of feasible solution.
In that case one Lime can be used in real time system for non certified TCAS, OGN or FLARM
traffic advisory in general aviation. Which was one of mine original tasks for LimeSDR.
73
Djani

1 Like

@shao
I am quite interested in this activity and it ll be excellent if you let me in.
looking forward to your reply.

1 Like

@9a4db
hi!
i ve find something about timestamp that may be solution for phase diff.
here is the url you can give a shot:
https://github.com/myriadrf/LimeSuite/blob/master/docs/StreamProtocol.pdf
and here is the high light point you may go deeper:

1 Like

and BTW there is also an example for

@martywittrock
marty, i have a glimpse of the guide:lms7_api_quick_start_guide.pdf(since my exam is just around the corner).
the guide presents 3 methods about tx&rx, and the last on is:


hope it work :slight_smile:

1 Like

@shincky,

Worth a try from my perspective - please advise us all here on how it works for you if you try it, too.

73 de Marty, KN0CK

Great to hear that. Let’s do this together. :slight_smile: Please share with us what you found about TDOA with LimeSDR, thanks.

@martywittrock ,
I am trying to setup the development environment and test the code.
Once the code comes into life I will github it and tell you.

1 Like