Date   
Re: New to Metop

Alan Sewards
 

Duncan,
The temp_directory is optional and will default to the specified received directory, as is explained in the commented text that follows the line. So it does not matter if it is undefined, although I use it myself for the reason stated.

Best regards - Alan S

On 24/02/2011 12:35 PM, Duncan Edwards wrote:
Geoffrey. Without interupting you i hope and this might mean nothing i
have noticed you have an # in front of your #temp_directory=receiving/tmp

I may be wrong here but surely this will stop the files being sent to
the directory.I am probably wrong so i would verify this with Alan.
Regards Duncan

--
Alan Sewards
email: alan@...
web site: http://asewards.free.fr

Re: New to Metop

David J Taylor
 

Duncan,
The temp_directory is optional and will default to the specified
received directory, as is explained in the commented text that follows
the line. So it does not matter if it is undefined, although I use it
myself for the reason stated.

Best regards - Alan S
Alan,

It may matter that it's not defined. As I understand it, large files will be built up in situ if the "tmp_directory" is not defined, and therefore programs which check for the presence of a file may see the file as being present, even though it is not yet complete. Attempting to process such a file may result in an incomplete or lost image. With "tmp_directory=temp" in the recv.ini file, new data will be built up in the "temp" directory, and only moved to the appropriate \received\ directory when it is complete.

My recommendation therefore is to include, a common line in the recv.ini such as:

[parameters]
tmp_directory=temp

(there will be other lines in the parameters section, of course).

By the way, much of the recv-channels.ini file is commented out - I have now taken to removing those comments to leave a clearer file, and one I find easier to understand. For example, this could be the entire file:

____________________________________
[EPS-10]
target_directory=received\EPS-10

[EPS-15]
target_directory=received\EPS-15

[EPS-18]
target_directory=received\EPS-18

[EUMETSAT Data Channel 1]
target_directory=received\Data Channel 1

[EUMETSAT Data Channel 2]
target_directory=received\Data Channel 2

[EUMETSAT Data Channel 3]
target_directory=received\Data Channel 3

[Info-Channel-1]
target_directory=received

[Info-Channel-2]
target_directory=received\Info-Channel-2

[WWW-Channel]
target_directory=www/eumetsat
____________________________________


(I appreciate that you know this already, but others may not).

Cheers,
David
--
SatSignal software - quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@...

Re: New to Metop

geoffreygee90
 

Alan

Sorry for delay in coming back but I had to go out this morning.

Apologies for my poor description of the situation. You are quite right the second received file which I found is in the c root directory,just below programmes,i.e....C:\received and in it are shown five folders for the Channels 1 to 4 plus EPS-10.

My Metop set up shows for the received files path.................C:\received\EPS-10

No data is coming through.

Best regards..............Geoffrey

Re: New to Metop

geoffreygee90
 

Duncan

Thank you for your two messages.Everything helps and is appreciated, my faith in human nature is much restored by so many offering assistance.

Regards..........................Geoffrey

Re: New to Metop

Alan Sewards
 

Geoffrey,
Thanks for that info. Now, (1) is any data coming through Channels 1-4? And (2), have you removed the RAMdrive that you were trying? If no to (1) and yes to (2), have you changed the file_database_directory in recv.ini to point to the receiving folder? (It would have been set up to point to the RAMdisk when you were using that.)
The received directory seems to be correctly set up and so is METOP, so we have to work back up the chain to find out where the data loss is occurring.

Best regards - Alan S

On 24/02/2011 5:49 PM, Geoffrey Gee wrote:
Alan

Sorry for delay in coming back but I had to go out this morning.

Apologies for my poor description of the situation. You are quite right the
second received file which I found is in the c root directory,just below
programmes,i.e....C:\received and in it are shown five folders for the
Channels 1 to 4 plus EPS-10.

My Metop set up shows for the received files
path.................C:\received\EPS-10

No data is coming through.

Best regards..............Geoffrey



------------------------------------

Unsure what a term means? Check the Glossary at:
http://www.satsignal.eu/wxsat/glossary.htm
Yahoo! Groups Links



--
Alan Sewards
email: alan@...
web site: http://asewards.free.fr

Re: New to Metop

geoffreygee90
 

Alan

Thanks again......Files for Channels 1-4 show data 24/02/11................Nothing in file for EPS-10.................ramdisk all removed.

Rec.ini shows..............#file_database_directory=receiving /tmp

Regards.....Geoffrey

Re: New to Metop

Alan Sewards
 

Geoffrey,
Good, we are making progress if you have data files arriving in Channels 1-4. That shows that data is arriving and being processed into the right channels, which means the receiver and Tellicast software are working. There are only two reasons I can see that prevent the [EPS-10] data from coming through: (1) that it has not been activated by Eumetcast, and (2) the PID is not set in Setup4PC. We will assume that Eumetcast have done their part (although I have known them telling me I was activated and I wasn't), leaving the Sky Star software. The only way that data can be coming in with some missing is if the PID in Sky Star for that data is not set. Right-click on the green orb in the tray and select Setup4PC. Click on Data Services. Uncheck the box in the PID List labelled Hexadecimal, and verify that 510 appears in the list. If it does not, type 510 in the box under Hexadecimal and click Insert, when it should appear in the list. Then OK and Close to leave. You can then try and see if data is coming in to the EPS-10 received folder, but be aware, the data does not come in continuously, there are gaps of a few minutes between data dumps, so if nothing happens, wait say ten minutes to be sure.
Regarding the recv.ini entry for the receiving folder: the # at the start of the line indicates that the line is to be treated as a comment and the line is ignored as an instruction. That means that the receiving folder is undefined but the fact that you are receiving Channels 1-4 means that the software has found a place for receiving and knows how to get there. If you want the folder defined, just remove the # at the beginning of the line.

Best regards - Alan S

On 24/02/2011 7:18 PM, Geoffrey Gee wrote:


Alan

Thanks again......Files for Channels 1-4 show data
24/02/11................Nothing in file for EPS-10.................ramdisk
all removed.

Rec.ini shows..............#file_database_directory=receiving /tmp

Regards.....Geoffrey



------------------------------------

Unsure what a term means? Check the Glossary at:
http://www.satsignal.eu/wxsat/glossary.htm
Yahoo! Groups Links



--
Alan Sewards
email: alan@...
web site: http://asewards.free.fr

New to Metop

geoffreygee90
 

Alan
After 20 mins.......... No data in EPS-10 other channels still receiving data.

Checked PID's as instructed. 510 is shown.

See below Eumetsats confirmation of what I should be able to receive.


Best regards............Geoffrey











Notification No : 300008749

Dear Geoffrey N. Gee,

Subject : 300008749 Licence Renewal

I am pleased to inform you that we have activated the services that you
have requested for.

Please see below the complete list of services to your account :
Services:
ears-avhrr
EPS-METOP-ASCA-L2
EPS-METOP-ATOV-L2
EPS-METOP-AVHR-L1
EPS-METOP-IASI-L2
EPS-NOAA-ATOV-L2
EPS-NOAA-AVHR-L1
EPS-SERVICE
High Rate SEVIRI - 15 min
High Rate SEVIRI - 30 min
High Rate SEVIRI - 3 hourly
High Rate SEVIRI - 60 min
High Rate SEVIRI - 6 hourly
Low Rate SEVIRI - 30 min
Low Rate SEVIRI - 3 hourly
Low Rate SEVIRI - 60 min
Low Rate SEVIRI - 6 hourly
Foreign Satellite Data
Hourly Foreign Satellite Data
Meteorological Products - 15min
msg-lrit-mpef-eur
Meteorological Products - 1 to 3 hourly
msg-rss-lrit-mpef
msg-rss-lrit-mpef-low
HRI - IODC - 6-hourly
SAF-LSA-afr
SAF-LSA-afr-15m
SAF-LSA-eur
SAF-LSA-eur-15m
SAF-LSA-sam
SAF-LSA-sam-15m
SAF-O3M-eur
Ocean + Sea-ice SAF
OSI-SAF Data Europe
UNS-general
www-eumetsat

Please do not hesitate to contact us if you experience any technical
issues with reception of the data.

Regards,

Pamela Sch�bel-Pattiselanno




User Service Helpdesk
EUMETSAT User Service
Tel: +49 6151 807 377
Fax: +49 6151 807 379
Email: ops@...

Re: New to Metop

Ian Deans
 

Alan and Geoffrey,

To avoid too many mails and confusion ( too many cooks etc ) I have remained away from this thread but it is worth mentioning that Geoffrey did get up and running with Metop after sorting out the settings in Metop Manager. However without a RAMDisk he was experiencing a number of lost chunks. It is almost certain that the present loss of data is due to a misconfiguration with the RAMdisk.

Regards
Ian.

-----Original Message-----
From: Geoffrey Gee
Sent: Thursday, February 24, 2011 8:32 PM
To: MSG1 Yahoo Group
Subject: [MSG-1] New to Metop

Alan
After 20 mins.......... No data in EPS-10 other channels still receiving
data.

Checked PID's as instructed. 510 is shown.

See below Eumetsats confirmation of what I should be able to receive.


Best regards............Geoffrey

Re: New to Metop

Alan Sewards
 

Ian and Geoffrey,
At this point I am out of ideas. Data is coming in on some channels, so the receiver chain is working as is the Tellicast software. If one channel is not producing data it can only be because the data is not being sent or something required locally is not set. I can't think of anything other than the PID and that has been checked.
I had not realized that successful reception of METOP had occurred - I can't see how with the number of misconfigurations of the received folders recently uncovered! But if that is the case it should suffice to go back to the settings in recv.ini and recv.channels.ini that worked now that the RAMdisk has been removed.

Best regards - Alan (signing off for tonight)

On 24/02/2011 10:00 PM, Ian Deans wrote:
Alan and Geoffrey,

To avoid too many mails and confusion ( too many cooks etc ) I have remained
away from this thread but it is worth mentioning that Geoffrey did get up
and running with Metop after sorting out the settings in Metop Manager.
However without a RAMDisk he was experiencing a number of lost chunks. It
is almost certain that the present loss of data is due to a misconfiguration
with the RAMdisk.

Regards
Ian.

-----Original Message-----
From: Geoffrey Gee
Sent: Thursday, February 24, 2011 8:32 PM
To: MSG1 Yahoo Group
Subject: [MSG-1] New to Metop

Alan
After 20 mins.......... No data in EPS-10 other channels still receiving
data.

Checked PID's as instructed. 510 is shown.

See below Eumetsats confirmation of what I should be able to receive.


Best regards............Geoffrey















------------------------------------

Unsure what a term means? Check the Glossary at:
http://www.satsignal.eu/wxsat/glossary.htm
Yahoo! Groups Links



--
Alan Sewards
email: alan@...
web site: http://asewards.free.fr

Re: Getting MRTG to work

Ulrich G. Kliegis
 

David, it needn't be you to reply, maybe some of the other MRTG-ops can direct me too.

I created a first basic configuration file today, and - since I don't intend to monitor the ethernet
traffic of that PC right now, commented-out all line that deal with the ethernet interface -
realizing that an IP address deliberately given by the DHCP-server may cause additional efforts
- or will the mrtg mechanism look up the address each time the PC is restarted?

Anyway, not the topic right now, but rather this: Here ist the top of the DVB-related part of the
config file generated by the cfgmaker routine:

### Interface 131074 >> Descr: 'TechniSat-DVB-PC-TV-Star-PCI' | Name: '' | Ip:
'192.168.238.238' | Eth: '00-d0-d7-0f-ee-a5' ###

Target[windbuedel_131074]: 131074:public@windbuedel:
SetEnv[windbuedel_131074]: MRTG_INT_IP="192.168.238.238"
MRTG_INT_DESCR="TechniSat-DVB-PC-TV-Star-PCI"
MaxBytes[windbuedel_131074]: 12500000
Title[windbuedel_131074]: Traffic Analysis for 131074 -- WINDBUEDEL
PageTop[windbuedel_131074]: <h1>Traffic Analysis for 131074 -- WINDBUEDEL</h1> ...

windbuedel is the PC-name. I saw in your examples, David, that you use a nomenclature like
Target[windbuedel_dvb]. Is this preferable (except for readability)? And if so, where is the place
to tell mrtg that 131074 = dvb?

Sorry for my probably rather trivial questions, this is a new field for me. So, thanks in advance
for all helpful advice!

Cheers,
U.


An: <MSG-1@...>
Von: "David J Taylor" <gm8arv@...>
Datum: Thu, 24 Feb 2011 08:08:58 -0000
Betreff: Re: [MSG-1] Getting MRTG to work
Antwort an: MSG-1@...

Ulrich, my apologies in that with all the effort put into the PHP
pages, I have rather neglected the plain HTML pages, but I've now
added a couple of links which may make it easier to find the extended
MRTG information. Too many ideas, too little time!

Re: Getting MRTG to work

David J Taylor
 

David, it needn't be you to reply, maybe some of the other MRTG-ops can direct me too.

I created a first basic configuration file today, and - since I don't intend to monitor the ethernet
traffic of that PC right now, commented-out all line that deal with the ethernet interface -
realizing that an IP address deliberately given by the DHCP-server may cause additional efforts
- or will the mrtg mechanism look up the address each time the PC is restarted?
You can use the loopback address (127.0.0.1) or PC name instead of the numeric IP address:

Target[Alta-LAN]: 11:public@....0.1

Target[Alta-LAN]: 11:public@Alta

The loopback address doesn't look as elegant, but is most likely to stay the same!

The interface/network number (11) may vary if you change the configuration (e.g. add Wi-Fi dongle). Once the configuration is set, I tend to reboot, and run cfgmaker, to see what the network numbers actually are.

Anyway, not the topic right now, but rather this: Here ist the top of the DVB-related part of the
config file generated by the cfgmaker routine:

### Interface 131074 >> Descr: 'TechniSat-DVB-PC-TV-Star-PCI' | Name: '' | Ip:
'192.168.238.238' | Eth: '00-d0-d7-0f-ee-a5' ###

Target[windbuedel_131074]: 131074:public@windbuedel:
SetEnv[windbuedel_131074]: MRTG_INT_IP="192.168.238.238"
MRTG_INT_DESCR="TechniSat-DVB-PC-TV-Star-PCI"
MaxBytes[windbuedel_131074]: 12500000
Title[windbuedel_131074]: Traffic Analysis for 131074 -- WINDBUEDEL
PageTop[windbuedel_131074]: <h1>Traffic Analysis for 131074 -- WINDBUEDEL</h1> ...

windbuedel is the PC-name. I saw in your examples, David, that you use a nomenclature like
Target[windbuedel_dvb]. Is this preferable (except for readability)? And if so, where is the place
to tell mrtg that 131074 = dvb?

Sorry for my probably rather trivial questions, this is a new field for me. So, thanks in advance
for all helpful advice!

Cheers,
U.
I try and keep a consistent set of names across the PCs here, so I would use:

Target[Alpha_DVB]: 16:public@....0.1

Target[Bravo_DVB]: 14:public@....0.1

Target[Charlie_DVB]: 11:public@....0.1

and once I know the DVB network number I tend to use copy-and-paste from an existing config such as:

________________________________________________________
#---------------------------------------------------------------
# PC Alta DVB World USB box
#---------------------------------------------------------------

Target[Alta_DVB]: 16:public@Alta
MaxBytes[Alta_DVB]: 12500000
Options[Alta_DVB]: unknaszero, growright, noo
Title[Alta_DVB]: EUMETCast - Eurobird-9 satellite on DVB World USB box
PageTop[Alta_DVB]: <H2>EUMETCast - PC Alta - DVB World USB box
</H2>
<TABLE>
<TR><TD>Interface:</TD><TD>DVB World USB box</TD></TR>
<TR><TD>Max Speed:</TD><TD>12.5? MBytes/s</TD></TR>
</TABLE>
________________________________________________________


The network number is the most awkward to get, as cfgmaker will list all sorts of artificial interfaces as well as the real ones! Tunneling, Toredo and all sorts. With experience, you get to spot the real ones, but sometimes using a ROUTE PRINT command from DOS will help, as there is a list of interfaces at the start of its output. That's the way to find the number for the Target line (such as 16 in the Alta example above). If you get a plot of zeroes you know you may have the wrong number!

Cheers,
David
--
SatSignal software - quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@...

Re: Getting MRTG to work

Ulrich G. Kliegis
 

An: <MSG-1@...>
Von: "David J Taylor" <gm8arv@...>
Datum: Fri, 25 Feb 2011 07:45:27 -0000
Betreff: Re: [MSG-1] Getting MRTG to work
Antwort an: MSG-1@...

If you
get a plot of zeroes you know you may have the wrong number!
Sounds like fundamental experience... :)

Thank you so much for the detailed background info, I'll try to do a few steps
of my own then...

Cheers,

U.

Re: Getting MRTG to work

David J Taylor
 

If you
get a plot of zeroes you know you may have the wrong number!
Sounds like fundamental experience... :)
"been there .. done that" as we say!

Thank you so much for the detailed background info, I'll try to do a few steps
of my own then...

Cheers,

U.
Have fun!

Cheers,
David
--
SatSignal software - quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@...

Re: New to Metop

geoffreygee90
 

Alan and Ian

Many thanks for yesterdays mails, your help is much appreciated and I am sorry to be such a nuisance.

Following your comment, Alan, and as a double check I have this morning sent an e-mail to Eumetsat to see if I am still registered for Metop.

Best regards...........Geoffrey

Re: Getting MRTG to work

Ulrich G. Kliegis
 

sometimes using a ROUTE PRINT command from DOS will help, as there is
a list of interfaces at the start of its output.
David,
for this machine here (not the receiver) the interface list looks like this:

C:&#92;WINDOWS&#92;system32>route print
=============================================================
Schnittstellenliste
0x1 ........................... MS TCP Loopback interface
0x2 ...00 11 2f db ff c7 ...... Marvell Yukon 88E8001/8003/8010 PCI Gigabit Ethe
rnet Controller - Paketplaner-Miniport

So, I guess, the number right of the 0x ist the interface number, right?

Cheers,
U.

Re: Getting MRTG to work

David J Taylor
 

David,
for this machine here (not the receiver) the interface list looks like this:

C:&#92;WINDOWS&#92;system32>route print
=============================================================
Schnittstellenliste
0x1 ........................... MS TCP Loopback interface
0x2 ...00 11 2f 00 00 c7 ...... Marvell Yukon 88E8001/8003/8010 PCI Gigabit Ethe
rnet Controller - Paketplaner-Miniport

So, I guess, the number right of the 0x ist the interface number, right?

Cheers,
U.
Yes, they are hex numbers, so 0x2 hex (also 2 decimal) is the interface number for your 1Gb/s networking card. On the Windows XP PC I'm using right now, I get:

Interface List
0x1 ........................... MS TCP Loopback interface
0x2 ...00 80 56 00 00 08 ...... VMware Virtual Ethernet Adapter for VMnet8
0x3 ...00 80 56 00 00 01 ...... VMware Virtual Ethernet Adapter for VMnet1
0x10005 ...00 00 00 00 00 e0 ...... Intel(R) 82566DC Gigabit Network Connection

so 10005 (hex) is the network card number, which is 65541 (decimal). I used the Windows calculator to convert. Checking my mrtg.cfg file, I see a line:

Target[Narvik]: 65541:public@....0.1

By the way, I changed the MAC addresses before publication. Checking on the Windows-7 PC Alta we used earlier, which has a DVB World box attached (and this seems to give the results in decimal, not hex).

Interface List
16...00 00 00 00 08 08 ......DVB Net ETAdapter
11...20 cf 30 00 00 49 ......Realtek PCIe GBE Family Controller
1...........................Software Loopback Interface 1
12...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
13...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
15...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2

and we have in the mrtg.cfg file:

Target[Alta_DVB]: 16:public@Alta

Target[Alta]: 11:public@....0.1

You can see I used both versions of the IP address!

Cheers,
David
--
SatSignal software - quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@...

Re: Getting MRTG to work

Giuseppe Cico
 

On Fri, February 25, 2011 08:45, David J Taylor wrote:
David, it needn't be you to reply, maybe some of the other MRTG-ops can

.....
You can use the loopback address (127.0.0.1) or PC
name instead of the
numeric IP address:

Target[Alta-LAN]: 11:public@....0.1

Target[Alta-LAN]: 11:public@Alta

The loopback
address doesn't look as elegant, but is most likely to stay
the
same!

The interface/network number (11) may vary if
you change the configuration
(e.g. add Wi-Fi dongle). Once the
configuration is set, I tend to reboot,
and run cfgmaker, to
see what the network numbers actually are.

Anyway, not the topic right now, but rather this: Here ist the top of
the DVB-related part of the
config file
generated by the cfgmaker routine:

###
Interface 131074 >> Descr: 'TechniSat-DVB-PC-TV-Star-PCI' | Name: ''

| Ip:
'192.168.238.238' | Eth:
'00-d0-d7-0f-ee-a5' ###

Target[windbuedel_131074]: 131074:public@windbuedel:
...

Ulrich,
you can solve the "131704"
problem using IP address as the reference for MRTG by
changing the line

Target[windbuedel_131074]:
131074:public@windbuedel:

to

Target[windbuedel_131074]: /192.168.238.238:public@windbuedel:

and then any of "windbuedel_131074" to
"windbuedel_DVB" or anything you want; it's just a name:

Target[windbuedel_DVB]: /192.168.238.238:public@windbuedel:
SetEnv[windbuedel_DVB]: MRTG_INT_IP="192.168.238.238"
....

Ciao

Giuseppe






[Non-text portions of this message have been removed]

Re: Getting MRTG to work

Ulrich G. Kliegis
 

Giuseppe,

mille grazie, this solves a couple of present and upcoming questions.

Cheers,
U.


An: MSG-1@...
Von: "Giuseppe Cico" <giuseppe.cico@...>
Datum: Fri, 25 Feb 2011 15:57:02 +0100 (CET)
Betreff: Re: [MSG-1] Getting MRTG to work
Antwort an: MSG-1@...

Ulrich,
you can solve the "131704"
problem using IP address as the reference for MRTG by
changing the line

Target[windbuedel_131074]:
131074:public@windbuedel:

to

Target[windbuedel_131074]: /192.168.238.238:public@windbuedel:

and then any of "windbuedel_131074" to
"windbuedel_DVB" or anything you want; it's just a name:

Target[windbuedel_DVB]: /192.168.238.238:public@windbuedel:
SetEnv[windbuedel_DVB]: MRTG_INT_IP="192.168.238.238"

Re: Getting MRTG to work

Giuseppe Cico
 

Glad for being helpful; bitte.
Now I have a problem to solve,
since I answered other questions in advance... I MUST think about
next lottery numbers!!!!

Ciao

Giuseppe


On Fri, February 25, 2011 17:13, Ulrich G. Kliegis wrote:
Giuseppe,

mille grazie, this solves a couple
of present and upcoming questions.

Cheers,
U.


An: MSG-1@...
Von: "Giuseppe Cico" <giuseppe.cico@...>
Datum: Fri, 25 Feb 2011 15:57:02 +0100 (CET)
Betreff:
Re: [MSG-1] Getting MRTG to work
Antwort an:
MSG-1@...

Ulrich,
you
can solve the "131704"
problem using IP address as the reference for MRTG by
changing the line

Target[windbuedel_131074]:
131074:public@windbuedel:

to

Target[windbuedel_131074]: /192.168.238.238:public@windbuedel:

and then any of
"windbuedel_131074" to
"windbuedel_DVB" or anything you want; it's just a name:

Target[windbuedel_DVB]:
/192.168.238.238:public@windbuedel:
SetEnv[windbuedel_DVB]:
MRTG_INT_IP="192.168.238.238"





[Non-text portions of this message have been removed]