G8JNJ

Some further notes that may help folks who are trying to use this extension.

There are still quite a few bugs to be sorted out, but I have been able to get very accurate locations, certainly close enough to be able to find the TX site on Google Earth & Street View

e.g.



https://www.google.co.uk/maps/@51.8090686,3.8966839,3a,60y,246.34h,90.69t/data=!3m6!1e1!3m4!1sUQvXw0TenHFOgXCRkkrKQA!2e0!7i13312!8i6656


Brief 'How To' based on my experience so far.......

I find that in order to get consistent results, if I make any major changes to the setup of the signal being detected, I have to refresh the browser and reopen the TDoA extension

Set the mode to I/Q and reduce the bandwidth to just cover the target signal.

Then set the SDR map to cover the target area, be careful not to 'nudge' the frequency on the waterfall whilst doing this.

Check each KiWi you are intending to use can hear a clean signal by double clicking on the KiWi 'flag' on the map, before adding it to the list

Choose KiWi's carefully. You can use KiWis much closer together for signals on the lower frequencies typically <5MHz. But for higher frequencies you need to use KiWi's much further apart in order to ensure that each KiWi is the correct 'skip distance' away from the likely signal source

TDoA works the best if you can choose SDR's that are approximately the same distance away from the likely source of the transmission

Ideally the SDR's should be chosen as opposing pairs, either side of the likely source of the transmission, for example one North and another to the South, a further pair to the East and West would then give the best results.

If all of the SDR's are on one side of the likely source of the transmission, the results can be ambiguous, so it is always best to experiment with different SDR's in order to find the ones that give the clearest indication.

Northern Europe is fairly well covered but Southern Europe is not. More TDoA KiWi's in places like Portugal, Spain, Tenerife, Ascension Island, Azores and Africa are required

Once running the sampling should only take 40 seconds at most.

I suspect that the process can fail if one of the previously chosen KiWi's becomes too busy, or looses GPS lock in the time between initial selection and actual sampling.

If the sampling phase takes longer than 1 minute, refresh the browser and start again.

Once the sampling has finished it may take several minutes to get a result back from the server.

If the server running Octave can't get a good correlation it will also fail, sometimes without an error message and it just keeps trying.

If the TDoA running phase hasn't finished after 5 mins, refresh the browser and start again.

I usually start with just 3 KiWi's to get a rough location and then zoom in as required. Take a look at the maps from pairs of KiWi's and delete the KiWi's that that don't provide good clear contours from the list, then add somenew ones and try again.

Sometimes it may take two or three attempts to get a good map back.

If you don't get good clear results, try running it a few more times, as sometimes the propagation is not favourable during a sampling run, but may improve on subsequent ones.

I have tried it with AM, RTTY, STANAG, SSB and other digital modes, including some short duration burst type signals, and with perseverance have managed to get good results. The only type of signal I have had difficulty with has been Morse.

Regards,

Martin - G8JNJ

Hi John,

This week I've been trying to use a number of KiWis to perform some antenna field strength measurements, but its been a somewhat frustrating process.

So I'd also like to echo Jim's request for an option to allow the the S-meter logging period to be even slower, perhaps up to 24hrs, so that I could also use it to monitor changes in my noise floor, signal levels from BC stations and other propagation related monitoring.

It's currently a real pain to have to derive this information from the graph image and the subsequent visual resolution is only about 3dB or so, it's also difficult to check for max values over a period of time or try to determine the signal average level. I know there is already a request to provide this functionality, but I also know that there are more pressing or higher priority fixes to be implemented first.

I wondered if it would be possible to add a function to store and be able to download the graphed dBm values as a CSV file. Each value to be timestamped and the header to the contain frequency and RX bandwidth.

This would permit much more detailed off-line analysis of max /min values, averages and other trends, which wouldn't need to be added to the existing graphing option. Maybe sampling intervals could be defined or automatically selected as a function of logging period so that huge files are not generated. Each time the S-meter restarts the file could be overwritten, perhaps a bit like the fax image files ?

Regards,

Martin - G8JNJ

Hi John,

Also be aware that there is some controversy regarding the frequencies used for WSPR on 80m.

"with WSJT-X v1.8 we intend to correct an anomaly that has existed for a long time in that Japanese amateur radio operators have no privileges for the frequencies commonly used for WSPR, JT65 and JT9. The current frequencies (USB dial frequency) are:

WSPR 3.592600 MHz, JT65 3.576000 MHz, JT9 3.578000 MHz

because we strongly prefer that WSPR and JT mode frequencies are globally coordinated where possible, the proposed new frequencies are:

WSPR 3.568600 MHz, JT65 3.570000 MHz, JT9 3.572000 MHz, FT8 3.573000 MHz

This places the conventional 200 Hz wide WSPR sub-band (centred around +1500 Hz audio offset) into the lower 200 Hz the JT65 sub-band. The lower 200 Hz of the JT65 sub-band is not used due to SSB filter roll off."

Most folks are sticking with the original allocations, but you may wish to include the new(ish) proposed frequency in the KiWi WSPR decoder list of frequencies.

Regards,

Martin - G8JNJ

Hi Ron,

Hi Ron,