Thread: New Release 0.4: Now includes tasty GUI

Well I nearly got this working (!)

After all the fun of getting the OBD scanner working (dozens of windows tools - mostly useless) (finding a decent usb driver) then getting gpsd working with a bluetooth GPS (flakey to say the least) then finding cmake then finding time to get it all together and in the car and ...

... I now have one database where just the obd was working fine and entering data (no idea what happened to the gps data) and one database where the gps was working fine and entering data but the obd was just throwing "[HL]OBD reported NO DATA for cmd 05: NO DATA[/HL]" endlessly and not recording anything in the db! (instead of using the trip functionality I was making separate db each time since an earlier SQL-related error spooked me into avoiding any chance of bad data confusing or corrupting any good data).

Hopefully I'll get another chance to try and get it running better tomorrow, or more likely sometime at the weekend, but it's been a struggle so far. I'm not really a coder - if make "doesn't" and google doesn't have any clues for me I'm generally stuck.

Here are some things that tripped me up. (Intel Macbook Air 10.5.6, OBDpros USB, GlobalSat BT-368)

• I don't think cmake is installed by default with Xcode
• Current version of cmake (2.6-3) doesn't generate valid Xcode (3.1.2) projects despite listing it as a viable generator
• gpsd (2.39) doesn't always detect the GPS unit properly - it connects at 9600 and needs 'prompting' by briefly running the GPSUtility program included with the GlobalSat (which says it connects at 4800) - this usually wakes up gpsd
• No idea whether gpsd needs to be run as root or not - nor whether I should use the /dev/cu.BT-GPS... (which works) or /dev/tty.BT-GPS... (which maybe worked) or even the serial port osx said it had assigned to the device for me.
• FLTK apparently is available somewhere (I have X11 and Xcode) but I've never found it - so no GUI for me so far
• Probably another half-dozen things I'll remember later

I'll post again when I have a nice image to share!

Thanks for trying it out!

OK, so, your problems:

0) OBD GPS Logger not doing what you expect.
I'll bet that the first time [where you couldn't get gps data] was linked to gpsd starting before you turn on the receiver or something. I'll make a comment about how I run gpsd in a minute...

The second time, I don't know what's up with that. NO DATA errors are usually what you get if the engine isn't running, or something like that.

Check that your OBD device is fully plugged into the port in your car, I've had mine wiggle out a couple times while driving that caused serious confusion.

1) GPSD stuff.
I use gpsd with your exact receiver. gpsd does have a protocol for reconnecting to bluetooth devices [or any devices], but really it's a PITA.

What I do is, start by turning on the receiver, then run
gpsd -N /dev/cu.BT-GPS...

The -N causes it to not go into the background. Then I can close gpsd when I'm done. Really the whole getup for gpsd to work with bluetooth is a bit hokey IME.

You want to use ./dev/cu.{whatever}. That's what mac calls things that look like serial ports, and gpsd and obdgpslogger want serial ports. You shouldn't need to run it as root but if you do, just check that your user has permission to use /dev/cu.{whatever}, and you'll be fine.

2) cmake
Yeah, I always forget it doesn't come in the box by default. I use fink on all my macs. After XCode, fink contains just about everything that you'll ever need to run other projects [except gpsd... *grumble*]

The bug where it generates an XCode project that doesn't work is something I know about, I just didn't get around to fixing it yet. That's pretty much just *my* bug, not apple's or cmake's.

3) Other stuff
fltk and fluid, also both in fink :-)

OBD GPS Logger does its best to not corrupt the database, at all, ever. It only puts things into it that are known-good. The only problematic one is trips; it puts a trip into the database at the start time, and then updates it later with the end time. I may change this so that it does a single insert later, but for now the way it works [such as default values, etc], will just mean that your trip doesn't appear in the output, rather than breaking anything.

Thank-you very much for trying it out, and lemme know how it goes!

Gary (-;

Originally Posted by chunkyks

The second time, I don't know what's up with that. NO DATA errors are usually what you get if the engine isn't running, or something like that.

Check that your OBD device is fully plugged into the port in your car, I've had mine wiggle out a couple times while driving that caused serious confusion.

That is quite likely - I have an angled connector which points towards the door and I'd been in and out of the car between trips.

I'll have another go tonight -- it's close!

Success!





Apart from accidentally saving a database called "b" ... because "-db" isn't an option it all went very smoothly. First time I started the gpsd/logger, for some reason gpsd decided to connect straightaway and (probably because I ditched the "bluetooth safe" -b option) it sniffed a proper sirf connection instead of the default nemea thing.

For some reason after switching the engine off and being very careful to restart everything in the exact order I did the first time when I restarted it the gpsd decided it couldn't see the unit anymore until I briefly ran the GPSutility that seems to wake it up.

Is there an OSX equivalent to 'par' that I used to use occasionally back when I had a proper unix (Irix) ? It was very handy for tracing system calls made from non-debug binaries, I'd like to see what GPSutility is doing to wake up the gpsd/gps connection.


(ps. don't mock my on/off approach to the accelerator pedal, it's an empty road and late at night ! )

Woooo! Congratulations, those look awesome.

I used bluetooth safe for a while too. After I got some decent traces, I decided that worst case I'd brick my forty dollar unit and get another. Best case I'd quit having to worry about bricking my forty dollar unit.

I actually keep pondering changing the args around so you don't need to pass --database, it just assumes [on each of the cmd-line apps] that the first argument after the -args is a database filename. Might add that.

Not really sure what good tools there are on OSX to do what par did. Solaris has truss [good times, good times. rot in hell.], linux has strace.

I pretty much use Shark for everything that might even conceivably work like that on OSX nowadays. There's obviously dtrace, but I wouldn't know how to ask it to do what par used to do [I'll bet it's easy though]. Supposedly ktrace is a weak but tolerable equivalent, but my leopard machine doesn't have the binary installed [although it does have the man page. ... ?]


You have no idea how stoked I am to see someone other than me posting google earth screenshots :-D
Doubly awesome is that you're driving around my old stomping grounds where I grew up :-D

Gary (-;