TDOA - Scan never completes [fixed in v1.563]
Hi folks, for many years the TDoA extension worked perfectly for me but some months ago something changed. I set frequency, IQ mode, then select two or three SDRs from the map. In the TDoA mini window, the selections light up with a green loudspeaker symbol and the number of fixes/min is displayed against each participant. I then hit the SUBMIT button. The white circles slowly clock up with the blue progress indicator and 'sampling started' appears. When the circles are fully blue, I'd expect to see the heatmap appear. But nothing happens. I've waited for many minutes. See attached screengrab.
The SDR is still receiving fine - no sign of a crash - so could this be a security issue which is preventing TDoA data flowing with the server? I have tried pausing my virus checker and firewall, but there is no difference.
WINDOWS 11, Chrome. (The problem is also the same on a separate laptop running Windows 10 and Chrome)
Many thanks for any advice you can offer!
Steve G4HPE
Comments
Hi Steve,
I just tried a TDoA and it alll worked fine with a position report returned to me a few seconds after the audio sampling had been completed.
Try this TDoA which should show the TX location as Cornwall.
http://kernow.hopto.org:8073/?f=5109.85iqz10&pbw=3280&ext=tdoa,lat:54.10,lon:-2.99,z:5,G8AOE1,IO90bs,EI7KN
Sometimes when the TDoA solution is 'hard' it takes a long time to get a computed position back from the server and it just sits there.
Sorry I can't really offer any other any other advice.
Regards,
Martin
Steve,
The kiwisdr.com server sees your TDoA request and logs the attempt. But the usual completion message is never logged. I don't see any error messages either. So I don't understand what's wrong.
Have you tried running it from another Kiwi? It doesn't matter which Kiwi you run the TDoA extension on. What matters are what sampling stations used, frequency and map coordinates etc.
Thank you both, Martin and John.
Martin, I tried your suggestion but again the process didn't complete. Most strange. Thank you for taking the time to reply.
John, many thanks for your help and advice. I've tried three or four different KIWIs but the result is always the same. Everything seems to proceed but however long I wait beyond the expected 30 seconds I don't seem to reach the 'sampling complete' stage and no results are displayed. The extension worked for years, always following M0TAZ's YouTube demo and written instructions, then one day it just wouldn't work any more. I cannot recall any particular clue as to why, e.g. I don't think it coincided with a change of ISP or OS or hardware. All of my IP is via 4G LTE, by the way. Not sure if that could be significant.
I'll continue to play here, but I'm running out of ideas!
73 de Steve G4HPE
Steve,
I have added some debugging to the TDoA script. Could you try again from the ip address ending in .187 please? Or failing that, run the TDoA on a unique frequency, like 12345.00, that I can spot in the log. Do that once, let me know here, I'll setup the script using whatever ip address that request came from, then I'll ask you to run it again. Thanks.
Since you're on a 4G connection another thing to try: On the admin page, network tab, change the
Ethernet interface MTUmenu (top right) from 1500 to 1440. No restart is required.Interestingly, mine has stopped working since I changed to a 4G internet connection. I will give that a try thanks John.
Thank you guys, I really appreciate the time you're taking to help!
I think my IP should remain static for these tests.
OK, I am giving it a try now via the Kelvedon Hatch GB0SNB Kiwi at 1742 UTC.
Frequency will be entered as 12.345 MHz.
Steve G4HPE
Just to report back that the process stalled as usual after the 30 sampling period during the 1742UTC test.
I changed the 4G LTE router to MTU 1440 and retried the test, but same result.
I'm still wondering if it is a security issue. Is it possible that I need to unlock any TCP or UDP ports in the router?
Steve G4HPE
Okay, I see 12.345 MHz try. But the ip address was slightly different. So please run it again and I should be able to capture the debugging now. Thanks.
Sorry about the IP address change - I guess the cell dynamically allocates.
Will repeat test at 1930 UTC.
It keeps assigning a different address. I'm going to have to trigger on a partial ip address. Hold on..
It's all a bit wild on the IP front because it's possible to bounce cells pretty regularly. It's currently ends in 178.105 I think!
Okay, try again please. I'm now triggering on it starting with 92.40
OK, trying at 1945 UTC
Okay, got a trigger. Checking..
Excellent! Thank you for your time. Do you want to go to a different messenger to save filling this up? I can do Echolink for example. I think the IP address you're seeing there for me is not one I can see on my router here!
Try again please.
OK, at 2005 UTC
Okay, got that one. Again please?
Coming right up!
Thanks, got that one. One more time please? (I keep making changes to try and fix this)
Awesome, thank you. I can keep triggering if you wish. Anyway, next one coming up 2015
Okay, I've run out of ideas for now.
Your TDoAs are completing fine. What's happening is that your mobile provider is closing the connection to tdoa.kiwisdr.com prematurely before the final completion status is sent to the extension with the result. I have no idea why this is.
Also, I don't have the details of exactly what error the mobile provider is sending since I don't know how to get that from a PHP script buried inside a web server.
I tried a few things to flush and pad the final output, but that had no effect. So I'm not sure what to do at this point. This is very rapidly going to become a case of "throwing good money after bad". The new mantra of this project..
Crumbs, that sounds a bit naughty on the mobile provider front. Thank you for looking into this. At least we now have a solid reason for the issue. I guess some other users must be experiencing the same and at least I'm relieved that it is not something stupid that I'm doing here. I can't think of a way round the premature closing of the connection, unless I can somehow keep it busy?
Thank you for spending so much time on this, John.
G4HPE: I wonder what would happen if you went into the admin console shell and sent pings to the server during the period you were also running TDoA. Maybe that would keep the connection alive.
Hi James, interesting thought. A 'keep alive' routine of some sort, ideally not with me having to do it manually, though! Strange that the connection should closer so quickly.
Steve,
something like ping -i 5 tdoa.kiwisdr.com might do it. Every 5 seconds, adjust as needed.
I think I have an alternative that might work. But it will require a new Kiwi software release before it can be tested.
That's exciting, John. I am very happy to test with you as and when. Let me know how I can help. Feel free to email me directly if that is easier. It's such a useful extension, hopefully your plan will come to fruition.
Okay, I have the new scheme working. Pretty sure it will work with mobile connections. The whole PHP "long polling" scheme, which was always sort of hack, is replaced with short polling which should be reliable. It has more overhead. But that hardly matters for TDoA which is used relatively infrequently in the larger context of things.
It will take me a bit to get a release together as there is bunch of work-in-progress..