Thread: logging suddenly stops

I suspect you may need the -m option to make it daemonise; rc.local shouldn't contain anything that blocks, which obdgpslogger is effectively doing if you don't daemonise it. I don't know why it's exiting; it may be that init notices something is wrong [ie, rc.local blocked] only after you try to do something else on the system.

If you're having gps problems, it may be because what you really need is to be sure that obdgpslogger starts *after* gpsd connects to the device; At the moment, obdgpslogger only makes one attempt to connect to gpsd. I'm planning on changing this so that it keeps trying occasionally if it couldn't get a connection first time around.

In the meantime, I resolved this with a little script called that waits a few seconds before launching obdgpslogger; it basically pauses execution for a few seconds, to give gpsd a chance to start. That's not ideal, and a much much better solution is to fix obdgpslogger to reconnect once in a while [as above]. The script is is doc/ in svn, called udev_delay.sh. That script does some other stuff that you can probably mostly take out. I put some other thoughts in the same doc dir, in the file auto_launch

Assuming that your system is using udev, I strongly suggest using udev to launch obdgpslogger instead of rc.local. It works the same way on bootup, but obdgpslogger's launch is tied to the actual usb device rather than the system startup. Sure, udev is irritatingly opaque to configure, but it'll also still work if the device ordering changes or you hotplug your USB devices. The docs linked above provide a few samples on how best to configure udev to work for you.

Gary (-;

The gpsd problem is actually unrelated, I think upgrading to gpsd 2.90 would solve this, as I tried it earlier in with my laptop. I'll try it tomorrow on the carpc. I'll just have to remember to recompile obdgpslogger or else it wouldn't work (right?).

I was actually thinking of getting it to run in the background, but I couldn't find how. I didn't spend that much time looking, just an obdgpslogger --help. I just checked the man page now and it's there.

I'll also have to look into udev a lot more. My searching mostly pointed to udev being the better option but it wasn't working for me then. I'll try switching to udev the next time I work on this.

Thanks! Really helpful to get better input regarding this.

Yeah, 2.90 is a different tool using a different API. You'll need to re-build from scratch [including re-running cmake; I suggest rm -rf the build dir and starting again from scratch].

I still haven't actually been able to *try* gpsd 2.90, so the code may be incorrect. Please let me know [eg, strange lockups or crashes, or just never logging gps data]

Thanks,
Gary (-;

I just read on udev, and its pretty cool. Definitely switching to this later. I'll probably set a rule for my phone too or usb drives to copy out the most recent databases(I plan to create a new one per day) to it automatically as I don't have any other interface yet to my carpc other than an ad-hoc network and ssh.

I haven't had the time to fiddle with gpsd and obdgps logger again yet, but my last attempt went something like this:

I started gpsd 2.90 manually, then checked cgps to see if it's working fine. I see that it is indeed working, and move on to obdgpslogger.
It starts fine, I see the lights on the obdLink blink, and the output indicates it found the obd device and gpsd. It says Creating new trip... but it stops there. obdLink LEDs stop blinking, and only one row is in the table.

I haven't fully tested this so I may just be missing something. This time, I remembered to:
unmerge then re-emerge gpsd properly
remove all obdgpslogger files from /usr/local/bin
remove the build directory
run cmake then ccmake to change the devices to /dev/obd and /dev/gps
make && make install
then ran the proper commands

It's almost certainly locking in the gpsd_poll call. I saw that once before, but can't remember how I changed it. *strangled sound*

Oh, also, I committed a change to obdgpslogger last night where every five seconds [or so], it'll attempt to create a connection to gpsd if it didn't get connected at launchtime. That may resolve some of your cold boot problems. Note that that won't help if gpsd "goes away", though.

Gary (-;

I forgot to put in a step there that I did...
iptables --flush

that got me stuck for quite a while a few days ago. I forgot to put accept on the loopback device. I just flushed to make sure its not the firewall.

I'll try that update tomorrow and maybe dig into the code too!

I'm not sure if its gpsd that's causing my problems, but here's what I tried when I was checking on this.

I pretty much extracted the gps related code from obdgpslogger and came up with this:

note: I don't usually use C, so if there's anything wrong here, let me know.

Code:

  #include <stdlib.h>
#include <gps.h>

static struct gps_data_t *gpsdata;

int main(int argc, char * argv[]){

  int mustexit = 0;
  double lat,lon;

  printf("Starting gps client\n");

  gpsdata = gps_open("127.0.0.1", "2947");

  if(gpsdata == NULL){
    printf("Error: Unable to connect\n");
    mustexit = 1;
  }
  else{
    printf("Connection established\n");
          gps_stream(gpsdata, WATCH_ENABLE, NULL);
  }

  if(mustexit)
    exit(1);

  gps_poll(gpsdata);

  if(gpsdata->fix.mode < MODE_2D){
    printf("location available\n");
    lon = gpsdata->fix.longitude;
    lat = gpsdata->fix.latitude;
  }

  printf("lat: %f\n",(float)lat);
  printf("lon: %f\n",(float)lon);

  gps_close(gpsdata);
  return 0;
}

I then tested it out with gpsfake running on a test log I found from the gpsd svn. Approximately 1 out of 20 times, I get to the end of the code(but the numbers are always "nan"). Most of the time though, it'll stop at "connection established", and my cpu utilization would skyrocket because of the client.

I tried to look for a guide on how to use the C library properly, but I couldn't find any.

I tested this out on three systems, all running gentoo, gpsd 2.90, two are 64bit, 1 is 32bit. I'm guessing this is a gpsd problem?

So the root cause of this was that gps_poll blocks. There's a POLL_NONBLOCK option, but I was advised not to use it for now by the gpsd maintainer.

Borrowing from cgps, I've put a select in there so that it'll only call gps_poll when there's data waiting to be read.

At the moment, it's still broken: no data appears to be waiting most of the time, and then suddenly it starts polling after a minute or so - but no fix is ever attained. I'm highly confused.

But at least if you svn update right now, it no longer starts and then blocks immediately - it won't log gps, but it will log obdii.

I'm still working on this!

Gary (-;