<div>Mitch</div>
<div> </div>
<div>When you upgraded the software in the refteks did you also upgrade the PLD&#39;s on 2 of the boards inside the unit?  some of the function in software will not work until those are either replaced or reprogrammed using files from reftek.</div>

<div> </div>
<div>Also one other note with the &quot;dsl&quot; routers  I have had issues with the linksys (cisco) small routers not forwarding UDP packets.  They work for a while and then just stop.  when they are rebooted the start working again.  I have converted to the netgear wireless routers that are using open source firmware and turning the wireless off.  It seems to have stopped the issues we were having with UDP packets on the Q330&#39;s   The model number of the one I am using is:  wgr614 and it is about 50.00 at CDWG</div>

<div> </div>
<div>Bob<br><br></div>
<div class="gmail_quote">On Thu, Nov 10, 2011 at 10:48 AM, <span dir="ltr">&lt;<a href="mailto:mwithers@memphis.edu">mwithers@memphis.edu</a>&gt;</span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote"><br>Whoops, we&#39;re running cpu version 3.0.0 on the station referenced here 3.2.2<br>on another problem station, and 3.3.0 on still others (even the ones running<br>
3.3.0 seem to have the problem though not as bad).  Its a little hard<br>to prove, but my guess is that the rt130 makes a udp connection and the<br>router assigns a comm port.  Then for whatever reason, the port the<br>router has assigned is not the same as what the rt130 and rtpd think<br>
is being used.  Rebooting syncs everyone up again (though not today for<br>an unknown reason).  This gets particularly problematic with multiple<br>das&#39;s behind a single router. 
<div class="im"><br><br>Mitch<br><br>Center for Earthquake Research and Information (CERI)<br>University of Memphis                Ph: <a href="tel:901-678-4940" target="_blank" value="+19016784940">901-678-4940</a><br>Memphis, TN 38152                   Fax: <a href="tel:901-678-4734" target="_blank" value="+19016784734">901-678-4734</a><br>
<br><br></div>
<div>
<div></div>
<div class="h5">On Thu, 10 Nov 2011, Philip Crotwell wrote:<br><br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">Do you know what firmware you are running? My memory is that there was<br>a firmware upgrade in the not too distant past that addressed some<br>
issues with refteks not reconnecting even when the link was up. Sorry<br>I don&#39;t remember the exact version.<br><br>Philip<br><br>On Thu, Nov 10, 2011 at 11:22 AM,  &lt;<a href="mailto:mwithers@memphis.edu" target="_blank">mwithers@memphis.edu</a>&gt; wrote:<br>

<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote"><br>We have 6-c retek RT130&#39;s behind a netgear router.  The ones on private<br>networks seem to work great but the ones on public networks seem to stop<br>
streaming data every couple weeks (or every couple days in extreme cases).<br>When it does this we can get an http connection to the router.  We can<br>use rtcc to get a direct connection to the reftek.  We can see that the<br>
reftek is operating and acuisition start is on and buffer is filling up.<br>But data are not received by rtpd and can&#39;t get an rtpd type connection<br>from rtcc.  A power cycle on the router and reftek usually works but not<br>
today.  Does anyone have any ideas on what we could try next to get data<br>flowing again?<br><br>Here are some relevant lines from the log:<br>2011:314-15:49:33 achilles rtpd[21986] RTPHandleEvent: Unit AC00 Event: TO-<br>
(Sync-Sent)<br>2011:314-15:49:33 achilles rtpd[21986] RTPHandleEvent: Unit AC00 Action:<br>This Layer Down<br>2011:314-15:49:33 achilles rtpd[21986] RTPHandleEvent: Unit AC00 Application<br>layer (RTP) Down!<br>2011:314-15:49:33 achilles rtpd[21986] RTPHandleEvent: Unit AC00 Action:<br>
This Layer Finished<br>2011:314-15:49:33 achilles rtpd[21986] RTPHandleEvent: Unit 0000 Transition<br>to State: Stopped<br><br><br>Mitch<br><br>Center for Earthquake Research and Information (CERI)<br>University of Memphis                Ph: <a href="tel:901-678-4940" target="_blank" value="+19016784940">901-678-4940</a><br>
Memphis, TN 38152                   Fax: <a href="tel:901-678-4734" target="_blank" value="+19016784734">901-678-4734</a><br><br><br>______________________________<u></u>_________________<br>ANSS-netops mailing list<br><a href="mailto:ANSS-netops@geohazards.usgs.gov" target="_blank">ANSS-netops@geohazards.usgs.<u></u>gov</a><br>
<a href="https://geohazards.usgs.gov/mailman/listinfo/anss-netops" target="_blank">https://geohazards.usgs.gov/<u></u>mailman/listinfo/anss-netops</a><br><br></blockquote><br></blockquote></div></div><br>_______________________________________________<br>
ANSS-netops mailing list<br><a href="mailto:ANSS-netops@geohazards.usgs.gov">ANSS-netops@geohazards.usgs.gov</a><br><a href="https://geohazards.usgs.gov/mailman/listinfo/anss-netops" target="_blank">https://geohazards.usgs.gov/mailman/listinfo/anss-netops</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Robert Wurth<br>AV Computer Tech<br>Department of Atmospheric and Earth Sciences<br>St Louis University<br>205 O&#39;Neil Hall<br>3642 Lindell Blvd.<br>St. Louis, MO 63108, USA<br>
Phone (314) 977-3137, 314-977-3135 <br> Fax (314) 977-3117 <br>