The BladeRF sounds like a nice unit. I have a couple of LimeSDR’s and it sounds a bit like them in capability……although I must admit that the LimeSDR-Mini v1 is a bit on the deaf side. I mainly use it for transmit. A good low noise figure LNA out at the antenna generally sorts out marginally deaf receivers.
My main SDR for satellite work is a SDRplay RSPdx……this unit works well.
On the doppler front, if you have the doppler correction software installed and you are still getting the signal shifting across the band then it is clearly not working correctly.
Doppler is interesting……because we use predictions to calculate the frequency offset and to point antennas it is very important to get your ground station location, the system time and the frequency correct and to use the latest keplerian elements. If any of these are wrong the doppler offset and the antenna pointing Az/El will be off. I generally correct the time on my PC and download the latest keps before I start using my satellite software.
I am not sure what you are using to calculate the doppler and feed it to GNU Radio but a good starting point is often Gpredict feeding GQRX driving your BladeRF SDR. If you have all this correct then the satellite signal should run straight down the waterfall. GQRX is based on GNU Radio so once you have it working you should be able to swap over to your GNU Radio flowgraph and know that the doppler feed from GQRX is ok.
I’ve done a bit more research on the topic. I’m using GNU Radio with the Doppler correction block from gr-satellites, along with some Python code I found in the repository. It seems like this behavior is normal, but I’m not entirely sure. When I start the flowgraph, the signal initially appears at the center but gradually shifts to the left, never to the right. Shouldn’t the correction also prevent it from shifting to the left?
this sounds like you have not generated the doppler file properly or using a old file. the block will interpolate between the frequency and timestamps in the file, if it is outside the first to last timestamps it will just stay at the same spot, which is no correction at all.
there is some additional quirks with some sdr’s that spits out a timestamp of 0 so the time isn’t actual time but in the 1970’s. they can be stripped with the tag gate block, as I did in this flowgraph.
that repo with the flowgraph is tested and works, feel free to use in whole or parts.
Doppler is always tricky…… There is a concept called “the one true frequency” which basically aims to keep the receive and transmit frequency at the satellite on a constant frequency. This means on transmit that you start at AOS with the Tx frequency below “the one true frequency” and shift up in frequency until at LOS you are above “the one true frequency”. Receive is the opposite……start high at AOS and end low at LOS.
AOS = Acquisition of Satellite – At the horizon coming up
TOCA = Time of Closest Approach - Satellite is overhead
LOS = Loss of Satellite – At the opposite horizon going down
On a practical level if you look at the receive frequency waterfall before doppler correction you will see the receive frequency swing from above frequency through “the one true frequency” to below frequency. If you look at the receive frequency waterfall after doppler correction the signal should go straight down “the one true frequency”.
So I suggest you check in GNU Radio where you are looking at the frequency…. before or after doppler correction.
As a side note, if you have a terrestrial signal that showing up in your receiver it will go straight down the waterfall before doppler correction and in the doppler corrected waterfall it should start low and go high. This makes sense because at AOS you are subtracting doppler from the receive frequency so the terrestrial frequency will appear low. It will gradually shift higher as you pass through TOCA to LOS.
Hope this makes sense……good luck with sorting it out.
I used the Tag Gate, but it didn’t seem to have any effect. I’ve been using this code to generate the Doppler correction text file. However, as you can see in the examples below (the first one being the CUTE CubeSat and the second SOMP-2b), there is a shift to the left. I provided timestamps in Unix format, a duration of 20 minutes (although the duration is typically between 5 and 9 minutes), and, of course, accurate latitude and longitude values. I have been watching the waterfall (live) as the small satellite passes over and been recording two variants: one without the Doppler correction and the second with the correction. As expected, the recording without the correction starts to the right of the desired frequency and transitions to the left, while the “corrected” frequency is what you see in the pictures.
Hmm, that’s interesting. So, what you’re saying is that it doesn’t matter what I do. I will always expect some shift regardless of the correction, even if the correction is applied while the CubeSat is passing overhead.
I think you have slightly misinterpreted what I was saying……
If you are doing the doppler correction properly then it should go straight down the waterfall. If it is not going straight then one or more of the inputs is incorrect. This is what Daniel SA2KNG is saying in his response.
Since these sats have been around a while the keps should be accurate for a week or so……but they do go off……so the keps need to match the time of the recording. Also I have found getting timing miss matches between the recording and the doppler prediction for the recording causes problems.
Note also that the most rapid frequency shifts are when the sat is overhead. A small error there will often show up as a sideways movement in the middle of the waterfall plot. The rest of the plot will look pretty good.
Find a sat that transmits continuously (AO-73 is back on high power so it would be good) and the shifts will be more obvious.
One other way around this is to try and do some live satellite tracking using your SDR. This removes some of the issues with aligning timing for your doppler correction and the incoming signals….plus it is a buzz……
It sounds like you are honing in on the correct solution. Keep working on it.
for what it’s worth, generating an hour for any leo satellite at any time will produce a correction pattern, regardless where it is or even if it is above the horizon. this will show up on all terrestrial signals and show if the thing actually does something.
on another note, it is really important to have correct frequency in the calculations as this scales with that. so if you generate for 145MHz but use it at 435MHz it will be too little correction and not stay centered.
