ALDLDroid Android App

[quadstar87]

Love this app and appreciate all the badassery you put into it

[antus]

Also watch out for clones. I tried a prolific for an unrelated project on the weekend, and got hit by the windows "This device cannot start. (Code 10)" error. I hacked around that and found the device was unstable anyway. The other problem with prolific is most of them dont support 8192 baud, so then you get 9600 baud and data errors because its close enough to work but not properly.

[3400tZ]

ralcool: As festy said, what you're talking about probably isn't a Prolific chip. There is code available for Android for that chip (https://github.com/felHR85/UsbSerial) so it's possible to support but there is so little people using USB chips AFAIK, that it's probably not worth the trouble, at least definitely not until the more important things are knocked off my TODO list, if that ever happen OBD-II is in the app and I did tested it VERY briefly on my daily driver (and I do have an OBD-II simulator) and it was working but I never developed it further. Torque is probably your best bet for OBD-II, I just added basic support just for "completness" and really just for fun to be honest but this app really is focused on ALDL ECUs. As for Prolific, antus experience is similar to mine. The drivers on Windows used to have a bug that created BSOD (blue screen of death), took them forever to fix. Their driver on Android, I have a friend that I'm helping working on an Android app for MegaSquirt and Prolific is a lot more commonly used there (as its using standard baut rate, 9600 and 115200) and, long story short, he ended up having to bundle two versions of the Prolific drivers to support all Prolific devices as some versions of drivers have bugs that make it not work on some devices and some other versions have issues with other devices... And I believe their newer drivers won't work with counterfeit chips and there is a lot of that out there, but people hate you when your app doesn't work with their USB chip when really they bought a shit chip to begin with and there isn't much you can do. And I don't even want to talk about how much of a pain it can be to debug communications issues at distance. Anyway, this is probably a lot more info than you wanted, long story short, probably won't be new USB chips support in a very near future, and next one would probably be Prolific (with their new driver only and it would work with whatever chips it works with and that's it).

quadstar87: Nice screenshot, always cool to see how people use the app, glad you like it!

[festy]

Actually it's not a bug in their drivers, the code 10 is their counterfeit detection.
Unlike FTDI who think it's reasonable to brick your device or silently corrupt your datastream if they think it's a clone, Prolific just won't talk to counterfeit devices at all.

[3400tZ]

Actually it's not a bug in their drivers, the code 10 is their counterfeit detection.
Unlike FTDI who think it's reasonable to brick your device or silently corrupt your datastream if they think it's a clone, Prolific just won't talk to counterfeit devices at all.

Yeah, that is just something the application needs to handle although there is more issue than that Another problem is that there is A LOT of counterfeit chips out there and I believe this might of been the reason my friend brought in the old driver in his app, to support them because just too many people have them. Also, when you implements the FTDI driver and the Prolific driver, you realize how much better quality the FTDI driver is (API quality, documentation, etc.).

A real FTDI chip is the way to go IMO

[antus]

Can new prolifics even do 8192 baud?

[quadstar87]

But my clone FTDI cable only cost $2 so I was able to save up that $700 for my forged LS2 pistons

[3400tZ]

antus: I don't believe they do 8192 baud. The prolific driver was more for OBD-II which is already way down on the priority list so yeah... not happening soon

Some good and bad news tonight. Good news is that I believe the NVRAM support is working and done. I've done minimal testing but it seems to be working so since I don't have the time I would like to have to test, I might as well just give it to you guys to play with instead of having you wait even more.

Now, the problem is when I was looking at random things in the 12P XDF and modifying values, I've noticed some things that aren't properly implemented or incomplete. For example, the "Map A: EST - Boost Main Spark Advance vs MAP and RPM" table is using label source "linked, scaled", that wasn't supported. Now, I've added support for that, it seems OK now but there is still another issue. This table "Boost Table Break Break Points - Large (DO NOT EDIT)", the Z axis is defining math equations for each rows. For example, if we take math equation of row 2:

<MATH row="2" equation="(10*(Y>>6))+100">
<VAR id="Y" type="address" address="0xC" />
</MATH>

Do you guys know if the base offset (<baseoffset>-32768</baseoffset>) should be applied to the 0xC ? That Z-axis is also defining an mmedaddress... (<EMBEDDEDDATA mmedaddress="0x9AD9" mmedelementsizebits="8" mmedrowcount="11" mmedmajorstridebits="0" mmedminorstridebits="0" />) , is the 0xC the offset from this address or from the base offset or from 0 ? I've tried a lot of combination and I never get the same values as TunerPro for some reason. If any of you guys have an idea how this thing work, I would love to know to save some time playing with this more to eventually figure it out.

Thank you

[Jayme]

OK, cleaned up my double posts of incorrect info and starting again.

VL400 set this xdf up. The goal is this: when you tick the 2 or 2 bar bar map sensor flag (Map A: MAP Sensor Type Selection A \ A:B Clear = 1Bar), it changes the break points in the boost table from 100-200 kpa to 100-300 kpa without having to have 2 separate statically defined XDF's.

so that item in the XDF is listed as 800C but it takes away the base offset of 8000 so the actual address of the map sensor flag is 0C.

so the Y value in that equation should be linking directly to 0C with no offset applied.

[3400tZ]

Thanks Jayme!

Actually, there was three issues. First, I wasn't supporting "Linked, scale" for label source of xdf axis so I added support for that. Then, the table was showing but the values were all 0. I realized the base offset was being applied to linked variable addresses when it shouldn't, I'm pretty sure I tested that with an XDF with base offset with 0 so that's why it looked fine when I first implemented it. After all that the values still weren't looking right. After a night of sleep, looking again tonight, I saw that I had some random BMW bin file loaded in TunerPro somehow (instead of the 12P bin file I thought I had) so sure enough once I loaded the right one, everything matched and we're good.

So even more good news now, I just pushed version 0.80 of the app on Play (update should show up in an hour or two usually). Here is the changes log:
- Added support for real-time tuning of NVRAM ECUs
- Added support for "Linked, scale" label source of xdf axis
- Fixed issue where base offset was being applied to address of linked variable in math equations when it shouldn't
- Allow to load / save dashboard files when dashboard is in edit mode
- Fixed crash when opening empty data log file in log viewer

I've said it a couple times and I will say it again, consider the NVRAM implementation ALPHA. That mean test it on the bench and please report your observations, good or bad, in this thread. A debug log and any information to help debug is always appreciated! I also haven't tested with anything else than 12P as this is the only hardware I have. The code is based on antus oseplugin so it should support the same ECUs.