ALDLDroid Android App

[3400tZ]

Cool. If it's user error from ALDLdroid use, I don't mind adding some validation where needed. I would admit there is probably not enough of that right now. I have a feeling something isn't quite right still from your message, let me know once you play with it more if you figure anything out on that front.

If you see the success message, it does mean the app got a successful reply from the ECU, but its still somehow possible the offset was wrong or the data was wrong or something like that. There is a fail message with the reason when the ECU reply with a fail message (or time out or whatever).

[quadstar87]

Josh: Did you use "upload calibration" at all or you just modified wideband VE learn thing and let the real-time thing do the write ? The bin that you downloaded from your ECU, is it the same that is configured into the "tuning files" menu ? Maybe a debug log would help if you can (settings section, enable debug log or something like that should create a debug log in the debug folder of the app).

quadstar87: Yes, save/load dashboard should work... I'm kind of curious to know why you see what you're seeing. I will have to try that feature again myself I guess, I did that before the NVRAM stuff so its been some time but it was working OK. And by XDF, I guess you mean ADX ?

Yea I meant ADX. Brain fart because I was doing disassembly and mapping when writing that post.

I can do some more testing tomorrow as well.

[antus]

12p will only reply if it was a successful write and it does verify its writing specifically to the calibration area, so if the response check code did the right thing (I imagine it would have) then the address must have been between 0x8000 and whatever the upper bounds cal area limit is (not sure off the top of my head). There cant have been any epic shift of address which is normally how I would expect that stuff to go wrong (miss the whole 0x8000 offset or similar).

[3400tZ]

quadstar87: cool!

antus: I didn't know there was some validation on the ecu side as well, that's good.

Anyway, we'll wait for feedback from some more people as well, it does seems somewhat promising so far or at least not a complete train wreck of a first version, so that's something!

[ralcool]

I have an early Moates Burn1.. I used to use it to tweak my $12A AT29C256 modified memcal for a V8.

You mentioned adding support for it in ALDLdroid, and I see its listed.. As is 29F040

Craig once told me he wasn't sure if it could support 29F010.. do you think it would? I was going to attempt one, set the hex range.
Never worked in F'nB.

I use 29F010 flash roms with a TOP2007 programmer.. Works fine for me so far, but thinking of buying an NVRAM from the forum for realtime.

Which h/w version did you say Burn1 had to be?
My HTC One X immediately says my Burn1 isn't supported, and ALDLdroid doesn't detect it when I enter 'chip programmer'. Stupid phone.
Hmm, this is the only thing other than the missus Galaxy Note 5 I'll try after she's home from work.

4 other andoids in the house but all too old or cheap to do usb host...

So i couldn't try... the Burn1 is FTDI powered so it should be fine, and is known to be working perfectly otherwise.
Flash n Burn detects it as version v5.9F on the laptop just now.

No fault on your side, carry on Sir!

Pity my FT232 chip didn't arrive today, things could have been brighter.

[3400tZ]

Hi ralcool,

The burn1 implementation should be working, I only tested with the burn2 but they are really similar from what I understood. Pretty sure it's using an FTDI chip as well, which is the only one supported by the app right now. I'm not sure if the app will be able to burn the chip you're interested in but it depends on the hardware as well and if the official software isn't working, I would probably say the result will be the same with the app unfortunately :/ Definitely still worth a try once you can get your hand on a device with USB host mode support tho!

[festy]

I've done a bit more testing this morning.
First off, a bug or two. Attempting to write to a write protected NVRAM seems to crash the app. I sent a couple of crash reports relating to this.
Also with the data traces, one item works ok but any additional traces just take the values of the last trace in the list. Here I've selected 3 data items, and they're all getting the third item's data. I've tried a bunch of combinations but it always seems to have the same result.

traces.png

Also when selecting the items with my phone in landscape orientation I can't see the Apply button, but when I rotate the display the item selection window closes and I lose my changes. Only a minor issue but it caught me out so many times this morning.

I'm not sure if I'm doing something wrong here or not, but I downloaded the cal, changed a flag, downloaded the cal to a different filename, changed another flag, saved another cal, changed a table cell etc and then transferred the 5 different saved cals to my pc and compared them - they were all identical.
So then I went back out and grabbed the cal off the ECU using tuner pro and compared that to the 5 cals, and it's the same. Could it be that aldldroid is writing the original data to the ECU and not the updated values? I can sniff the ALDL traffic on a write if that helps?

A few more screenshots - checking DTCs:

flags.png

tables display:

2d.png

Rotating a 3d table display:

3d_1.png

3d_2.png

I'm running this on an old Samsung Galaxy S3, some screens are a bit cramped but it's perfectly usable.

[festy]

And a minor RFE, would it be (or is it already) possible to have a dash command button's background change depending on whether it's active or not? i.e. a "start datalogging" button's text changes to "stop datalogging" when it's active, it would be handy to be able to have the background colour change as well as the text - like how they currently can if they're disabled. On a small screen it's difficult to work out if a button is on or off at a quick glance.

Also is there a way of setting the hold time a button has to be selected for before it's switched, or is that long press a system thing? I'd love an option to use short presses for the buttons, life is too short to be holding buttons down

And last one, have you considered adding a settings option to auto-start datalogging on ECU connection?

[Jayme]

dropped into bigw today and bought a new OTG cable.... testing ahoy! time to fire up my 12P and 11P test benches

[3400tZ]

Josh:

- Data log viewer issue turned out to be some incomplete work that somehow made it to this release when it shouldn't have. Fixed for next version. I'm happy some more people reported the issue tho, which mean people are using this feature that I spent a crazy amount of time on, so that's good
- The dialog closing on rotation change is actually an "Activity lifecycle" Android thing. It can be worked around, I will add to the endless TODO list.
- I will check for the bin editing thing, seems weird nothing is being saved for you. If you take NVRAM out of the equation and just try to modify the local bin file on the Android device, does that at least work ?
- I have also added the dashboard enhancements to the endless TODO list. I did add a ton of code in that area few versions ago to make the dashboard component styling more straight forward to add/improve later down the road but not much as been done to expose the options to the user just yet.
- Button hold time could also be an option I guess, to either be triggered on tap or on long press.
- Auto logging was just added to endless TODO list and I already had data logging triggers in there (for example, start logging if MAP > 80kPA... things like that, customizable by the user)

Jayme: sweet!