My cable will be here today if you need me to try it I can as well
My cable will be here today if you need me to try it I can as well
Sounds good, can't wait!
I know you mentioned not wanting to do it, but I'd also be willing to test method four--the custom driver. I understand it's not practical for general use, but if that ends up being what it takes, I don't think it's unreasonable to note that Corvette guys would just need to go for a specific cable and use a specific driver. That is, if one of the three doesn't do the job.
1990 Corvette (Manual)
1994 Corvette (Automatic)
1995 Corvette (Manual)
nah i don't want you vette guys to run nonstandard drivers. i have written for libftdi before and it's great but you literally have to make your cable only work with libftdi. there's some hacky driver switching tool out there too.
if you haven't noticed, a lot of people tuning old gm stuff aren't too computer savvy, so i don't want to make my user base do things that'll just result in me having to teach them individually.
i think we'll find a method that'll work for everyone, although i'm thinking there's a chance you'll average around 10 seconds for initial connection time even with an ideal method.
just out of curiosity, what tools have you used that do connect reliably to your vehicles?...
TunerCats works...up to a point. The program itself (GUI?) puts such a load on my netbook that after a little while the screen can't refresh fast enough and it falls out of sync and pegs the processor to 100%. If I set it to only record a log and not display anything it's fine, but that's not particularly useful. WinFlash works perfectly, though as I've pointed out in logs before, it's using an incredibly aggressive method to get through noise on the bus (just keep ramming data through until you get a response that matches). EEHack works perfectly on my '95, but doesn't work properly on my '94. Still haven't been able to figure out why.
Haven't tried TunerPro RT yet.
1990 Corvette (Manual)
1994 Corvette (Automatic)
1995 Corvette (Manual)
Steveo,
Send me a message on here on what you need tested on a bbody platform, I haven't had the chance to read the whole thread. Just let me know
Thanks
Mike
Wow I've fallen way behind, I haven't been on here for a long while.. Steveo I'll be another test subject, 95 fbody Lt and OS in my S10 Ive started playing with again. I started out with Tunercat n playing with EEhack for a while now with my TC cable. Recently been trying to dial in a SD cal because my space is just to limited for my MAF and intake plumbing. I'll download the new software when I get off work today and give it a whirl
always nice to have more testers! i'll try to get a new version up later today after doing some testing myself and we can 'vote' the best connection method in based on what works for everyone.
steveo, some thoughts:
1. Having high latency is not a unique problem to this interface; it happens in all sorts of applications. What if there was a way to determine the latency? Without being hooked to the vehicle, if I just plug in the USB to serial converter and then send a message and read the same message right back since TX and RX are connected together, can't we figure out the latency for a given hardware setup? Heck, just have the user turn the key off and wait for the bus to quiet, the software could figure out the latency even with the cable connected to the vehicle, if the PCM doesn't pull it to ground when off?
2. Then, watching the B-body idle traffic scan data, there WAS a repeating pattern of messages, and some of those gaps were significant. What if we listened to the bus and figured out the pattern, then How long a gap do we need to make a bus master message? How long is that message?
3. Knowing our latency and knowing the message pattern, couldn't we then insert a bus master request at the right time?
At least for the Corvette, the bus continues to communicate even when the key is off. Don’t know about other platforms.
1990 Corvette (Manual)
1994 Corvette (Automatic)
1995 Corvette (Manual)
No worries, just have the user disconnect the cable.
i think you're assuming a level of precision that doesn't exist consistently between interfaces and drivers. i'm done trying to 'time' the thing as i want an approach that works for everyone with every interface so i don't have to deal with everyone asking me why its not working. there's a reason no windows based aldl software is doing that. of course if someone else wants to develop and test that approach i will definitely use it upon success but it does have to use QSerialPort as i need this to be multi-platform as well
Thinking big picture, if the sledgehammer method works for now, there's more value add to be had in other areas. Smash away and move on.
i've been trying stuff all night and i'm just too burned out by this aldl crap to write a proper testing routine.
just try this i hope it works.
http://fbodytech.com/flashhack/
oh, to just test the connection routine, use 'load kernel' in the advanced tab or something, if it loads the kernel good, if not no good
Bookmarks