[obdgpslogger] sampling rate

[ken f]

On 04/28/2014 12:14 PM Gary Briggs wrote:
> 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.

I forgot to mention in my previous post that I also ran iotop and it 
showed nothing which could be called a burden on I/O.


>>
>> 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...]

It's not flattery if it's accurate and you deserve it.

Gary, if points of possible improvement were noted in the code and/or in 
TODO, perhaps enterprising coders might take a run at them.

On that note, my brain couldn't readily translate the output in epoch 
seconds so I composed a few lines of C to convert that into what "date 
+%F %T" does (except the C runs a smidge faster and also rounds up when 
the fraction of a second is a half or bigger, which the "date" utility 
doesn't).  Not wanting to possibly slow down obdgpslogger, I 
incorporated my 'date' function only into a bash script for 
post-processing squlite3 output into an html page... which, per 
<http://www.newcultures.com/obd>, is still very much a work-in-progress.


>
> 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?

Good question.  The one I got is <http://www.obdtester.com/elm-usb>, 
which claims not to be made in China, but other than that I have no way 
of knowing or judging, not a clue about possible metrics or anything 
else which might indicate its actual quality... in terms of demonstrated 
functionality.  A little utility which would exercise various dongles 
and produce useful metrics about them would be handy here... and in a 
way totally subversive to those whose business relies on ignorant 
consumers like myself.

Are there any particular dongles known to perform well...? or some 
already existing way to assess them objectively?


>
> 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.

Just so I get this right the first time, that would be:

obdgpslogger -s /dev/ttyACM0 -a 0 -i rpm -d dongle-rate.db &

I guess I should also mv /etc/obdgpslogger off to something else to 
prevent it from possibly confounding this dongle-rate test. (?)


>
> 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

I'd love to do this one, but after reading the odbsim manpage back and 
forth a few times, I still can't figure out what all the options should 
be.  And, if obsim simulates a dongle, I suppose I should then run the 
above obdgpslogger command, but instead of /dev/ttyACM0, using the 
pseudo-device created by obdsim, yes?


>
> 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.

Good to hear.  Yeah, BMW does a lot of stuff right and better than the 
average car.  Makes it worth the higher entry and maintenance costs... 
most of the time.


>
> Let me know how it goes!
> Gary
>

Will do.