ALDLdroid

[3400tZ]

Real time tuning will be the Moates Ostrich 2 (and 1) and chip programming will be the BURN2 (and BURN1 I guess?). Actually, my Moates hardware is currently at the post office, I just have to go pick it up :D

Here is the latest versions changelog:

0.33
- Fixed NPE reported on Play when starting the app with a dead gauge indicator

0.32
- Fixed annoying false triggering of editing a cell in tuning section when scrolling a 2D table
- Added "critically damped spring" smoothing algorithm to gauge indicators
- Added the possibility to view a data log as a Google map with the GPS location data from the data log displayed

0.31
- Added a "Time" column in data log

0.30
- Fixed a Bluetooth issue with the production V2 adapter of Red Devil River

0.29
- Added a debug logging option in the "Settings" section. This will create a "debugLog.txt" file in the "debug" folder on the SD card with all the ECU communications

0.28
- Fixed crash when the itemidhash of a dashboard entry is not present
- Fixed crash when the packet offset of an ADX value overflow an integer
- Added possibility of choosing where to display the digital display for gauge (above or below needle pivot point)

0.27
- Fixed random crashes when using Bluetooth
- Fixed some indicators such as Accelerometer X/Y/Z not updating properly
- Code cleanup

[-=Jeff=-]

I have a burn1 when you are ready test

[3400tZ]

So I got this, YAY!:


According to the hardware documentation, both the Ostrich and BURN2 should send their firmware version back when you send them "VV" AKA "0x56 0x56" on their serial port at 921600bps. Of course that would be too easy because I can't get neither to work... I've sniffed traffic on the serial port on Windows when using the Flash & Burn software and that really seems to be all of what is happening, yet it doesn't work in Android for me for some reason...

I'm probably just missing something simple, the fact that I'm currently brain dead doesn't help anything. I will try more this weekend and hopefully figure this out!

If anybody has coding experience with that hardware, feel free to shim in as well :)

[antus]

Its been a while, but before tunerpro 5, I implemented a protocol level emulator for autoprom (antusprom) which spoke the hardware side of the moates protocol. It was ugly and used virtual com port loop back to sit in between the ecu and our $12p software. It became obsolete when tunerpro gained official plugin support, but the source code is still here:

http://antus.no-ip.biz/antusprom/ant.../antusprom.cpp

Its been quite a while since I looked at it and it looks foreign to me now but what your doing sounds about right. Perhaps its a com port speed setting or a case sensitivity setting?

Have a look at the input_handler_thread function to see some protocol stuff. You could also try setting it up and running it against tunerpro 4 to get some debug info. http://pcmhacking.net/forums/viewtopic.php?f=3&t=30

PS, any chance you can support wiring to our nvram based systems? The protocol is standard aldl with write modes to function along side the read ones. I can provide details off forum if your interested.

PPS I have now tested ALDLdroid on a samsung galaxy tab 3 in one of my cars. It was just a test install (read: taped to dash in front of a gopro) but heres some footage. http://www.youtube.com/watch?v=MgTZORvxlqU

Is the g-force meter expected to work? I do believe the tab has the hardware.

Also a feature request for smaller widgets, and/or to be able to pack several text items in a text list down the page similar to the tunerpro data list view?

[3400tZ]

Cool I will take a look. At this point tho, the bottom line is when sending 0x56 0x56 at 921600bps, I should get 3 bytes back and I'm not so I really have to see what's going on with that!

I could support other real time tuning option in the future, I really want to support the hardware I have first, and that will be quite a bit of work.

I've seen your video a few days ago, even commented on it actually! :) I love it!

G-Force meter will work if your Android device has a triple axis accelerometer, make sure the Accel-X, Accel-Y, Accel-Z gauge are working. G-Force is just a calculation based on those.

I do have some smaller widget in mind. Judging by your video, it looks like you figured out the edit mode of the dashboard so you can resize the current indicators but I understand it might not be enough. You can use multiple dashboard pages as well.

Thanks

[3400tZ]

So I woke up today with the idea that I wouldn't sleep tonight until I have figured out what the hell is going on with this. I started by downloading the sample FTDI Android app and tried to send "VV" to the BURN2 and it worked. From there, since I had the source code of the sample app, I figured it would be easy. Turned out it took another like 4 hours of investigating to find that my issue in my app was that I was sending the serial commands from the UI thread and Android doesn't like that so it was blocking the read. The exception was swallowed at a lower level in the FTDI drivers so I couldn't see it. I ended up decompiling the FTDI drivers to investigate that and finally figured it out, PITA :)

Anyway, I've worked on the UI and on getting some functions to work for the BURN2 (and BURN1 and AutoProm). Here is a screenshot:




Burning a chip with the "Flash & Burn" program on Windows, and then reading the chip on Android and creating a .bin file out of it, then bringing that .bin file back on Windows and comparing it with the original using WinMerge, I got this (YAY!):




My Android tablet with the BURN2 connected to it



So far I got these functions working:

- Fetching hardware version
- Erase chip
- Blank check
- Read chip
- Save buffer to file

Now, I have a lot of rework on the comms side of thing so that everything play nice together (ex: ECU & Ostrich connected at the same time, one using Bluetooth, one using USB for example).

I also have a Bluetooth module coming for the Ostrich, I will make an how to for that if it works.

[RobertISaar]

so i'm curious... are there basically "profiles" in the BURN2 hardware that are selected via software on the PC side, or is it all done over code to select which PROM settings are used?

reason being: are there more PROM types than the ~8 or so that the BURN2 is officially capable of reading and ~3 of writing that can be used.

[3400tZ]

It's all done PC (Or Android :P) side. It's to the app to tell the hardware where and what to write. No hard coded profile on the hardware's firmware. So yeah, I guess theorically the hardware should be able to interact with more chips then what the Flash & Burn software is defining.

[hotrodssnova]

Looks like some nice progress. Keep up the good work.

[RobertISaar]

It's all done PC (Or Android :P) side. It's to the app to tell the hardware where and what to write. No hard coded profile on the hardware's firmware. So yeah, I guess theorically the hardware should be able to interact with more chips then what the Flash & Burn software is defining.

mucho neato.

i know there are some common higher than 64KB density EEPROMs out there that are still really cheap, i want to say the big brothers of the 27SF512. i guess Craig left that option open in the future should the SF512 and 29F040 chips run out.

[3400tZ]

Moved firing the commands over to an AsyncTask tonight like it should be (to avoid doing too much in the UI thread) and added a ProgressDialog (for obvious progress monitoring). That alone took a few hours so that was it for tonight. Hopefully I can start on the remaining incomplete commands (mainly programming chip) soon!

[-=Jeff=-]

Man this will be awesome... on stop shop, datalog change and burn.. will the next part be auto-tune ;) LOL

[3400tZ]

Auto-tune could be a possible feature but real-time tuning will have to be first obviously because I would want auto-tune to happen right away, not to generate a table after a run that you would have to manually enter. Although a proper log viewer and some different / better indicators design will probably come before auto-tune. I wish I could work on this app full time cause it's a lot of fun but I just can't for obvious reasons :P

I know some people are sceptic about auto-tune features but it's implemented in some MegaSquirt software and let me tell you, it works AWESOME! Just google VE Analazer Live for TunerStudio and you will see... It's not rocket science to tune a VE table but it takes time. There is no reason a software cannot do it just as good as a human can as the idea is just to get close to an AFR target. Obviously other parameters have to be tuned right first otherwise you're just chasing your tail, but that is true with auto-tune or not anyway. Auto-tune is something I would like to experiment with but it has been done by others and proven to work. What I've seen with OBD1 is that spread sheet stuff which is a bit too clunky and painful to use IMO. I'm not even sure if those tools all filter transition events such as AE, DE and that kind of stuff so they might not work as expected as well.

Anyway, back to interacting with a BURN2 for now :D

[hotrodssnova]

Auto tune does work well. Best to get your fuel maps close and then it takes over. This is coming along nicely. I will have to take a break on testing, I just ripped the hub from my clutch disk.

[3400tZ]

That sucks Eric! I hope you can get that fixed soon. Dropping a transmission isn't too bad tho. I guess you should still be able to test the chip programming stuff, but won't be able to test that chip in your car just yet.

The auto tune spread sheets might have got better (I've read mixed feelings personally tho), last I used one was in 2008. :D