Will it be able to handle any OBDI ADX file?
There is already a OBDII ADX file as well...
Printable View
Will it be able to handle any OBDI ADX file?
There is already a OBDII ADX file as well...
I've got a rooted SIII and usb aldl cables,if it will let me read pids as easily as my bluetooth/torque/obdii than I would very likely pay around that price just to have another easy diag option for on the fly.Keep it up,great job so far looks like.
Currently, it's ADS file. I have ADX file support pretty high on my TODO list now (already got the parser written).
ODB2 would require a bit more work but it can definitely happen. I even have a ELM327 bluetooth adapter and a few random ODBII ECU laying around :P Won't be for a little while tho.
I'm still fighting with Bluetooth, I got my adapter somewhat working in TunerPro but it's very unstable. Still talking with Mark (TunerPro) and Timm (Red Devil River) to figure it out. They are both super useful so it shouldn't be too long. I would like it to work properly with TunerPro before I start playing with it with ALDLdroid.
Here is what I spent literally all night working on. There is more important stuff to do right now but I felt like working on that night... Oh well, that's one less thing on the TODO list :) It's all Android sensors (Latitude, longitude, azimuth, bearing, altitude, accel x/y/z axis) that can be both indicators on the dashboard as well as logged into data log files. The app now generate data log files just fine :) Definitely usable with USB even if some stuff is a bit rough around the edges.
Attachment 5539
Very cool improvements you did tonight! Especially if they can be in same data log with TunerPro!
But I'm curious why your working with an ADS file? They were changed to ADX over 2 years ago?
Of course, its just extra columns in the data log!
I started with ADS as this is what I know existed. Last time I tuned a car using TunerPro was 5 years ago. I started the ADS parser as pretty much the first thing in the app and didn't realize ADX existed. We will see if I completly drop ADS support or add support for both. Seems like nobody cares about ADS :|
It's notthat nobody cares, it's just that so much work has gone into the new format, and ADXs created in the new format, and will be the only supported format for the foreseeable future it just makes more sense to support that format, over one that is no longer being used by the majority, if you had to choose between one or the other. It would be great if you could support both though. :)
Another reason why I think ADX support will be so important is that Tuner Pro V5, has many more featires that allow for a wider variety of ECMs and applications, due to plug ins and other built in features that use ADX, will only mean a broader clientel that would be interested in using this.
I still haven't come up with a more fitting name yet.
Yeah, that's what I meant, I thought that some people were still using ADS files but I guess with TunerPro V5, you have to convert them anyway. So TunerPro itself doesn't even support ADS anymore really. I will see if I realize its too much of a pain in the ass, I will just support ADX but I will try to do both.
Tonight turned out to be a night of polishing a bunch of stuff to make the app more user friendly. Currently, when tapping "Connect to ECU", if for some reason the app cannot make sense of the data, beside Connected at the top of the dashboard, "Incorrect response length" will appear. Otherwise, it's also possible to see "Checksum mismatch" because I validate the checksum and make sure the dashboard is displaying only good data (same for data log). For some reason, it seems like I cannot get data from the ECM right away all the time, sometime I get it almost right away, some time you will see "Incorrect response length" and/or "Checksum mismatch" for a few seconds until the app is able to make sense of the data. Not sure if that is something I can fix or not but TunerPro seems to be having a somewhat similar issue so it could easily well be on the ECM side.
Btw, Is 8.9 reads per second any good ? :happy:
http://i.imgur.com/Fz36uae.png
Yeah, that's an average read rate.
You'll likely find that it will be due to the code being used whether it will connect easily or not.
There are some codes that are known to be more flaky than others. Some, like $58 have a patch to make connection easier, and also possible while using an Autoprom, I found that one out the hard way... $59 has the patch installed as a base, along with a few other patches. ;) I can verify this more once I get a compatible device. ;)
8.9 isn't bad at all. with a typical datastream size of 63 + header + checksum, i've logged an average of 10.6Hz on my laptop IF i don't have the monitors tab open or anything else requiring a lot of processing time.
So you guys confirmed that I'm not doing too bad, that's good :) I didn't test totally removing the delay I'm adding between write (I think I was at 15ms), removing it would probably bring the RPS ~10 I would say.
I'm testing with $8F btw
No freaking cable, this is Bluetooth! Works great (once I fixed my brain fart in the code :P) Reads / sec is a bit lower at around 6.5 but I was excepting that. TunerPro is around the same but for some reason the gauges are dropping to zero every few seconds. So far its been pretty solid with ALDLdroid, so that's good :) YAY!
http://i.imgur.com/84FJUQR.jpg
There's a possible solution to the gauges dropping to zero. It's detailed on the Tuner Pro forums, and I know Mark knows exactly what it is that is added to the ADX. I want to say it's a delay to waiting for response from the ECM but I don't recall exactly.
I did add this thing:
<ADXCLISTENSILENCE id="M1M0pause" idhash="0x5EF379D0" title="Mode 1 Message 0 Pause">
<desc>Wait on packet drop</desc>
<silencelen>200</silencelen>
<totaltimeout>250</totaltimeout>
</ADXCLISTENSILENCE>
This is the latest values I used, which are probably way too high but I tried everything in between as well :|
Anddd, I just added support for other commands defined in the ADS file (someone should tell me I need to support ADX files :P) such as clear trouble codes... Cleaned up some code in the process. That's enough for tonight =)
I'll do it...
You need to support ADX files...
X2! ^^^^
Since your using $8F.. which is not widely used! And it's an ADS file the fix was probably never done!
What your doing with silence commands may work? But it also may screw up some other ADX files?
The fix for all working ADS files converted to ADX when TunerPro V5 cam out was to add "1" to body size. So why not try that first?
I was adding this to an ADX file obviously, not ADS :P
I didn't try to add 1 to body size yet but I will try that for sure :) thx!
Well by the time this is release I will have stolen my wife's kindle fire. Nice work!
Brainstormed about the ADX support tonight. It's a bit more of a pain in the ass then I was hoping :P It's similar to ADS but sort of different at the same time. What I'm thinking to do is just use the data that I need from the ADX file to fill the data structure that I'm currently using for ADS. Is there any point to support "monitor" or "listview" or "histogram" ? I mean, I already have those widgets, or will have them at some point anyway and everything get saved to a much more flexible dashboard file. There is also some stuff that doesn't really apply to android like the position of the widget on the dashboard. I can somehow try to convert them but with different screen ratio and stuff, it will probably end up looking like a mess. So I'm thinking about parsing ADX files just for the ECU data length, all the values, bit masks, that kind of stuff (everything that is in the ADS really, that's all I need)... I can probably add support for more stuff as needed... does that make sense ?
Today, it's been exactly a month since I started working on the app. Pretty happy with the progress in a month, considering I have a full time job as well :rockon:
Tonight, I got the "Auto-connect" feature working. It was a bit more work then excepted because I ended up adding a "data stream file selection" entry in the settings section of the app so I don't have to display the "select a data stream file" thingy at every ECU connection (which was very annoying anyway). This allow the auto-connect to be able to silently connect to the last ECU. When a different code mask is used, the settings section can be used to go change the data stream file.
Have you tested this on an actual android device (with comms) or just in the dev environment?
I'm supposed to be getting that Android device soon...
I think so?
Just opened TunerPro RT and then looked at my Android phone. There's a lot in TP on a PC that won't be needed with TP on an Android, even less on a phone. The entire data log file will have to be able to be saved and emailed. But since you have basically a dashboard you can pick and choose what you want to see and use, I think what needs to be supported is anything in Values or Bitmasks!
History tables aren't going to be much help on a phone... monitors would be to small to find trends or glitches... your making dash boards... have to be able to read codes that are set or switches on or off.
I'm still wondering what I would do with this? It's a cool toy, but for tuning? I'd just need my laptop! That said for personal use I could do a data log without the laptop and email it for later review. The ability to reflect the phone off windsheild as a second dashboard at night is a cool feature.
Now what excites me is the GPS functions, (Latitude, longitude, azimuth, bearing, altitude, accel x/y/z axis)! If this is in same data log then we could probably make history tables, graphs etc... and have a way to time! Like a dyno or 1/4 mile run! That adds a whole new demention to data logs from TP!
One thing I just thought of and thought I'd pass it on in hopes of helping... while comparing TP on my laptop and TP on my phone is your doing all this work on a.... whatever that thing is? :laugh: A tablet? In all reality all these options and adjustments need to be done on a much smaller scale for the cell phone.
If you want testing done on android phone I have one. Would need to be able to load the $42 ADX. Which brings up another issue... maybe. This ECM is 160 Baud and I think your working with 8192 Baud.
HTH! :rockon:
Come on Chris, have you seen my video and/or screenshots ? :laugh:
I always test with real devices only, the Android emulator isn't that great, doesn't support Bluetooth for example... not sure about USB. :P
So far I've tested with my tablet (Asus TF300) and phone (HTC One V). Both works great.
I have experience tuning with Android device (on MegaSquirt) so let me give you my opinion on that. I like to use my phone for data logging. Its the smallest thing I have that can data log and get the job done. For data logging, you really don't need more so for that alone, the app is really nice (and you get the extra sensors logged as well which is a cool bonus as you said) For tuning, on a phone, it's a major pain. It's still cool to be able to do little tune tweak (adjusting idle cells of VE table for example) with it but I wouldn't start a full tune using that.
On the other hand, a 10" tablet is pretty much the same size as most netbook. I also have the keyboard dock for my tablet which make it a touch screen netbook pretty much. It's apparently very similar to a laptop as both of you guys seemed a bit confused about it :P That make tuning a lot easier then on a phone and the touch screen and everything else of the Android device make it a great tuning platform. If this app get full tuning capability at some point and you have a 10" tablet, you could end up liking this setup for then you laptop, trust me :)
So already, it has advantages TunerPro doesn't have like logging extra sensors and portability being the two main one IMO but of course it's not a TunerPro competitor, just a great complement.
The 160 baud is indeed an issue. I don't have a 160 baud ECU so I cannot test that and I would assume it doesn't currently work.
Fair enough, I understand the confusion :P Trust me, it is an Android tablet (running Android 4.2) docked into a keyboard :P
I also have a '7747 ($42/160 baud) ECM that is set up to be used with my test bench, one of the many ECMs I can bench test. ;)
You could test but I'm 99% sure it won't work :/ Does that ECU use the same harness as a '7730 ? Or you have a different test harness for every ECU you have ? :|
I have a different harness made up for each ECM I use, other than ones that can be shared. I.E. the '7730 and '7749 can use the same harness, but they can also use the same codes, so the other reason to switch between them is to test for actual hardware differences, which there are a couple. The '7747 uses a different harness than the '7730, different than the '7165, different than the '7427, different than the '7060...
Damn it! Is there any 160 baud ECU that use the same harness as the '7730 ?
So I would basically need this: http://www.ebay.com/itm/1987-92-CHEV...-/390647507497
Meh, I guess I will wait :P
could go full-banana and get a '7165, which i THINK is the only ECM that did both 160 and 8192. it's actually pretty "easy" to make any ECM do 160 baud communications though.... thank GM's engineers for setting up a 160Hz loop for that one.
Yeah, that could be an option as well. :) I guess I need to get the ball rolling with this app and then I can spend some more money on test equipment.
Oh, and some random app progress, I just added a G-force indicator (as well as data logging G-force), sweet!
I've got a 8062 which is 160 Baud $4E you can have and I'll even pay shipping. But only one pigtail... the other plug has no wires... if you want it PM me your address.
No wire at all on the other plug ? I guess I can add some back in there ? I'm probably interested :D
Maybe someone has the large plug with pigtails? I have the small plug with pigtails...
PM sent :)
Which plug do you need? I have both 7747 plugs with no wires, and a pile of wires with pins that came out of them. But not sure if thats what you need.
I also have a test bench I can test 7427, 7727, and 7730 ecm's on, but no 7747.