Date   

Re: Ayecka SR1 controller

Philip Robinson
 

Hi Daviid
I tried reinstalling java twice same result.

I will probably  try downloading winrar and associate file with that, see if that works

Anyone else have any ideas

Philip


Re: Ayecka SR1 controller

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

Hi David or anyone
I right click properties on the sr1Control.jar there is nothing that indicates block or unblock.
I right click or double click and nothing happens. I have no open with command just open.

the (assoc)command file is .jar=Java(TM)PlatformSEbinary


My java file is in C:\Program Files(x86)\Java\jre1.8.0_191\bin\javaw.exe So in the registry do i add \ "-jar"%1"%* at the end

or do i need another piece of software like winrar or 7zip to open a .jar file

I am just a bit confused ( as usual )

If i have to go in to the registry jarfile is in several places. I am a bit lost in there.. Not sure in the registry where to put the jarfile=>shell=>command:"C:\Program Files(x86)\Java\jre1.8.0_191\bin\javaw.exe

i didnt have this prob on my other machine which i did have winrar installed

I want to keep this new computer as clean as possible and do not want to add software if not needed.. I have a 2TB SSD drive with 16mb ram. My other machine was becoming so slow thought it time to upgrade. Not looking forward to adding all the new software but i am sure i will get there.
help please:-)

Philip
==============================

Philip,

Best guess - re-install Java. It should set up the required entries.

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


Re: Ayecka SR1 controller

Philip Robinson
 

Hi David or anyone
I right click properties on the sr1Control.jar there is nothing that indicates block or unblock.
I right click or double click and nothing happens.  I have no open  with  command just open.

the (assoc)command file is  .jar=Java(TM)PlatformSEbinary


My java file is in   C:\Program Files(x86)\Java\jre1.8.0_191\bin\javaw.exe                So in the registry  do i add   \ "-jar"%1"%*      at the end

or do i need another piece of software like winrar or 7zip to open a .jar file

I am just a bit confused ( as usual )

If i have to go in to the registry jarfile is in several places. I am a bit lost in there.. Not sure in the registry where to put  the jarfile=>shell=>command:"C:\Program Files(x86)\Java\jre1.8.0_191\bin\javaw.exe  

i didnt have this prob on my other machine which i did have winrar installed

I want to keep this new computer as clean as possible and do not want to add software if not needed.. I have a 2TB SSD drive with 16mb ram. My other machine was becoming so slow thought it time to upgrade. Not looking forward to adding all the new software but i am sure i will get there.
help please:-)

Philip


Re: AVHRR Manager

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

David I just do a manual download ('save page') at https://celestrak.com/NORAD/elements/weather.txt whenever AVHRR Manager warns me, or if I think of it before. I don't seem to have problems with this file - though I'm quite good at not seeing problems.
AVHRR issue sorted out, once again with Graham's help.

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

Glad to hear it's resolved, Robert.
What was the problem, in case I should add it to the FAQ?

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


Re: Ayecka SR1 controller

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

Hi,
I am starting the process of moving all my software on to a faster windows10 machine. I clicked on Ayreka SR1-console2014-10-6.zip. It opened up and have the sr1.cmd and SR1Control.jar executable file. When i double click on the SR1Control executable file nothing happens. I have Java installed.
On my older machine it ran perfectly. I am not sure what i did on my older machine to get it to open, as its a very useful tool when i start to install the rest of my satellite software.
Any help please.
Philip
=============================================

Philip,

Double-clicking on the .JAR file should be enough. Perhaps check that it's not right-click, Properties, Unblocked?

Does .JAR have the correct association? Here using assoc (command-line program) I see:

.jar=jarfile

and from the registry editor:

jarfile => shell => command:
"C:\Program Files\Java\jre1.8.0_191\bin\javaw.exe" -jar "%1" %*

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


Ayecka SR1 controller

Philip Robinson
 

Hi, 
I am starting the process of moving all my software on to  a faster windows10 machine. I clicked on Ayreka SR1-console2014-10-6.zip. It opened up and have the sr1.cmd and SR1Control.jar executable file. When i double click on the SR1Control executable file nothing happens. I have Java installed.
On my older machine it ran perfectly. I am not sure what i did on my older machine to get it to open, as its a very useful tool when i start to install the  rest of my satellite software.
Any help please.
Philip


Re: AVHRR Manager

Robert Moore
 

 
 
David I just do a manual download ('save page') at https://celestrak.com/NORAD/elements/weather.txt whenever AVHRR Manager warns me, or if I think of it before. I don't seem to have problems with this file - though I'm quite good at not seeing problems.
AVHRR issue sorted out, once again with Graham's help.

Robert


Robert
Telephone and fax: 44 (0) 1352 714456
________________________________________


Robert,

You seem to have a very large delay in your system.  My 1030 NOAA19 logs as:

10:38:05  10:37  10:30    7.2  + 3  avhrr_20181025_103000_noaa19.hrp.bz2

so you are (13:08 - 10:38) behind me, about 2.5 hours.  This /might/ suggest
a large number of unprocessed files, or simply that you only just started
the program!

You should see segments on the NOAA-19, Metop-A or Metop-B tabs immediately
after processing.  I don't know why you aren't seeing that, but I would
check that your Kepler data is not too far out of date.  On the Ground
Stations tab, look in the Kepler status box.

Be aware that the Kepler data from Space-Track can sometimes have incorrect
orbit number at epoch  information, which can mess things up.  Following a
suggestion from Thorsten, I now use Kepler data direct from EUMETSAT.  I'll
attach an example script, but it need wget installed, and you will need to
edit the directory names to suit your system.  It's worked reliably here for
several months.  My thanks to Thorsten for providing the script, and any
errors through changes are mine!

Cheers,
David


Re: AVHRR Manager

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

I have data in Data Channel 1, AVHRR Manager is pointed at it and can see it, there's a lot of processing activity on the Manager, but nothing to be seen as a result. Here's a recent section of the AVHRR log:

3:08:38 11:41 11:35 6.7 +21 AVHR_HRP_00_M02_20181025113500Z_20181025113600Z_N_O_20181025113709Z.bz2
13:08:40 11:42 11:36 6.8 +22 AVHR_HRP_00_M02_20181025113600Z_20181025113700Z_N_O_20181025114009Z.bz2
13:08:41 11:43 11:37 6.8 +23 AVHR_HRP_00_M02_20181025113700Z_20181025113800Z_N_O_20181025114009Z.bz2
13:08:42 11:44 11:38 6.9 +24 AVHR_HRP_00_M02_20181025113800Z_20181025113900Z_N_O_20181025114009Z.bz2
13:08:43 11:45 11:39 7.0 +25 AVHR_HRP_00_M02_20181025113900Z_20181025114000Z_N_O_20181025114239Z.bz2
13:08:44 11:47 11:40 7.2 +26 AVHR_HRP_00_M02_20181025114000Z_20181025114100Z_N_O_20181025114239Z.bz2
13:08:45 11:48 11:41 7.2 +27 AVHR_HRP_00_M02_20181025114100Z_20181025114200Z_N_O_20181025114239Z.bz2
13:08:46 10:37 10:30 7.2 0 avhrr_20181025_103000_noaa19.hrp.bz2
13:08:47 10:38 10:31 7.2 + 1 avhrr_20181025_103100_noaa19.hrp.bz2
13:08:49 10:39 10:32 7.3 + 2 avhrr_20181025_103200_noaa19.hrp.bz2
13:08:50 10:40 10:33 7.3 + 3 avhrr_20181025_103300_noaa19.hrp.bz2
13:08:51 10:41 10:34 7.4 + 4 avhrr_20181025_103400_noaa19.hrp.bz2
13:08:52 10:42 10:35 7.5 + 5 avhrr_20181025_103500_noaa19.hrp.bz2
13:08:53 10:42 10:36 6.5 + 6 avhrr_20181025_103600_noaa19.hrp.bz2
13:08:54 10:43 10:37 6.6 + 7 avhrr_20181025_103700_noaa19.hrp.bz2
13:08:55 10:44 10:38 6.6 + 8 avhrr_20181025_103800_noaa19.hrp.bz2

Can't see what I'm doing wrong!

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

Robert,

You seem to have a very large delay in your system. My 1030 NOAA19 logs as:

10:38:05 10:37 10:30 7.2 + 3 avhrr_20181025_103000_noaa19.hrp.bz2

so you are (13:08 - 10:38) behind me, about 2.5 hours. This /might/ suggest a large number of unprocessed files, or simply that you only just started the program!

You should see segments on the NOAA-19, Metop-A or Metop-B tabs immediately after processing. I don't know why you aren't seeing that, but I would check that your Kepler data is not too far out of date. On the Ground Stations tab, look in the Kepler status box.

Be aware that the Kepler data from Space-Track can sometimes have incorrect orbit number at epoch information, which can mess things up. Following a suggestion from Thorsten, I now use Kepler data direct from EUMETSAT. I'll attach an example script, but it need wget installed, and you will need to edit the directory names to suit your system. It's worked reliably here for several months. My thanks to Thorsten for providing the script, and any errors through changes are mine!

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


AVHRR Manager

Robert Moore
 

I have data in Data Channel 1, AVHRR Manager is pointed at it and can see it, there's a lot of processing activity on the Manager, but nothing to be seen as a result. Here's a recent section of the AVHRR log:

3:08:38  11:41  11:35    6.7  +21  AVHR_HRP_00_M02_20181025113500Z_20181025113600Z_N_O_20181025113709Z.bz2
13:08:40  11:42  11:36    6.8  +22  AVHR_HRP_00_M02_20181025113600Z_20181025113700Z_N_O_20181025114009Z.bz2
13:08:41  11:43  11:37    6.8  +23  AVHR_HRP_00_M02_20181025113700Z_20181025113800Z_N_O_20181025114009Z.bz2
13:08:42  11:44  11:38    6.9  +24  AVHR_HRP_00_M02_20181025113800Z_20181025113900Z_N_O_20181025114009Z.bz2
13:08:43  11:45  11:39    7.0  +25  AVHR_HRP_00_M02_20181025113900Z_20181025114000Z_N_O_20181025114239Z.bz2
13:08:44  11:47  11:40    7.2  +26  AVHR_HRP_00_M02_20181025114000Z_20181025114100Z_N_O_20181025114239Z.bz2
13:08:45  11:48  11:41    7.2  +27  AVHR_HRP_00_M02_20181025114100Z_20181025114200Z_N_O_20181025114239Z.bz2
13:08:46  10:37  10:30    7.2    0  avhrr_20181025_103000_noaa19.hrp.bz2
13:08:47  10:38  10:31    7.2  + 1  avhrr_20181025_103100_noaa19.hrp.bz2
13:08:49  10:39  10:32    7.3  + 2  avhrr_20181025_103200_noaa19.hrp.bz2
13:08:50  10:40  10:33    7.3  + 3  avhrr_20181025_103300_noaa19.hrp.bz2
13:08:51  10:41  10:34    7.4  + 4  avhrr_20181025_103400_noaa19.hrp.bz2
13:08:52  10:42  10:35    7.5  + 5  avhrr_20181025_103500_noaa19.hrp.bz2
13:08:53  10:42  10:36    6.5  + 6  avhrr_20181025_103600_noaa19.hrp.bz2
13:08:54  10:43  10:37    6.6  + 7  avhrr_20181025_103700_noaa19.hrp.bz2
13:08:55  10:44  10:38    6.6  + 8  avhrr_20181025_103800_noaa19.hrp.bz2

Can't see what I'm doing wrong!

Robert


Re: Sizing of the Discs

Graham Woolf
 

Hi

Just to add my input

I take all three services and all processed on one PC

I dont use a RAM disk at all apart from placing the animations from MSG Animator on one and I have a separate ramdisk where Sentinel processing is done

Apart from that  the BAS, HVS and HVS2 all go to separate hard drives and have run without problems for quite a while now and I do take a lot of the BAS data too

Regards

Graham


Re: Sizing of the Discs

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

David,

As a matter of fact the Basic Service is sometimes even more the
problem for a system without RAMDISK. This is because we have much
more parallel streams comming in. So the heads of a HDD must move
quickly between the different open temp files building up. On HVS
(up to now) files are sent more one after the other which eases
the workload of the HDD.

The problem you face with with bad weather is that the TC client
leaves broken temp files for very long times on the disk. These
files often have the full size but "holes" filled with zeros
because of packet loss. There is very small chance that these
holes can be fixed by partial retransmissions that do exist. The time
a broken temp stays on your HDD or jams your RAMDISK can be set
per channel by EUMETSAT. It was 3 hours for OLCI files when I
studied the new client. There is and additional problem that you
cannot tell a broken temp from a temp that has a "transmission
interrupted" for a while. I have discussed that with K.-P. years
back. Tellicast lets priviledged stations ask for retransmissions.
K.-P. said that everybody can benefit from a retransmission. My
point was that chances are close to zero that an amateur has
the same hole in a broken temp file as a priviledged station
that can start a retransmission. This is only the case when the
problem for packet loss was on the uplink side. But your reception
problems are local weather most of the time. The discussion was
also about the "transmission ended" message. At that time TD15
stated that this message was harmless. But my point was that
"transmission ended" is always followed by broken temp and "file
lost". You can easily see that with TCLogSummary. There exists
an easy fix for all that making RAMDISKs far easier to handle:

The tellicast client should have a switch where every station
can decide: "I do not hope for retransmissions and want all
temp files with transmission ended be deleted automatically".

This way we would only have to move the completed files from
RAMDISK to HDD and could get away with much smaller RAMDISKs
as well. And we would never take an "old" temp file that has
"transmission interrupted" as a broken temp to be cleaned by
our scripts. As the new TC client is still not finalized maybe we
should bring this point up again. The original promise of the
new client was that RAMDISKs are not necessary anymore and that
we have no size problems with all temp files on HDD. But as you
know this is not the whole story and even TD15 now admits that
RAMDISKs can help sometimes to reduce packet loss. So K.-P.
might now have a more open ear for my proposition above.

Cheers
Ernst
=========================================

Ernst,

Thanks for your detailed reply and a reminder (for me) of some of the issues.

Yes, the number of streams can also be an issue for some earlier versions of Windows where fewer UDP connections an be made. I've not tried BS reception without a RAMdisk for some time now, and would not recommend it. It's also a reason to restrict the number of channels to which you connect. Sentinel-1 and -2 should be 180 degrees out of phase in their orbits, so if we are lucky the files will still normally be sequential - the TelliCast flow does seem to have gaps. But it will be an extra load. This from an Ayecka SR1.

https://www.satsignal.eu/mrtg/stamsund-lan-2.html

I guess that Sentinel-2 data is already present in the stream, as the all-PIDs data from the TBS6903 is much more continuous.

https://www.satsignal.eu/mrtg/lund-1-hvs.html

I very much like your idea for the TelliCast client - a "no-retransmissions, delete temp files at transmission end". I hope that K.-P. will consider your suggestion more favourably.

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


Re: Sizing of the Discs

Ernst Lobsiger
 

David,

As a matter of fact the Basic Service is sometimes even more the
problem for a system without RAMDISK. This is because we have much
more parallel streams comming in. So the heads of a HDD must move
quickly between the different open temp files building up. On HVS
(up to now) files are sent more one after the other which eases
the workload of the HDD.

The problem you face with with bad weather is that the TC client
leaves broken temp files for very long times on the disk. These
files often have the full size but "holes" filled with zeros
because of packet loss. There is very small chance that these
holes can be fixed by partial retransmissions that do exist. The time
a broken temp stays on your HDD or jams your RAMDISK can be set
per channel by EUMETSAT. It was 3 hours for OLCI files when I
studied the new client. There is and additional problem that you
cannot tell a broken temp from a temp that has a "transmission
interrupted" for a while. I have discussed that with K.-P. years
back. Tellicast lets priviledged stations ask for retransmissions.
K.-P. said that everybody can benefit from a retransmission. My
point was that chances are close to zero that an amateur has
the same hole in a broken temp file as a priviledged station
that can start a retransmission. This is only the case when the
problem for packet loss was on the uplink side. But your reception
problems are local weather most of the time. The discussion was
also about the "transmission ended" message. At that time TD15
stated that this message was harmless. But my point was that
"transmission ended" is always followed by broken temp and "file
lost". You can easily see that with TCLogSummary. There exists
an easy fix for all that making RAMDISKs far easier to handle:

The tellicast client should have a switch where every station
can decide: "I do not hope for retransmissions and want all
temp files with transmission ended be deleted automatically".

This way we would only have to move the completed files from
RAMDISK to HDD and could get away with much smaller RAMDISKs
as well. And we would never take an "old" temp file that has
"transmission interrupted" as a broken temp to be cleaned by
our scripts. As the new TC client is still not finalized maybe we
should bring this point up again. The original promise of the
new client was that RAMDISKs are not necessary anymore and that
we have no size problems with all temp files on HDD. But as you
know this is not the whole story and even TD15 now admits that
RAMDISKs can help sometimes to reduce packet loss. So K.-P.
might now have a more open ear for my proposition above.


Cheers
Ernst


Re: Sizing of the Discs

R. Alblas
 

Ernst,

Yes, I am using the old style, so that explains why it works here.
Sounds to me like a 'Tellicast for Linux' problem (so Tellicast to blame) rather than a Linux problem?

Rob.

On 10/25/2018 12:36 AM, Ernst Lobsiger wrote:
Rob,

You understand me right. I cannot have temp and received on different filesystems. If I do the TC Client says something like:
"ERR: Cannot rename file xxx crosslinked files". The "move" is only made by hardlink. Do you use the old style RAMDISK
where you  have the *.fsy files? If so we are not talking about the same receiver setup. I use current Debian 9 and Devuan 2..

Regards,
Ernst


On Wed, Oct 24, 2018 at 01:29 PM, R. Alblas wrote:
Ernst,

Maybe I understand you wrong, but I have temp on a RAMDISK and received on HDD, it is possible with Gnu/Linux; the move (=cp+rm) done by Tellicast. Nothing done special for that.

(You can also use the mv command to move files from one filesystem to another. Which is then of course a combination of cp and rm, done 'under water'. On very old Linux system that wasn't possible with mv.)

Rob.

On 10/24/2018 09:54 PM, Ernst Lobsiger wrote:

David and Ron,

Basically the difference between temp and temp + received
on RAMDISK should be small. It depends on how frequently
you move received files to HDD and clean out broken temps.
Under GNU/Linux it is impossible to have only temp on a
RAMDISK. If a temp file is complete it is only renamed and
becomes a received file. No data is moved. Under Windows
this certainly works like that if temp + received are on the
RAMDISK. Different from GNU/Linux Windows allows for temp
and received on different filesystems. Then a complete temp
has to be moved (copied and deleted) by the TC client to HDD.

My receivers work with Basic + HVS-1 + HVS-2 on a 3GB RAMDISK.
This strongly depends on the biggest filesizes and the schedule.

Regards,
Ernst

On Wed, Oct 24, 2018 at 11:58 AM, David J Taylor wrote:

Ron,

Very quick guide:

- BS reception alone with just temp on the RAMdisk, 1 GB
- BS reception alone with temp and received on the RAMdisk, 4 GB
- HVS-1 and HVS-2 reception with temp and received on the RAMdisk, 10 GB


Re: Sizing of the Discs

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

David and Ron,

Basically the difference between temp and temp + received
on RAMDISK should be small. It depends on how frequently
you move received files to HDD and clean out broken temps.
Under GNU/Linux it is impossible to have only temp on a
RAMDISK. If a temp file is complete it is only renamed and
becomes a received file. No data is moved. Under Windows
this certainly works like that if temp + received are on the
RAMDISK. Different from GNU/Linux Windows allows for temp
and received on different filesystems. Then a complete temp
has to be moved (copied and deleted) by the TC client to HDD.

My receivers work with Basic + HVS-1 + HVS-2 on a 3GB RAMDISK.
This strongly depends on the biggest filesizes and the schedule.

Regards,
Ernst
=================================

Ernst,

As I said, it was a very quick guide! I am in the unfortunate position of being exposed to winds which appear to affect the dish more than I would like, and not having as good weather as some locations. We can get quite a lot of rain, which together with the wind can make reception difficult at times!

It's important, as you hint, to have the tmp and received on the same file system (i.e. the same disk partition under Windows), so that TelliCast can simply rename the files rather than have to copy hundreds of megabytes of data when an incoming stream is complete. "Rename" simply involves a directory operation.

Some graphs from actual systems so that you can judge for yourselves. No IASI data is taken. The pink lines show peak usage with a 5 minute monitoring interval.

BS only, tmp on RAMdisk. With poor conditions the 1 GB isn't enough, but 300 MB would suffice for much of the time.
https://www.satsignal.eu/mrtg/alta-ramdisk.html
https://www.satsignal.eu/mrtg/stamsund-ramdisk.html

BS only, tmp and received on 4 GB RAMdisk. Again, under normal conditions 300 MB suffices, but under a (EUMETSAT) fault conditions the 4 GB was almost exhausted. Windows Robocopy used to copy processed data from received to an HDD for further action.
https://www.satsignal.eu/mrtg/harstad-ramdisk.html

HVS-1 and HVS-2, tmp and received on 10 GB RAMdisk. I would recommend a 3 GB minimum for this arrangement, and bear in mind that this is within only one Sentinel satellite in operation, with a second due to join it soon, so perhaps 6 GB minimum. Windows Robocopy used to copy processed data from received to an HDD for further action.
https://www.satsignal.eu/mrtg/lund-ramdisk-trees.html

Having said all that, the original RAMdisk was used to hold a temporary database as the performance back in 2002 wasn't fast enough to take all the data without losses. More recent versions of TelliCast now hold that database in memory. But then we started getting more data and the temporary files could be held on RAMdisk for better performance, and with even more data (600 MB Sentinel files) holding both received and temporary files on RAMdisk was what we tried. Even newer TelliCast versions can have more internal buffering (RAM).

However ... I have one system here taking HVS-1 data from an Ayecka SR1 with no RAMdisk at all (but a separate HD devoted to HVS-1) which often has zero losses under good conditions, and another system taking HVS-2 data (again to a different disk to BS) with no RAMdisk and often without loss. Both these systems are running Windows-10/1803/64-bit with TelliCast 2.14.4, and because of the disk arrangement, both tmp and received are on the same disk partition.

So perhaps today's advice should be: try without a RAMdisk, monitor missed segments and missed/recovered TelliCast packets, and adjust your system accordingly. But if buying from new, 16 GB memory minimum.

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


Re: Question about the power (dBm) values

Herman Vijlbrief
 

Many thanks David for this reply.
I'll see it is no problem to keep de Inverto at the dish.

Have i nice F1 weekend with hopefully the same two winners as last year..

Greetings Herman

Op 24-10-2018 om 20:54 schreef David J Taylor via Groups.Io:

Dear all,

During installation of my new dish I thought it was the moment to change my old Smart Titanium LNB with a new Inverto Black Ultra LNB.
The SNR of the Inverto was about 0,5 dB higher comparing to the Titanium LNB.

And i saw a significant increase of the power level from - 26 dBm (Titanium) to - 19 dBm (Inverto) in the SR1 controller display.
Because de dBm value is out of the green display area a question came up about this high value.
Is that high value OK or is it too high for good reception.
And if it is too high can I tweak this value down?

Any advise highly appreciated.

Greetings,

Herman Vijlbrief
======================================

Herman,

On my own Ayecka HVS-1 receiver I see -18/-19 dBm and I don't see problems. If it was significantly higher that that I might add a splitter (likely cheaper than a 3/4 dB attenuator!).

Cheers,
David


Re: Sizing of the Discs

Ernst Lobsiger
 

Rob,

You understand me right. I cannot have temp and received on different filesystems. If I do the TC Client says something like:
"ERR: Cannot rename file xxx crosslinked files". The "move" is only made by hardlink. Do you use the old style RAMDISK
where you  have the *.fsy files? If so we are not talking about the same receiver setup. I use current Debian 9 and Devuan 2..

Regards,
Ernst


On Wed, Oct 24, 2018 at 01:29 PM, R. Alblas wrote:
Ernst,

Maybe I understand you wrong, but I have temp on a RAMDISK and received on HDD, it is possible with Gnu/Linux; the move (=cp+rm) done by Tellicast. Nothing done special for that.

(You can also use the mv command to move files from one filesystem to another. Which is then of course a combination of cp and rm, done 'under water'. On very old Linux system that wasn't possible with mv.)

Rob.

On 10/24/2018 09:54 PM, Ernst Lobsiger wrote:

David and Ron,

Basically the difference between temp and temp + received
on RAMDISK should be small. It depends on how frequently
you move received files to HDD and clean out broken temps.
Under GNU/Linux it is impossible to have only temp on a
RAMDISK. If a temp file is complete it is only renamed and
becomes a received file. No data is moved. Under Windows
this certainly works like that if temp + received are on the
RAMDISK. Different from GNU/Linux Windows allows for temp
and received on different filesystems. Then a complete temp
has to be moved (copied and deleted) by the TC client to HDD.

My receivers work with Basic + HVS-1 + HVS-2 on a 3GB RAMDISK.
This strongly depends on the biggest filesizes and the schedule.

Regards,
Ernst

On Wed, Oct 24, 2018 at 11:58 AM, David J Taylor wrote:

Ron,

Very quick guide:

- BS reception alone with just temp on the RAMdisk, 1 GB
- BS reception alone with temp and received on the RAMdisk, 4 GB
- HVS-1 and HVS-2 reception with temp and received on the RAMdisk, 10 GB


Re: New version EUMETCastView 1.4.2

Douglas Deans
 

On 24/10/2018 13:22, Hugo wrote:
This release fixes some bugs ; one in the projection routine and one in the calculation of the HVR image.
As always, you can download the new version at https://github.com/hvanruys/EUMETCastView/releases
Kind regards,
Hugo
============================================================================

Yes all working perfectly now Hugo. Many thanks.
Also notice the geographic overlay for GOES 16 is now perfect.

Regards,
Douglas.


Re: Sizing of the Discs

R. Alblas
 

Ernst,

Maybe I understand you wrong, but I have temp on a RAMDISK and received on HDD, it is possible with Gnu/Linux; the move (=cp+rm) done by Tellicast. Nothing done special for that.

(You can also use the mv command to move files from one filesystem to another. Which is then of course a combination of cp and rm, done 'under water'. On very old Linux system that wasn't possible with mv.)

Rob.

On 10/24/2018 09:54 PM, Ernst Lobsiger wrote:

David and Ron,

Basically the difference between temp and temp + received
on RAMDISK should be small. It depends on how frequently
you move received files to HDD and clean out broken temps.
Under GNU/Linux it is impossible to have only temp on a
RAMDISK. If a temp file is complete it is only renamed and
becomes a received file. No data is moved. Under Windows
this certainly works like that if temp + received are on the
RAMDISK. Different from GNU/Linux Windows allows for temp
and received on different filesystems. Then a complete temp
has to be moved (copied and deleted) by the TC client to HDD.

My receivers work with Basic + HVS-1 + HVS-2 on a 3GB RAMDISK.
This strongly depends on the biggest filesizes and the schedule.

Regards,
Ernst

On Wed, Oct 24, 2018 at 11:58 AM, David J Taylor wrote:

Ron,

Very quick guide:

- BS reception alone with just temp on the RAMdisk, 1 GB
- BS reception alone with temp and received on the RAMdisk, 4 GB
- HVS-1 and HVS-2 reception with temp and received on the RAMdisk, 10 GB


Re: New version EUMETCastView 1.4.2

g3pha.morris@btinternet.com
 

Greetings Hugo , Just updated successfully to V1.4.2 and HVR grey scale images now OK.
                            Many thanks.  Like Douglas and others, looking forward to the future release
                             of the animation feature. In the meantime best regards,    John Morris.


Re: Sizing of the Discs

Ernst Lobsiger
 

David and Ron,

Basically the difference between temp and temp + received
on RAMDISK should be small. It depends on how frequently
you move received files to HDD and clean out broken temps.
Under GNU/Linux it is impossible to have only temp on a
RAMDISK. If a temp file is complete it is only renamed and
becomes a received file. No data is moved. Under Windows
this certainly works like that if temp + received are on the
RAMDISK. Different from GNU/Linux Windows allows for temp
and received on different filesystems. Then a complete temp
has to be moved (copied and deleted) by the TC client to HDD.

My receivers work with Basic + HVS-1 + HVS-2 on a 3GB RAMDISK.
This strongly depends on the biggest filesizes and the schedule.

Regards,
Ernst


On Wed, Oct 24, 2018 at 11:58 AM, David J Taylor wrote:

Ron,

Very quick guide:

- BS reception alone with just temp on the RAMdisk, 1 GB
- BS reception alone with temp and received on the RAMdisk, 4 GB
- HVS-1 and HVS-2 reception with temp and received on the RAMdisk, 10 GB

3501 - 3520 of 30989