I'm really on a bit of a fishing expedition to see if there is any interest in this. I'm currently ploughing through gobs of C++ from Megatune and converting parts of it to Java with the idea of running it on Android devices using a bluetooth connection to MS. Right now, I'm only looking at logging and some rudimentary data display. A full Megatune/TunerStudio type user interface is never going to work on a small touch device so this would be a supplement to a laptop. Use MT/TS on the laptop for initial config and set up, then do on the road tuning/logging to the phone in your pocket rather than have the laptop skating around in the footwell. To this end, I've got a few questions for you :-

1) Are you interested in this?
2) What version of Android are you running?
3) What Megasquirt hardware/firmware do you have ?
4) Bluetooth serial adapters cost about £20-£50, would this put you off?
5) What would you be prepared to pay for such an application given all of the above?

Regards,
Dave

Would be slightly intrested in this,

Android Version 2.2 (HTC DESIRE HD)

Problem I foresee is connecting the Phone to the Megasquirt. Most USB to Blue tooth are designed with the idea of bule tooth enabling a computer not bule tooth enabling a device.

You may need to look at building a custom "Android" cable. Then you have the problems of linking it to the phone.

Not a USB - bluetooth (which are dirt cheap), but an RS232 - Bluetooth adapter, which are not dirt cheap. Something like this (which happens to be two of them)
RS232 Serial Bluetooth Adapters (Pair) Brand New on eBay (end time 06-Feb-11 06:47:42 GMT)

the problem i see with the serial bluetooth adapters is how to power them. i don't think serial sockets have power supplies built in, like USB does...

would be good for finding and fixing ignition faults on the car when you're awya from home though. i'd like it, if it could be used for everything rather than just logging. however i don't have a smartphone. considering iphone, but i'm not going to pay for one lol. plus o've only got ignition anyway, as my car's on carbs

I'd be up for this.

Presently running an Orange version of Android on a San Francisco, but don't mind reinstalling the OS from a more normal source.

MS is MS2 daughter card upgrade.

Have you considered using a cable instead of the bluetooth? That is what I had going with my palm pilot. I don't mind "investing" in a serial bluetooth adapter if that is what is needed though.

It would be megacool to integrate this app. with the GPS accelerometer datalogging stuff that is out there for these phones, with a bit of intelligent software it could do some nice stuff once you could integrate this stuff together.

Matt

The megasquirt powers the bluetooth adapter. One of the pins (pin 9 I think) provides the requisite juice. I haven't looked too deeply into any sort of cable as far as I can see there is no standard cable based capability with Android devices, where as bluetooth is pretty much everywhere (except the really cheap tablets that Maplins sell). I was looking to see if it was possible to do RS232 over the headphone socket by bit banging the audio hardware, but there doesn't seem to be anything out there about that idea.

As for logging, I'd love to throw in GPS, compass & accelerometer as well, but that may mean taking liberties with the format expected by megalogviewer. It won't be as accurate as dedicated data loggers, but it'll be good enough for most people. First steps first though, I've got to get it correctly decoding all the INI files for the various different megasquirts.

Regards,
Dave

Certainly an interesting idea.

Sadly I have neither MS (yet!) or a decent phone!

I know that as long as 4 or so years ago CalvinX was converting MS to run with Bluetooth instead of serial so if you can track him down (I believe some people on here are still in touch with him) then he might be able to help.

Cheers,
James

quote:

---

Originally posted by James
Certainly an interesting idea.

Sadly I have neither MS (yet!) or a decent phone!

I know that as long as 4 or so years ago CalvinX was converting MS to run with Bluetooth instead of serial so if you can track him down (I believe some people on here are still in touch with him) then he might be able to help.

Cheers,
James

---

Plenty of people on the msefi forums that have fiddled with serial bluetooth adaptors, but hardly any at all that have had any kind of reliability. Most people's experiences seem to be that if they can even connect at all, it'll last for a matter of seconds then drop the connection.

There's a project going to get a similar app on the iphone that is based around using a serial to wifi module instead, mainly to circumvent the restrictions apple place on using the serial interface. It does have a slightly higher initial cost but appears to be more reliable from early indications, and has the benefit of being totally platform agnostic. They have been using a wi-fly/rn-134 module, although I've recently seen a SPI-wifi module from H&D wireless that looks promising and is dirt cheap (£28 for the module, but will need a few quid's extra hardware to get it passing RS232).

The developers behind both Tunerstudio and Megatunix are apparently planning to look at this 'at some point' as well. If you need advice regarding log file formats and things then Phil Tobin (Tunerstudio) appears to be quite helpful if you ask him nicely.

This would be very interesting, i have been using a Bluetooth Socket like this

linky

on tunerstudio and megatune for a couple of years now, i've been looking for phone version as i really want to datalog without the laptop.

So i'll definitely be wanting this thread

I'm going for bluetooth right now as I have a couple of BT-RS232 adapters kicking around and I'm not fighting the limitations on the iOS platform. It should be feasible to interface over both in the s/w though.

I'm not going to have anything available for a few months yet, but I'll keep this thread alive with progress for those who are interested.

Regards,
Dave

Not interested myself but saw this and thought of you.

http://www.msextra.com/forums/viewtopic.php?f=122&t=34779&sid=df5ed9dda03b713a886043e7d15f60c6

I posted on that thread when I was doing this for the Nokia N900. I've abandoned that line of code though as the platform is a dead end.

OK, I've written a MS simulator that takes log files and pumps them out as if it is a megasquirt. It should be adaptable based upon the log file format it is fed to simulate different flavours of megasquirt. This way I can push the main development ahead without being tied to the actual hardware.


I need your log files!


I've only got ones generated by my MS so if you have anything other than a MS1Extra I'd be grateful if you could send me a sample log file. No multi megabyte beasts, but at least a couple of minutes of run time. If it also captures starting or stopping the engine that'd be great. Send them to me at dave.g.smith@gmail.com

Regards,
Dave

quote:

---

Originally posted by scudderfish
OK, I've written a MS simulator that takes log files and pumps them out as if it is a megasquirt. It should be adaptable based upon the log file format it is fed to simulate different flavours of megasquirt. This way I can push the main development ahead without being tied to the actual hardware.


I need your log files!


I've only got ones generated by my MS so if you have anything other than a MS1Extra I'd be grateful if you could send me a sample log file. No multi megabyte beasts, but at least a couple of minutes of run time. If it also captures starting or stopping the engine that'd be great. Send them to me at dave.g.smith@gmail.com

Regards,
Dave

---

My wife just phoned me to let me know that the cheap Android tablet I bought from eBay has arrived Now I have real hardware to develop with (and a weeks holiday coming up), I should make more progress.

Instead of trying to support every MS version under the sun, for now I'm only going to target MS1/Extra and MS2/Extra. If you have anything else and you're interested in this, send me some log files.

Regards,
Dave

quote:

---

Originally posted by scudderfish
I posted on that thread when I was doing this for the Nokia N900. I've abandoned that line of code though as the platform is a dead end.

---

quote:

---

Originally posted by HowardB

quote:

---

Originally posted by scudderfish
I posted on that thread when I was doing this for the Nokia N900. I've abandoned that line of code though as the platform is a dead end.

---

My N900 still works and there seems to be stuff about. Guess it just wasn't popular enough.

Having said that I now use it as a web browser, and email client at home to save booting the PC.

---

not getting you wrong, and I am with you on their misdirection, I have told Nokia of my thoughts and no doubt they will ignore me along with many millions of their loyal followers by teaming up with micro$oft!

oh well, what we had were phones, now we have computers that allow us to make phone calls occasionally,...

what about doing one for megajolt? as a programmer? would that work?
just got an HTC desire HD, so now thinking it waould be awesome, but i'm using megajolt.
i'd give it a go myself but haven't got a clue where to start lol

edit, looks like autosport labs are already on it
http://www.autosportlabs.org/viewtopic.php?p=16131&sid=c4f220b19fd0b35e048ef01040182518

just need to find a way to get my older megajolt to work on bluetooth reliably, and see if new megajolt software works properly with my old version of megajolt... should have waited to get my megajolt shouldn't i? lol

[Edited on 20/2/11 by blakep82]

Been playing a bit with the UI as I got bored fiddling with the code that runs in the background. Given the small nature and low res of the target screens it probably won't get much more advanced than this mock up, probably a few LED type indicators for 'oh sh*t' values.


Description

looks really good i can get you some ms3 logs but they will only be a startup idle and shutoff as the car isnt taxed at the moment. i acording to james and ken the jump from ms2extra to ms3 isnt to bad in terms of what you are trying to achieve.

quote:

---

Originally posted by scudderfish
Been playing a bit with the UI as I got bored fiddling

---

That will look nice.

Have you considered whether you could recycle the .dash dashboard file format that is implemented in TunerStudio. It is a simple xml format, so is human readable.

It is more than you really need, but if you implemented a gauge and a labelled warning light, then you would have everything that you have talked about. The only other thing would be a graph (i.e. AFR versus time, RPM versus time and TPS versus time) but these are not as essential.

Matt

quote:

---

Originally posted by matt_gsxr
That will look nice.

Have you considered whether you could recycle the .dash dashboard file format that is implemented in TunerStudio. It is a simple xml format, so is human readable.

It is more than you really need, but if you implemented a gauge and a labelled warning light, then you would have everything that you have talked about. The only other thing would be a graph (i.e. AFR versus time, RPM versus time and TPS versus time) but these are not as essential.

Matt

---

fair enough. It was just one of those thoughts.

Just looking at that picture on my San Francisco now. It looks plenty big enough. The only problem would be the font size.

Some gauges need to have decent resolution (i.e. map, AFR, pulse width), but loads don't matter (e.g. is the temp sensor plugged in? have I got some volts?). A benefit of the TunerStudio type design is that its already been thought about and will include most of what is needed, but there would be considerable implementation effort.

Your plan to hardwire in v0.01 makes good sense.

MAP, AFR, RPM, and whether warmed or not and whether it is logging would pretty much cover it.

Now I need to think about buying a bluetooth serial adapter.

Matt

Please don't spend any money until I've actually got it working If you're prepared to test I've got a spare BT-Serial adapter I could lend to you.

Regards,
Dave

i think the only way to get more info on screen is to do away with the gauges and just show the numbers kind of like a digital watch display.

in theory if you root your android phone install the full jre you should be able to run the linux version of ts, not sure how you would get ts to use the phones blue-tooth for the serial connection it would either require a code change in ts or a bit of hacking about with the kernel on the phone to spoof the blue-tooth connection into thinking its a serial device so ts can see it.

if i had the time i would offer to help with a bit of coding, did java visual studio .net c++ etc at uni so wouldnt find it hard to get back into the swing of it. unfortunately im up to my eyeballs with work at the minute.

have subscribed to this as im interested to see the progress.

[Edited on 8/3/2011 by ashg]

I got TS running on my Nokia N900, but it relies on a native code library to interface to the serial port, and the UI is designed for PC sized screens. In the end I took the Megatune C++ code for decoding the INI files and translated it to Java. Now it's a matter of connecting the dots between data coming off either BT stack or a network socket, to the MT based guts to whatever UI components are currently displayed to a logging engine.

The gauges really are just a bit of bling to see how it would look, my initial prototype was really just three labels and three numbers. Swapping layouts at runtime is easy to do on Android, it's creating the on phone UI for creating or modifying layouts that is a PITA.

Have you had a look at Torque-BHP ?
(http://torque-bhp.com/)


Same idea, but reading from OBD port. We use it at work on a selection of HTC Android phones.
The interface is quite nice. May give you some ideas on what is readable / sensible.


Cheers

tim.

NumericControls




Playing with LCD alike displays. Not using dials gives me more room to play with, I could easily fit another 3 to the display above. Question is, what other 3 would be on your 'must have' display ? Coolant temp, air temp and......

Something like this?


Description

Could do with another field just to balance out the display

hey I found this thread by google, never thought that there were this kind of discussion here!

I'm following. Need badly some kind of display device for my MS. Multiple physical gauges is a no no, LCDash is not produced anymore (and I don't like it) and megaview is a little sh*tty

Open a thread in msextra too, please, there are a lot of people that would like this and could help to test/build!

Phil (of Tunerstudio) is working on it too and he say something could be out for spring...
http://www.msextra.com/forums/viewtopic.php?f=122&t=34779&start=80

cheers,
I'm nuvolarossa on there

quote:

---

Originally posted by nuvolae36
hey I found this thread by google, never thought that there were this kind of discussion here!

I'm following. Need badly some kind of display device for my MS. Multiple physical gauges is a no no, LCDash is not produced anymore (and I don't like it) and megaview is a little sh*tty

Open a thread in msextra too, please, there are a lot of people that would like this and could help to test/build!

Phil (of Tunerstudio) is working on it too and he say something could be out for spring...
http://www.msextra.com/forums/viewtopic.php?f=122&t=34779&start=80

cheers,
I'm nuvolarossa on there

---

OK, I'm happy with this for now. I've added in spark angle, and a big 'Start Logging' button. It'll say 'Stop Logging' if you currently logging data


Description

nice,

Those look good.

TPS might be useful (just as a debug tool), sync errors can be handy, battery voltage (is useful, if you have a rubbish alternator like me). It all depends on what is going on, but I like the ones you have.

Does this actually get signals from anywhere, or is this a mock-up still?

Matt

Right now, this is mostly a mockup so I can play with layouts and colours. However it does connect to my MS simulator, probe it, and then load and parse the associated INI file. I need to set up a timer to query the sim and then connect the returned values to the half dozen displayed controls.

Regards,
Dave

It appears that I was converting the Megatune code, I had stubbed out a big bit that "I'd do later". It turns out later is now so back into the guts with not a lot to show for it

MegaTune is quite a complex beast...

Given an INI file entry such as :-


accDecEnrich = { (engine & 0b00100000) ? tdePct : ((pulseWidth-injOpen) / (pulseWidth-accelEnrich-injOpen) * 100) }, "%" ; In percent, centered on 100% meaning no correction.


It effectively compiles the statement into a datastructure that represents a stack based virtual machine and then 'executes' it at runtime.

However the insidious differences between C++ & Java are making getting this to be a 100% faithful reproduction quite tricky. Tonight I'm going to have a play around with embedding BeanShell and see if I can get that to do all the heavy lifting. It should just need a bit of preprocessing on the statements to Javafy them, so the above becomes

accDecEnrich = (engine & 32) != 0 ? tdePct : ((pulseWidth-injOpen) / (pulseWidth-accelEnrich-injOpen) * 100);

The more I dig into this, the more I'm impressed with the work B&G did to produce the MS.

Regards,
Dave

Aha! Discovered that the bluetooth module I've got plugged into my MS is powerful enough to communicate with my desktop in the house. This should make dev work a bit easier as I can talk with the real thing rather than messing around with the simulator.

quote:

---

Originally posted by scudderfish
Aha! Discovered that the bluetooth module I've got plugged into my MS is powerful enough to communicate with my desktop in the house. This should make dev work a bit easier as I can talk with the real thing rather than messing around with the simulator.

---

This project isn't dead yet I've now bought myself an HTC Desire S, and it's making the development a lot easier. I'm now communicating with the MS, and evaluating all the expressions in the associated INI file. Next major hurdle is to connect the internal numbers to the controls on the display. Once that's done, logging to file should be straightforward. I did a side project for a friend for logging GPS position, so I'll slide that code in as well so your MS log will contain location info as well.

Awesome news. I have built a speedo with an arduino, so hopefully I can send the speed into to the MS as an additional input, so GPS + speedo + MS should mean pretty nice datalogging.

Looking forward to it.

Matt

quote:

---

Originally posted by matt_gsxr
Awesome news. I have built a speedo with an arduino, so hopefully I can send the speed into to the MS as an additional input, so GPS + speedo + MS should mean pretty nice datalogging.

Looking forward to it.

Matt

---

My reasoning to consider adding direct speed information is that I think that speed from GPS is generally pretty poor.

I loaded up one of those apps for trackdays and logged whilst on a bus on the motorway. The speed wasn't very stable ranging up and down as much as +/-10mph (the bus basically sits just below its speed limiter).

I am told that GPS can determine speed in two ways.
Either using the positions divided by time (simple but differentiation of position amplifies the errors).
or using doppler http://nujournal.net/HighAccuracySpeed.pdf which will be much more precise

I don't think phones do doppler speed stuff and have relatively low frequency basic GPS.

Accelerometer use is interesting idea. For it to work we would need to fix the phone in a single orientation and then combine the accelerometer with the GPS either using a Kalman filter (if we need real-time) or something cleverer if we don't need real-time. I haven't googled on it, but if the problem of velocity drift could be managed then it could work well. I am sure it has been done 1000 times before.


With a direct speedometer it would be easier.

Matt

p.s. I am at one with my inner geek

Comms started

Screenshot hot off my phone which is now talking to my MS and attempting to show numbers. The numbers are wrong (my car is sat in the garage with the MS on, but the engine not running), but the major plumbing is now working

Awesome news

thats looking really sweet. if you want to do some testing on ms3 i can do it for you.

I need to get it working with my MS1 before I venture into other areas. I'd be interested in your INI file and an example log file though please to throw into the test cases.

Regards,
Dave

Slight change in direction. My initial aim has always been for log capture. I've gone down a side street with heavyweight INI file processing and expression evaluation that the full TunerStudio does. This has caused me no end of problems. What I've done tonight is cut out those code paths and implemented the raw datalog documented here. These files can be converted by TunerStudio into an MSL file for Megalogviewer to parse. I'm going to strip down the UI just to show logging progress for now, and introduce the other stuff later when I've got a better handle on just how fast I can run this. I think accurate high resolution logging is more important than eye candy.

Regards,
Dave

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.

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]

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!

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.

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.....

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

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.

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.

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

---

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.

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!

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

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

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?

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

Incidentally 2.2 is a minimum, I'm running 2.3.3 at the moment.

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.

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

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

I'm getting there, updated to 2.3.3 gingerbread today, very easy.
Now to order a bluetooth to serial thingy

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

How are you finding devloping on android generally?

quote:

---

Originally posted by hobbsy
How are you finding devloping on android generally?

---

I've just emailed the beta version out to the testers. If anyone else wants a crack at it, let me know.

Regards,
Dave

watching this with interest as I will get a tablet in 2012, and already have MS on the car,...

very good work

Just had first reports in of success in connecting to and getting data from an MS2. Some of the logged values are borked, but it basically works. Happy days

Yup, it works. Nice work.

I'm having very spotty comms with my MS2 Extra310. I can get the M and S banners occasionally, but also get errors and disconnects. I don't think it's your app as I also get weirdness with Tunerstudio. I did get one of the BT adaptors you recommended (BT-232B-E) and I can get easy BT pairing etc between both my phones (Galaxy Nexus and Desire) and my laptop...

I also got 2 of the BT adaptors and both do the same.

I have set the adaptors to 115200, 8N1...

As I say, not an issue with your SW, I just hoped maybe you had some pointers given you have used the same BT adaptor (or know someone who has used it successfully)

(I have emailed logs to you separately)

I am able to get a reliable USB-Serial connection to Tunerstudio with a Prolific adaptor so I think the MS is ok.

I did read somewhere about mods to the MS required to use a BT adaptor but nothing on your page so I am hoping that was for much older hardware or adaptors without the config options these have?

Cheers - Neil G

ps. Edit - WOW, can't believe this is my first post here - I have been reading for ages! I have a Toyota based 4AGE locost Toy with IRS and LSD.

[Edited on 20/12/11 by Talkiet]

I thought it not fair to be charging for something I couldn't properly support, debugging connectivity issues at a distance is no fun at all, and the level of sales didn't make it worthwhile. Consequently I'm releasing MSLogger and it's supporting application into the wild. The source for MSLogger can be found here :-

https://bitbucket.org/scudderfish/mslogger

It has a companion command line application call Normaliser. This does the heavy lifting of translating an MS INI file into a Java class. The source for that can be found here :-

https://bitbucket.org/scudderfish/normaliser

I'm going to carry on developing it for my own use and fun, but if you want to take a stab at doing your own thing, go right ahead. If you happen to fix any bugs, I'd appreciate a patch.

Regards,
Dave

Ill try your stuff when I get time because a pocket contained datalogger would be mighty handy for me on the track, but mainly Im posting here with a further option.
For archos 101IT owners who have installed the angstrom developer edition of linux, you can then install the openAOS debian build alongside android (I have four o/s on at the moment, android, cyanogen, angstrom and openaos) and I have a .deb of megatunix compiled for debian arm. So now I can datalog with my phone and tune with my tablet. Ive already converted my megasquirt to talk over a bluetooth link and used it with megatunix on my linux net top so I know that bit of the equation is ok.

Sadly my middy v8 build is again stalled while I build a workshop, but the megasquirt is currently on a street motorbike, and im building another for a dragbike project...

[Edited on 11/1/12 by MrFluffy]

[Edited on 11/1/12 by MrFluffy]