Printable View
I have a modified version of $EE that I am trying but get connection that very quickly connects and disconnects. Is it OK to use the autoprom cable on this or do I need a plug-in to use with my cable that I use for tunercat?The files I am trying to use is below.
i really need to start playing with that adx thing.
i'm being lazy about it though.
why? because i can't do it like i want, because although you can do loop breaking in macros for a tiny bit of branching, it's too weak of a branching system for me to wrap my head around making it 'perfect'.
it's a simple protocol, but there are lots of little details that can make or break the reliability of your datalogger.
see the biggest problem on getting your initial connection reliable is to not just disable chatter, but make sure it is actually disabled before starting requests. otherwise you'll get some successful data requests through, but the rest will be laced with chatter.
disabling chatter reliably the first time round is a matter of ensuring your disable comms request doesn't get overwritten by idle traffic. the ideal way to do this is to listen for idle chatter strings. idle chatter on ee, in my experience, is NOT consistent enough to listen for specific strings, and the spaces between them are not necessarily predictable.
even if it was, there's no need, really. to determine a silence point, you have to listen for the idle traffic, and count the spaces between the bytes. as soon as you've had silence for say 5-10 milliseconds, it's generally safe to send your disable comms command, and have it work.
but don't count on it, it's not 100%. after sending it, it should actually check the contents of the reply, otherwise how is it going to know if the request is successful, and chatter is really gone, or whether to try again?
anyway if there's there's no way to time the disable comms request with idle traffic properly, which it seems there isn't, you don't have to. i hate this method, but to disable comms on EE you can nail it by repeating 3 or 4 disable comms requests, about 75ms apart, and just dont worry about idle traffic. one of them is pretty much garunteed to land in between idle chatter and be successful. (someone else's research, and that's not how i do it, but it does work perfectly)
after that, a buffer flush should be done since there's no way to know how much idle garbage is the buffer, but im not sure if that's necessary on tunerpro. or is it? actually, thinking about it, how does tunerpro even manage its buffers? does a serial write always flush the serial read buffer? do timeouts flush the buffer? this stuff isn't documented at all. maybe it's not necessary, but having junk in the read buffer could wreck your first packet.
once a connection is established, statefulness is important in maintaining a reliable connection in the long term, that's tolerant to ecm power cycling, glitches in the serial interface, whatever, if you even care about that (i do), and you can't really do that manually without branching or more complex macros either. does tunerpro do that on its own?
during successive requests with no reply at all, the state of waiting for idle chatter should be re-entered, as the ECM has likely lost power (key off, whatever). another failure state can be established that in a certain timeframe, if many packets have failed checksum, the macro that attempts to disable chatter can be re-entered without even waiting for idle traffic (since the ecm may have gone back out of that mode, due to a timeout or an ecm power cycle that wasn't detected).
i don't see any way of accomplishing that in tunerpro either, although a combination of macros in loops with fail-success breaks might do it.
if you can be stateful as far as 'the datastream is probably reliable' or 'the datastream is probably unreliable' or 'the datastream is plain dead', you have a machine that tends to grab the maximum amount of reliable data possible at all times, and lights right back up if something goes wrong.
an A+ datalogger to me means you press connect, close the lid of your laptop, and go for a drive, and know that the data collection will be as fault-tolerant and aggressive as possible, to be sure you're getting as much data as you can, and no matter what happens, it's going to try its best to constantly maintain a disable comms state and then grab more data.
do adx files like that exist? lets see some examples
Your making this way to hard. It's an old PCM, you get what's programmed into ALDL data stream you pick. In the original ADX file I built it has worked on all Lt1 cars but some need a Connect, dis-connect and re-connect because I have silence HVAC module that was in a Roadmaster which messes up others that don't.
Open up the ADX file and click on the 2 gears Icon or Edit Acquisition file and look into commands. There's a lot that can be done there for things you mentioned.
of course im making it hard, that's me. if it's easy, i'm obviously doing it wrong.
i realize once the datastream is up and running it's all good, but getting reliable silence and reconnection behavior on the fly isn't so cut and dry; so says my many hundreds of hours writing my datalogger from scratch, and making sure there were no failure modes that'd result in the datastream being interrupted for longer than necessary.
i didnt know about that hvac module in the roadmaster, new one to me! now i want to hack one into my fbody
anyway im playing with it a bit more now, i think im starting to get the control logic i want. im going to do a from-scratch super-simple adx and try to get it optimal on just my car, and get all the *important* DA association stuff working again (i think i've broken a bit of it from screwing around in my xdf)
that silence hvac thingie could be selectable by nesting macros i think; i'll keep it in mind, have a connection macro for roadmaster, and other, and just make roadmaster people select a different connection macro?
Yup!Quote:
Originally Posted by steveo
Then there is another one that needs to be silenced as well for Corvette dashboard... CCM?
Look up the climate control swap using RoadMaster parts into Caprice and Impala SS. Pretty cool unit as it would read codes and such as well.
I disconnected and reconnected many times trying to get this to work but didnt have any success and this was on a 95Z28. Only thing I chnaged was WB stuff for my AFM1000. Eagle Mark, should I have been trying something else?
Anyone else had any luck scanning $EE lately? Starting to think I may have cable issues. I noticed, while using DM, that I got a intermittent data issue. My cable is probably 10 years old.
if datamaster doesn't maintain a connection its probably your cable
if you ran linux I could run my homemade ee scanner in debug mode and tell you what's up though
Try PCMcomm first. Some years ago I wanted to log my 95 vette and had no luck with TunerPro. By inspecting what PCMcomm has put to the line I adapted it for TunerPro and got it work finally. But what I found out was that PCMcomm was very reliable, so give it a try. In general I agree with steveo, that $EE especially in Y-Body with all that chatters on the line is hard to get silent.
Steveo,I didnt run linux. Does anyone offer a usb type cable for aldl comms? The one I have is serial and am sometime wondering if the converter is the issue.
absolutely, there are a quite a few options, try to get one that uses an ftdi chipset.
you have an obd-ii connector with obd-i protocol, right?
you can either use the ones they sell on this forum somewhere with an adaptor (lost the thread now) or the cables from sites like aldlcable.com, which already have the right connector
I actually have a cable that has both obd1 and obd2 cables attached.