Dear All,

during the ongoing solar outage season I give Robert Moore a hand
to measure SNR for possible hints regarding his antenna pointing.

I have written the attached CMD script (BETA) for this purpose.
As I have no Novra box and can only run the script with DEBUG
lines or in my head. Especially I do not know whether cmcs.exe
does accept CON as output log file. My script does rely on this!

Can some brave owner of a Novra box please test this (Thorsten)?
Can this very user also confirm that -45dBM is a common Novra
signal strength reported by cmcs for EUMETCast transponder T1
(Novra S300E, 1 m dish, LNB Inverto Black Ultra, cable unknown)?

Thorsten Miglus reports -20dBM (Novra S300N, 1.25m dish, LNB
Inverto Black Ultra, 20m cable length). Difference S300E, S300N?

Can some Windows user explain how to plot more than one day of
solar outage onto the same image with plotSNR.exe (David, John)?

Thanks,
Ernst

... in addition to the above post: If I start plotSNR.exe (with the log file name as parameter)
in a CMD window I sometimes get empty plots and then I get plots as the one attached.
The starting date tab bottom left does not change anything. The smoothing tab
does not work either and the legend at right leaves me rather confused.

This also applies if I take the original logs from 2017 distributed in sub folder DavidTaylor.

Cheers,
Ernst

... after some more experimenting I found the solution for the plotSNR.exe part.
I have to give the files with wildcards. There remains the part of my CMD script
that I cannot test here. The plot files that plotSNR.exe understands have been
made so far in an adventurous way including GNU/Linux as cmcs.exe (among
other unexpected things) only gave WIN specific (?) dates and times in minutes.

Ernst

On 15/10/2022 13:49, Ernst Lobsiger via groups.io wrote:

... after some more experimenting I found the solution for the plotSNR.exe part.
I have to give the files with wildcards. There remains the part of my CMD script
that I cannot test here. The plot files that plotSNR.exe understands have been
made so far in an adventurous way including GNU/Linux as cmcs.exe (among
other unexpected things) only gave WIN specific (?) dates and times in minutes.

Ernst

Ernst,

I think it's even easier than that. Without checking in detail, in my own
tests I have a script:

PUSHD <directory with log files>
XCOPY <remote files>snr*.log .
start <directory with program>\PlotSNR.exe
POPD

The XCOPY is because I collect on one PC and plot on another.

My collection program uses UTC yyyy/mm/dd hh:mm:ss format.

Sorry to be late replying but I've been struggling with Python and a Raspberry
Pi Pico to record temperature, pressure, and humidity.

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

On Sat, Oct 15, 2022 at 07:15 AM, David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺 wrote:

My collection program uses UTC yyyy/mm/dd hh:mm:ss format.

David,

thanks for your explanation. The data Robert Moore collected with
cmcs.exe from his Novra box had timestamps 10/15/2022 11:02
with no seconds (!) and your detection of UnixTimes checking
character 5 (IIRC) would fail anyway ... Well that's Windows:

You use dates like   2017/09/23
Arne had dates like 2017-10-11
My dates show as   15.10.2022
etc. etc.

That's why I used UnixTime again simply counting seconds since
1970/01/01 and I'm very glad that this still works with plotSNR.exe.

After all that's not for me but for Windows users like Robert Moore.

Cheers,
Ernst

Ernst,

find attached my script (snrlog.txt) for collecting SNR values from my Novra boxes.
And one sample file, that can be processed for example with Excel.
The script starts by task scheduler half an hour before the event.
It collects data for about one hour until it terminates.
Sorry, no comments inside the script. Just quick and dirty programming. :-)

Cheers,
Thorsten

On Sat, Oct 15, 2022 at 04:45 PM, Thorsten Miglus wrote:

Sorry, no comments inside the script. Just quick and dirty programming. :-)

Thorsten,

no problem reading this. My problem is rather too much comments
so that todays programmers say: TLDR. Your cmd script shows me:

1.) You have two slightly different Novra 300 receivers. Model guess:
Novra S300N, ip_tp1=192.168.3.100, cmcs reports SNR at token=11
Novra S300E, ip_tp2=192.168.4.100, cmcs reports SNR at token=10

2.) You ran into all the Windows problems I tried to circumvent:
You have to manage "," versus "." as decimal delimiters in SNRs.

3.) Your output will work in a German version of ExCEL but not
with David's program plotSNR.exe that will not understand your
date and time stamps and probably not your ',' delimiter either.


It would help a lot if you could answer these 3 questions below.

A) Could you please confirm my Novra model guess in point 1.)?

B) Robert typically sees -45dBm signal power (LNB same as yours)
but you report -20dBm on David's page. Do you use IF amplifiers?

C) Could you please just test at the CLI for me with this simple
line below that cmcs accepts CON (the "screen") as output file?

C:\Tools\novra\cmcs -ip 192.168.4.100 -pw Novra-S2 -csv1status CON


Thank you for your help,

Ernst

On 15/10/2022 20:17, Ernst Lobsiger via groups.io wrote:

David,
thanks for your explanation. The data Robert Moore collected with
cmcs.exe from his Novra box had timestamps 10/15/2022 11:02
with no seconds (!) and your detection of UnixTimes checking
character 5 (IIRC) would fail anyway ... Well that's Windows:
You use dates like   2017/09/23
Arne had dates like 2017-10-11
My dates show as   15.10.2022
etc. etc.
That's why I used UnixTime again simply counting seconds since
1970/01/01 and I'm very glad that this still works with plotSNR.exe.
After all that's not for me but for Windows users like Robert Moore.
Cheers,
Ernst

Ernst,

Checking the source code for the BDADataEx logger I see:

FormatDateTime ('yyyy/mm/dd hh:nn:ss ', NowUTC)

so with the TBSxxxx seconds should be included.

As Robert uses a Novra box with the "cmcs.exe" software I have no control over the results.

The string in the plotting is decoded as:

2017/10/14 10:50:20 12,6
yyyy mm dd hh mm ss <snr>

the "/" or ":" aren't examined. If that fails (i.e. date/time are invalid), the first string in the line is decoded as UNIX time. If that fails, the line is skipped. If needed, I could accept "10/15/2022 11:02 <snr>". <snr> is accepted with either "." or "," as the decimal separator.

I try to abide by "receive anything", "send correctly".

BTW: when I type "time" I get:

The current time is: 10:13:27.86

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

Ernst,

A) With point 1. you are right.

B) The LNB is connected directly to the Novra box. With
my old 90 cm dish I have seen a signal power like Robert.
Cable length may be shorter than 20 m. Maybe in the range
of 10 m to 15 m. It is a rough estimate. And in Germany
I am located near the center of the beam.

C) This has written a file with the name CON to my SSD.
It is not easy to remove a file with the name CON from a Windows PC.
But Google gave me a solution. :-)

Cheers
Thorsten

On Sun, Oct 16, 2022 at 03:36 AM, Thorsten Miglus wrote:

C) This has written a file with the name CON to my SSD.
It is not easy to remove a file with the name CON from a Windows PC.
But Google gave me a solution. :-)

Thorsten,

sorry for the inconvenience and thanks for your help. So I will
have cmcs.exe to write to a temporary file the way you do it.

Confirming 1.) is a valuable result. Maybe David should make
a note on his web page under:

https://www.satsignal.eu/wxsat/dvb-s2/sr1-mrtg.html#s300n

So the difference between Novra S300N and Novra S300E
seems to be more than just marketing and price tag :-).

The difference of 25dB in signal power still seems extremely big.
I'll try to check what type and length of IF cable Robert uses.

Cheers,
Ernst

David,

I took it for granted that below explanation in message 25863 still holds:

https://groups.io/g/MSG-1/message/25863

<CITE>
Determining whether it's "my" or "your" data format is done by checking character 5 to be a
number (UNIX time) or a non-number ('/' or ':') for a human-readable date (e.g. 2017/10/05).
</CITE>

Now (5 years later and after some possible plotSNR code changes) you explain:

https://groups.io/g/MSG-1/message/33459

<CITE>
The string in the plotting is decoded as:

  2017/10/14 10:50:20 12,6
  yyyy mm dd hh mm ss <snr>

the "/" or ":" aren't examined.  If that fails (i.e. date/time are invalid), the first string in the line is decoded as UNIX time.  If that fails, the line is skipped.  If needed, I could accept "10/15/2022 11:02 <snr>".  <snr> is accepted with either "." or "," as the decimal separator.
</CITE>

This is somewhat wider in scope as it has a chance to decode date
"08.10.2022" or even "10/08/2022" correctly if asking the Windows
registry for local date formats. *PLEASE DO NOT CHANGE ANYTHING!*

I tried Thorsten's format "12.10.2022 10:37:01,61 15,4 14,5"
(two Novra boxes) in plotSNR.exe and got an empty plot.
This already fails in decoding the first string whatever
explanation above is correct. Thorsten also uses Windows
environment variable %time% that is not UTC and that gives
back seconds with decimals that might use '.' or ',' :-).

The Novra cmcs.exe might or might not give date and time
in some Windows set format. In any case I will *not* use
it's date and time (Robert's PC logs no seconds) anymore.


My script always returns UTC stamps and can easily write to a
format plotSNR.exe understands with no code changes at all
(and whatever decoding explanation above is the correct one).

My idea of asking cmcs to write to CON was BAD though ;-(.


Cheers,
Ernst

On 16/10/2022 12:17, Ernst Lobsiger via groups.io wrote:

I tried Thorsten's format "12.10.2022 10:37:01,61 15,4 14,5"
(two Novra boxes) in plotSNR.exe and got an empty plot.
This already fails in decoding the first string whatever
explanation above is correct. Thorsten also uses Windows
environment variable %time% that is not UTC and that gives
back seconds with decimals that might use '.' or ',' :-).

Ernst, Thorsten,

I've updated the PlotSNR.exe program to handle Thorsten's format, but it's
untested.

"12.10.2022 10:37:01,61 15,4 14,5"

It currently looks at the first value - 15.4 - so which should it use - the
first or the second?

https://www.satsignal.eu/software/SolarOutageSNR.zip

Please test and let me know if it's correct. It's using the position of the
strings.

On checking, I do use character 5, but this is now overridden if character 3 is
a period as in Thorsten's data. The decimal seconds are ignored.

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

On 16/10/2022 11:54, Ernst Lobsiger via groups.io wrote:

Confirming 1.) is a valuable result. Maybe David should make
a note on his web page under:

https://www.satsignal.eu/wxsat/dvb-s2/sr1-mrtg.html#s300n
<https://www.satsignal.eu/wxsat/dvb-s2/sr1-mrtg.html#s300n>

So the difference between Novra S300N and Novra S300E
seems to be more than just marketing and price tag :-).

Good idea.
Done!

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

David, Thorsten and All,

There is a much improved BETA2 of the novralog-SNR.cmd attached. It can be started
as is by everyone. There is a :: DEBUG line to make it work using cmcs.exe in a real
setup with a Novra S300N or S300E. Regarding the format of the log file that should
be usable for PlotSNR.exe I have a proposal as well. Already in 2017 my outage logs had
entries from 2 receivers. Thorsten uses 2 entries from his Novra S300 boxes as well. Soon
we will have 3 transponders and one TBS-6909X you can even receive 4 transponders.

My format proposal for SNR log files is (times whenever possible in UTC):

yyyy/mm/dd  HH:MM:SS  snr1  snr2  snr3  snr4  + user specific columns

Everybody must at least use (backward compatibility)

yyyy/mm/dd  HH:MM:SS  snr1

Three more columns must stay reserved for snr2 - snr4

Thorsten already uses 2 of the 4 columns reserved for snr.

As I prefer UnixTime I would e.g. on a TBS-6903 use

yyyy/mm/dd  HH:MM:SS  snr1  snr2  0  0  UnixTime

<cite>
It currently looks at the first value - 15.4 - so which should it use - the
first or the second?
</cite>

David could implement an additional  command line parameter
for PlotSNR.exe that selects the snr column (1 .. 4, default 1)

David could delete the code that checks for UnixTime in the
first column and then reads snr in column 5 (my 2017 format).
I have no problem adapting my stuff. Just thinking out loud ...


Cheers,
Ernst

P.S.
Thorsten, not sure you will test my BETA2 script after the CON disaster :-) ?
I was lucky: The first BETA had an additional BUG and will not work anyway.

The attached log file does not yet have the format proposed above though.

On 17/10/2022 14:37, Ernst Lobsiger via groups.io wrote:

David, Thorsten and All,

There is a much improved BETA2 of the novralog-SNR.cmd attached. It can be started
as is by everyone. There is a :: DEBUG line to make it work using cmcs.exe in a
real
setup with a Novra S300N or S300E. Regarding the format of the log file that should
be usable for PlotSNR.exe I have a proposal as well. Already in 2017 my outage
logs had
entries from 2 receivers. Thorsten uses 2 entries from his Novra S300 boxes as
well. Soon
we will have 3 transponders and one TBS-6909X you can even receive 4 transponders.

My format proposal for SNR log files is (times whenever possible in UTC):

yyyy/mm/dd  HH:MM:SS  snr1  snr2  snr3  snr4  + user specific columns

Everybody must at least use (backward compatibility)

yyyy/mm/dd  HH:MM:SS  snr1

Three more columns must stay reserved for snr2 - snr4

Thorsten already uses 2 of the 4 columns reserved for snr.

As I prefer UnixTime I would e.g. on a TBS-6903 use

yyyy/mm/dd  HH:MM:SS  snr1  snr2  0  0  UnixTime

<cite>
It currently looks at the first value - 15.4 - so which should it use - the
first or the second?
</cite>

David could implement an additional  command line parameter
for PlotSNR.exe that selects the snr column (1 .. 4, default 1)

David could delete the code that checks for UnixTime in the
first column and then reads snr in column 5 (my 2017 format).
I have no problem adapting my stuff. Just thinking out loud ...


Cheers,
Ernst

Ernst,

Program updated to accept your formats. Reading, and plotting, multiple
devices would be too confusing, in my view, and arguably unnecessary.

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

On Mon, Oct 17, 2022 at 07:51 AM, David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺 wrote:

Program updated to accept your formats.

David,

TBH I get problems to follow all the formats around. My idea was not to plot multiple
devices with PlotSNR.exe but to allow for reading SNR.logfiles that contain more
than one device like the ones from Thorsten. But you are perfectly right: In that case
the plot should also indicate what device (column) is displayed. So the small version
of my proposal is just your format and let the user do whatever he wants behind:

yyyy/mm/dd  HH:MM:SS  snr   +   user specific columns

From now on I will always write UnixTime as additional user column and
you can simplify the code! If you want to play around with all sorts of date
and time display versions of Windows this is up to you. But programmers that
write SNR loggers should also know how to write the format exactly as above
if they want their files to be read and displayed by your program PlotSNR.exe.

To make it 100% clear. From now on if I write a line like the one below

yyyy/mm/dd  HH:MM:SS  snr   UnixTime

this means I write the exact Date and Time twice. The first 2 columns
are human readable, UnixTime is used in my own plots that reference
the time axis exactly with the azimuth crossing time of the sun. In the
plots from PlotSNR.exe there is a daily shift due the "equation of time".

Cheers,
Ernst

On 17/10/2022 16:44, Ernst Lobsiger via groups.io wrote:

David,
TBH I get problems to follow all the formats around. My idea was not to plot multiple
devices with PlotSNR.exe but to allow for reading SNR.logfiles that contain more
than one device like the ones from Thorsten. But you are perfectly right: In that case
the plot should also indicate what device (column) is displayed. So the small version
of my proposal is just your format and let the user do whatever he wants behind:
yyyy/mm/dd  HH:MM:SS  snr   +   user specific columns
From now on I will always write UnixTime as additional user column and
you can simplify the code! If you want to play around with all sorts of date
and time display versions of Windows this is up to you. But programmers that
write SNR loggers should also know how to write the format exactly as above
if they want their files to be read and displayed by your program PlotSNR.exe.
To make it 100% clear. From now on if I write a line like the one below
yyyy/mm/dd  HH:MM:SS  snr   UnixTime
this means I write the exact Date and Time twice. The first 2 columns
are human readable, UnixTime is used in my own plots that reference
the time axis exactly with the azimuth crossing time of the sun. In the
plots from PlotSNR.exe there is a daily shift due the "equation of time".
Cheers,
Ernst

Ernst,

I'm happy with the format you suggest:

yyyy/mm/dd HH:MM:SS snr UnixTime

with a /single/ space character between the field. Comma or period both are OK for the decimal separator in the SNR field.

The date/time format has /nothing/ to do with Windows - it's simply what I made my programs write and read. It's the standard to which any data for my plotting program should conform.

Multiple devices could be handled by multiple directories with the SNR files. By the way, the wildcard the program scans for is: snr-log-*.log, if a wildcard isn't otherwise given.

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

On Mon, Oct 17, 2022 at 10:50 AM, David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺 wrote:

with a /single/ space character between the field. Comma or period both are OK for the decimal separator in the SNR field.

The date/time format has /nothing/ to do with Windows - it's simply what I made my programs write and read. It's the standard to which any data for my plotting program should conform.

David,

I only put 2 spaces between for this web post. In Thorsten's logs the date and time field is taken from the Windows 10 environment
(echo %date% %time%) which of course is very country specific. You can take it for granted that all my future loggers use the format

yyyy/mm/dd HH:MM:SS snr UnixTime + maybe more columns (times in UTC, all columns separated with one blank)

and I expect PlotSNR.exe to rely on the first 3 columns only. Thanks for the wildcard "nr-log-*.log" hint too.

Cheers,
Ernst

On 17/10/2022 19:10, Ernst Lobsiger via groups.io wrote:

David,

I only put 2 spaces between for this web post. In Thorsten's logs the date and
time field is taken from the Windows 10 environment
(echo %date% %time%) which of course is very country specific. You can take it
for granted that all my future loggers use the format

yyyy/mm/dd HH:MM:SS snr UnixTime + maybe more columns (times in UTC, all
columns separated with one blank)

and I expect PlotSNR.exe to rely on the first 3 columns only. Thanks for the
wildcard "nr-log-*.log" hint too.

Cheers,
Ernst

Ernst,

Yes, I often put multiple spaces for clarity as well! Really, if PlotSNR was
written as a general purpose program from the start it should be open in
accepting a variety of formats, but original it was written as part of a pair
of programs. Now, with your script, it will be more generally useful, so
thanks for that.

I see why you mention the Windows time format - this is something chosen by the
user and not imposed by Windows. Explained here:


https://winbuzzer.com/2021/08/20/how-to-change-date-and-time-format-in-windows-10-xcxwbt/

but whether that affects the environment variables I don't know. Another issue
is that the logs should be readable anywhere - even in another country where
the decimal separator is different (HI!). So it would be the wrong approach to
assume that the format is always the "Windows" format. I like having the UNIX
time and I will be using your script in the future.

One issue I found this autumn was that the TBS drivers appear to give a zero
SNR once the threshold has been passed, and data is turned off. The Ayecka SR1
doesn't do this, and some TBS drivers don't, but those drivers give a much
higher packet loss rate, sigh!

A most helpful discussion, and one which may benefit other users, too.

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

Ernst,

the result of BETA2:

NovraType=S300N
NovraType=S300E

I can not identify a SNR value within the output.

Output from my script:
10/18/2022 15:51,S300E,00-06-76-05-16-ba,192.168.4.100,,101.000000,Locked,Locked,No Fault,0.00e+00,,14.200000,-22,,0,8264619,

Cheers,
Thorsten