XEDE serial output protocol?
I'm definitely interested. I've been considering building something like this. What do you guys think would be the best way to develop the xede protocol in order to keep it portable (windows xp embedded, pocket pc, linux... etc)
Originally Posted by freedom
As I discussed with Shiv last summer I'm considering building up a single din mount display / control that will tap into the Xede's serial bus, as well as the OBD II connector. There is a low cost Linux based Intel Xscale PXA255 processor w/ bluetooth & MMC card slot that seems to be well suited for this task and permit a PDA / notebook to interface wirelessly with the Linux board. In addition I want to use Defi sensors for oil / fuel pressure, temp, etc given their availability and quality. Finally a bit map VFD (display) should be a nice touch that can handle all temperature conditions (e.g. no LCD problems with temperature extremes.)
I'm interested in making this an open source development such that I don't have to accept 100% of the software development burden. Plus I'm not that good at man machine interface design (e.g. anyone can do a better job than me on graphics design).
All of this has been hinged on the release of the protocol. Is there any interest in such a project?
Ideas for additional features (e.g. wideband input, map storage)?
I'm interested in making this an open source development such that I don't have to accept 100% of the software development burden. Plus I'm not that good at man machine interface design (e.g. anyone can do a better job than me on graphics design).
All of this has been hinged on the release of the protocol. Is there any interest in such a project?
Ideas for additional features (e.g. wideband input, map storage)?
Originally Posted by Rushi
What do you guys think would be the best way to develop the xede protocol in order to keep it portable (windows xp embedded, pocket pc, linux... etc)
I'm building a general purpose xede protocol library in python. It should work, unmodified, on Mac, Windows, Linux, and the BSDs.
I think part of the protocol document I have is incorrect. The framework itself for the library is written, but I don't think I have all the command codes right. The IOArray values don't make any sense.
d
Originally Posted by Rushin
would you be able to interface with the python lib from c++ or vb?
...as for vb. I have no idea. I haven't looked at a VB program in ten years or even owned a copy of windows for almost that long.
d
Last edited by donour; May 10, 2005 at 12:57 PM. Reason: grammar
Originally Posted by Rushin
Alright.. so what is the final product going to be? Perhaps we should bounce some ideas back and forth. Features.. hardware??
EDIT: if somebody wants to help right now, fire up a serial port monitoring tool and start xmap3. send me a text file of the first 60 seconds.
d
Originally Posted by donour
I think that's beyond the scope of this thread. I'm only interested in the protocol itself.
EDIT: if somebody wants to help right now, fire up a serial port monitoring tool and start xmap3. send me a text file of the first 60 seconds.
d
EDIT: if somebody wants to help right now, fire up a serial port monitoring tool and start xmap3. send me a text file of the first 60 seconds.
d
I think we're interested in the same thing, a general library for xede communication. The developers here have different plans for the final product (platform, features.. etc), but we could all benefit from this lib. You seem to be the farthest ahead with the development. Are you planning to continue with python? I understand that its good for rapid development/testing, but will not intergrate easily with anything else.
[QUOTE=Rushin]Man.. I wish I wasn't at work. I can do that in two hours, if no one else can.[\QUOTE]
Alright then, send it my way. :-p
I understand your concern, but I wouldn't worry about it much at this point. I can easily port anything I have over to C if there's a real need. More often than not, there isn't. Python works wonderfully well for cross platform developement and you can easily build very sophisticated applications with it.
When it comes down to it. You _can_ call python from c/c++. It's not really hard at all. You just have to pay attention to what your doing as there is funnyness when working across type systems...and of course there's the famous pytho global interpreter lock that can run you aground if you're trying to do fancy thread things (working with the same python vm from different threads simultaneously).
d
Alright then, send it my way. :-p
Are you planning to continue with python? I understand that its good for rapid development/testing, but will not intergrate easily with anything else.
When it comes down to it. You _can_ call python from c/c++. It's not really hard at all. You just have to pay attention to what your doing as there is funnyness when working across type systems...and of course there's the famous pytho global interpreter lock that can run you aground if you're trying to do fancy thread things (working with the same python vm from different threads simultaneously).
d
Originally Posted by donour
EDIT: if somebody wants to help right now, fire up a serial port monitoring tool and start xmap3. send me a text file of the first 60 seconds.
d
d
Originally Posted by Rushin
Which tool do you use?
Both of these offer free trials:
http://www.aggsoft.com/serial-port-m...l-port-spy.htm
http://www.hhdsoftware.com/sermon.html
If you would like to speak with me on the phone, pm me.
d
Ok. During my lunchbreak I was able to get a dump of the xmap3 startup sequence. Surprise, surprise - it's different from the protocol specifications that chiptorque gave me.
On a side note: you wouldn't believe how evil my solution was to get a serial dump. Lets put it this way: Mac, usb/serial, virtual pc, gdb, ktrace, userspace pty faking. :-p
d
On a side note: you wouldn't believe how evil my solution was to get a serial dump. Lets put it this way: Mac, usb/serial, virtual pc, gdb, ktrace, userspace pty faking. :-p
d
Ok. I got something.
Yup. XMap3 uses totally different control codes than I've ever seen specified by the developers. However, looking at the first 60 seconds of an xmap3 session gives me just about everything i need to do datalogging. I'll worry about mapping later.
This afternoon I whipped a little script up that will allow me to datalog a high frequency to a file. Yes, I know xmap3 can do this already, but I don't have readily available access to any windows machine.
For you doubters, try this:
In your favorite programming language, open up your serial port (the one plugged into the xede) at 115200 baud. Send this request across the line:
0xF8 (new request)
0xAC (request io data)
0x00 (request engine rpm)
0x00 (junk)
0x00 (junk)
Then read back 6 bytes. Byte 5 will be the low byte of RPM and byte 6 is the high byte. For example, if you get back 0x64 0x03 (ie 0x364) then the engine is spinning at 868 RPM .
questions?
d
This afternoon I whipped a little script up that will allow me to datalog a high frequency to a file. Yes, I know xmap3 can do this already, but I don't have readily available access to any windows machine.
For you doubters, try this:
In your favorite programming language, open up your serial port (the one plugged into the xede) at 115200 baud. Send this request across the line:
0xF8 (new request)
0xAC (request io data)
0x00 (request engine rpm)
0x00 (junk)
0x00 (junk)
Then read back 6 bytes. Byte 5 will be the low byte of RPM and byte 6 is the high byte. For example, if you get back 0x64 0x03 (ie 0x364) then the engine is spinning at 868 RPM .
questions?
d