Lowrance Globalmap / LMS GPS Antenna Replacement Modification

The older Lowrance Globalmap and LMS series of marine electronics are terrific GPS receivers. The only common issue I see with them is that the GPS antenna units for them often go bad. The antenna are about 4" round white pucks that you mount high up on your boat that actually contains the GPS antenna / receiver along with an optional DGPS receiver. This then connects to the back of your Lowrance unit supplying power and communication to the antenna from the head unit itself.

There are two series of these GPS antennas depending on how new your Lowrance unit is. The older ones are NMEA-0183 based while the newer stuff is NMEA-2000 based (most models support both). The advantage of the older 0183 protocol is that is uses a simple RS-232 serial interface, while the 2000 protocol is CAN-bus based (not that this is bad, CAN is a great protocol, but for the point of interfacing these units the RS-232 protocol is significantly easier to work with). Both of my units (A Globalmap 3000 and LMS-480) support NMEA-0183.

Repairing the antennas themselves is a huge pain. I have a dead Lowrance LGC-3000 GPS CAN bus antenna that I cracked open to take a look inside, these units are definitely designed to not be opened, it took some serious cutting to get inside.

Inside Lowrance LGC3000

Nothing unexpected found, a basic GPS receiver, small micro, and an impressive watertight enclosure. Typically I see the micro and/or GPS receiver itself is dead. I'm not sure if heat is the cause or possibly static discharge is, but repairing usually isn't really feasible. Just getting into the thing pretty much destroys the nice water-tight enclosure.

So what to do if your GPS antenna is dead and don't want to spend $100+ for a new one? Simply use any GPS receiver that outputs NMEA-0183 data and feed it directly into the Lowrance spare serial port. This is pretty much every GPS receiver / module ever made.

Each device within the Lowrance family has an optional NMEA-0183 input (and sometimes output depending on device) that allows you to daisy-chain units together. So a single unit connected to the GPS antenna can send the GPS information via NMEA-0183 through multiple units allowing you to need only one antenna. Now the cool thing about this is in the Lowrance configuration menu, you can set which serial input you wish to receive the GPS information from along with what GPS strings you want to receive. This means you can feed NMEA-0183 GPS strings directly into the units spare serial input from any 0183 compatible receiver, not needing to use the Lowrance expensive antenna.

My solution as to use an old 12 channel Cirocomm receiver that I have had laying around which cost about $12. This receiver runs off of 3.3V- 5V and outputs TTL level NMEA-0183 GPS strings. The original GPS  module in the LGC puck can also be used as long as it is not dead itself. To use this with the Lowrance, I added an RS-232 level converter and small power supply to run directly off of 12V. I had these boards already designed and built for Xbee use, it was just a matter of wiring in the GPS unit to make it work. The only downside of this is you need to power the GPS unit directly as the Lowrance does not supply power on the spare serial interfaces like it does on the direct GPS interface. The serial interface requires only two wires, TX from the GPS antenna to RX on the Lowrance unit and ground. You could also interface this into the GPS input connector on the Lowrance, but if you are missing the antenna and cable, wiring to the spare serial interface avoids sourcing the expensive twist-lock connector. Once the new receiver is put together the only thing remaining to do is to mount it in a sealed watertight enclosure, something nice looking so it doesn't look stupid. Also preferably something plastic and white to reflect heat and be transparent to the GPS signal.

To use, set the Lowrance to use the NMEA-0183 input for GPS, then set the correct baud rate and GPS strings your receiver supports ($GPGGA and $GPGLL are the important ones). That is all, the Lowrance should respond indicating it is receiving GPS data and begin to populate you satellite information screen. Multiple units can then also be daisy-chained in the exact same manner.

Lowrance Globalmap 3000 NMEA Config

My Cirocomm GPS unit defaults to 4800 8N1, which is fine and sends $GPGLL, $GPGGA, $GPGSA, and $GPRMC strings, so make sure those are selected in the GPS configuration. If daisy-chaining, make sure the NMEA outputs are also enabled and set to the same baud rate on the sending units.

Lowrance LMS-480 NMEA Config

Note that again almost any GPS receiver can be used to supply GPS information to the Lowrance. Something like an old Garmin GPS 12 also works great as a spare if your antenna dies, simply take its NMEA-0183 output and feed it directly into the input of the Lowrance in the exact same manner.

Both units are daisy-chained off of my GPS receiver. Note testing was in my basement, so no GPS lock here

XBee Interface for the Davis Vantage Vue Personal Weatherstation

About a month ago I finally purchased a good personal weather station, a Davis Vantage VUE. I performed a ton of research over the past few months and the Davis models seemed to be some of the best within a reasonable budget. One of the main features I liked about the Davis models is the wireless capability of the sensor unit and most importantly the two second data update interval. This was important to me as I wanted to be able to submit real-time data up to the Weather Underground utilizing their rapid-fire servers and API.

I had been doing this previously via some home made sensors I had put together, at the time I was sending temperature and humidity data to my Wunderground station (KMIWESTB14) via one of my datacenter temperature monitoring sensors I had built. The sensor was mounted outside and transmitted data via an XBee to a linux server in the basement rack where a simple bash script listened to the serial port, reformatted the data and sent it up to Wunderground. While it was cool, I wanted more data. My station was lame compared to many of the other nearby stations, so I looked to expand. Barometric pressure was easy as SPI/i2c sensors to receive air pressure are cheap and prevalent  but the remaining sensors, notably wind direction and speed were not. These sensors would require mechanical designs (which I am all for building) along with calibration which would be the more difficult piece to solve. Calibrating a wind vane would be simple, but calibrating a anemometer would require a calibrated source or device, I would at least have to invest in a good handheld anemometer to calibrate my home built one. With the cost of these even used not really cheap, I finally decided to retire my station and purchase a commercial one.

The Davis Vantage VUE system is awesome and I have been very happy with it for the first few weeks of using it. The only complaint I have is it did not have any type of available interface to access it by, no direct serial, ethernet, USB, etc. These were all additional add-ons that were necessary to purchase along with the unit. I knew this when purchasing it, and I had plans to reverse engineer it as soon as I received it.

The Davis Vantage VUE console is a rather simple device, the main board has a handful of components which include a common ATMEL microcontroller, so this was going to be easy. Figuring out the pinout on the back of the unit was trivial at best, but it turns out that a group of people already have. A few weather forums out there have a good amount of information on the Davis interface which consists of a 20pin, (2x10) 2mm pitch connector that the factory options can install onto. A pinout of this interface is readily available along with a full API of the serial interface.

Once discovering that a serial interface was available on the back of the unit, my immediate thought was to use an XBee. Checking the pinout of the connector there was also +3V and Gnd available. Perfect! Since an XBee can run between +2.8V and +3.4V,there would be no issues as long as not too much current was consumed eliminating the need for any additional power source. Because I had no data on how much current I could actually draw off of this port, I stuck with a standard XBee (non-pro) as its transmitting current at 3.3V is only 45ma. Assuming it may be slightly higher at 3.0V, it would still be low enough (I had hoped) to run the XBee, and after some testing I proved that it was.

Once some basic testing was made with the XBee to prove that it worked, I designed up a simple board and sent it off. Once received, I threw it together and here is the final device:

It tucks neatly into the back of the Davis console. I chose to use an original V1 XBee (still wearing the MaxStream logo as it was pre-Digi) because it was the only one on hand that I had with a nice low profile chip antenna.

Once I had it installed, which fit very nicely into the back of the console, I wired up another XBee to serial interface on my desktop and powered up the Davis. The unit initially responds with an 'LCD ok' message at the same time the unit goes through its self testing at which point it is ready for commands. The easiest is to send an 'STRMON' to it which will dump all of the raw sensor data from the external sensor unit every two seconds.

I have had this running for a few days now without any issues, the next step will be to rewrite my simple script to grab this new data and reformat it according to the Wunderground API and send it.

One additional note on this, apparently Davis has limited the usability of the serial port on the newer versions of firmware. Luckily my new unit came with the older version of firmware which still allows access to the serial interface. It is unfortunate that this has happened, I can't imagine getting around whatever was put in place to figure out how to re-enable the serial interface would be too difficult, but I am not about to update my unit to find out.

Cooperative multitasking

Sitting down this past weekend for a large amount of time to begin a new project (details will be provided in the next post)... I discovered an amazing feature with Rabbit Semiconductors microcontrollers. Cooperative multitasking. I have actually always known about the multitasking capability of these processors, but never actually used them in any real form.

Cooperative multitasking unlike preemptive multitasking has many benefits. For one, variables can be easily shared among different tasks. This simplifies the necessary code needed immensely as you don't need to take any necessary precautions while sharing variables in a typical interrupt driven preemptive environment. Cooperative multitasking also allows many tasks to be run at once (as they only appear to... time slices are actually given to each function running just like in any modern multitasking OS). The microcontrollers also take advantage of the natural delays that occur in most code execution to provide cpu cycles to other tasks.

Playing with this multitasking environment I was able to update information on an LCD via an array of switches in real-time, without taking any time away from any other running timers or processes. It essentially allows me to run several tasks at the same time while providing data input without the necessity of any type of interrupt. This is extremely powerful.

I have nearly finished the code for the current project tonight, I hope to have the project finished by the end of the week as an update to what this project is will be given upon completion.

Hardware password sniffing and hacking

I recently came across a really cool piece of gear... a rack mounted SNMP network interface unit. This device is essentially a interface that allows you to monitor and control external devices of your choice via SNMP.

There is one issue... I don't have a password to console into it to configure it. Finding a default login password or a reset procedure for this device has been an impossible task. Marconi (the maker of this device) has since been dissolved into several companies making any documentation out there extremely scarce. The only things I have found are links to a manual that point to websites no longer in existence, and very vague product feature descriptions. (if anyone out there does happen to have a manual for this device, please let me know!)

I really want to get this device working, it is extremely flexible and there really isn't anything else on the market that can inexpensively and easily do the same thing.

So here is my idea. Since breaking in through the console port doesn't look feasible, and there is no hard manual reset to restore it's factory defaults, i'm not left with very many options. Opening it up, I discovered that the device contains a 16bit flash eeprom... all configuration information is stored on this device as it's the only writable memory on it. At some point while the embedded arm processor is loading it's basic embedded os/program from prom, it has to load this saved configuration from the eeprom. So I will simply sniff the data coming off of it's data bus with a logic analyzer, convert the two bytes of info into ascii and hope that everything is in clear ascii text. I can't imagine that the data on this device would be encrypted between the arm processor and flash... so this data should be easily retrievable.

Step 1: I obtained the data sheet for the AMD 16bit eeprom and wired the 16 pins off of it's data bus with interfacing leads:

The remaining leads were soldered to points on the bottom of the board.

Step 2: Wire the 16bit data bus to my logic analyzer.

Step 3: Power on the device and capture the data!

The issue I am having now is understanding the data. I have no idea how the arm processor is writing data to memory and what type of endianness it is using. ( it doesn't help that this arm processor manufacturer is no longer in business either :( ). Since arm processors can be configured as big-endian or little-endian I will have to decode the data both ways until I see some legible data. My logic analyzer can take the data seen above and convert it into ascii text, displayable on the screen. It's a slow process, but i'm making progress.

I haven't seen the password yet, but I'm still confident it's in there. There is just a lot of data to sniff through... and a large mess on my bench.