The Aero Thread..

Vipersan said:
..From what I read ...the ESX wont be suitable which is why I'm currently swapping out the Titanium for the circular polarised ESX ..
Apparently the ESX isn't suitable because it aint PLL ..
I hope I'm not going to all this trouble for nothing ..
DOH!
..at least it aint raining ..so should be safe enough up short ladders..
fingers crossed
Click to expand...
Mine ain't PLL VS, using quite an old Astrotel gold
 
scopus said:
Mine ain't PLL VS, using quite an old Astrotel gold
Click to expand...
Dammit ...not what I read ...
Too late now ...the swapout is in progress ..
Grrrr

..Shouldn't be too dificult to return the ESX to Christina anyway ...once the experiment is over ..
Took a Sharpie out with me ..and marked EVERYTHING..
;)
 
aero2.webp OK it's done ..and I still can't get a lock ..though there looks to be more activity in the waterfall ..
So I'm guessing it's more to do with my setup .
Is anyone using the SDRplay ?
and how are you isolating the aero signals ...?
are you using a passive splitter ...or using loopthrough ?
 
Gave up on using SDR# ....and tried HDSDR ...and very briefly got a signal lock ...and some coherent activity in the constellation window ...
Still nothing remotely resembling data ...but there are other SDR apps out there ...
The noise floor is better handled in this app ...so I guess is more suited to SDRplay.
Progress of sorts I guess.aero3.webp

It would help of course if the bird wasn't inclined ..as I can't be sure I'm holding target long enough.
...which is one of the reasons I first tried Carl ..
Smaller dish = less critical beamwidth ..
 
Last edited:
I am sure you'll crack it. Others seem to have had success on similar sized dishes.

Sorry I can't be of help - don't even have a decent dish up!
 
scopus said:
OK dll file is in directory, added the two lines to the Plugin XML. When I open SDR I keep getting an exception report. Does this XML file look right?

<?xml version="1.0" encoding="utf-8" ?>
<sharpPlugins>
<add key="AF DNR" value="SDRSharp.DNR.AFNoiseReductionPlugin,SDRSharp.DNR" />
<add key="IF DNR" value="SDRSharp.DNR.IFNoiseReductionPlugin,SDRSharp.DNR" />
<add key="Noise Blanker" value="SDRSharp.NoiseBlanker.NoiseBlankerPlugin,SDRSharp.NoiseBlanker" />
<add key="Wave Recorder" value="SDRSharp.WavRecorder.WavRecorderPlugin,SDRSharp.WavRecorder" />
<add key="Zoom FFT" value="SDRSharp.ZoomFFT.ZoomFFTPlugin,SDRSharp.ZoomFFT" />
<add key="Frequency Manager" value="SDRSharp.FrequencyManager.FrequencyManagerPlugin,SDRSharp.FrequencyManager" />
</sharpPlugins>
<add key="AuxVFO-1" value="SDRSharp.AuxVFO.AuxVFOPlugin,SDRSharp.AuxVFO" />
<add key="AuxVFO-2" value="SDRSharp.AuxVFO.AuxVFOPlugin,SDRSharp.AuxVFO" />
Click to expand...

The two new entries need to be above the closing tag so the file should look like it does below. (Just to add that the line controlling SDRSharp.FrequencyManager. is a single line in the xml file but might be wrapped due to width limitations on posting this message.)

<?xml version="1.0" encoding="utf-8" ?>
<sharpPlugins>
<add key="AF DNR" value="SDRSharp.DNR.AFNoiseReductionPlugin,SDRSharp.DNR" />
<add key="IF DNR" value="SDRSharp.DNR.IFNoiseReductionPlugin,SDRSharp.DNR" />
<add key="Noise Blanker" value="SDRSharp.NoiseBlanker.NoiseBlankerPlugin,SDRSharp.NoiseBlanker" />
<add key="Wave Recorder" value="SDRSharp.WavRecorder.WavRecorderPlugin,SDRSharp.WavRecorder" />
<add key="Zoom FFT" value="SDRSharp.ZoomFFT.ZoomFFTPlugin,SDRSharp.ZoomFFT" />
<add key="Frequency Manager" value="SDRSharp.FrequencyManager.FrequencyManagerPlugin,SDRSharp.FrequencyManager" />
<add key="AuxVFO-1" value="SDRSharp.AuxVFO.AuxVFOPlugin,SDRSharp.AuxVFO" />
<add key="AuxVFO-2" value="SDRSharp.AuxVFO.AuxVFOPlugin,SDRSharp.AuxVFO" />
</sharpPlugins>
 
fwiw I have also had occasional signal lock using SDR-Console ...
Still not seen the green data light in Jaero ..when the beeps are present..and can be heard.
at this point I have to assume I simply dont get sufficient signal ...perhaps a different method of coupling the SDRplay input to the lnb ....or maybe a lna would be beneficial .
I am making small progress so I aint giving up ....but my gawd this is slow and painful.
rgds
VS
 
aceb said:
VAC and Jaero both look like this, make sure you've got the correct mode in Jaero.
Click to expand...

As per mine and Scopus screen grabs Jaero needs to be running in 10500 burst mode, 600BPS is used for the forward and return links on L band. Don't know what size dish you're using VS but John who was the OP about Aero is up in the NW somewhere using a 1.8 and getting very good results on 15W.
 
aceb said:
As per mine and Scopus screen grabs Jaero needs to be running in 10500 burst mode, 600BPS is used for the forward and return links on L band. Don't know what size dish you're using VS but John who was the OP about Aero is up in the NW somewhere using a 1.8 and getting very good results on 15W.
Click to expand...
I'm currently using a C1PLL offset by about 5 degrees from focus on Christina ..
my petalised and enlaged 1.8 PF ..
..and have had occasional lock light on Jaero ..but no lock on data light as yet.
Could you tell me what dongle/receiver you are using mate ?
SDRplay doesn't work well with SDR# ..so thinking of trying and RTL dongle next.
So far my best and only signal lock (no data) results have been with SDRplay and HDSDR or SDR-console
rgds
 
Vipersan said:
It would help of course if the bird wasn't inclined ..as I can't be sure I'm holding target long enough.
Click to expand...
It was 0.7 N at the time of your first screenshot according to Orbitron and fresh tle data. Use it to predict the next pass over the equator. It passed at 18:50 UTC+1 yesterday evening but I haven't ran it today.
 
I'm using an Airspy but there's no reason why the SDRPlay shouldn't work, in fact looking at your waterfall in HDSDR there appears to be sufficient signal for a good decode. If you zoom in to one of the channels and open up the bandwidth to about 10K position it so the right hand side of the passband sits on the right hand edge of the burst rather than centring it over the signal and make sure any audio filtering is turned off.

My RTL dongle is using an R820T which is touch and go on 1.6GHz at the best of times but it's encased in copper clad board so gets too warm for it to lock on 1.5GHz.
 
It could be that there are issues with SDR# and SDRplay ..
Support for extio was dropped soon after the version of SDR # I'm using.
Suffice to say I can't get any sort of signal lock not even temporary using SDR#....and I've tried various settings..
I have had signal lock occasionally with HDSDR ...
This isn't going away ..
I will crack it..
Airspy is natively supported in SDR# which might be relevant..

Just as an aside ..I have seen these ceramic GPS passive antennas ...and cheap too ..so would like to have a go at the homebrew patch antenna in this article ...which Jonti has had some success with ...but no info in the article about building it..
does anyone have a link to the build details ??
inmarsat Archives - rtl-sdr.com
 
Just for completeness I mounted the ESX on Carl which was originally fitted with the C1PLL ...and turned on HDSDR and looked at the waterfall ...
Nothing at all ...no aero traffic ...
So ...is it really the case that certain lnbs are required ?
Is there truth in what I read that PLL is actually needed ?
Or is it that the ESX has filters that prevent its use ?
I'd have to re-fit the Titanium to prove this.
certainly it has me wondering.
..anyway I found another C1PLL on ebay delivered for about £15 so put one on order...
It never hertz to have a spare..
There is a WiMax filter version which is presumably band restricted ...so was careful to avoid this and order a wideband version.
Hopefully it is the right one.
rgds
VS
 
Doh ..
Stupid boy I am ..
I have had my gutters cleaned today ...and the guy who did the job perched his ladder on my lnb cable ...and he has cut it internally ..
Had to re-make the cable using 2xFs and an in line straight coupler ..
Now I'm back in business ...and am getting bursts from 12W on Carl again ..using the ESX ..
Do my eyes decieve me or are those peaks slightly stronger than they were ??
more digging to do ...but looks like the ESX will work ..but is it stable enough for data ??
rgds
VS
 
aero5.webp ...yes those peaks/bursts are more clearly defined with the ESX ...but now I know why a PLL is recommended ..
I can set the marker on the waterfall ...but within a minute or so ...that marker is no longer under the signal ...it has drifted so no longer on target ..
Yes the ESX works ...but simply isn't stable enough ..
What this tells me is what I suspected all along ..
The ESX is a higher gain & lower noise lnb than the Titanium ... but drifts ...
Hence the need for PLL.

Check out this image for the very obvious lateral drift ...which is actually apparent also when listening to the beeps ...
you can actually hear doppler shift in real time..

and within 10 minutes not one single bit of L band Aero data remained visible in the zoomed waterfall ..requiring significant vxo shift to relocate it..
So ...I need the gain and noise levels of the ESX and the stability of the Titanium..
Perhaps the new C1PLL will be better ?
..or a total re-think regarding the lnb ???????
 
Last edited:
scopus said:
OK dll file is in directory, added the two lines to the Plugin XML. When I open SDR I keep getting an exception report. Does this XML file look right?

<?xml version="1.0" encoding="utf-8" ?>
<sharpPlugins>
<add key="AF DNR" value="SDRSharp.DNR.AFNoiseReductionPlugin,SDRSharp.DNR" />
<add key="IF DNR" value="SDRSharp.DNR.IFNoiseReductionPlugin,SDRSharp.DNR" />
<add key="Noise Blanker" value="SDRSharp.NoiseBlanker.NoiseBlankerPlugin,SDRSharp.NoiseBlanker" />
<add key="Wave Recorder" value="SDRSharp.WavRecorder.WavRecorderPlugin,SDRSharp.WavRecorder" />
<add key="Zoom FFT" value="SDRSharp.ZoomFFT.ZoomFFTPlugin,SDRSharp.ZoomFFT" />
<add key="Frequency Manager" value="SDRSharp.FrequencyManager.FrequencyManagerPlugin,SDRSharp.FrequencyManager" />
</sharpPlugins>
<add key="AuxVFO-1" value="SDRSharp.AuxVFO.AuxVFOPlugin,SDRSharp.AuxVFO" />
<add key="AuxVFO-2" value="SDRSharp.AuxVFO.AuxVFOPlugin,SDRSharp.AuxVFO" />
Click to expand...
Success, Jaero now reading both data bursts. Thanks ACEB.
 
..so something close to success ..
most often is corrupt and garbage...but data nonetheless ..and that is with the ESX on Carl ..
..using HDSDR ....
The vxo drift is more pronounced when using SDR# with SDRplay ..
It is evident on HDSDR but appears less so ..but this may just be the zoom level setting ...but I think not ..
Personally I think SDR# just does not like SDRplay ...
..and I can't compare notes with anyone using a similar setup so ..something close to data.webp
cest la vie
...
 
Took some notes on the Drrrriffft issue ..
let the whole system cool ..then powered up and activated the lnb ...ran up HDSDR and Jaero ...at 23:45 ..
located the T data stream at 1,537,106,635...then waited .....and watched jaero do it's stuff interpreting flight data ...which is now coming through fairly solidly...
Until the R/T data packets turned bad ..
Now minight ....and that same stream is now located at 1,533,774,079
So yes the drift is substatial ...BUT ...is this the LNB ? ....or is it SDRplay that is drifting ....?
I will try and get to the bottom of this if I can..
It is well documented that RTL SDR dongles drift at high frequencies ...but a purpose built unit like SDRplay ?
Surely not ....
Does Airspy drift at all ?
Just curious..
rgds
VS
 
Back
Top