Re: experiences and lessons learned with a fresh Eumetcast install for WIndows and Linux
David J Taylor GM8ARV 🏴 🇪🇺
1. tc-cast-client is buffering the logs. In result, upon start we saw
only like 5 first lines of expected logs and then nothing any more.
So when you are tailing the log ('tail -f recv_bas.log'), you would
think something is hanging (the last line was "Child connecting to
watchdog on port ..."). What was actually going on is that everything
ran smoothly and only when the logging buffers flushed the contents
to the disk (when some data is received, which can take a loong time
on BAS), we could see that everything is OK.
2. the second point of confusion was monitoring the tellicast web
interface. It relatively quickly connects to the announcements
channel, but then no data channel is active. What we did not know was
that transmissions on this channel happen only once per hour
approximately in the time block X:00 to X:15. And only when the
client is actually decoding the data it reports a connection to a
data channel. In result, for 45 minutes in every hour it seems that
the client is not connected, while actually everything is OK. Only in
retrospect we realised that of course this makes sense because our
Ayecka SR1 is sending UDP packets only when it receives something, so
there's no concept of a session and thus tellicast cannot report
Thanks again for all the help we received. This thread was very
informative and helpful.
Just a couple of points.
1. You can turn off the log buffering, I believe, but I've never done so:
I recall (but it's not documented, so I'm probably wrong) that ">>" implied buffering. Perhaps it simply means "append". The ">>" may apply to something else in an earlier TelliCast, so please check. Maybe that wouldn't help in your case anyway.
2. Almost all BAS data should be sent every 15 minutes, with the possible exception of some meteorological data and some FSD. You must be looking for relatively obscure data!
SatSignal Software - Quality software for you