Results 1 to 5 of 5

Thread: Atma support in obdsim

  1. #1
    licensed to kill - FKA kev000
    Auto Apps:loading...
    tripzero's Avatar
    Join Date
    Aug 2006
    Location
    16.40618, 120.61106
    Posts
    2,560

    Atma support in obdsim

    i think it would be really cool if obdsim supported atma.

    i love you,
    -tripzero
    Former author of LinuxICE, nghost, nobdy.
    Current author of Automotive Message Broker (AMB).
    Works on Tizen IVI. Does not represent anyone or anything but himself.

  2. #2
    SuperMod - OBDII GPS Logger forum
    Auto Apps:loading...

    Join Date
    Mar 2009
    Location
    Los Angeles
    Posts
    929
    So if I was really going to do this, I'd want to do it "properly" [I could hokey something together in 15 minutes but it would suck].

    How would this work? Current ECUs/Generators don't have an address or anything, other than the order they were generated in [then added to a base ecu address, different for each mode].

    So to write ATMA support, there are several potential things here:

    1) ATMA as "banter between ECUs in obdsim".
    I could randomly poll each ECU and throw stuff out onto the "bus".
    This is very doable, but after some talk in IRC it seems this wouldn't meet your needs [but for reasons I'm not entirely clear on]


    2) ATMA as "banter between ECUs not in obdsim"
    Which would be generated/stored output from ... somewhere else?
    How would you generate that banter? Where would it come from?
    I know you talked about just having a flat text file with raw data, but how would that fit in with multi protocol support? What if I have a KWP 5baud car? How would timings work?
    Admittedly, there is a certain level of "users are expected to know what they're doing" here, but still; there's some contract breaking involved in ATSP2;ATMA churning out a series of CAN messages, no matter what the user did.
    Alternatively, it could be richer text format that included delay-since-last-message, to/from ecu, value. But now the ecu addresses won't be reliable as-is, again for multi-mode reasons.

    I'm not even clear if this is something I would be implementing as a "generator" [once instance of a generator is currently synonymous with "one ecu"] or if it'd be a separate codepath in the obdsim core. Which, while I'm not opposed to it, doesn't necessarily seem like the best of ideas.


    3) ATMA as "something else I don't fully get"
    Enlighten me.


    Overall, as I've said on IRC... I'm not against implementing this, I'm just not clear on how to implement it so that it's
    1) properly designed and improves OBDSim, not just some hokey'd on thing
    2) useful in the long term to other users aswell.

    "Just have a parameter that reads from a text file when the user specifies ATMA" is what I would consider to be hokey-as-all-hell. So... how do I implement this?

    Gary (-;
    OBDGPSLogger, for logging OBDII and/or GPS data
    OBDSim, an OBDII/ELM327 software simulator
    mp3car forums: obdgpslogger, obdsim

  3. #3
    SuperMod - OBDII GPS Logger forum
    Auto Apps:loading...

    Join Date
    Mar 2009
    Location
    Los Angeles
    Posts
    929
    Also, I'm not entirely precluding the possibility of a combination of the above, I just want to be sure it's useful.

    Gary (-;
    OBDGPSLogger, for logging OBDII and/or GPS data
    OBDSim, an OBDII/ELM327 software simulator
    mp3car forums: obdgpslogger, obdsim

  4. #4
    licensed to kill - FKA kev000
    Auto Apps:loading...
    tripzero's Avatar
    Join Date
    Aug 2006
    Location
    16.40618, 120.61106
    Posts
    2,560
    So first, let me describe the use-case. Random-FE-Dev wants to write a plugin for Random-FE that reacts to steering wheel button presses to integrate with the FE's media player. He starts writing an app but grows weary of constantly walking out to the car to test. To make life easier, Random-FE-Dev uses a simple tool that listens on the canbus and logs messages. He needs a tool that take this log, and spit it out on a pty that his application can read. Since he's working with ELM scantools, he figures that obdsim would be a great place to start since it already understands elm commands.

    Quote Originally Posted by chunkyks View Post
    So if I was really going to do this, I'd want to do it "properly" [I could hokey something together in 15 minutes but it would suck].

    How would this work? Current ECUs/Generators don't have an address or anything, other than the order they were generated in [then added to a base ecu address, different for each mode].

    So to write ATMA support, there are several potential things here:

    1) ATMA as "banter between ECUs in obdsim".
    I could randomly poll each ECU and throw stuff out onto the "bus".
    This is very doable, but after some talk in IRC it seems this wouldn't meet your needs [but for reasons I'm not entirely clear on]
    ATMA, in basic terms, just spits out information as it reads it off the CAN bus. This could be the steering wheel controls talking to the headunit, or it could be the keyfob receiver telling the doors to lock. These "ECUs" or modules have very vehicle specific ids. This wiki page simplistically describes the message format: http://wiki.openice.org/index.php?title=Gmlan

    the payload per module is really specific to that car. You really couldn't have obdsim simulate every car, that would be silly. So the best you can do is either generate useless information by polling the ECUs for whatever data they have or you can spit out some data that the user provides. The former really isn't very helpful because application writers generally want to test with data that they'd see in real life, aka, the latter option.

    2) ATMA as "banter between ECUs not in obdsim"
    Which would be generated/stored output from ... somewhere else?
    How would you generate that banter? Where would it come from?
    I know you talked about just having a flat text file with raw data, but how would that fit in with multi protocol support? What if I have a KWP 5baud car? How would timings work?
    Admittedly, there is a certain level of "users are expected to know what they're doing" here, but still; there's some contract breaking involved in ATSP2;ATMA churning out a series of CAN messages, no matter what the user did.
    Alternatively, it could be richer text format that included delay-since-last-message, to/from ecu, value. But now the ecu addresses won't be reliable as-is, again for multi-mode reasons.

    I'm not even clear if this is something I would be implementing as a "generator" [once instance of a generator is currently synonymous with "one ecu"] or if it'd be a separate codepath in the obdsim core. Which, while I'm not opposed to it, doesn't necessarily seem like the best of ideas.
    Others would have to chime in if this would be useful or not, but for me this is the "right way (TM)" to do it:

    1) user provides obdsim with a log. This log is a two column sqlite table of messages and a timestamp.
    2) when obdsim sees the "atma" command, it proceeds to spit out messages at the rate of the delta of the timestamps
    3) obdsim breaks and returns to normal operation when it gets a interrupt message (ie, any char read from the pty)

    Now, this has a few issues. The worst case is that the user's app expects a 5baud protocol, and obdsim is feeding it data at rates that the app doesn't expect. What would happen? One would hope the user would feed it a log relevant to the protocol he wants to use. But maybe you want to abstract all usage responsibility away from the user. If this is the case, that's okay too.

    I admit that I'm unfamiliar with the differences between different protocols. What does obdsim do when it gets an atsp*? If I do a obdsim -g Logger -s ces2010.db and set the protocol to atsp5, does that change the rate I receive data?

    If this seems hokey to you, I'm open to ideas on how to do it the real "right way (TM)". You know about as much as I do about what my particular need is.
    Former author of LinuxICE, nghost, nobdy.
    Current author of Automotive Message Broker (AMB).
    Works on Tizen IVI. Does not represent anyone or anything but himself.

  5. #5
    SuperMod - OBDII GPS Logger forum
    Auto Apps:loading...

    Join Date
    Mar 2009
    Location
    Los Angeles
    Posts
    929
    No, OBDSim doesn't actually cap the samplerate although it could do fairly easily..

    Thinking about it, currently it sleeps for a #define'd period of time once every time around, I could change that to depend on protocol - does anyone have a list of maximum samplerates reasonably expected by each protocol? That would be trivial to add, and I concur it would be sensible and useful thing to do.

    At the moment, OBDSim's behaviour relating to protocol only changes ATDP, ATDPN [obviously], and the format of the headers when ATH1 is set.

    Overall, though; is your message format the same no matter what the protocol is? Because what you describe sounds fine to me when put like that. But I wonder what will happen if someone changes protocol?

    Gary (-;
    OBDGPSLogger, for logging OBDII and/or GPS data
    OBDSim, an OBDII/ELM327 software simulator
    mp3car forums: obdgpslogger, obdsim

Similar Threads

  1. OBDSim now with multi protocol, benchmarking
    By chunkyks in forum OBDSim
    Replies: 6
    Last Post: 09-18-2010, 09:07 PM
  2. RR 7-8-06.. Pic Viewer & more
    By guino in forum Road Runner
    Replies: 183
    Last Post: 09-11-2006, 12:35 PM
  3. Tech Support Calls
    By Rafster in forum Off Topic
    Replies: 8
    Last Post: 06-12-2006, 11:49 AM
  4. Speed Camera and multicam support
    By TommyTott in forum Centrafuse
    Replies: 8
    Last Post: 05-26-2006, 07:51 PM
  5. Integrated character LCD support!
    By veetid in forum Centrafuse
    Replies: 4
    Last Post: 12-21-2004, 02:04 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •