>From: Tim Alberta <alberta@xxxxxxxxxxxxxx>
>Organization: UCAR/COMET
>Keywords: 200110300043.f9U0hS105503 Unidata-Wisconsin MDR
Tim,
>Does anyone know why, at 00Z, the radar coded message (MDRadar), instead
>of providing the 00Z image, retransmits the 23Z image?
Small correction: the MDR radar product in the Unidata-Wisconsin datastream
is not created from Radar Coded Messages.
More importantly, I hadn't noticed that the 0Z MDR product is never
being sent. This will take some investigation on the Unidata-Wisconsin
datastream injection machine.
>And why the real
>00Z image never appears? I think the 01 and 02Z RCMs are also absent
>most of the time, but what we're really looking for is 00Z.
>
>This is what I see on ldmwatch:
>
>Oct 29 23:06:27...MCIDAS 000 pnga2area Q1 U3 204 GRAPHICS UNKBAND 5km
>20011029 2259
>
>at 2306Z, and
>
>Oct 30 00:06:15...MCIDAS 000 pnga2area Q1 U3 205 GRAPHICS UNKBAND 5km
>20011029 2259
>
>at 0006Z.
>
>My pqact.conf entry looks like
>
>MCIDAS ^pnga2area Q. (..) (.. ) FILE -close /tmp/rawarea.0\2
>MCIDAS ^pnga2area Q. (..) (.. ) EXEC /pub/ldm/bin2/mvarea1.pl -l
>/tmp/rawarea.0\2
>
>MCIDAS ^pnga2area Q. (..) (... ) FILE -close /tmp/rawarea.\2
>MCIDAS ^pnga2area Q. (..) (... ) EXEC /pub/ldm/bin2/mvarea1.pl -l
>/tmp/rawarea.\2
>
>and to verify, gif images of the two products (23Z and 00Z) are
>identical.
>
>Any insight would be appreciated!
The problem is not on the receiving side. It is on the sending side.
I will try and look into this tomorrow.
Tom
>From alberta@xxxxxxxxxxxxxx Tue Oct 30 11:22:42 2001
>Subject: Re: 20011029: Radar Coded Messages
Tom,
Thanks for looking into this, and thanks for the correction - I always
"knew" the MDRadar as part of the RCM, but was always confused as to why
I called it that. Thinking about it, I'm now realizing the RCM is what
we want to replace MDRadar with in some cases, so we can overlay it on
top of a sat image.
Further information - this is something we've noticed for a long time
(probably well over a year), but have not had the inclination to deal
with it - we always assumed it was a problem on our side.
Thanks again,
Tim
