Thread: Build on Linux

Originally Posted by longfeltwant

The output of the stderr pane of the "Raw Output" window is

execlp failed: No such file or directory

Oh. obdgpslogger isn't in your path anywhere. I presume you're running from the build directory instead of having done a "make install". Try adding the bin directory to your path, something like:

Code:

mkdir build; cd build; cmake ..; make # Usual build instructions
# While still in build:
PATH=`pwd`/../bin:$PATH; export PATH
obdgui

Basically, just adding the bin dir to your path so that execlp will find obdgpslogger.

Originally Posted by longfeltwant

And while we're debugging, I'm interested in pursuing the reason I see "OBD reported NO DATA for cmd 10: NO DATA" when I spam stdout. You say that is the actual text returned from the OBD device, where in the code would I look for that? In fact, if I want to look at the code, do you have a recommendation where I should look at first?

The code that actually sees "NO DATA" is in obdserial.c line 139. It literally looks for the string "NO DATA" in the buffer.

Hrm. What I really need to do is add a real OBD logfile to this...

Originally Posted by longfeltwant

I have attached my obdlogger.db file

Hrm. That contains gps data, but no trip or OBD data. Trip data is done automatically when obd data is added to the database...

Ah. Looking at the whole logical flow of the program again, if any single item fails, then it assumes that whole row is a bust and starts again. [main.c, lines 410 to 427 gets the data, then lines 429 to 451 write it to the database]. Evidently one item is regularly failing for you, more than just the occasional "NO DATA" line.

Try adding a printf before the break in main.c line 425:

Code:

printf("cmd: %02X [%s] failed, returned status %i\n",
          obdcmds[cmdlist[i]].cmdid,
          obdcmds[cmdlist[i]].db_column,
          obdstatus);

It should show you exactly which command is causing the problem each time.

Also, can you run obdgpslogger with the "-p" option, which prints a list of all the commands your car reports it's capable of.

Gary (-;

Great progress! I got it all running including the GUI today. First I manually fired up gpsd, then I started obdgpslogger from the command line. I tried both with spam-stdout and without it. I could see GPS data and OBD data printed. Then I quit that (ctrl-C) and fired up the GUI. I tried it both by running gpsd myself, or running gpsd from inside the GUI; both worked. I had only minor problems. If I left it running when I turned off my engine, the program would continue to print GPS data without OBD data; and if I turned back on the car the program would automatically start showing OBD data again. That was all really great!

When I was done I had a 40K obdlogger.db file in my home directory. When I run obd2csv, however, I still get nothing but a text file with headers only. I decided to install sqlite3, so I'm going to try to probe the database.

Oh, now I understand what you typed in your last reply. You said that one piece of data must be regularly failing, and you are right, it is. I can't say exactly which one it is, maybe oil temp. I'll try to debug that. But, it might be best if the software would write the line to database if any of the data is valid, instead of only if all the data is valid. I want it to log as much as it can get its hands on, so I will have the most data to work with when converting to CSV/KML.

That brings me to the question of updating the code. If I modify something, how should I submit that back to you? (Do you want that?)

What coding environment do you use? Do you use Xcode on Mac? or do you have a process on Linux? Do you just use emacs, then cmake .., then cmake install ..?

If I left it running when I turned off my engine, the program would continue to print GPS data without OBD data; and if I turned back on the car the program would automatically start showing OBD data again. That was all really great!

Aye, I call that feature "trips"; when you export the data to google earth, you'll find it actually does separate trips as separate graphs. It automatically starts and stops trips when the engine is running. This way you can have a single database containing a whole bunch of trips, and it'll magically "do the right thing". http://icculus.org/obdgpslogger/examples/testingtrips/ was the first outing after I implemented it.

But, it might be best if the software would write the line to database if any of the data is valid, instead of only if all the data is valid.

Yes, after this email thread I have realised that this is a better way of doing stuff. I need to figure out correct program flow to make it all not screw up, but that might be committed before the end of this evening.

That brings me to the question of updating the code. If I modify something, how should I submit that back to you? (Do you want that?)

Absolutely! You can post it here, or on the mailing list, or to me personally, or whatever.

If I wasn't interested in what other people had to say, I'd probably never have posted it at all, or wouldn't have posted the source :-D

What coding environment do you use? Do you use Xcode on Mac? or do you have a process on Linux? Do you just use emacs, then cmake .., then cmake install ..?

Hoooo boy. I actually use lots of different tools depending on my mood. Well, you asked:

I'm using cmake as the build system, so there's always a "mkdir build; cd build; cmake .." involved.

On OSX, I sometimes use XCode ["cmake -G Xcode .." instead of "cmake .."] which exports a .xcodeproj bundle instead of unix makefiles [I do explicitly support it, had to change cmake in a couple places to make it work]. For really big projects on OSX, I lean heavily towards XCode.

On Linux and OSX both, I mainly use screen + vi. On archaic unices, vi.

On Linux, Windows, and OSX I use netbeans a lot. I have a netbeans project I've been using but haven't committed yet. Don't really know if I want to bother committing something tied to a specific IDE/editor. Of all the IDEs that aren't XCode, netbeans is hands down my favorite.

Most of the time I don't use obdgui. When I do, I set PATH by hand before running it. On OSX, "make install" does work, but I like the package more, it enjoys the mac kool-aid a lot better - although isn't as conducive to command-line usage. Most of the time, for things undergoing rapid development, I find "make install" to be a PITA step I try to avoid.

One of the joys of cmake is that you can pretty much use it as you see fit - I'm endeavoring not to force anyone to use anything they don't like, even emacs users ["heathens", in common parlance] are welcome.


Oh. Brief bit of evangelism before I turn back to a normal person:
valgrind alone is sufficient reason to port *any software*, *ever*, to Linux.
Shark alone is sufficient reason to port *any software*, *ever*, to OSX.
Anytime I want to debug something, XCode's gdb front-end is definitely my way of choice.

Just wanted to throw that out there to all the single-platform heathens.

Gary (-;

PS I don't really hate emacs users. Personally I always suggest people learn both [when I'm asked by a budding unix user which they should choose], and pick the one they prefer.

PPS Then, two months later, I spit on them if they pick emacs.

Also, I feel bad; I feel like this is way way harder for you than it should be. Please accept my humble apologies!

Gary (-;

It worked! So I was futzing with it all night. I did

Code:

obdlogger -p

to see the capabilities of my 2005 Jeep Liberty. I wish I had the output right now, but I don't, but the important thing is that it was missing code 10, which is why we were seeing the NO DATA for command 10.

So I went in to main.c and looked at lines 410 - 427. I simply removed the conditional statement around the part that pushes data to the database, so that it would always do that no matter what. Unfortunately I didn't get a chance to test that because I ended up riding in a different car. However, I did run obdgpslogger in that car, and successfully got trip data, and successfully used obd2cvs and obd2kml to export it. I opened the KML file in Google Earth and saw my trip! That's proof of concept, so I'm pretty happy about that.

I did make one easy improvement to your software. Your GUI uses the same configuration value for the OBD device and the GPS device. I added another value for the GPS device in your CMakeLists file and in obdconfig.h.cmake. Now I have the GUI set up with default values so I can easily open it, start the GPSD, and start the logger.

I need to spend some more time reading your code, then I'll dive in and see what I can do. If I can get it to run consistently and stably on Linux in my car with few hangups, then the major modification I want is to add photograph references to the KML file, and maybe other annotations.

Originally Posted by longfeltwant

the important thing is that it was missing code 10, which is why we were seeing the NO DATA for command 10.

Ah. That's Mass Airflow. Without that I don't know how to calculate mpg, perhaps start a new thread asking for wisdom on how to get MPG without MAF, if you want?

So I went in to main.c and looked at lines 410 - 427. I simply removed the conditional statement around the part that pushes data to the database, so that it would always do that no matter what. Unfortunately I didn't get a chance to test that because I ended up riding in a different car. However, I did run obdgpslogger in that car, and successfully got trip data, and successfully used obd2cvs and obd2kml to export it. I opened the KML file in Google Earth and saw my trip! That's proof of concept, so I'm pretty happy about that.

Awesome.

Currently, the list of things that the system logs are in obdinfo/obdservicecommands.h; if you edit that and change "maf" [with the quotes] to NULL, the software will just not bother logging that. I've just added to my TODO list "Only log things that the car reports it's able to log.", which will also neatly fix that problem.

I did make one easy improvement to your software. Your GUI uses the same configuration value for the OBD device and the GPS device. I added another value for the GPS device in your CMakeLists file and in obdconfig.h.cmake. Now I have the GUI set up with default values so I can easily open it, start the GPSD, and start the logger.

Grrr. I already had that done on another of my machines, I just hadn't committed it. No idea what possessed me to commit code where we assume the gpsdefault port is the exact same one as the obd port, that doesn't even make sense.

It's committed now, sorry :-(

I'm glad things are getting working properly!

One other thing you can look forward to is a couple of beefy performance improvements in the next day. SQLite is being a performance bottleneck right now, and I've received some incredibly useful advice from Graham McKechnie on a couple other optimisations.

I've thought more about what to do with certain specific columns failing. I think I might keep the current flow [if any single one fails, then don't log that row], but have a loop in the start of the app that ensures we don't attempt to log anything that the car claims it's not capable of. All the code is already there, I just need to futz it together. Whaddya think? The engineer in me feels it's a "better" solution, but the realist in me suspects it'll still break on certain cars.

Gary (-;

Little burst of commits:

1) Couple optimisation things. We strip all spaces from the obd communications, reducing its cost overhead by 1/3.
2) Serial logging. Passing the -l{filename} parameter on the commandline will log all serial communications to the listed file
3) broke out obd capability listing code, make it more generic
4) use obd capabilities to only attempt to log things car claims to be capable of
[in your case, you should now see something on stderr like "OBD PID 10 [MAF] unsupported"]
5) Make the default gps device in UI separately compile-time configurable
6) Couple days ago, I moved obdgpslogger source into its own subdir. Whole thing feels cleaner now.

I'm sure there'll be more today, but I figure that's a healthy start.

Gary (-;