scudderfish
|
| posted on 7/7/11 at 11:32 AM |
|
|
Bugger me, it worked! 
After a bit of fiddling with comms timing as eventhough I've got an MS1 running at only 9600 baud, I have to insert a few pauses in the dataflow
so it can keep up, I got it to generate this binary FRD log file. TunerStudio then
converted it into a standard MSL file and MegalogViewer displayed
it. Now I need to get some sort of display going to show that there really is activity going on.
|
|
|
|
|
scudderfish
|
| posted on 7/7/11 at 09:52 PM |
|
|
Hmmm, after my success, I put the 'full fat' calculations back in, and it worked again However, it isn't exactly performant.
This chart
 
Description
is the time in milliseconds to process the data from the MS in all its glory, averaging at about 175ms, which means just under 6 log events per
second. Is this fast enough? I think I may need too routines, a slow eye candy mode with GPS logging as well, and a binary logging mode that has a
faster sampling rate, but no extras such as much of a UI or extra data items such as GPS. Thoughts anyone?
Regards,
Dave
[Edited on 7/7/11 by scudderfish]
|
|
|
matt_gsxr
|
| posted on 7/7/11 at 10:12 PM |
|
|
175ms is a bit on the slow side for things like Acceleration Enrichment, and for spotting problems (like electrical interference on sensors). My
standard MS2 logs to my little netbook at ~60ms.
For basic logging 175ms is fine and would allow me to detect loads of basic problems.
I would worry about logging things like acceleration, braking points, or suspension movement at 6Hz (Cosworth recommend sampling suspension motion at
200Hz), but if we had an accurate GPS signal then 6Hz would be plenty for that. A higher sampling rate is good as it allows us to average to reduce
errors.
If you have 175ms now, then I am sure with a bit of fiddling it will be 100ms, which is pretty close to 60ms. Sounds like a great start.
Nice work
Matt
p.s. I'm not sure of your new avatar though, preferred the Fury, the monkey scares me!
|
|
|
scudderfish
|
| posted on 8/7/11 at 07:00 AM |
|
|
I had a bit of a brainwave last night. I can catch the actual runtime variables from the MS and log them (as per FRD file above) at a good lick. The
slow bit is calculating all the nice stuff. This is the current list of nice stuff as per the INI file
accDecEnrich = (( (engine & 32) != 0 ) ? 100 : ((pulseWidth1-injOpen1) / (pulseWidth1-(accelEnrich / 10)-injOpen1) * 100));
batteryVoltage = (batADC / 255.0 * 30.0);
coolant = (tempCvt(table(cltADC, "thermfactor.inc" )-40));
egoVoltage = (egoADC / 255.0 * 5.0);
ego2Voltage = (fuelADC / 255.0 * 5.0);
mat = (tempCvt(table(matADC, "matfactor.inc" )-40));
rpm = (rpm100*100);
time = (timeNow());
egttemp = (egtADC * 3.90625);
lambda2 = (table(fuelADC, "WBlambda100MOT.inc" ) / 100.0);
afr2 = (lambda2 * 14.7);
afr = (egoADC * 0.039216 + 9);
lambda = (afr / 14.7);
TargetAFR = (afrtarget * 0.039216 + 9);
TargetLambda = (TargetAFR / 14.7);
barometer = (table(baroADC, "kpafactor4250.inc" ));
map = (table(mapADC, "kpafactor4250.inc" ));
throttle = (table(tpsADC, "throttlefactor.inc" ));
advSpark = ((advance * 0.352)-10);
KnockAng = ((KnockAngle * 90 / 256));
KnockDeg = (-KnockAng);
CltIatAng = (CltIatAngle * 90 / 256);
CltIatDeg = (CltIatAng < 45? CltIatAng: -90 + CltIatAng);
fuelvolt = (fuelADC < 1 ? 0.0 : fuelADC * (5/255) - 0.5);
fuelpress = (fuelADC < 1 ? 0.0 : fuelvolt / 0.04 +1);
altDiv1 = (alternate1 != 0 ? 2 : 1);
altDiv2 = (alternate2 != 0 ? 2 : 1);
cycleTime1 = (rpm < 100 ? 0 : 60000.0 / rpm * (2.0-twoStroke1));
nSquirts1 = (nCylinders1/divider1);
dutyCycle1 = (rpm < 100 ? 0 : 100.0*nSquirts1/altDiv1*pulseWidth1/cycleTime1);
cycleTime2 = (rpm < 100 ? 0 : 60000.0 / rpm * (2.0-twoStroke2));
nSquirts2 = (nCylinders2/divider2);
dutyCycle2 = (rpm < 100 ? 0 : 100.0*nSquirts2/altDiv2*pulseWidth2/cycleTime2);
Open_Time1 = (1.0);
Open_Time2 = (1.0);
InjectorRating1 = (100);
InjectorRating2 = (100);
dutyCy1Real = (rpm < 100 ? 0 : InjectorRating1*nSquirts1/altDiv1*(pulseWidth1-Open_Time1)/cycleTime1);
dutyCy2Real = (rpm < 100 ? 0 : InjectorRating2*nSquirts2/altDiv2*(pulseWidth2-Open_Time2)/cycleTime2);
veCurr = (veCurr1);
pulseWidth = (pulseWidth1);
iTimefull = ((iTimeX*65536)+ iTime);
RpmHitmp = (iTimefull > 0 ? (60000000 *(2.0-twoStroke1)) / (iTimefull * nCylinders1) : 0);
RpmHiRes = (RpmHitmp > 20 ? RpmHitmp : 0);
vacuum = ((barometer-map)*0.2953007);
boost = (map < barometer ? 0.0 : (map-barometer)*0.1450377);
boostVac = (map < barometer ? -vacuum : (map-barometer)*0.1450377);
floodclear = (tpsADC > 200 ? 1 : 0);
Timeroll = (portc & 4);
waterIlog = (porta & 16);
MAFVolts = (fuelADC * 0.0196078);
nosActive1 = (( (portd & 2) != 0 ) ? 0 : 1);
However, I don't really care about all of those at run time. I only need to calculate the half dozen I'm using in the UI whilst I'm
running. When the user presses the 'Stop logging' button I can then run over the full set with info I read back from the FRD file, mix in
some captured GPS and accelerometer stuff and generate the full fat MSL file in a few seconds.
The best I can get out of the 9600 baud interface is a sampling rate of about 26Hz, lets see how close I get.
|
|
|
scudderfish
|
| posted on 8/7/11 at 07:43 AM |
|
|
Hmmm, cutting the calculations down to this
coolant = (tempCvt(table(cltADC, "thermfactor.inc" )-40));
mat = (tempCvt(table(matADC, "matfactor.inc" )-40));
rpm = (rpm100*100);
lambda2 = (table(fuelADC, "WBlambda100MOT.inc" ) / 100.0);
afr2 = (lambda2 * 14.7);
map = (table(mapADC, "kpafactor4250.inc" ));
results in
 
Description
which isn't nearly as dramatic as I'd hoped. Time to figure out how to do accurate profiling in Android.....
|
|
|
matt_gsxr
|
| posted on 8/7/11 at 08:26 AM |
|
|
Perhaps those lookup table commands are demanding, I know on the MS they interpolate.
On the MS there isn't much memory, you could pre-calculate the mappings into an array and then use the integer value for each of the parameters
as an index to that array. It would be fast, and I doubt the Android has much in the way of memory limitations.
Just a thought
Matt
|
|
|
scudderfish
|
| posted on 8/7/11 at 08:52 AM |
|
|
I've been doing software dev for 20+ years and it still catches me out I forgot my performance mantras
You can't optimise what you can't measure
Premature optimisation is the root of all evil
Getting the data is a three step process
1) Get the data from the MS
2) Convert the raw data bits into something more amenable to manipulation in Java
3) Run the calculations.
I assumed point 3 was where the time was being spent. Turns out I was wrong.
getRuntime() 104.77
populateUserVars() 4.17
recalc() 30.49
The comms side of it is running too slow. I had added some delays to sort out what I thought was data corruption (turned out to be crap in the
buffers), so I'll pull those out and see what happens.
|
|
|
scudderfish
|
| posted on 10/7/11 at 08:22 AM |
|
|
I've gone public
https://github.com/scudderfish/MSLogger
No releases, but the source is there. If an installable app is an ExtraEFI MS ECU, this is a random collection of unlabelled electronic components.
|
|
|
scudderfish
|
| posted on 10/7/11 at 08:24 AM |
|
|
quote:
Originally posted by matt_gsxr
Perhaps those lookup table commands are demanding, I know on the MS they interpolate.
On the MS there isn't much memory, you could pre-calculate the mappings into an array and then use the integer value for each of the parameters
as an index to that array. It would be fast, and I doubt the Android has much in the way of memory limitations.
Just a thought
Matt
The table functions are a simple lookup which is nice and fast. Android apps do have a hard limit of 16Mb. More than available on the MS, but still
somewhat constraining
|
|
|
scudderfish
|
| posted on 21/7/11 at 03:04 PM |
|
|
Ooo, a bit of progress
I've got it writing out both a binary FRD file and a more usable MSL file. I just converted the FRD file with TunerStudio, and apart from my
time function not working and a couple of fractional rounding differences, it's a match.
|
|
|
scudderfish
|
| posted on 2/8/11 at 01:05 PM |
|
|
I had a bit of an epiphany. I was bending over backwards to parse standard INI files, and it was burning a lot of CPU time on devices that are CPU
constrained. I assume most users do not hack around the INI file to add their own equations for logging. You can do that by feeding the MSL file
into Excel and chomping on it there. I was never planning on letting people upload their own INI files. Therefore, I'm basically rewriting
from scratch. Out the window goes all the INI parsing and processing, in comes a set of predefined ECUs, starting with MS1Extra & MS2Extra, with
others added as people actually ask for them. If I do this, then the data processing time should effectively disappear, which frees up more time for
logging and the user interface whilst getting as close as possible to running the serial connection as fast as the bit rate will allow. MSLogger is
dead, long live MSLogger!
|
|
|
scudderfish
|
| posted on 17/8/11 at 08:32 PM |
|
|
I'm now making quite rapid progress on this. A bit of scripting can do the heavy work of converting MS INI code into Java code. For example,
this bit of line noise:-
cat output.txt | grep -v '{' | grep -v '#' | sed -e 's/^[ \t]*//' | grep -v '^;' | sed -e
's/scalar,//' | sed -e 's/[SU]16/getWord(ochBuffer/' | sed -e 's/[SU]32/getLong(ochBuffer/' | sed -e
's/bits,[ \t]*U08/getBits(ochBuffer/' | sed -e 's/[SU]08/getByte(ochBuffer/' | sed -e
's/\[\([0-7]\):\([0-7]\)\]/\1,\2);/' | sed -e 's/".*//' | sed -e 's/,[ \t]*$/);/'
just converted the output section of an MS2extra ini file into a chunk of Java to convert the byte buffer into a set of variables. I'm posting
it here so I don't lose it
|
|
|
scudderfish
|
| posted on 7/10/11 at 12:22 PM |
|
|
Oops, long time since I've updated this. I was on the verge of abandoning this as I was struggling to get a reliable connection between my ECU
and phone. After much thrashing around I've got something that works. I'm now producing FRD and MSL log files at about 10Hz. A lot of
the overhead appears to be in the Android Bluetooth subsystem so there isn't a lot I can do about that. On a plus note, my MSL log files now
contain longitude, latitude, bearing, speed, accuracy and millisecond time. I'm thinking of making this available for test now. If you are
interested you will need :-
1) An Android device running at least Android 2.2
2) A paired bluetooth serial adapter.
3) An MS firmware I support. Currently it's limited to MS1/Extra format 029y3 as that is what I have and MS2Extra Rel 2.1.0q (what Matt has).
I'm probably going to implement MS2Extra Serial310 tonight as that is the latest MS2Extra firmware. If you have any particular request, send me
your INI file for inclusion.
Email me at dave@smithfamily.org.uk if you want to give this a go.
Regards,
Dave
|
|
|
matt_gsxr
|
| posted on 10/10/11 at 12:59 PM |
|
|
I need to upgrade my San Francisco to 2.2 (not a big deal I am told), and get hold of a Bluetooth adapter.
Can you suggest a suitable adapter?
|
|
|
scudderfish
|
| posted on 10/10/11 at 01:15 PM |
|
|
I got a single one of these LM TECHNOLOGIES (TWIN PACK) BLUETOOTH RS232 SERIAL PRINTER DUO ADAPTOR LM048SPA2 | eBay for
about £25.
This could be useful
http://www.ebay.co.uk/itm/Smart-RS232-Bluetooth-Module-DB9-Interface-/270739589434?pt=LH_DefaultDomain_0&hash=item3f0956493a#ht_5277wt_1199 or
this one looks a bit more professional
http://www.ebay.co.uk/itm/Bluetooth-Serial-RS232-Adapter-Class1-100meter-range-/260851969761?pt=UK_Computing_CablesConnectors_RL&hash=item3cbbfd2e
e1#ht_820wt_1199
If you search ebay for 'RS232 bluetooth' you'll also come up with a bunch of bare boards that could be mounted directly on the MS.
I haven't done that, but I might do in the future.
The important thing is to get TunerStudio talking to the MS over bluetooth first as that will isolate BT problems a lot easier than trying to do it
all on the phone.
Regards,
Dave
|
|
|
scudderfish
|
| posted on 10/10/11 at 01:51 PM |
|
|
Incidentally 2.2 is a minimum, I'm running 2.3.3 at the moment.
|
|
|
matt_gsxr
|
| posted on 10/10/11 at 08:57 PM |
|
|
Thanks, I will get on with 2.3.3 and bluetooth tomorrow.
Won't be ready to try it out your stuff until next week though.
|
|
|
scudderfish
|
| posted on 11/10/11 at 12:07 PM |
|
|
I've developed a small program to digest INI files and spit out Java code, this should speed up adding new firmwares. It also lets me find
which firmwares are actually identical (for as far as I care), such as 2.1.0p and 2.1.0q. Right now the software generates a .msl and a .frd file.
The frd is basically a binary dump of the datastream from the MS and you can use TunerStudio to convert it to an msl file. I generate both to sanity
check the msl generation. Before I let this out, I'll also add an application log file so I can hopefully figure out what went wrong when it
crashes. It doesn't send any updates to the MS, but until it has proven itself take a back up of your tune and don't go out without a
laptop loaded with TunerStudio in case it craps all over your map. This will be a beta release so don't volunteer and expect a polished
application. Have I put everyone off now?
Regards,
Dave
|
|
|
scudderfish
|
| posted on 11/10/11 at 12:31 PM |
|
|
Incidentally, it's home page has moved to https://bitbucket.org/scudderfish/mslogger/wiki/Home . I'll be using this for documentation,
bug tracking and feature requests.
Regards,
Dave
|
|
|
matt_gsxr
|
| posted on 11/10/11 at 09:01 PM |
|
|
I'm getting there, updated to 2.3.3 gingerbread today, very easy.
Now to order a bluetooth to serial thingy
|
|
|
scudderfish
|
| posted on 11/10/11 at 09:12 PM |
|
|
Well I just created the 1.0 MSLogger.apk file ready to test I'm hopefully going to have a chance to do a smoke test against an MS2 ECU later
this week. If it passes that I'll email it out to those who have volunteered.
Regards,
Dave
|
|
|
hobbsy
|
| posted on 11/10/11 at 09:44 PM |
|
|
How are you finding devloping on android generally?
|
|
|
scudderfish
|
| posted on 12/10/11 at 08:17 AM |
|
|
quote:
Originally posted by hobbsy
How are you finding devloping on android generally?
I like it a lot. I've previously attempted iPhone coding but I couldn't get on with Objective C. I wrote some stuff for the Nokia N900
in Python & C++ which was quite fun, but a technological dead end. My day job is writing large systems for telcos in Java & Oracle, so doing
Java on a hand held device is a refreshing change, but not too far out of my comfort zone.
|
|
|
scudderfish
|
 posted on 13/10/11 at 11:47 AM |
|
|
I've just emailed the beta version out to the testers. If anyone else wants a crack at it, let me know.
Regards,
Dave
|
|
|
HowardB
|
| posted on 13/10/11 at 12:07 PM |
|
|
watching this with interest as I will get a tablet in 2012, and already have MS on the car,...
very good work
Howard
Fisher Fury was 2000 Zetec - now a 1600 (it Lives again and goes zoom)
|
|
|
