Topics

Problems with FY-3D python script


Graham Woolf
 

Hi Ernst

I am having trouble getting any images of the UK from my FY3D script at the moment -it seems to stop at southern europe

I have attached the latest image and the script I am using and I wondered if you can see a problem

I suspect it might have something to do with the orbit time

Regards

Graham


Ernst Lobsiger
 

Graham

have you ever updated the TLE-File? There is a Batch file or script to do that.

Regards
Ernst


Am 14.10.2020 20:12, schrieb Graham Woolf:

Hi Ernst
I am having trouble getting any images of the UK from my FY3D script
at the moment -it seems to stop at southern europe
I have attached the latest image and the script I am using and I
wondered if you can see a problem
I suspect it might have something to do with the orbit time
Regards
Graham


Graham Woolf
 

Hi Ernst

Yes I did today

I also set the string so that it downloaded the file from the internet

My PC is set to local time too

Regards

Graham


Douglas Deans
 

On 14/10/2020 19:12, Graham Woolf wrote:
Hi Ernst
I am having trouble getting any images of the UK from my FY3D script at the moment -it seems to stop at southern europe
I have attached the latest image and the script I am using and I wondered if you can see a problem
I suspect it might have something to do with the orbit time
Regards
Graham
============================================================================
Graham I have noticed for a long time now that there is usually a portion of the UK missing from FY3D. My script runs from Africa to Greenland.
On checking the FY3D timestamps on the files I see that the actual files are missing so it may be a problem of the EARS system.
Perhaps we should check with Eumetsat.
Typical image attached.

Regards,
Douglas.


Ernst Lobsiger
 

Graham
It must be UTC on your PC (is that your local time?)

Douglas
Yes I had that some time back these FY3D segments missing over the UK.

Sorry, still busy with TBS HW and driver SW.

Best Regards
Ernst


Am 14.10.2020 20:51, schrieb Douglas Deans via groups.io:

On 14/10/2020 19:12, Graham Woolf wrote:
Hi Ernst
I am having trouble getting any images of the UK from my FY3D script at the moment -it seems to stop at southern europe
I have attached the latest image and the script I am using and I wondered if you can see a problem
I suspect it might have something to do with the orbit time
Regards
Graham
============================================================================
Graham I have noticed for a long time now that there is usually a
portion of the UK missing from FY3D. My script runs from Africa to
Greenland.
On checking the FY3D timestamps on the files I see that the actual
files are missing so it may be a problem of the EARS system.
Perhaps we should check with Eumetsat.
Typical image attached.
Regards,
Douglas.


Graham Woolf
 

Hi Ernst

No my local time is UTC + 1 - do I need to adjust something in theย  python file for that

I have had some missing segments too

Regards

Graham


Ernst Lobsiger
 

Graham

Most probably it's only relevant when you schedule image processing.
If you have a certain time of sat overhead from filenames it's UTC.
Adding some slack for timelyness (preprocessing by EUMETSAT) it's
still UTC. But the Windows scheduler might only work with local time.

Regards
Ernst


Am 15.10.2020 00:05, schrieb Graham Woolf:

Hi Ernst
No my local time is UTC + 1 - do I need to adjust something in theย 
python file for that
I have had some missing segments too
Regards
Graham


David J Taylor GM8ARV ๐Ÿด๓ ง๓ ข๓ ณ๓ ฃ๓ ด๓ ฟ ๐Ÿ‡ช๐Ÿ‡บ
 

Graham

Most probably it's only relevant when you schedule image processing.
If you have a certain time of sat overhead from filenames it's UTC.
Adding some slack for timelyness (preprocessing by EUMETSAT) it's
still UTC. But the Windows scheduler might only work with local time.

Regards
Ernst
===============================

The Windows Scheduler works in the current operational time of the PC.

There is an option somewhere to schedule across time zones but I've never used that, and it may be just for meetings in some other software.

Linux crontab also works in "current operational time" at least on my Raspberry Pi cards.

Cheers,
David
--
SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: david-taylor@...
Twitter: @gm8arv


Christoph Neuhaus
 

David

Linux crontab also works in "current operational time" at least on my
Raspberry Pi cards.
You can add the line
CRON_TZ=UTC
to your crontab file to change the timezone to UTC.


Regards,
Christoph



Am 15.10.20 um 10:38 schrieb David J Taylor GM8ARV ๐Ÿด ๐Ÿ‡ช๐Ÿ‡บ via groups.io:
Graham
Most probably it's only relevant when you schedule image processing.
If you have a certain time of sat overhead from filenames it's UTC.
Adding some slack for timelyness (preprocessing by EUMETSAT) it's
still UTC. But the Windows scheduler might only work with local time.
Regards
Ernst
===============================
The Windows Scheduler works in the current operational time of the PC.
There is an option somewhere to schedule across time zones but I've never used that, and it may be just for meetings in some other software.
Linux crontab also works in "current operational time" at least on my Raspberry Pi cards.
Cheers,
David

--
_____________________________________________

University of Bern
Department of Geography
Remote Sensing Research Group

Christoph Neuhaus
ICT Expert

Hallerstrasse 12
3012 Bern - Switzerland

mailto:christoph.neuhaus@...
skype: nihil14
http://www.geography.unibe.ch/remotesensing
_____________________________________________


David J Taylor GM8ARV ๐Ÿด๓ ง๓ ข๓ ณ๓ ฃ๓ ด๓ ฟ ๐Ÿ‡ช๐Ÿ‡บ
 

David

Linux crontab also works in "current operational time" at least on my
Raspberry Pi cards.
You can add the line
CRON_TZ=UTC
to your crontab file to change the timezone to UTC.

Regards,
Christoph
=============================

Thanks, Christoph. I may do that, although the system is already mixed in that It's an Amateur Radio system (see: Pi-Star if interested) and logging there should be in UTC, all my MRTG logging is in UTC (which is clock time for half the year here!), but the included Dashboard software is in local time, which agrees with the wall clock if I want to know who was last on!

The program is supplied as a pre-built RPi image, to which I add things like NTP and MRTG, so any changes I make would be lost and the next major version. Hence I fiddle the lest, to create the least amount of work in the future.

Cheers,
David
--
SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: david-taylor@...
Twitter: @gm8arv