Date   

Re: TelliCast Missed Packets False Alarms

David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

David

Running out of other options: Have you tried to disable C-States in the BIOS (if possible at all)?
Christian recently had this deja vue with a Technisat SkyStar2 eXpress HD card on his Ancalagon.

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

Thanks, Ernst. No, I've not tried at. I see 13 C-states listed here:

https://www.dell.com/support/article/en-uk/qna41893/what-is-the-c-state?lang=en

Were you thinking of any particular one?

What was Christian's problem exactly? Perhaps there is a message reference?

I wish I knew the time that it takes for a missed packet to be recovered. USB devices are polled every millisecond, so perhaps if the device isn't polled sufficiently frequently that's the missed packet, and on the next poll there's enough to recover the packet. Perhaps the USB is too busy? Why do we only see this on direct PCie and USB devices, and even then only on /some/ systems. I've never seen this on network-connected receivers where the MTU is about three times bigger (1500 bytes) than what I've seen quoted for USB 2 (500 bytes).

Back of envelope sum: USB practical max, say 240 Mbps, 30 MBps, 1 millisecond polling => 30 kB per poll. EUMETCast Basic Service 55 Mbps, well under 240 Mbps. Doesn't help!

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


Re: TelliCast Missed Packets False Alarms

Ernst Lobsiger
 

David

Running out of other options: Have you tried to disable C-States in the BIOS (if possible at all)?
Christian recently had this deja vue with a Technisat SkyStar2 eXpress HD card on his Ancalagon.

Regards
Ernst


Re: TelliCast Missed Packets False Alarms

David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

Progress report.

I've been trying to resolve the steady missed/recovered TelliCast packets issue on PC Penguin, and I did further tests yesterday and today but without success so far.

- Adding a RAMdisk (tmp and received)

- changing to a TBS5925 (from TBS5927)

- and moving to a USB 3 port (from USB 2) have all made no difference.

Items left in common: BDADataEx (but that works correctly with the TBS6903 PCIe card running BAS, HVS-1 and HVS-2, and with an earlier PC with a TBS5925 USB receiver plugged into a separate USB3 card). TelliCast was 2.14.5 on the old PC, 2.14.6 on the new. I'm reluctant to revert TelliCast, or the TBS5927, as they are units which the new user would be using.

It seems that the new PC has a single main USB hub internally on the motherboard, so perhaps there's a parameter I can tune there? If so, I couldn't see one Perhaps adding a low-profile PCIe USB 2 card could be an option giving two top-level hubs, such cards seem to be no longer available! I am trying to avoid USB 3.0 cards as they require extra power connectors.

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


Re: Gaps in AVHRR images yesterday.

David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

That solved the problem empirically but not (for me) theoretically. I ran Kepler updater and now have lat/long and outlines correct in AVHRR Manager. I normally download Keplers by hand and did so this morning. When I came to compare the two lines for satellites in the manually download file with the updater files, they were identical. But perhaps one overwrote the other thus making them identical. I'll run the updater overnight in future.
Ah, well ......
BTW Is the Kepler Manager program superseded by Updater (not that I've used the former for a long while)?
Robert
===========================

Always good to hear of progress, Robert..

Yes, the Kepler Manager was replaced in July 2019, as [I hope] notified in the SatSignal group. The SSL libraries now required were incompatible with the older program. In addition, I wrote the updater to be more efficient, and to use the EUMETSAT Kepler data for the polar orbiting satellites they operate (as discovered by Thorsten Miglus).

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


Re: Gaps in AVHRR images yesterday.

Robert Moore
 

That solved the problem empirically but not (for me) theoretically. I ran Kepler updater and now have lat/long and outlines correct in AVHRR Manager. I normally download Keplers by hand and did so this morning. When I came to compare the two lines for satellites in the manually download file with the updater files, they were identical. But perhaps one overwrote the other thus making them identical. I'll run the updater overnight in future.
Ah, well ......
BTW Is the Kepler Manager program superseded by Updater (not that I've used the former for a long while)?
Robert

-----Original Message-----
From: MSG-1@groups.io <MSG-1@groups.io> On Behalf Of David J Taylor GM8ARV ?????????????? ???? via groups.io
Sent: 18 September 2020 13:55
To: MSG-1@groups.io
Subject: Re: [MSG-1] Gaps in AVHRR images yesterday.

I have my weekend job, checking packet loss etc. Meanwhile a different problem has emerged: a very nice NOAA-19 image this morning 0620_NOAA19_59849, no missing segments. The latitude of my home station is correctly entered in HRPT Reader, the countries.dat file is present and Keplers are up to date (today). But HRPT Reader says I am at 2.75 degrees south, when I'm 53.26 degrees north. So I turned on country outlines; outline of southern England just visible off the top of the image. Denmark is just below the outline for the southern coast of West Africa - obviously the outline is serious displaced northwards. So turned on lat. and long.
markers - to my surprise the longitude line converged southwards, the with North pole somewhere in South Africa (not visible in this image) and I'm now at 3.3 South, Denmark on the Equator.
So; outlines displaced drastically northwards, right way up, and lat/long upside down. The image itself excellent!
Might it be a good idea to uninstall and reinstall AVHRR Manager just to eliminate any corruption of something somewhere?

Robert
====================================

Robert,

Overlays being way off very strongly suggests that your Kepler data is way out of date. Look at the View, Diagnostics menu, and search for lines like:

Decoded pass quarter hour is 2019-May-15 10:00 UTC Update orbit data for METOP-A read from C:\Tools\SatSignal\HRPTreader\Keps\Updates\METOP-A.txt
Orbit data is only 0.1 days stale - OK

Perhaps the HRPT Reader isn't looking where you expected? Remember that the HRPT Reader can accept either current data (like weather.txt with multiple
satellite) or historic data such as METOP-A.txt with many entries for a single satellite. My KeplerUpdater will keep the historic data current. If yours has lapsed, there's a daily update here:

http://www.satsignal.eu/software/KeplerUpdates.zip

See:

http://www.satsignal.eu/software/KeplerManager.htm

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


Re: Gaps in AVHRR images yesterday.

David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

I have my weekend job, checking packet loss etc. Meanwhile a different problem has emerged: a very nice NOAA-19 image this morning 0620_NOAA19_59849, no missing segments. The latitude of my home station is correctly entered in HRPT Reader, the countries.dat file is present and Keplers are up to date (today). But HRPT Reader says I am at 2.75 degrees south, when I'm 53.26 degrees north. So I turned on country outlines; outline of southern England just visible off the top of the image. Denmark is just below the outline for the southern coast of West Africa - obviously the outline is serious displaced northwards. So turned on lat. and long. markers - to my surprise the longitude line converged southwards, the with North pole somewhere in South Africa (not visible in this image) and I'm now at 3.3 South, Denmark on the Equator.
So; outlines displaced drastically northwards, right way up, and lat/long upside down. The image itself excellent!
Might it be a good idea to uninstall and reinstall AVHRR Manager just to eliminate any corruption of something somewhere?

Robert
====================================

Robert,

Overlays being way off very strongly suggests that your Kepler data is way out of date. Look at the View, Diagnostics menu, and search for lines like:

Decoded pass quarter hour is 2019-May-15 10:00 UTC
Update orbit data for METOP-A read from C:\Tools\SatSignal\HRPTreader\Keps\Updates\METOP-A.txt
Orbit data is only 0.1 days stale - OK

Perhaps the HRPT Reader isn't looking where you expected? Remember that the HRPT Reader can accept either current data (like weather.txt with multiple satellite) or historic data such as METOP-A.txt with many entries for a single satellite. My KeplerUpdater will keep the historic data current. If yours has lapsed, there's a daily update here:

http://www.satsignal.eu/software/KeplerUpdates.zip

See:

http://www.satsignal.eu/software/KeplerManager.htm

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


Re: experiences and lessons learned with a fresh Eumetcast install for WIndows and Linux

David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

Hi all

I thought this would be a suitable thread to post my problem with setting up a Eumetcast system. I basically started a new system besides using an existing dish which was aligned correctly.

I am based in South Africa so I am using the Eumetcast Africa service, using a Norva satellite receiver on Windows 10. I installed the EKU, tellisat and configured the receiver. The EKU and receiver are working fine and I am able to connect to the announcement channel (TSL-AFR-1) but none of the additional data channels appear even though the license is active.

I would appreciate any advice.

Kind regards,
Jean du Preez
====================================

David,

- are the PIDs correct?

- what does the TelliCast log file say? The last few lines, that is!

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


Re: Gaps in AVHRR images yesterday.

Robert Moore
 

I have my weekend job, checking packet loss etc. Meanwhile a different problem has emerged: a very nice NOAA-19 image this morning 0620_NOAA19_59849, no missing segments. The latitude of my home station is correctly entered in HRPT Reader, the countries.dat file is present and Keplers are up to date (today). But HRPT Reader says I am at 2.75 degrees south, when I'm 53.26 degrees north. So I turned on country outlines; outline of southern England just visible off the top of the image. Denmark is just below the outline for the southern coast of West Africa - obviously the outline is serious displaced northwards. So turned on lat. and long. markers - to my surprise the longitude line converged southwards, the with North pole somewhere in South Africa (not visible in this image) and I'm now at 3.3 South, Denmark on the Equator.
So; outlines displaced drastically northwards, right way up, and lat/long upside down. The image itself excellent!
Might it be a good idea to uninstall and reinstall AVHRR Manager just to eliminate any corruption of something somewhere?


Robert





Thanks for the response David.
[]
** I can only judge from reception of MSG, RSS, GOES-16 and 17, Himawari and IODC. All coming through to the processing PC perfectly. The Ethernet graph in Task Manager/Performance on the receiver shows moderate traffic but at regular intervals has a burst for which the peaks go off the top of the scale.

** EUMETSAT_data_channel_1 has files that don’t appear to be moving: BUFR,
NOAA-19 and BIN files. ‘Delete files from RX’ is ticked in AVHRR Manager [] Thanks for the help.

Robert
==========================================

Robert,

Thanks for the answers.

"Perfect reception": The programs handling the data you mention have the ability to fill in missing data (by the Persistent Images setting). So it's possible that any imperfections are being hidden. Use the Tools, Missing Segments Report... menu option to see whether the reception is as perfect as you expect.

"Unused files": The EARS AVHRR Manager should be handling the NOAA-19 data.
Is there an image on the NOAA_19 tab, and if so, what is the date of that image in the lower left corner. On the Ground Stations tab, is NOAA-19 checked (I don't think that makes a difference) and it the Kepler status showing a sensible age? The program version here is a beta 4.1.1.241 2019-Mar-11, although 4.1.2 is the release version.

"BUFR and BIN data": Is the "Process AVHRR polar winds" box checked in the relevant Metop Managers?

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


Re: experiences and lessons learned with a fresh Eumetcast install for WIndows and Linux

Peter Novak
 

Hi Jean,

I am based in South Africa so I am using the Eumetcast Africa service,
using a Norva satellite receiver on Windows 10. I installed the EKU,
tellisat and configured the receiver. The EKU and receiver are working fine
and I am able to connect to the announcement channel (TSL-AFR-1) but none
of the additional data channels appear even though the license is active.
That sounds like exactly the same confusion we ended up with. I suggest
the following:
1. keep the system running for several hours
2. after, say half a day, check
a) the data output directory for content (normally you'd expect
several dozens of megabytes of output data); and
b) check the number of reported missed packets and amount of
received data.

The point is that the web interface seems to be reporting "Connected" to
a channel only during the short period of time when it is actually
receiving/decoding a file. Out of those times it reports no connection
to data channel - it simply seems like it is "not connected". Since the
setup can go for longer periods of time without receiving anything,
depending on your configuration of products you want to receive in your
DVB-S2 receiver, it is easy to fall into a trap of thinking that the
system is not configured properly (because you see no "Connected"
status), while it is only not actively receiving anything at the moment
you are looking at it.

Best,

Peter.

--
Meandair B.V. | aviation navigation solutions
Olof Palmestraat 14 | 2616 LR Delft | The Netherlands
Tel +31 (0)638 167 279 | http://www.meandair.com/
Participant in ESA BIC Noordwijk, The Netherlands


Re: experiences and lessons learned with a fresh Eumetcast install for WIndows and Linux

David Jean du Preez
 

Hi Ernst

I have done both those. In the log file the license check succeeds . 


Kind regards,
Jean du Preez


On Fri, 18 Sep 2020 at 12:16, Ernst Lobsiger via groups.io <ernst.lobsiger=belponline.ch@groups.io> wrote:
Jean

Have you set your "user_name" and "user_key" in cast-client.ini  (needs a restart of the client)?
Have you choosen your channels in cast-client-channels.ini  (can be done in a running system)?

Regards
Ernst


Re: experiences and lessons learned with a fresh Eumetcast install for WIndows and Linux

Ernst Lobsiger
 

Jean

Have you set your "user_name" and "user_key" in cast-client.ini  (needs a restart of the client)?
Have you choosen your channels in cast-client-channels.ini  (can be done in a running system)?

Regards
Ernst


Re: experiences and lessons learned with a fresh Eumetcast install for WIndows and Linux

David Jean du Preez
 

  Hi all

I thought this would be a suitable thread to post my problem with setting up a Eumetcast system. I basically started a new system besides using an existing dish which was aligned correctly. 

I am based in South Africa so I am using the Eumetcast Africa service, using a Norva satellite receiver on Windows 10. I installed the EKU, tellisat and configured the receiver. The EKU and receiver are working fine and I am able to connect to the  announcement channel (TSL-AFR-1) but none of the additional data channels appear even though the license is active.

I would appreciate any advice.

Kind regards,
Jean du Preez


On Fri, 18 Sep 2020 at 00:05, Andreas Mueller <juamueller@...> wrote:
On Thu, Sep 17, 2020 at 12:59 PM, Ernst Lobsiger wrote:
If your Windows setup allows for MODCOD selection
try to set 8PSK 2/3 only (you should see a remarkable improvement).
Ernst - can 100% confirm this - by setting the MODCOD in Win10's BDADataEx to '8PSK,3/5' i see 0 missed packets / missing keys - so for Basic Reception it's really great. Guess (as said) will try to get a 5925 and use your patched driver for my Linux environment.

Andreas


Re: experiences and lessons learned with a fresh Eumetcast install for WIndows and Linux

Andreas Mueller
 

On Thu, Sep 17, 2020 at 12:59 PM, Ernst Lobsiger wrote:
If your Windows setup allows for MODCOD selection
try to set 8PSK 2/3 only (you should see a remarkable improvement).
Ernst - can 100% confirm this - by setting the MODCOD in Win10's BDADataEx to '8PSK,3/5' i see 0 missed packets / missing keys - so for Basic Reception it's really great. Guess (as said) will try to get a 5925 and use your patched driver for my Linux environment.

Andreas


Re: experiences and lessons learned with a fresh Eumetcast install for WIndows and Linux

David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

Hello David,
[]
1. tc-cast-client is buffering the logs. In result, upon start we saw
only like 5 first lines of expected logs and then nothing any more.
So when you are tailing the log ('tail -f recv_bas.log'), you would
think something is hanging (the last line was "Child connecting to
watchdog on port ..."). What was actually going on is that everything
ran smoothly and only when the logging buffers flushed the contents
to the disk (when some data is received, which can take a loong time
on BAS), we could see that everything is OK.
2. the second point of confusion was monitoring the tellicast web
interface. It relatively quickly connects to the announcements
channel, but then no data channel is active. What we did not know was
that transmissions on this channel happen only once per hour
approximately in the time block X:00 to X:15. And only when the
client is actually decoding the data it reports a connection to a
data channel. In result, for 45 minutes in every hour it seems that
the client is not connected, while actually everything is OK. Only in
retrospect we realised that of course this makes sense because our
Ayecka SR1 is sending UDP packets only when it receives something, so
there's no concept of a session and thus tellicast cannot report
"connected".
[]
Thanks again for all the help we received. This thread was very
informative and helpful.

Best,
Peter.
===================================

Peter,

Just a couple of points.

1. You can turn off the log buffering, I believe, but I've never done so:

[locations]
log_file=>>\EUMETCast\logs\recv.log

I recall (but it's not documented, so I'm probably wrong) that ">>" implied buffering. Perhaps it simply means "append". The ">>" may apply to something else in an earlier TelliCast, so please check. Maybe that wouldn't help in your case anyway.

2. Almost all BAS data should be sent every 15 minutes, with the possible exception of some meteorological data and some FSD. You must be looking for relatively obscure data!

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


Re: experiences and lessons learned with a fresh Eumetcast install for WIndows and Linux

Peter Novak
 

Hello David,

Perhaps prove the system and its components first on Windows - much, much
easier!
Well, that's not really an option for us. This is a headless server in a
rack we have there.

My own experience with Linux is that everything is version dependent -
sometime critically so. So if EUMETSAT recommend a particular distribution,
and a certain version of that distribution, it's better to use what is
recommended rather than deviate in any way.
Indeed, we now understand why that is the case too :-). Anyway, we
finally managed to set it up even on the not well supported Debian 10.
The trick was indeed the 10.7.77 SAC driver (we'll still test Andreas'
advice about libgtk). From then on, we managed to get the thing running.

Perhaps you could post the last few lines of the TelliCast log file?
It turned out the whole setup worked, but there were two points which
caused confusion on our side:
1. tc-cast-client is buffering the logs. In result, upon start we saw
only like 5 first lines of expected logs and then nothing any more.
So when you are tailing the log ('tail -f recv_bas.log'), you would
think something is hanging (the last line was "Child connecting to
watchdog on port ..."). What was actually going on is that everything
ran smoothly and only when the logging buffers flushed the contents
to the disk (when some data is received, which can take a loong time
on BAS), we could see that everything is OK.
2. the second point of confusion was monitoring the tellicast web
interface. It relatively quickly connects to the announcements
channel, but then no data channel is active. What we did not know was
that transmissions on this channel happen only once per hour
approximately in the time block X:00 to X:15. And only when the
client is actually decoding the data it reports a connection to a
data channel. In result, for 45 minutes in every hour it seems that
the client is not connected, while actually everything is OK. Only in
retrospect we realised that of course this makes sense because our
Ayecka SR1 is sending UDP packets only when it receives something, so
there's no concept of a session and thus tellicast cannot report
"connected".

So now we have a setup basic service. Given that the process is backed
up by EUMETSAT and seems to be well supported on Windows out of the box
we did not expect the amount of confusion we would run into while
setting it up on Linux. But indeed, supporting this on different
versions of Linux is a bit bigger problem than on Windows where at least
there are not that many flavours and versions of binary environments in
which the software is running.

Thanks again for all the help we received. This thread was very
informative and helpful.

Best,

Peter.

--
Meandair B.V. | aviation navigation solutions
Olof Palmestraat 14 | 2616 LR Delft | The Netherlands
Tel +31 (0)638 167 279 | http://www.meandair.com/
Participant in ESA BIC Noordwijk, The Netherlands


Re: experiences and lessons learned with a fresh Eumetcast install for WIndows and Linux

David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

From: Ernst Lobsiger via groups.io
[]
@David
Agreed, Windows must be far easier for setting up a TelliCast receiver.
K.-P. is doing his best to make GNU/Linux TC receivers still possible.
But as you said, different distributions make this "mission impossible".
On the other hand automatic updates from Microsoft must be a nightmare.
[]
================================

I'm unsure about Linux updates. On the one hand the lack of automatic updates concerns me, on the other many of the updates I've seen have major problems due to lack of backwards compatibility. Certain programs which you might expect to be stable (e.g. gpsd) on closer examination are just in permanent beta. "Oh, we don't support that now". "Oh, that changed on 3.20 (but 3.17 in the latest in the distribution)". "Oh, that won't work unless you recompile from source". "Oh, you need to [attempt to] uninstall the version from the distribution" - except that it doesn't completely uninstall. You'll gather I've spent weeks trying to get this to work, I'd rather not go there again!

Some packages, such as NTP, work nicely and are even cross-platform!

It's straight-forward to turn off Windows Updates if you don't want them, and you can delay them if you wish. They're on the second Tuesday of the month, so you know when to expect them. Usually the monthly "security" updates are without problems, the six monthly "feature" updates may have minor issues, but there are so many beta [Windows Insider] users that any issues are either fixed before release, or very well documented. The only significant one recently was that microphone access was disabled by default, and those who hadn't been keeping in touch found that some sound programs couldn't find a sound source. Easily fixed with a single click change.

In practice, Windows-10 updates are usually not a significant issue.

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


Re: Removal of Sentinel-3 OLCI Level-1 Full Resolution NRT data from EUMETCast Satellite service

Daniele Guardigli
 

Or they're slowly moving towards a web service?


Il giorno gio 17 set 2020 alle ore 13:26 James Brown <satellite@...> ha scritto:

> On 17 Sep 2020, at 11:39, David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺 via groups.io <david-taylor=blueyonder.co.uk@groups.io> wrote:
>
> EUMETSAT announcement:
>
> Sentinel-3 OLCI Level-1 Full Resolution (FR) Near Real Time (NRT) data will be removed from EUMETCast Satellite in July 2021.  The planned date for the removal of OLCI Level 1 FR NRT data from our EUMETCast Satellite service is 29 July 2021.
>
> Alternative services to access these data are available:
>
> See:
>
> https://www.eumetsat.int/website/home/News/DAT_5184373.html
>
> Cheers,
> David
> --
> SatSignal Software - Quality software for you
> Web: https://www.satsignal.eu
> Email: david-taylor@...
> Twitter: @gm8arv

I’m wondering which of the new services they are making space for?

Cheers.
James.







--
Daniele Guardigli


Re: experiences and lessons learned with a fresh Eumetcast install for WIndows and Linux

David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

From: Andreas Mueller
[]
... or continue with Win10 (which I don't like much since i'm more with Linux like some others here)

Andreas
===============================

Andreas,

I don't particularly "like" Apple or iOS but I use it for my iPad because they get the job done.

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


Re: Removal of Sentinel-3 OLCI Level-1 Full Resolution NRT data from EUMETCast Satellite service

David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

I’m wondering which of the new services they are making space for?

Cheers.
James.
===============================================

Perhaps one of these? MTG looks earlier.

MTG satellites, imagers and sounders - 2022-2042

https://www.eumetsat.int/website/home/Satellites/FutureSatellites/MeteosatThirdGeneration/index.html



MetOp-SG imagers/sounders and microwave imaging - 2023-2038

https://www.eumetsat.int/website/home/Satellites/FutureSatellites/EUMETSATPolarSystemSecondGeneration/index.html

(Linux date rollover - 2038 - could be fun!).

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


Re: experiences and lessons learned with a fresh Eumetcast install for WIndows and Linux

Andreas Mueller
 

On Thu, Sep 17, 2020 at 12:59 PM, Ernst Lobsiger wrote:
@ Andreas
I tried to patch the stv0910x driver (without HW documentation!) for MODCOD selection along the lines I did it for stv090x. Unfortunately no success ..
Ernst - yes it was my 'silent' hope to get a positive message on that - so guess i've just 2 options left - improve my SNR and/or watch out for a 5925 and use your patched driver ... or continue with Win10 (which I don't like much since i'm more with Linux like some others here)

Andreas

1581 - 1600 of 31520