Connecting a BR-355 GPS receiver to Arduino with UART (TTL serial)

One of the reasons that I started with Arduino was that I had an idea about making something similar to the ScanGauge II that I read about at ThinkGeek. Reading electronics catalogs I realized that there were lots and lots of different cool sensors that I could integrate into such a design, and after a while I had a quite advanced design idea that may never be fully realized. After a year or two I came across the Arduino concept again, having read about it in magazines a few times, and decided to use this platform to try to implement at least parts of my idea.

One of the other sensors, apart from the OBD-2 interface, that I wanted was a GPS. That way I can keep track of fuel consumption on different roads, compare fuel economy between trips (especially the more common ones, from my house to work, to my  sons kindergarten and to local supermarkets and stores), and also get an idea about whether the car is going uphill or downhill, and in some future maybe get my device to give me advice on how to drive in order to save fuel even on roads not travelled before. To store data I will also want data logging, to SD card or USB stick, and maybe I will also implement automatic transfer of data to my home server over an Xbee link. (With the position from GPS the device I can turn on the Xbee when I am getting close to home, and start scanning for the home mesh network.)

Since I will probably end up with a device that is quite a bit bigger than the ScanGauge I may want to keep it lower down in the car, maybe on the floor with a cable to a unit with display and buttons on the dash. If I were to use a small embedded GPS unit it would not get optimal reception conditions stuffed in a box under the seat, and those embedded units are a bit too expensive for my taste, too. An external unit appeals more to me since I can then place it whereever I want, to get the best possible satellite reception.

My choice from the locally available units was the GlobalSat BR-355 for which I payed 399 SEK (about $55 USD, 39 EUR, todays conversion rates). It is a small waterproof receiver with a 1.5 m cable ending in a 6 pin mini-DIN male contact (same as PS/2 on mice and keyboards, different pinout), and it uses a SiRF Star III chip. I have used a GlobalSat BT-359 with different phones and found it to be working great, also having a SiRF Star III chip giving it excellent reception even indoors, so I have good experience with GlobalSat and with SiRF Star III. In the specifications I found the pinout (also available e.g. at the Hardwarebook site), and it also says that the communication is serial at TTL level — just what I wanted. So I bought it, cut a PS/2 keyboard/mouse extension cable in two, found the right wires with a multimeter and soldered a female header to the cable. When I connected it to an Arduino the GPS lit up and something happened on the serial line, but I did not received what I had expected.

I kept trying for a while, ended up buying a USB adapter cable in order to try the unit with my computer and GlobalSat’s own software. Using the adapter cable it worked fine, as expected, but not with the Arduino. So I bought a logic analyzer (Saleae Logic), used the other part of the extension cable to make a breakout cable, connected the GPS receiver to the first adapter cable, connected this to a breadboard connected to the logic analyzer and the second custom cable which in turn connected to the GlobalSat USB adapter and the computer. I was able to use the receiver from the computer, and Logic showed the expected short transmissions with a period of about one second, but still the character stream was not the NMEA sentences that should have been there, and that were transmitted according to the computer. Finally I found that if I told Logic to use “idle low” instead of the normal “idle high” I would get the correct character stream except that each byte was inverted (c xor 0xff). Since the “idle low” setting in logic only applies to the idle level, start and stop bits, but not to data bits, I deduced that the whole signal was probably inverted.

So the next step was to dig out a 74HC240, make a small test circuit on a breadboard using this chip to invert the signal from the GPS, and connect the whole thing to the computer again, this time through a Sparkfun 5V FTDI Basic breakout board (i.e. at the same levels as the Arduino uses). Finally it worked.

Summary

bt-355-to-serial-sch

The serial signal from the BR-355 is logically inverted, and simply running the signal through a 74HC240 (or e.g. 74HC04) makes it a standard TTL level serial signal ready to connect to a UART on the Arduino or other MCU. I ran the TX signal going to the GPS through the inverter too, but I have not done any real testing so I can not promise that this works as it should.

Eagle bt-355-to-serial-sch and bt-355-to-serial-brd.