reynico / raspberry-noaa

Fully automated ISS SSTV, NOAA and Meteor satellite image downloader using Raspberry PI
https://github.com/reynico/raspberry-noaa
GNU General Public License v3.0
181 stars 56 forks source link

Enchancements-Passes #7

Closed kingdom1981 closed 4 years ago

kingdom1981 commented 4 years ago

South-east europe the sun.py gives always the same enchancements. Some passes has too less capture time.

reynico commented 4 years ago

Hi! Thank you! I'll take care of it this week. Where are you located?

kingdom1981 commented 4 years ago

Greece

reynico commented 4 years ago

As per I tested, seems like sun.py is working as expected. I used

obs.lat='37.97945'
obs.long='23.71622'

For Athens.

https://www.timeanddate.com/astronomy/greece/athens 16:31 local time shows a 19 deg sun elevation, and the sun.py calculation shows the same for epoch time 1582641065 (14:31 GMT)

% python3 sun.py 1582641065
18

Perhaps adjusting SAT_MIN_ELEV helps?

kingdom1981 commented 4 years ago

% python3 sun.py 1582641065 2020-02-25 18:31:05 -31 is this normal ? so i have to put SUN_MIN_ELEV=-30?

reynico commented 4 years ago

Nevermind, I found the issue. Time ago I hardcoded +3*60*60 at the date line just for timezone reasons.

Just replace

date = time.strftime('%Y-%m-%d %H:%M:%S', time.localtime(int(sys.argv[1])-2*60*60))

with

date = time.strftime('%Y-%m-%d %H:%M:%S', time.localtime(int(sys.argv[1])))

So date will be your current date for your correctly set timezone:

n@linux:~$ date
Tue Feb 25 19:18:30 EET 2020 <--- I set my timezone to Athens/Europe
n@linux:~$ python3 sun.py 1582641065
25
kingdom1981 commented 4 years ago

It's working but i changed if [ "${SUN_ELEV}" -gt "${SUN_MIN_ELEV}" ]; then to if [ "${SUN_ELEV}" -gt 10 ]; then in receive.sh Also some captures are too short in time even with SAT_MIN_ELEV=30

dg9bja commented 4 years ago

Good job at all but I also had some problems with sun.py At the moment you hard coded localtime +3 60 60 as a result you get UTC time at your place. I needed -2 60 60 for UTC because our difference between local time and UTC is 2 hours (Germany). ephem uses UTC for calculations.

I tested that with timestamp from actual at jobs to see the result.

reynico commented 4 years ago

Thanks @dg9bja! Fixed on 81a7fd7

dg9bja commented 4 years ago

A lot of countries here in europe changes local time end of march and in october for one hour. summer daylight changes. I don't have a problem because I know about. tzdata could help. Another thing I tried now is https://github.com/dbdexter-dev/meteor_demod/tree/devel There are some important changes "improved lock detection" I got some better results with latest decode.