I come to observe frequency shifts in the pasadas del FUNCube-1, and I have reviewed that it is not a ppm theme.
It is also possible to decode it manually with the SDR and the Dashboard and it can be done, but normally it requires a shift at a frequency of about 1000 to 1500 Hz.
Is it possible that there is some problem with that particular satellite?
The best way to find out is to check several observations performed by different stations. If the difference is consistent then probably the “issue” is on the satellite’s transmitter. In this case the next step is to suggest the drift in transmitter’s page in SatNOGS DB.
Thanks @fredy I’ll check.
I add another recent observation, could it be that the TLE requires some adjustment and that causes the doppler to be miscalculated?
It would seem that it is more noticeable in some areas more than others.
Indeed the tx oscillator chain on FUNcube-1 is not thermally stable so the output frequency drifts slightly during the orbit.
This is due to its design to use only very very low power to ensure a good power budget on board.
The FUNcube windows based Dashboard and decoder incorporates an AFC tracking system. This deals with both Doppler and the drift effects automatically and provides a good solution.
If it is correct @graham_g3vzv, the drift in frequency has always been noticeable but lately (or at least in this area) it is much greater, to the point that the messages are no longer decoded with Satnogs (if I can do it with the FUNCube dashboard- 1).
Is there a solution to do frequency tracking with an AFC from satnogs?
Sorry - I am not a satnogs expert!
The amount of thermal drift changes as the spacecraft orbit changes…we have had periods of continuous sun light for some months - when the inside temps were hot but stable but currently we have 29 minutes eclipse every orbit so the temps are currently varying between -6 and +18 each orbit. FUNcube-1 was designed and built back before onchip TCXOs were invented…
Very clear explanation! Now I understand the reason for the current situation.
Hopefully something can be done from Satnogs.
I guess for mitigate this issue you will need some extensive calculations to find out how much is the drift depending on the orbit. I think that this is possible doesn’t sound like a priority.
Anyway, until we have such a mechanism, the only thing we can do is to update the DB entries and get as closer as we can in the real frequency.
Thanks @Fredy, understood.
Can I propose the update of the database or should someone from Satnogs do it?
Anyone logged in can add suggestions for adding new satellite or transmitter or changing details on existing ones.
Check this wiki page SatNOGS DB - SatNOGS Wiki, it needs some updates but for suggesting transmitters is pretty accurate. For editing the existing ones you just go to each transmitter menu and hit the edit button.
With the current transmitter there is not really any need to change it, have a look SatNOGS Network - Observation 6253116.
I would suggest to first measure your SDR freq error, if this is a RTL-SDR use the kal utility.
This post has an example how to use it: Observation 6111502: GRIFEX (40379)
Thanks to both of you, I continue to observe as follows and I have already verified the SDR frequency error (with all the others this shift is not seen, it only happens with the FUNCube-1), the shift may be more noticeable in this area of the southern cone , because I also see that in other northern stations the same thing does not happen.
I have not changed anything in the station, since the rest of the satellites are received correctly and on the exact frequency, and now the FUNCube-1 is with less frequency drift in this area and begins to decode.