Yup, we are on the same page. I haven't looked into it, but I'm willing to bet an OBDII simulator exists, and if so then the task shouldn't be that hard.
Printable View
Yup, we are on the same page. I haven't looked into it, but I'm willing to bet an OBDII simulator exists, and if so then the task shouldn't be that hard.
I saw a thread in the past week with someone asking for one. They were complaining that no one offers a cheap one. So that may be more difficult than we think. We'll have to see though...Quote:
Originally Posted by cgalpin
Actually, I just found that thread and malcom2073 has already made an OBD simulator and released the source!
http://www.mp3car.com/vbulletin/engi...simulator.html
Yup. I haven't tried it yet but it certainly looks like a good start!
kev000, isn't this what dmix [and the like] are for? I'm sure someone much smarter than I has a reason for this "prioritization" i just don't see it right now.Quote:
Originally Posted by kev000
UNLESS what you mean is one source will have priority over others .. so if music were playing and the GPS software wanted to say something it would mute the music play the gps sound then unmute the music [or phone call or traffic alert or if KITT wanted to say something witty] .. well through posting this i think i got the idea of what you're trying to do, I could just delete this post but a) i already typed it and b) maybe some one else will be confused like I was and this will help.
Yep, that's exactly what I mean :)Quote:
Originally Posted by red_parchel
I know I'm a bit late to this particular party, but I thought I'd throw in a couple thoughts:
Poor man's dynamic web page: For simple dynamic webpages, you could always do a poor man's version. Instead of a php daemon, you could have the component pieces dropping xml/JSON/flat text/etc files onto the filesystem, directly inside the webspace. Then have your html client software just refreshing as fast as you need.
eg, it would be possible to write a small gpsd client program that runs and dumps your current position to a three-line flat text file every second. A client could just reload that file regularly and show the contents appropriately. Another daemon program could grab dbus spam from obdgpslogger and write obd status files to disk.
It would be good, of course, to have a common standard amongst all these ... "daemonlets" for want of a word. But it's a thought.
OBD Simulators: Malcolm's obd simulator has put a bunch of ideas in my head. I'm strongly inclined to write an obd simulator that molests the pseudo serial ports like he does, except instead of pulling data from the GUI dials, it would pull it from an OBDGPSLogger log. Another difference between malcolm's and mine is that I'd be doing a command-line-only flavor, and using straight C instead of C++. This is just an idea that's been festering for a week or two. There'd be huge code duplication though, I suspect, so I'm not quite sure.
Sheeva: I can't afford one at the moment, but I did briefly experiment with the devkit earlier today. I've written instructions here: http://www.mp3car.com/vbulletin/obdi...processor.html on how to cross-compile obdgpslogger to run on the sheeva.
DBus: OBDGPSLogger does support dbus [thanks to a bit of harassment from tripzero], and signals across the SYSTEM dbus.
DBus explicitly isn't intended to be particularly network-friendly.
That's a brief braindump, apologies for any incoherence.
Gary (-;
Gary, input is always welcome at any point in time.
Flat text files are a hacky solution due to read/write access of the file. If the file is locked and you try to write it, it fails and vice versa.
Also, with flat files, you lose your ability to send data back to the server/request specific information. For example, you would never be able to tell the fusion brain to turn on output 4.
PHP is the easiest language out there, why not use it? Oh and you said PHP daemon. We ditched the PHP daemon idea. Theres just a php script that gets loaded every time information is requested and it loads the appropriate classes for collecting the information.
In other words, if I loaded the page http://sheeva/request.php?fetch=GPS.Coords
request.php would load the GPS class in PHP and get the coords.
Then the following would be sent back to the browser:
GPS.Coords.lat=54.26;
GPS.Coords.long =49.28;
The JavaScript on the browser side would then pass that on to the appropriate javascript objects for handling and they would take care of shooting it over to the web browser. Easy enough to code when I have a few hours and a linux box in front of me.
That makes sense. I mean, I know flat text blows, but it's an easy way to prototype :-)
One of the problems is that OBD isn't speedy; there's no way to immediately and obviously say "I want the status of the RPM, throttle, vss, temperature, etc etc" and not have it take a long time without some sort of caching or something.
This is kinda where I pimp myself a bit, but if you're using obdgpslogger, you could connect to the database and "SELECT * FROM obd ORDER BY time DESC LIMIT 1"
Although I think there's an issue with busy locking and the like right now.
Gary (-;
obdgpslogger could accept connections on a port and report the last values it received if it just caches a little....Think gpsd.