New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FY-2H offset #179
Comments
That is unfortunately down to the satellite / format. I process images "putting the lines in the right spot" using counters it provides, but the Earth still moves around. Perhaps if you could provide a few sample basebands of affected full disks I could see if there's something I can do. I could perhaps implement further processing to center it back. Nice reception by the way! Out of curiosity, where are you located and what's your setup? Pretty good results on L3 etc. |
Yup, i thought so, but worth to ask ;) Sure, I will upload some basebands within the same time period between them. Hope it helps. I have tried to use Sanchez on FY-2H but because of shift and different geometry/rotation its practically useless. Thanks, I have just replaced 0,7 offset dish to 1.9m parabolic mesh dish on a tower to be able to catch those, as all geosats are low elevation from my point. There is a helix with sawbird lna and finally rspdx. My location is near Zbychu's, Warsaw/Poland. FY-2H is fine, but still get too much errors on GOES GVAR, the only one GOES available here - its about 5-6dB SNR |
Thanks! I also need to make projection files for FY-2H etc anyway so it will be useful either way. Oh nice! That's pretty good. @ZbychuButItWasTaken was using a 1.8m for GVAR though, so chances are your feed needs to be linear and properly pointed. It's not an issue on ELEKTRO-L as it is RHCP but could really hurt you on GOES. |
5-6 db does sound about right for a circular feed, I was usually getting around 9db on my dish. That matches pretty well assuming 3db loss between circular and linear polarization |
@ZbychuButItWasTaken i wish, but im getting maaany horizontal lines. Started to think there is something more wrong here, as some of those lines are on every capture, for example the white lines here below. Maybe its kind of live processing issue, i have to try this on another machine |
Those lines are due to bad data, so low SNR mainly. The white ones are due to the same lines on IR channels... So unfortunately I highly doubt a better PC would help much at all. @ZbychuButItWasTaken used to run it on Core2Quad just fine (back when things were much, much less optimized). |
@Aang23 yea, but same lines are on channel 1, different time, which is strange that im getting bad data every time at the same point. |
Hmmm @sq7r0 perhaps if you can join the Matrix room (see the readme)? Will more practical to see what's going on there! |
to have a better view of the shift i made a two day animation FluffyAgitatedAoudad-mobile.mp4 |
Yes so that definitely is the sat. Is the offset identical at the same time of day? |
All that could really be done honestly is generating projections using TLEs, to change the point of view over time. But that's not going to be viable on the raw data, as the effect is not purely a translation of the image. @sq7r0 the best I can propose is implementing this above (which is what NSMC does actually), using a bunch of data if you are able to record it (as svissr files, without decoding to images live). But as far as the raw imagery goes, that'll have to stay a "wontfix". Can't do much when it's the satellite itself. |
Hi,
im not sure if this is possible to fix, but worth to mention. Have found an issue regarding Fengyun S-VISSR imagery which is offset every single frame received. I have drawn a line parallel to the south pole, to show how much the image is shifted every few hours. Any idea it could be fixed or its just a satellite sensor image shifted? There is a difference even between images from the same time of the day, different date. The offset makes the automatic processing pretty tricky
cheers
Krzysztof
The text was updated successfully, but these errors were encountered: