Date   

Silicon Labs CP210x driver.

geojohnt@...
 

Hello All,

I'm going round in circles!

Does the SR1 have to be disconnected before you install this software?
The Ayecka SR1 DVB Receiver EUMETCast Guide appears to suggest this.

I run 24/7 and don't want to interrupt the service but Ops suggest that my TC missing packets and SR1 Controller anomalies might be due to using the data link for monitoring.
I have bags of SNR and my computer is not 'stressed' so I shouldn't see missed packets(?).

I have cleared out all my old copies of CP210x - which were 'all over the place,' and just downloaded a fresh copy.
I unzipped the zip file and ran the installer and the Wizard told me that the software/driver was ready to use.
However, it refuses to show in Device Manager Ports (COM & LPT) list.

I'm losing the will to live.

Regards,
John Tellick.



Re: APT-like CLUT for GeoSatSignal and remapping

Daniele Guardigli
 

Thank you!


Il Ven 16 Ott 2020, 09:55 David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺 via groups.io <david-taylor=blueyonder.co.uk@groups.io> ha scritto:
From: Daniele Guardigli

Hello, I'm new to Eumetcast service and related software. Is there any way
to get a CLUT like pictures produced by wxtoimg software for apt sats? Is
there also a way to change remapping in 1080x1920 intead of 1920x1080?
Thanks
===============================

Daniele,

Interestingly Craig Anderson used my original ideas for CLUTs, and my CLUTs
work with some of his software.  The basic CLUT is a 100 (wide) by 256
(tall) 24-bit .BMP file, where the horizontal mapping is the selected
thermal channel -60C to +39C, and the vertical mapping is the brightness
channel 0..255.  You can add whatever colour you want for each combination
of temperature and brightness.  There are downloads from the GeoSatSignal
Web page:

  https://www.satsignal.eu/software/geosatsignal.htm

Look for the name: " Ton Lindemann".

Remapping:  the quickest solution would be to use the 2560 x 1920 mapping,
and crop afterwards in your favourite image processing software.  I could
perhaps add 1080 x 1920 as an extra option later.

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







Group subscription poll #poll-notice

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

The subscription for this group will be due at some point. There is the option of downgrading to a free group, but there will be a $220/year charge should we wish to retain features such as a Files section, and a Photos section which we currently enjoy as a Premium group (it was free to start with). There's a full feature list here:

https://groups.io/static/compare

My feeling is that the features of a Premium level are worthwhile, so I wonder whether you agree? We have over 800 members, so if even a small proportion of those chipped in a small amount (say £/€/$ 5) we could keep the Premium level.

What do you prefer?

Thank you for voting. Results will be available when the poll is closed.



Re: APT-like CLUT for GeoSatSignal and remapping

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

From: Daniele Guardigli

Hello, I'm new to Eumetcast service and related software. Is there any way to get a CLUT like pictures produced by wxtoimg software for apt sats? Is there also a way to change remapping in 1080x1920 intead of 1920x1080?
Thanks
===============================

Daniele,

Interestingly Craig Anderson used my original ideas for CLUTs, and my CLUTs work with some of his software. The basic CLUT is a 100 (wide) by 256 (tall) 24-bit .BMP file, where the horizontal mapping is the selected thermal channel -60C to +39C, and the vertical mapping is the brightness channel 0..255. You can add whatever colour you want for each combination of temperature and brightness. There are downloads from the GeoSatSignal Web page:

https://www.satsignal.eu/software/geosatsignal.htm

Look for the name: " Ton Lindemann".

Remapping: the quickest solution would be to use the 2560 x 1920 mapping, and crop afterwards in your favourite image processing software. I could perhaps add 1080 x 1920 as an extra option later.

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


APT-like CLUT for GeoSatSignal and remapping

Daniele Guardigli
 

Hello, I'm new to Eumetcast service and related software. Is there any way to get a CLUT like pictures produced by wxtoimg software for apt sats? Is there also a way to change remapping in 1080x1920 intead of 1920x1080?
Thanks


Re: Problems with FY-3D python script

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


Re: Problems with FY-3D python script

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
_____________________________________________


Re: Problems with FY-3D python script

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


Re: Problems with FY-3D python script

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


Re: Solar outage.

geojohnt@...
 

David,

Yes, sorry about the RTF - I don't know how I manged to get logs of 'both flavours.'

TW, I got a couple of 12 volt 3 amp mains adaptors from CPC today and the new one for the SR1 runs very much cooler than the old 12 v 2 amp adaptor.

Regards,
John.

+++++++++++++++++++++
 
John,

I had wondered whether the power level was too high, but I don't think so 
at -25 dBm.

Yes, that's why I plot these things.  An offset in days of maximum suggests 
an elevation offset, and one in time an azimuth error (skewed, of course to 
the ecliptic (IIRC)).

Thanks for the text log (but no the RTF one).  I can't see any errors there, 
so perhaps this "not locked" is a sensor error rather than a real issue? 
Would be nice to hear from someone else seeing this error.


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

+++++++++++++++++

-----Original Message-----
From: David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺 via groups.io <david-taylor@...>
To: MSG-1@groups.io
Sent: Wed, 14 Oct 2020 17:13
Subject: Re: [MSG-1] Solar outage.

David,

Normal signal level (SNR?) at that time of day is 13.2 - 13.1 dB.

If you mean Power, then -25.0 dBm.

Interestingly(?) my decrease in SNR was slightly worse by a couple of
decimal points on the day after my closest co-linearity.
Both your WXtrack and Sun Outage Visualiser Simulation agreed on the degree
of co-linearity on both days.
Which might lead one to conclude that my dish elevation is slightly out?
But given that my clear sky SNR with a 1 m dish is usually 13.2 dB +/- 0.1
dB, I don't think there is much wrong with the alignment.
Certainly not enough to adjust the dish to try to gain an extra 0.2 dB SNR.

Attached a screen shot the day after my predicted maximum outage showing
SNR, BS and HVS-1 parameter readings.

And the BS and HVS-1 TC logs for the 6 second period of the SNR showing NO
LOCKED.

Have I said this before(?) I'm beginning to think that this NOT LOCKED
indication every now and again by the SR1 Controller is an anomaly related
to my fairly frequent indication of negative Traffic.

Regards,
John.
==============================







Re: Problems with FY-3D python script

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


Re: Problems with FY-3D python script

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.


Re: Problems with FY-3D python script

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.


Re: Problems with FY-3D python script

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


Re: Problems with FY-3D python script

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


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


Re: Solar outage.

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

David,

Normal signal level (SNR?) at that time of day is 13.2 - 13.1 dB.

If you mean Power, then -25.0 dBm.

Interestingly(?) my decrease in SNR was slightly worse by a couple of decimal points on the day after my closest co-linearity.
Both your WXtrack and Sun Outage Visualiser Simulation agreed on the degree of co-linearity on both days.
Which might lead one to conclude that my dish elevation is slightly out?
But given that my clear sky SNR with a 1 m dish is usually 13.2 dB +/- 0.1 dB, I don't think there is much wrong with the alignment.
Certainly not enough to adjust the dish to try to gain an extra 0.2 dB SNR.

Attached a screen shot the day after my predicted maximum outage showing SNR, BS and HVS-1 parameter readings.

And the BS and HVS-1 TC logs for the 6 second period of the SNR showing NO LOCKED.

Have I said this before(?) I'm beginning to think that this NOT LOCKED indication every now and again by the SR1 Controller is an anomaly related to my fairly frequent indication of negative Traffic.

Regards,
John.
==============================

John,

I had wondered whether the power level was too high, but I don't think so at -25 dBm.

Yes, that's why I plot these things. An offset in days of maximum suggests an elevation offset, and one in time an azimuth error (skewed, of course to the ecliptic (IIRC)).

Thanks for the text log (but no the RTF one). I can't see any errors there, so perhaps this "not locked" is a sensor error rather than a real issue? Would be nice to hear from someone else seeing this error.

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


Re: Solar outage.

geojohnt@...
 

David,

Normal signal level (SNR?) at that time of day is 13.2 - 13.1 dB.

If you mean Power, then -25.0 dBm.

Interestingly(?) my decrease in SNR was slightly worse by a couple of decimal points on the day after my closest co-linearity.
Both your WXtrack and Sun Outage Visualiser Simulation agreed on the degree of co-linearity on both days.
Which might lead one to conclude that my dish elevation is slightly out?
But given that my clear sky SNR with a 1 m dish is usually 13.2 dB +/- 0.1 dB, I don't think there is much wrong with the alignment.
Certainly not enough to adjust the dish to try to gain an extra 0.2 dB SNR.

Attached a screen shot the day after my predicted maximum outage showing SNR, BS and HVS-1 parameter readings. 

And the BS and HVS-1 TC logs for the 6 second period of the SNR showing NO LOCKED.

Have I said this before(?) I'm beginning to think that this NOT LOCKED indication every now and again by the SR1 Controller is an anomaly related to my fairly frequent indication of negative Traffic.

Regards,
John.

+++++++++++++++++++++++++++++ 


John,

I would not expect an "unlocked" event, and I've not monitored in such 
detail.  Is there anything in the TelliCast log suggesting a "real" 
disconnection, or is it maybe a "sensor" error?  The only thing I can wonder 
is whether the gain in the receiver is stepping up, as the total signal 
level (wanted + solar noise) is gradually dropping.  But I don't think the 
total changes enough to matter, and in any case if it was a stepping issue 
you would see that in routine operation.  What is the nominal signal level 
shown by the Ayecka SR1?

Has anyone else seen this?

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


-----Original Message-----
From: David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺 via groups.io <david-taylor@...>
To: msg-1@groups.io
Sent: Mon, 12 Oct 2020 15:53
Subject: Re: [MSG-1] Solar outage.

All,

I don't like that Americanism - but I guess it's shorter than
Sun/satellite/dish co-linearity?

Today was my maximum co-linearity day and I videoed both BS and HVS-1 graphs
along with the SR1 Es/No dial during the whole event.
Of course if I had had Ernst's complete suite of logging graphs that would
have been great, but .....

One interesting event was after I had come out of co-linearity and my SNR
back to previous levels, my SNR then started to increase step by step and
suddenly  there was a sudden NOT LOCKED warning for 6 seconds.
At this time both NE Austrian uplink stations were well inside the - 6 dB
SNR degradation cone.

My TP 1 SNR before co-linearity 13.2 DB.

Around this 'NOT LOCKED event' SNR was:

11:10:35 - 13.2
11:10:50 - 13.3
11:11:04 - 13.4
11:11:18 - 13.5

11:11:22 to 11:11:28 NOT LOCKED.

Yet both BS and HVS-1 Tellicast graphs didn't show any break in data.

Attached screen shot of my predicted outage.
The red line is the 'line of maximum co-linearity,' and NE Austria is 'quite
close.'

Regards,
John Tellick.
============================================



Re: Solar outage.

geojohnt@...
 

David,

Thanks for your comments.

Oooops - data logging!
Sorry, slapped wrists for me.

Since the BS and HVS-1 TC data graphs didn't show a 6 second break in data I'm presuming that this NOT LOCKED SR1 event (and other more brief events I see now and again) are related to the 'negative data Traffic reading' events I get fairly frequently on my SR1 Controller dials - which Ayecka couldn't sort out?

I videoed yesterday's outage again this time also including the SR1 Telnet receiver status readings and need to check both for 'figures' as to when HVS-1 was lost and gained again and for how long.

Attached screen shot of maximum outage yesterday, the the Sun was 0.32 degrees 'below' the satellite according to WXtrack.

HVS-1 is in negative link margin and BS + 1 dB link margin with SR1 SNR 6.9 dB.
After outage TC HVS-1 showed 202 missed packets and 2 recovered, BS showed no missed or recovered packets and SR1 showed no bad frame or bad packet count. 

Yes, I too noticed the the 'outage cone' website had UTC OK but BST 'a year out.'
I will send them a note.

Oh, I'll have a look at my logs for the NOT LOCKED event.

Regards,
John.

++++++++++++++++++++

John,


The outage logging software is all mine, not Ernst (who you likely make a 
better job of it!).  The uplink stations adjust their uplink power to keep 
the output power from the satellite constant, as far as possible, so Austria 
shouldn't come into it (they would surely rely primarily on on-board 
telemetry).

I would not expect an "unlocked" event, and I've not monitored in such 
detail.  Is there anything in the TelliCast log suggesting a "real" 
disconnection, or is it maybe a "sensor" error?  The only thing I can wonder 
is whether the gain in the receiver is stepping up, as the total signal 
level (wanted + solar noise) is gradually dropping.  But I don't think the 
total changes enough to matter, and in any case if it was a stepping issue 
you would see that in routine operation.  What is the nominal signal level 
shown by the Ayecka SR1?

Has anyone else seen this?

The date caption in the plot shows both 2019 and 2020, by the way!

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


-----Original Message-----
From: David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺 via groups.io <david-taylor@...>
To: msg-1@groups.io
Sent: Mon, 12 Oct 2020 15:53
Subject: Re: [MSG-1] Solar outage.

All,

I don't like that Americanism - but I guess it's shorter than
Sun/satellite/dish co-linearity?

Today was my maximum co-linearity day and I videoed both BS and HVS-1 graphs
along with the SR1 Es/No dial during the whole event.
Of course if I had had Ernst's complete suite of logging graphs that would
have been great, but .....

One interesting event was after I had come out of co-linearity and my SNR
back to previous levels, my SNR then started to increase step by step and
suddenly  there was a sudden NOT LOCKED warning for 6 seconds.
At this time both NE Austrian uplink stations were well inside the - 6 dB
SNR degradation cone.

My TP 1 SNR before co-linearity 13.2 DB.

Around this 'NOT LOCKED event' SNR was:

11:10:35 - 13.2
11:10:50 - 13.3
11:11:04 - 13.4
11:11:18 - 13.5

11:11:22 to 11:11:28 NOT LOCKED.

Yet both BS and HVS-1 Tellicast graphs didn't show any break in data.

Attached screen shot of my predicted outage.
The red line is the 'line of maximum co-linearity,' and NE Austria is 'quite
close.'

Regards,
John Tellick.
============================================





Re: Solar outage.

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

All,

I don't like that Americanism - but I guess it's shorter than Sun/satellite/dish co-linearity?

Today was my maximum co-linearity day and I videoed both BS and HVS-1 graphs along with the SR1 Es/No dial during the whole event.
Of course if I had had Ernst's complete suite of logging graphs that would have been great, but .....

One interesting event was after I had come out of co-linearity and my SNR back to previous levels, my SNR then started to increase step by step and suddenly there was a sudden NOT LOCKED warning for 6 seconds.
At this time both NE Austrian uplink stations were well inside the - 6 dB SNR degradation cone.

My TP 1 SNR before co-linearity 13.2 DB.

Around this 'NOT LOCKED event' SNR was:

11:10:35 - 13.2
11:10:50 - 13.3
11:11:04 - 13.4
11:11:18 - 13.5

11:11:22 to 11:11:28 NOT LOCKED.

Yet both BS and HVS-1 Tellicast graphs didn't show any break in data.

Attached screen shot of my predicted outage.
The red line is the 'line of maximum co-linearity,' and NE Austria is 'quite close.'

Regards,
John Tellick.
============================================

John,

The outage logging software is all mine, not Ernst (who you likely make a better job of it!). The uplink stations adjust their uplink power to keep the output power from the satellite constant, as far as possible, so Austria shouldn't come into it (they would surely rely primarily on on-board telemetry).

I would not expect an "unlocked" event, and I've not monitored in such detail. Is there anything in the TelliCast log suggesting a "real" disconnection, or is it maybe a "sensor" error? The only thing I can wonder is whether the gain in the receiver is stepping up, as the total signal level (wanted + solar noise) is gradually dropping. But I don't think the total changes enough to matter, and in any case if it was a stepping issue you would see that in routine operation. What is the nominal signal level shown by the Ayecka SR1?

Has anyone else seen this?

The date caption in the plot shows both 2019 and 2020, by the way!

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

3361 - 3380 of 33410