Fred's firmware development diary

[Fred]

A screenshot of the datalog proving that the clock recovery stuff works:




And yes, that's the secret project, UltimateLogViewer lives and breaths and is in daily use here in Barcelona. Like UltimateLoader, if/when I release this generally, it'll be a paid app through which you can support me and know you're getting the best possible app for the job. For the time being, though, I'm keeping it for myself. It's not yet finished enough to charge for anyway.

Here's the development thread for it, including a story for each part, from scratch, per needs and requirements as I discovered and thought of them: viewtopic.php?f=25&t=2116

I talked to Ben yesterday and we've come up with a plan to get OLV 0.0.3 released ASAP, which is necessary for some changes that I want to introduce to the firmware. More on that soon.

Fred.

[Fred]

By the way, Andy's logs are immaculate from a sensor input point of view. As a result the other parameters are equally good. Here is a log he uploaded for me the other night: http://stuff.fredcooke.com/DeuceS10.nea ... 35.bin.bz2

His tuning isn't there yet, and it has some bad lean issues on tip in, but the log itself, and the install quality, is excellent.

Most FreeEMS users' logs will NOT look this nice for RPM and MAP and anything derived from those. There are technical reasons for that which I'll solve soon enough. The other sensors should definitely be this nice... No excuses, really. Make it happen.

Fred.

[Fred]

So, a year or two ago, my machine got nailed twice by MTX which logs to memory by default, and not disk. FreeEMS has pretty high data rates and memory is much more scarce than disk. I complained to Dave that it wasn't OK to basically intentionally leak memory like that. Much better to pump it to disk always and let the user clean that up if/when required. Here is some further proof. I had EMStudio hooked up to a device for more than 2 days solid, just shy of 52 hours in total. It logged 1.6 gig of raw log data. In OLV terms that's about 8 gig of RAM, so at best MTX would be up around 1.6 gig, and possibly a lot more (4 or 8 gig) depending on how it stores the data. ULV can/could/will load that up in about 1.5 gig of RAM. What's that you say, *less* than the original file? Yes, that's right. It's that efficient. ;-) Who ever said Java was a memory hog? Silly people.

Code: Select all

fred@cheetah:~/workspaces/freetune/core$ l -h ~/EMStudio/logs/*
-rw-r--r-- 1 fred fred 1.6G May 21 18:27 /home/fred/EMStudio/logs/2013.05.19-14.39.39.bin
-rw-r--r-- 1 fred fred  376 May 19 14:39 /home/fred/EMStudio/logs/2013.05.19-14.39.39.meta.json

[Fred]

Today I...

Added a tabular 3D table view to ULV, turned the bogus stats view into a real one, wrote some abuse about an idiot.

Tomorrow I'll...

Push two or three small commits on the firmware in the morning, then I need to sort out a hack for engine 20 to have a nice smooth tune.

Also:

ULV table needs some axes and labels and select/highlight/etc functionality.
UltimateLoader needs some proper retry behaviour.
ULV "stats" view needs to be configurable a bit.

And finally, the server also needs a bit of love tomorrow...

Lots going on in FreeEMS land. Lots to achieve. Lots of fun. Lots at stake. Pressure is on. As a wise man once said "Shit, or get off the pot." I hope he's reading this :-p

Fred.

[Fred]

Got some work done on firmware, but not enough to push anything, sadly. Didn't achieve much else, either. General fail. Had a minor medical moment, though, so some excuse :-p

Any help here would be appreciated, share the love :-) viewtopic.php?f=41&t=2140

Fred.

[Fred]

Today while sleeping in the sun I developed the new RPM calculation routines for the firmware. When I came in, I wrote them down on paper. I'll put them into code some time in the future :-)

Also put the SMD stuff on a Jag board for piimae and tested it, cleaned it, etc. Here's a 4 meg pic of solder flux that needs to be removed, nice and obvious once soaking in alcohol: http://stuff.fredcooke.com/PiimaesFirst ... isible.jpg

More tomorrow, hopefully much more, today/yesterday were too slow, though I'm in pain anyway. Fail.

Fred.

[Fred]

Code Reviewers and Review Requests thread that everyone should try to dig in and help with: viewtopic.php?f=41&t=2142

[Fred]

News hot off the wire tonight:

Need some improved RPM/MAP code before next weekend. The race is on, literally.

Fred.

[Fred]

A member of this forum is using Autronic on their development car, and had a picture of a datalog on facebook, which had "cyl sync 5.345" in it, which someone asked about, and he said this:

"cyl sync" possibly measures the timing difference between the crank sensor and reference cam sensor. This is mostly used for debugging possible trigger problems. No problems with that here!

Which might be a nice idea to use at some point. It's along the same lines as what is required for VVT control too. However for general sync debugging a proper LA style setup is vastly superior giving this info and much much more. I just wanted to note the idea down.

[Fred]

Mike has been good enough to document the process of building debian packages for N architectures from just one! Read all about it here: viewtopic.php?f=24&t=2144

Thank you Mike! I'll be putting that to use in future myself.

Fred.