Standard Horizon gx2400 GPS issue in PNW

[M Lofstrom]

So i'm just throwing this out to see how big of an issue it is with these radios in the PNW, and whether there any any other marine electronics in the PNW that might be affected:

Background: In early April, my Standard Horizon GX 2400 GPS started spontaneously and continuously rebooting itself about every 45 seconds. I managed to do a factory reset, and then it would just lock up entirely and could only be reset by removing the power. I have owned the Radio for 2 years, and it has been flawless. Thinking i might have a power input problem, I set up a fluke meter and my oscilloscope, and measured the input power. Solid 13V, and almost no ripple on the input power. I contacted Standard Horizon, and they suggested a return for warranty evaluation.

After they had it for 4 weeks with no word, I contacted them, and found out the following: "No problem found, but they have been getting multiple reports of this model radio exhibiting this failure mode in the PNW" Specifically in the eastern San Juan islands. The Tech mentioned he was plotting the failure locations and they seemed to be centered around northern Whidbey island. Not saying it might be something at NAS Whidbey, but strange coincidence?

The Tech also mentioned that is seems to be only the GX2400GPS, and none of their other radios, and the problem is only in the region to the south of Whidbey, Eastern San Juans, and North as far as Blaine. As of today, they are stumped. They aren't sure what the problem is or whether it is a hardware of firmware problem, and why it is only this geographic location. In the meantime, I am using a backup radio since i cant trust the 2400.

So, I'm throwing it out there to the TF community to try to gather some data, and maybe this will help them. Has any one else in this area had issues with this or similar AIS/GPS equipped VHF radios in the last 6 weeks? If so, Please post your location and radio model, and the issue you experienced, and whether it has resolved itself.

thanks,

Mike

 

[Comodave]

Well, I guess you will have to move…. Sounds like it might be the Navy doing something but you won’t ever get them to admit it.

 

[sjisailor]

That is interesting. I can say that my Garmin 800 AIS recently failed in exactly the same area. It was working fine and broadcasting while underway, and then just stopped broadcasting. My wife called me to see what was up (she was following on Marine Traffic). I had gone a few NM by that point.

After rebooting it worked OK again. I've seen a few other reports in the general vicinity, too: The TugNuts • View topic - Garmin AIS 800 Transmit Issues-Flashing Status LED's

So there may be something going on, but as Comodave said, we may never know.

 

[Jlearned]

Same issue

I have had mine for just over a year. I am home ported in the south sound in Gig Harbor. While in the SJI’s last year the radio 2 time froze up on us. Only way to get it working was cut the power. It happened a few times since in the south sound since but recently it happens as soon as I power it on. I sent it back to be tested and am still waiting for a response for 5 weeks. I would think that if this issue was being caused by external equipment that it would be effecting more than just standard horizon radios of a certain model number.

 

[M Lofstrom]

Gx2400 update

Just an update after I got the radio back from Standard Horizon. I reinstalled it in the boat On May 20th, and it worked fine. We spent a week in the SJI and Gulf Islands starting on the 23rd of may, and had no issues at all. I'm glad its working, but I'm a bit disappointed that the issue is still a mystery. When it was acting up, it went absolutely bonkers. The tech at Standard Horizon said that they might be able to issue a SW update in the future if they determine the root cause, and if it is correctible by software alone. I asked about possibly getting them to upgrade me to the next radio up in their AIS line, and they could not accommodate that even if I paid the delta cost. At this point, It's working, but I don't trust it enough to not have a spare radio on the boat. (i have an old Uniden in the spares locker).

I'll update this post in the future if the problem returns, or if i hear from Standard Horizon on root causes.

Mike

 

[JadePanama]

Holy crap. I thought I was just going crazy. I installed 3 new GX2400GPS units on our vessel in Seattle. I installed them back in Feb. They worked solid for a month or so. Then we went for a cruise late march/april and all 3 were just randomly rebooting a TON. Almost unusable. I was not happy but got through the cruise. I had actually forgot about it and we were out again late May for a week and there was not a single issue with them.

I have two of them on the nmea 2000 network, and one just using built in gps. One of the nmea connected ones, and the gps one have the wifi adapters for the remote radio, and the third is stand alone. From what I remember all had the issue but if it comes up Ill try and note any different behavior on them.

This aligns exactly with your timing and what they were seeing. Note, we were just in the Seattle area and not up by Whidbey or SJIs. Definitely let me know if you learn more.

 

[Jlearned]

I received my unit back from Standard Horizon this week, 6/12. They said they had it on the bench for two weeks with no issues found. I reinstalled it, and it worked fine at the dock for about 2 hours. SH said three other radios they had from this area were returned and installed, with no further issues reported. They surmise that the offending transmitting equipment in the area has been removed. Only time will tell if that was the actual issue.

 

[fgarriso]

Try charging up a 12VDC battery and connecting it to the radio. If it works OK then the problem is your supply power. The radio is seeing something that is making noise or inference on the ships power.

 

[M Lofstrom]

I appreciate the responses from those of you that experienced this bizarre issue with this particular radio. With the exception of the one Garmin AIS 800 report, it really does seem to be isolated to the GX2400GPS radios. Even S.H. confirmed that. I really like the radio, it has a great feature set for the price, and is pretty easy to use. Lets all hope it was a one time event and we wont see it again! ( i will keep my spare Uniden on board for a while tho!) As I stated in the previous posts, I'll update again if i see the issue again.

Mike

 

[wkearney99]

Did anyone having this problem see any GPS datum anomalies on other GPS devices?

I'd wonder if 'something' was transmitting incorrect data and the firmware within the SH was running into something like a 'divide by zero' problem. For those that don't know programming, dividing by zero is a bad thing for most digital devices and most software will check inputs to make sure that can't happen. But developers sometimes miss/skip that checking, assuming "this couldn't ever do THAT" and then it happens. And the processor hard faults on a DIV/0, causing a reboot. Which then repeats when it starts processing data again.. and the loop continues.

 

[M Lofstrom]

That is a very interesting possibility....On my Boat, the radio is interfaced to a Garmin GPSmap943xsv, and a Fusion stereo Via NMEA 2k. When the radio was acting up, I tried various combinations of connections with and without devices powered on NMEA. It didn't seem to make any difference to the radio at all. I do remember seeing position on the Garmin showing my boat in the slip as usual. So, it would appear that the positional data was intact, at least on my Garmin.

That said, the concept is intriguing. There does appear to be at least one Garmin AIS device that had a similar problem during this time period. So maybe it was a random or corrupted AIS signal that caused the processor to have the divide by zero type error. There are lots of boats whose AIS transponders seem to be left on continuously. I see boats on my GPS that are in the boat yard next door all the time. Lots of opportunities for a signal to be corrupted by battery chargers, inverters etc when boats are unattended for long periods.

 

[CaptTom]

I have the same radio, but on the other coast. I'll watch for any symptoms, hopefully it was a one-time thing.

But I do hope they find the source and issue a firmware update. My guess would be some sort of buffer overflow caused by a bad data packet. Interestingly, that's the vector a lot of viruses used to use. Computer operating systems have been hardened to try to limit that exposure. Perhaps the VHF and AIS developers haven't.

Of course, it could be an intentional hacking attempt, either by our own government or an adversary. Or it could be something as innocent as an error in some AIS transmitter somewhere. I notice the CG is starting to use the virtual ATONs more, maybe their software isn't 100 bug-free.

 

[wkearney99]

Unless you've got a computer on board with an N2K interface and suitable logging software it'd be difficult to run down a transient sort of error like that.

I'm no AIS, GPS or N2K expert but I could imagine a situation where a device was 'supposed to be' transmitting legit data, but wasn't doing so consistently and that left open a window of sorts for bad data to get collected by the radios. Their input sanitizing routines should have scrubbed the data BEFORE handing it over for other processing... but perhaps it didn't and BAM, the DIV/0 (or whatever, I've no proof that's what was happening, just guessing).

Among the top rules for programming is NEVER trust that input data will be in a legitimate format. ALWAYS scrub it so that it cannot exceed the bounds of what your code is known to be able to handle. Sounds easy, right? Yeah, it's not. Lots of compromises get made, especially on memory and CPU limited devices. You don't have enough firmware storage to 'bloat' it up with all of the correct error checking, and/or the device doesn't have enough processing power to get it all done without seeming slow to use. Or the programmers are just careless.

This is also how a considerable number of 'hacking' efforts gain a foothold on devices. They exploit hammering the devices with all manner of entirely bogus datasets and hope some part of the input handling slips up and lets them craft a payload that the device will execute. Sounds like it shouldn't happen, right? Yet it does... ALL THE TIME.

Heh, side joke for those that know SQL and programming, I wonder if changing a boat's name in AIS to a SQL database DROP TABLE command might cause some mischief...

There was a meme some years ago of a car having that sort of thing on the hood and causing the speed camera database to crash.

Unless the error is really repeatable I can't see a scenario where anyone would have enough of the data logging set up to make it possible to check. If you knew it would happen at a certain time/place then... maybe. Tools like wireshark are pretty handy at slogging through data like that. Not exactly layman's tools though.

 

[CaptTom]

Since we've already gone off the deep end speculating here...

First of all, I don't have the confidence in Garmin's programming prowess to think that they always do adequate error checking. I rather suspect a lot of it is outsourced to the lowest bidder, based on what I see just in the user interface. And given that maintenance is pretty much abandoned after the production run of the hardware, it's very likely there are known bugs which never get addressed.

As for discovering and exploiting buffer overrun type errors, that's exactly what governments and hackers do. It would be easy enough to buy the hardware and pass it all kinds of malformed data in the lab. Or you could just download the firmware updates and de-compile them. So much software these days is written in higher-level languages that it should even be easy to identify common code with known security vulnerabilities.

One could even imagine someone (or some government) testing a hack like this in the wild.

 

[wkearney99]

First of all, I don't have the confidence in Garmin's programming prowess to think that they always do adequate error checking. I rather suspect a lot of it is outsourced to the lowest bidder, based on what I see just in the user interface. And given that maintenance is pretty much abandoned after the production run of the hardware, it's very likely there are known bugs which never get addressed.

Wait, when did we shift to talking about the Fusion radio software?

heh.

But you do make a pretty accurate point about Garmin and the software on many of their devices.

 

[CompuNerd]

First of all, I don't have the confidence in Garmin's programming prowess to think that they always do adequate error checking.

25% of application development is designing the functionality; the remaining 75% is error checking and error handling. There's only time in the development schedule for the first 25%. The rest will be tested after product release.