Thread: Atma support in obdsim

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

Also, I'm not entirely precluding the possibility of a combination of the above, I just want to be sure it's useful.

Gary (-;

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.

Originally Posted by chunkyks

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.

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