Linux Web Front End Development Thread

[chunkyks]

Yeah, I was thinking about that, especially if I create a --daemon option.

*throws it on the idea pile*

The problem is, as always, that that's adding a lot of complexity to an otherwise pretty simple program.

Another option is something like that, but caching data off the dbus stream. A separate small program that does exactly what you describe.

I think this needs a week to fester in my brain before a decent solution appears.

Gary (-;

[PaulF]

Good call on the OBD speed issues.
Charles is the one who went against the idea of MySQL as a middle man. I figured MySQL as a middle man would be great because there would always be information INSTANTLY available. No real locking problems would exist. Maybe a millisecond wait though. We can do that on an as-needed basis with plugins tough.

[cgalpin]

Again think about how gpsd works - this really is no different. It sits and listens on a port for data, and one or more programs can ask it for that data and be independent of the device specific details and responds very quickly. I think for odb data we need the quivalent.

Then you layer apps on top of it. The logger portion can put it into a database for historical data, or a circular buffer etc. and apps that want that data can ask for it But other apps can just ask for current data and get that quickly in a consistent way.

The core daemon would be a good place to keep rolling averages, deltas etc but it
shouldn't be heavy.

I don't know enough about dbus to rule it out as a good way to access the current obd data.

charles

[PaulF]

I don't know enough about OBD II GPS Logger to tell how long it would take to access information over DBUS. This is going to take some time and testing.

To Gary... when you request OBD data via dbus, does it just instantly get the most current information or does it wait for the OBD information to load and then send it through dbus?

[chunkyks]

PaulF: I'm actually signalling using dbus, rather than operating as a {whatever they call their synchronous-ish RPC mechanism}.

So what happens is, each time obd gps logger has a sample it posts it to the system dbus. Anything listening at the time gets the data. Anything not listening doesn't.

I know how gpsd works, it's just a lot of work to engineer a protocol that doesn't suck then implement it [such that you're allowed multiple sockets connected at once, working effectively asynchronously]. It's not that it can't be done, or that I don't know how, it's that it'll take a while and I have lots of things on my plate :-/

Gary (-;

[PaulF]

Alright so it looks like we're going to need a simple daemon that is just sitting and listening for information on dbus from OBD.

[chunkyks]

Quote:

For anything I use the FB for that has OBDII analogs, I'd like to create a ODII simulator which servers the data collected just as if you'd get it from an OBDII vehicle.

*cough*

Last night I went into a bit of a coding frenzy. I've written the first 3/4 of a simulator that does exactly this, borrowing excessively from malcolm2073's code.

It talks ELM327 [currently honors ATS{0,1}, ATE{0,1}, ATZ, and recognises but doesn't yet honor ATH{0,1}. Others on the way].

My plan is for it to actually consume obdgpslogger logfiles - you feed it one of my logfiles, and it pretends to be the car that was used to create those logfiles in the first place.

"Only" thing left to do to have something fully functional is to make it actually pull the values from the database before outputting them, rather than making them up as it does right now.

Any advice or input before I write the other half is greatly welcomed.

Obviously I feel like I'm kinda dangling a carrot and pulling it away since it doesn't actually work yet, but I wanted people to know it's on the way rather than invest their own time.

Gary (-;

[cgalpin]

Quote: Originally Posted by chunkyks

Any advice or input before I write the other half is greatly welcomed.

Obviously I feel like I'm kinda dangling a carrot and pulling it away since it doesn't actually work yet, but I wanted people to know it's on the way rather than invest their own time.

Gary (-;

Sweet!

The only thing I'd suggest is also consider making it have a switch/mode that registers for the dbus signals from your logger and caches the last value. That way we'd just have to reproduce the equivalent signals from a FB daemon and we'd have a usable OBDII replacement!

It might even be a good way to test your simulator (think of it as a proxy and you can compare what you got against what you serve from the simulator for testing).

[chunkyks]

Few things:

1) This is completely standalone. It depends on some shared code inside the obdgpslogger source repo, but I'm explicitly keeping it entirely independant of the logger itself; partially because it's a good idea, and partially because I want it to be useful for other people too.

1a) But since it is primarily a tool to work with obdgpslogger, I will probably focus more on building ELM327 features required by obdgpslogger [ATE0, ATS0, etc] than I will on just trying to complete an ELM327 1.3-compatible tool.

2) It's just a simulator, it opens a pseudo terminal and obdII clients can connect to it - I'm trying to maintain a strict unix-y "one tool for one job" mentality throughout my codebase. I'm still not closed to the idea of having obdgpslogger a gpsd-socket-style thing, but I'm only one man and there's only so many hours in the day.

3) This will never reproduce results exactly - if you run it with a logfile, and use obdgpslogger to log to another file, you won't get the exact same results. Among other things, it's impossible to get exactly matching timestamps or GPS data. But what it *is* doing is linearly interpolating through the database stepping time forward at an equivalent rate; If you try to sample 100 times a second from my sim, and feed the sim a log sampled 5 times a second, and draw the graph afterwards, you'll get the same graph outline as you do with the source data - you might just get different datapoints along it.


And now for the rampaging SQL nerds; this is how to estimate a value for vss at time t, given an obdgpslogger logfile:

Code:

SELECT
   (s.time + ((t-s.time)/(e.time-s.time))*(e.vss - s.vss)) AS estvss
   FROM obd s, obd e
   WHERE s.time = (SELECT MAX(time) FROM obd WHERE time < t)
   AND     e.time = (SELECT MIN(time) FROM obd WHERE time >= t);

That's why my obdsim is hopefully going to meet my needs better than any other software sims. It even takes a good guess at how to respond to 01{00,20,40} based on what's in the database. Wooooo.


I think I'm probably just going to go back into my shell now, rather than continuing to promise the sun & stars. Rather than de-rail this thread anymore, if you do want to discuss obdsim specifically a bit more, perhaps we could take it to my project's own forum?

Gary (-;

[chunkyks]

A quote from a few days ago:

Quote:

For anything I use the FB for that has OBDII analogs, I'd like to create a ODII simulator which servers the data collected just as if you'd get it from an OBDII vehicle.

I just announced obdsim on the obdgpslogger forum:
http://www.mp3car.com/vbulletin/obdi...ml#post1321903

Specifically meeting the original comment here, one of my features:

Quote:

It reads the database created by obdgpslogger, and when asked what it supports [via 0100/0120/0140/0160], it responds accurately with a list of what it found based on columns in the database. Short version, it really pretends to be the car the log was originally created in.

Have fun,
Gary (-;