[obdgpslogger] sampling rate

[Gary Briggs]

On Mon, Apr 28, 2014 at 05:10:02AM -0400, ken f wrote:
> obdgpslogger is compiled and installed on my Raspberry Pi.  Initial
> testing indicates it's working fine except the sampling rate is
> significantly slower than what I specified, both on the command line
> and in the config file.  In one test I used:
>
> obdgpslogger -b 38400 -d ~/logs/obddb-${time} -u
> ~/logs/obdgpslogger-${time}.out -l ~/logs/obdgpslogger-${time}.log
> -a 1 -i temp,iat,rpm,throttlepos,vss,fuelsys,load_pct
> 
> (Ignore any line-wrapping your email client might have done.
> Commands were entered all on a single line.)
> 
> Instead of getting ECU data once per second (as per "-a 1"), it came
> very close to once every three seconds.  I ran tests specifying in
> the config file
> 
> baudrate_upgrade=0
> 
> and then
> 
> optimisations=1
> 
> but still only got back ECU data once per three seconds.
> 
> During these tests I ran "top" and it showed a load average of only
> 0.5 (thereabouts), so the code isn't at all taxing the Pi's
> processor.
> 
> Though baudrate_upgrade wasn't able to get a connection faster than
> 38k, that should be plenty fast enough for the meager amount of data
> being sent and received.  (I recall from earlier times how
> 'incredibly fast' my 9600 baud modem was, that it could put data
> onscreen way faster than I could ever possibly hope to read it...
> the amount of data coming from the ECU is much, much less than that
> was.)
> 
> So unless I'm missing something, I can only imagine that my car's
> ECU is the bottleneck, and/or that it can't return the amount of
> data I'm asking for any faster than once per three seconds.  (If it
> matters, the car in question is a '98 BMW 318i.)
> 
> What kind of speed are others getting?  Is anyone getting a better
> rate than I am?  If so, how?
> 
> Thanks for any tips and info.  obdgpslogger is a great and very
> impressive mass of code, absolutely the best FOSS I've found for
> OBD... and, must say too, very impressive for /any/ kind of FOSS
> I've seen. Many thanks to the author.

I'm very flattered, thank-you :-)
[not to say there aren't a number of things I did egregiously wrong in
retrospect... one day I'll get around to fixing all those things...]

OK, my immediate question is about hardware: What dongle do you have? Is
it something cheap off ebay, or is it one of the premium ones?

I've had experiences consistent with what you describe with cheapo
ebay dongles. Low CPU utilisation could be that obdgpslogger is
voluntarily sleeping, or it could mostly be blocked on serial i/o.

To test it out, do this: set samplerate to zero ["-a 0"], and sample
exactly one thing ["-i rpm"].

In the output logfile, the number of rows is the raw number of samples
taken [when you sample multiple PIDs, it'll be num_rows * num_PIDs]. So
start there, do one run for a while, and see what observed samplerate
you get. My guess is that it'll be about the same as you see right now.

Another comparison to try is to run obdsim with the obdgpslogger you have,
on the hardware platform you're currently using [pi + SDcard/etc]. With
ELM optimisations enabled, obdsim generally is *fast* at responding.
Give that a try, and see if your samplerate goes up; it's an
easy way to identify if you have car-and-OBD-hardware-slowness or
obdgpslogger-and-raspberrypi-slowness

Your car pre-dates 2002, so some of the "optimisations" may not actually
work properly with your car. That being said, my experience is that BMW
are relatively well-behaved in that regard.

Let me know how it goes!
Gary