I and another student are experimenting with the LimeSDR at our university to see if we can do some TOA or TDOA positioning. We purchased 3 of the LimeSDRs but have mostly been playing around with one to get an idea of how it and SDR works in general.
So far we have been using our car door openers and some Bluetooth LE devices to transmit some data, and we’ve had varying levels of success picking it up using the Pothos GUI.
We know to do positioning with TOA or TDOA the timing needs to be pretty exact. I feel it is unlikely that we will sync the clocks on 3 LimeSDRs so well that we can do this is unlikely, but I would like to know what the community things our options are, and give us a better idea of what the limitations really are.
To start up simple, we’d like to see if we can utilize the two channels on the SDR to see if we can reliably pick up that one channel is picking up a signal before the other. Doing some back of the napkin calculations it seems if we space the antennas apart by about a meter, we should be able to theoretically pick up the signal at noticeably different times. I feel we are making a couple of assumptions though.
Given what I’ve said, I’d like to ask a few questions:
Do the two channels on the LimeSDR independently receive a signal? That is, assuming the rest of the world is perfect, could I reasonably expect to reliably detect a time difference in a signal being received?
If the answer to Question 1 is yes, then: When using Pothos GUI or writing my own C program that I run on my laptop that is connected to the LimeSDR, any timing information I get is based on the clock of my laptop. The problem with that is my OS is constantly doing all sorts of things not related to processing the signal, so it seems to me that based on what the OS is doing my timing will yield all sorts of different results. Is there a way to get the LimeSDR itself to timestamp some received information?
If the answer to Question 1 is yes, but Question 2 is no: If I am not able to get the LimeSDR to meaningfully timestamp some data for me, is there any reading I can do, or any recommendations you can give me to solve my timing dilemma? We are pretty green in the area of SDR, but are very eager to learn and make something cool happen. One of us has a pretty decent background in mathematics, so tackling some dense reading material wouldn’t be frowned upon.
Has anyone tried to sync the clocks on multiple LimeSDRs such that they are accurate enough to do TOA or TDOA? Is there maybe another approach that we should be considering?
One last method we though of is using DOA (direction of arrival) using antenna arrays on multiple LimeSDRs. I think this would allow us to infer the basic direction of the signal of interest, but without the need for syncing the clocks on all the LimeSDRs. This of course plays into the timing issues I mentioned above. Is there anything that has been done with doing DOA on a single LimeSDR?
What are people using as a communication protocol when attempting this? Are raw WiFi, BL, etc packets being sent? What is a convenient and easy protocol used to be able to transmit data packets of interest for testing such a setup?
My apologies in advance if I haven’t used the terminology correctly. Please do let me know if I was unclear in anyway, or if I can provide further information. Any and all help/information would be greatly appreciated.
This is very interesting, thanks for the response! I watched the video and reviewed the thread, but it doesn’t seem like you gave many details. Have you possibly decided to release your code? Would it be possible for you to address some of the questions I asked since you seem to have detailed knowledge of how the LimeSDR works?
With what I currently see it seems like what I want to do is possible, but a plethora of questions remain between me and how to do it.
We are interested in doing what is likely to have the highest chance of success with regards to implementation. I had mentioned in my original post that I think TOA is out of the option for us as we won’t receive a signal with a timestamp from the object to be located.
We are strongly thinking about TDOA, but the issue of clock synchronization on multiple LimeSDRs seems like an issue.
Assuming that we want to do TDOA on a single LimeSDR, how can we proceed? I assume we limit ourselves to only being able to read two samples (instead of a three was we only have two channels) of a given signal emitted on the object to be located when using a single LimeSDR, and thus get a set of solutions instead of a single solution.
With this in mind, would you be able to give us any input, or address some of the questions I had asked in my original post?
Most battery backed RTC (Real Time Clock) modules in computers used a relatively cheap (50 cent) 32768 Hz non-temperature compensated quartz crystal +/- 50 ppm. The RTC had two modes of operation, one running from the 10 year lithium battery (or super capacitor these days) when the computer/device is unplugged and an active mode when fully powered. Traditionally a simple 2^15 binary counter circuit of 15 flip-flops was used to generate an interrupt which would bring the device out of deep sleep mode and increment the time counter, stored in SRAM, by one second (usually stored as Epoch time - roll on year 2038), and then go back into deep sleep mode again. And an active mode where it can tap from the 7th flip-flop to provide 1/100th of a second measurements (well in reality 1/256 rounded up to 1/100).
So anyhow long story short if you want to measure time more precisely than 1/100th of a second (enough time for RF to travel 2997025 meters in air, or ~1862 miles) with a accuracy of 50 ppm best to totally avoid using the computers time. And as you have mentioned there is lots of additional non-realtime OS jitter from the instance you ask what time it is, until you are told what time it was. Some newer RTC’s in active mode may be able to provide 1/10000th of a second (in reality 1/32768 rounded up to 1/10000) of a second by tapping the crystal directly (enough time for RF to travel 29970 meters in air, or ~18.6 miles).
Ultimately it boils down to how accurate is accurate enough for your purpose.
If you want to do tdoa, you need 2 limesdr and place them apart for a long distance. Otherwise, the sample rate isn’t enough to distinguish the time delay, as the signal is traveling under the speed of light. You can synchronize them based on other signals like your local FM or DAB station. Actually shincky has posted some existing repo on github that implemented this kind of applications.
In my video, I am not doing tdoa, we are comparing the phase of signals.
Best is to use GPSDO’s, mine is a surplus Trimble unit from a cell tower.
It has been running for a couple of months and the 10MHz output is 21ppt stable while the 1 sec pulse output is holding at 134ns.
Plug it into the external clock input and your clock will be accurate to specs far beyond what you are stating.
Do you need to modify the hardware/software on limesdr to use it with gpsdo? Or simply plug the output of gpsdo to clk_in of limesdr and it will automatically use that external clock?
Yes I totally agree a well designed GPSDO using an OCXO and ideally a clock jitter attenuator(DSPLL) which get it’s time from passive hydrogen masers is the way to go if you can, but they were asking about using the PC’s internal time, and I was trying to explain why it is never used.
I fully agree, those little clock chips in the standard PC are worthless if time keeping is what you need.
Just wanted to supply an alternative that they may have not thought of, these little Trimble units are pretty cheap on eBay and worth every penny spent if keeping something on frequency is the requirement.
