[ANSS-netops] ANSS-netops Digest, Vol 58, Issue 2
Smith, James
jimsmith at usgs.gov
Sat Dec 20 03:38:00 UTC 2014
Hello All,
As Jonah pointed out, we've been back and forth on this issue, and with the
latest firmware updates the problem seems to persist in some units, hence
the KMI belief that the CF cards could be at fault, and at this point I am
leaning toward that as well as we have already witnessed the same issues in
several of our Granites as well as Granites belonging to other agencies.
We've literally popped in SanDisk CF cards fresh off of imaging, only to
have them work for a little bit and then the problem rears it's ugly head
again.
Here's the backstory behind KMI's belief on the CF card as the culprit:
Somewhere along the way SanDisk changed from being a player primarily in
the embedded market (like KMI) to being firmly in the consumer market.
Probably a good business decision for them, but it means that their
products changed to meet the needs of that market (which are all about
cost) and they started using cheaper and cheaper flash to compete. Also,
being consumer based things like traceability, failure analysis, even clear
product versioning were "reduced". All of this means that KMI can't tell
when the switchover occurred.
As a result, KMI is replacing the SanDisk CF cards for free for affected
devices and for all units that come in for repair (for free up to 5 years),
even if the repair is unrelated. If you want to know what they have
switched to, they now use the Transcend CF2001 model. They go for about
$100-150 for 8/16GB.
Hope this helps. I've gotten 2 units back with the new CF cards so when I
get back from leave we'll them out and see if the problem (same as in this
thread) disappear.
r/Jim
On Fri, Dec 19, 2014 at 3:40 PM, <anss-netops-request at geohazards.usgs.gov>
wrote:
> Send ANSS-netops mailing list submissions to
> anss-netops at geohazards.usgs.gov
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://geohazards.usgs.gov/mailman/listinfo/anss-netops
> or, via email, send a message with subject or body 'help' to
> anss-netops-request at geohazards.usgs.gov
>
> You can reach the person managing the list at
> anss-netops-owner at geohazards.usgs.gov
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ANSS-netops digest..."
>
>
> Today's Topics:
>
> 1. Re: help with basalt, pls? (Merritt, Jonah)
> 2. Re: help with basalt, pls? (lynn.kaisan)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 19 Dec 2014 17:26:51 -0600
> From: "Merritt, Jonah" <jmerritt at usgs.gov>
> To: Jacob Crummey <jcrummey at usgs.gov>
> Cc: anss-netops at geohazards.usgs.gov, "lynn.kaisan"
> <lynn.kaisan at noaa.gov>
> Subject: Re: [ANSS-netops] help with basalt, pls?
> Message-ID:
> <
> CAPTFOo07q+F6LevDDA4-OLPU0yR-OKjwTTBWA189UbdTTe561w at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello everybody,
>
> We are seeing the same issues! Jacob is correct...if you reboot the Basalt
> (or Granite) it loses contact with the gateway. This issue seems to have
> manifested itself more is subsequent Linux updates (we are running 2.6
> update 6). We also almost exclusively use Raven XE or GX440 modems.
>
> What I have found that all is well after performing the "netconfig" script
> and setting up NetWatcher. However, once you reboot you loose all remote
> connectivity. If you get into the Basalt locally via SSH and restart
> networking (/etc/init.d/networking restart) all is well again....until the
> datalogger reboots again.
>
> It should be noted that if you are able to log into the Raven, you can
> successfully ping the Basalt.
>
> I have contacted KMI about this and it was suggested that the problem
> resides with the modem and not the digitizer. I'm not convinced that it's a
> Raven issue as we have used these for several years without any significant
> issues. It was also suggested that the NetWatcher ping address be something
> else besides the gateway address....say 8.8.8.8. I did this without any
> resolution.
>
> We will be experimenting with this over the coming weeks, but I suspect
> that it is an issue with the digitizer itself. I'll keep the group posted.
>
> Regards,
>
>
> Jonah Merritt
> US Geological Survey
> National Strong Motion Project
> 345 Middlefield Rd. MS-977
> Menlo Park, CA 94025
> (650)329-5696 (office)
> (650)276-6579 (mobile)
> jmerritt at usgs.gov
>
> On Fri, Dec 19, 2014 at 4:43 PM, Jacob Crummey <jcrummey at usgs.gov> wrote:
>
> > Hi Yolanda and Lynn,
> >
> > I have seen some of our Basalts loose the router info, specifically the
> > gateway. I have yet to figure out what is causing this. It seems to
> > happen on boot. My guess is the Basalt runs fine when initially set up
> and
> > then if it reboots, it looses the routing table.
> >
> > Lynn, what version and update of Linux are you using on the Basalt? And
> > are you using the net-watcher feature that is set up in the netconfig?
> >
> > -Jacob
> >
> >
> >
> > On Dec 19, 2014, at 2:22 PM, Yolanda Prior <yprior at usgs.gov> wrote:
> >
> > > Have any end users of the Basalt seen similar issues as Lynn below? Any
> > > help for Lynn would be appreciated. Thanks!
> > >
> > > Yolanda Prior
> > > Engineering Technician
> > > Albuquerque Seismological Laboratory
> > > (505) 846-5662
> > >
> > >
> > > -----Original Message-----
> > > From: lynn.kaisan [mailto:lynn.kaisan at noaa.gov]
> > > Sent: Thursday, December 18, 2014 3:01 PM
> > > To: yprior at usgs.gov
> > > Subject: help with basalt, pls?
> > >
> > > happy holidays, yolanda,
> > >
> > > my name is lynn and i work at the pacific tsunami warning center.
> > >
> > > i am jumping into the maintenance of our kinemetrics equipment without
> > any
> > > training and we seem to have a lot of common problems amongst a few
> > > stations.
> > >
> > > may i ask if you have had this experience?
> > >
> > > i went to three sites that were not transmitting seismic data. at the
> > > site, our IT guy found some settings on the modem template that seemed
> to
> > > be the culprit. things like too short tcp idle and timeout time
> > settings.
> > > another basalt lost its router setting. after changing those fields,
> the
> > > site would be happy and transmitting data for a couple months or weeks,
> > > then...no data. we are still able to "see" the modem (ravens) and the
> > > received signal strength indicator is at acceptable levels.
> > >
> > > we use various models of the raven x modem. our sites are metrozet or
> > > basalt equipment, sometimes both.
> > >
> > > if you have any idea what to check, that would be great. for one site,
> > > the inject process had to be restarted but it was not the fix for the
> > > other two...very weird.
> > >
> > > thanks yolanda. i know i am asking a lot from you and i appreciate it.
> > > _______________________________________________
> > > ANSS-netops mailing list
> > > ANSS-netops at geohazards.usgs.gov
> > > https://geohazards.usgs.gov/mailman/listinfo/anss-netops
> >
> > _______________________________________________
> > ANSS-netops mailing list
> > ANSS-netops at geohazards.usgs.gov
> > https://geohazards.usgs.gov/mailman/listinfo/anss-netops
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://geohazards.usgs.gov/pipermail/anss-netops/attachments/20141219/4054dce5/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Fri, 19 Dec 2014 13:40:42 -1000
> From: lynn.kaisan <lynn.kaisan at noaa.gov>
> To: "Merritt, Jonah" <jmerritt at usgs.gov>, Jacob Crummey
> <jcrummey at usgs.gov>
> Cc: anss-netops at geohazards.usgs.gov
> Subject: Re: [ANSS-netops] help with basalt, pls?
> Message-ID: <5494B77A.20602 at noaa.gov>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> thank you all!
>
> i do appreciate your help.
>
> very generous!
> =================================
> On 12/19/2014 1:26 PM, Merritt, Jonah wrote:
> > Hello everybody,
> >
> > We are seeing the same issues! Jacob is correct...if you reboot the
> > Basalt (or Granite) it loses contact with the gateway. This issue
> > seems to have manifested itself more is subsequent Linux updates (we
> > are running 2.6 update 6). We also almost exclusively use Raven XE or
> > GX440 modems.
> >
> > What I have found that all is well after performing the "netconfig"
> > script and setting up NetWatcher. However, once you reboot you loose
> > all remote connectivity. If you get into the Basalt locally via SSH
> > and restart networking (/etc/init.d/networking restart) all is well
> > again....until the datalogger reboots again.
> >
> > It should be noted that if you are able to log into the Raven, you can
> > successfully ping the Basalt.
> >
> > I have contacted KMI about this and it was suggested that the problem
> > resides with the modem and not the digitizer. I'm not convinced that
> > it's a Raven issue as we have used these for several years without any
> > significant issues. It was also suggested that the NetWatcher ping
> > address be something else besides the gateway address....say 8.8.8.8.
> > I did this without any resolution.
> >
> > We will be experimenting with this over the coming weeks, but I
> > suspect that it is an issue with the digitizer itself. I'll keep the
> > group posted.
> >
> > Regards,
> >
> >
> > Jonah Merritt
> > US Geological Survey
> > National Strong Motion Project
> > 345 Middlefield Rd. MS-977
> > Menlo Park, CA 94025
> > (650)329-5696 (office)
> > (650)276-6579 (mobile)
> > jmerritt at usgs.gov <mailto:jmerritt at usgs.gov>
> >
> > On Fri, Dec 19, 2014 at 4:43 PM, Jacob Crummey <jcrummey at usgs.gov
> > <mailto:jcrummey at usgs.gov>> wrote:
> >
> > Hi Yolanda and Lynn,
> >
> > I have seen some of our Basalts loose the router info,
> > specifically the gateway. I have yet to figure out what is
> > causing this. It seems to happen on boot. My guess is the Basalt
> > runs fine when initially set up and then if it reboots, it looses
> > the routing table.
> >
> > Lynn, what version and update of Linux are you using on the
> > Basalt? And are you using the net-watcher feature that is set up
> > in the netconfig?
> >
> > -Jacob
> >
> >
> >
> > On Dec 19, 2014, at 2:22 PM, Yolanda Prior <yprior at usgs.gov
> > <mailto:yprior at usgs.gov>> wrote:
> >
> > > Have any end users of the Basalt seen similar issues as Lynn
> > below? Any
> > > help for Lynn would be appreciated. Thanks!
> > >
> > > Yolanda Prior
> > > Engineering Technician
> > > Albuquerque Seismological Laboratory
> > > (505) 846-5662
> > >
> > >
> > > -----Original Message-----
> > > From: lynn.kaisan [mailto:lynn.kaisan at noaa.gov
> > <mailto:lynn.kaisan at noaa.gov>]
> > > Sent: Thursday, December 18, 2014 3:01 PM
> > > To: yprior at usgs.gov <mailto:yprior at usgs.gov>
> > > Subject: help with basalt, pls?
> > >
> > > happy holidays, yolanda,
> > >
> > > my name is lynn and i work at the pacific tsunami warning center.
> > >
> > > i am jumping into the maintenance of our kinemetrics equipment
> > without any
> > > training and we seem to have a lot of common problems amongst a few
> > > stations.
> > >
> > > may i ask if you have had this experience?
> > >
> > > i went to three sites that were not transmitting seismic data.
> > at the
> > > site, our IT guy found some settings on the modem template that
> > seemed to
> > > be the culprit. things like too short tcp idle and timeout time
> > settings.
> > > another basalt lost its router setting. after changing those
> > fields, the
> > > site would be happy and transmitting data for a couple months or
> > weeks,
> > > then...no data. we are still able to "see" the modem (ravens)
> > and the
> > > received signal strength indicator is at acceptable levels.
> > >
> > > we use various models of the raven x modem. our sites are
> > metrozet or
> > > basalt equipment, sometimes both.
> > >
> > > if you have any idea what to check, that would be great. for
> > one site,
> > > the inject process had to be restarted but it was not the fix
> > for the
> > > other two...very weird.
> > >
> > > thanks yolanda. i know i am asking a lot from you and i
> > appreciate it.
> > > _______________________________________________
> > > ANSS-netops mailing list
> > > ANSS-netops at geohazards.usgs.gov
> > <mailto:ANSS-netops at geohazards.usgs.gov>
> > > https://geohazards.usgs.gov/mailman/listinfo/anss-netops
> >
> > _______________________________________________
> > ANSS-netops mailing list
> > ANSS-netops at geohazards.usgs.gov
> > <mailto:ANSS-netops at geohazards.usgs.gov>
> > https://geohazards.usgs.gov/mailman/listinfo/anss-netops
> >
> >
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://geohazards.usgs.gov/pipermail/anss-netops/attachments/20141219/bd4a6070/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> ANSS-netops mailing list
> ANSS-netops at geohazards.usgs.gov
> https://geohazards.usgs.gov/mailman/listinfo/anss-netops
>
>
> ------------------------------
>
> End of ANSS-netops Digest, Vol 58, Issue 2
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://geohazards.usgs.gov/pipermail/anss-netops/attachments/20141219/86d36a01/attachment-0001.html>
More information about the ANSS-netops
mailing list