fe3tcourier

Teaser :



More to come soon :-)

Fred.

Tom-Guy

Fred, one of my main complaints about MS was the lack of tunable cells. Even the high res code was lacking, especially if you are trying to use a 4 bar sensor or the like. Can you make fuel/ignition table size user defined?

fe3tcourier

Yep, already is, standard is 24 rpm 19 load with 27 being the max rpm and 21 being the max load (with less of the other)

The total size of each table is 1024 bytes including axis and table itself. There are 16 tables split into two sets of 8. 3 ve, 1 lambda, 2 inj adv, 2 ign adv. the two sets of 8 are for FULL tune switching. All boost control, idle control, injector conntrol, ve, adv, lambda, etc, the whole shooting match, switched at once. It would be fairly straight forward to hack it and change it to epic sized tables and less of them with less features etc.

I'm intending to try having no tables at some point. Just arbitrary points in space that you define the location of exactly. This will give a much finer ability to nail down trouble spots without wasting resolution on flat bits adjacent to that. That's a way away at the moment though :-)

Fred.

Tom-Guy

It's also an odd thought, but I can see it working well in the hands of a non-n00b. Some aggressive turbo cams on the Toy 3S cause wierd idle fuckage as idle vacuum (and therefore rpms) drift around.

fe3tcourier

I think the key to making that work (other than the math and stuff on the EMS side) is a really good interface. Imagine a flat map with only four corners defining it. It's idling fine, but as you rev it up you see the AFR go off, so you place a point where you see the change start to pin it still, and then another further up with a higher value. Once you have it roughed out, you can fine tune by centering the points on the exact points they are best suited to being at.

With a conventional table if you need to bunch it up for a problem spot at high load and there is no problem at low load the extra resolution is wasted in the low load region. With this even though it burns more memory for the same number of points, you can make better use of them and get a tighter tune with less points adjusted.

It's still a dream at the moment though, so it doesn't worry much thought really.

Fred.

NIGn0g

Nice work! I'll enjoy reading those sources.

What is the controller you use? Atmel?

I would like to have the time to work on a project like this, but no time left after school, job and life.

Good luck!

fe3tcourier

Thanks :-)

Freescale MC9S12XDP512

That's the thing, since I moved to england I haven't had a life, so I can work on it constantly. When I get back to NZ there will be life again, along with friends and parties and fishing and burnouts and track days and and and and and this will get a lot less of my time, hence rushing to get it up and smoking nicely in the next 6 months or so.

My goal is to rip the MS2 out of my ute when I get home and put this in. If I do that, things that aren't right will annoy me and I'll fix them. If not, who knows what'll happen. I'll never let it go though, HomeMadeEMS for life :-)

Fred.

fe3tcourier

Latest update hot off the press :

New firmware release : 0.0.18 JackTheRipper

The last two releases added real packet based serial communications with extensive error checking and verification. This isn't quite ready for the world as the tuning interface isn't quite finished just yet. It shouldn't be long before we can adjust the parameters the device is using on the fly, and when I say that, I mean almost all of them.

Enhancements over MS due to the serial architecture include, but are not limited to :

• Datalogging at double the speed over the same speed link.
• Reset the device via the tuning app without cycling the key.
• What you send IS what you get (checksummed and verified).
• Random data can not corrupt memory (no DMA setup, all by logic/lookups)
• If it works, it works right, though bad connections will make it slow, but that is FAR better than corrupt maps running your engine!
• Ability to burn small blocks straight to flash without sending the whole page
• Ability to save part of a block from live tunable ram without saving the rest

Additionally, it now builds on windows 2k and XP, thanks to Daniel for his help making that work. Thanks to Sean for his assistance in getting this far, the flash stuff is great. Finally, the mathematics code is much cleaner with no reduction in functionality.

A demonstration of the serial and flash functionality is available in this video :

http://www.youtube.com/watch?v=4MS_zc8sZxM



Version Control by Git

The firmware source code is now publicly hosted on github with the following URL :

http://github.com/fredcooke/freeems-vanilla/tree/master

This is an exciting move for a large number of reasons. Not least of which being the ability to fork the code easily and allow me to keep track of what you are doing with it. In this way if you don't want to discuss what you are doing with me until it is done, you don't have to. Of course, it is better if you say "I'd like to work on XYZ" so I can advise whether that is a good idea, and if so avoid that area myself. It is also possible to just download a tar ball or zip of the current repository version of the code at any time, however I urge you to fork it using github and publish your work for the world to see so we can easily integrate it back in.



Code Statistics by ohloh

With the public source code repository we now have a source of genuine statistics about the code base. These are generated by ohloh.net automatically and available for the world to see. So far the results look good. It will be interesting to see how they change over time. If you are interested, take a look here :

https://www.ohloh.net/p/freeems



Issue tracking with MantisBT

As the system grows and diversifies we will face many challenges. One of these is keeping track of bugs and feature requests from users and testers. In that direction Aaron was kind enough to set up and host an instance of Mantis Bug Tracker. This is available for use right now. Anyone can view it, but you must sign up to create bugs, at the moment an administrator needs to allow a member to create bugs, but we could change that in the future if it is too restrictive. Please use this for anything non-trivial that you notice that needs fixing or that you would like to see. Please us this service if you are planning on reviewing the code and/or testing it out on the bench and/or just want to ask for a feature. Also have a read around the forum and check for existing bugs and requests before creating your own, but don't be shy about it. The URL is here :

http://freeems.aaronb.info/tracker/



User driven documentation on DocuWiki

Aaron has also setup a user documentation system ah la wiki. The wiki is a DocuWiki which is best suited to source code use. To prevent vandalism by those who are less than enthusiastic about this project you need to have a login. If you feel you have something to contribute (So I can keep coding) you can find it here :

http://freeems.aaronb.info/wiki/



Doxygen code documentation

Jared has been generating automatic documentation from the source code with Doxygen for a few releases now. If you want to get a more visual insight into the source code, you can find them at the following location :

http://freeems.sourceforge.net/doxygen/



Release versions of the code

If you are interested in getting the latest official version of the code to tinker with, you can always find them on sourceforge. It is far superior to get the latest development copy from github as above, however the release versions are guaranteed to more or less just work as described. If you are conservative or want something to use on an actual car in future (once it works as a system) then get your copy from here :

https://sourceforge.net/project/show...kage_id=258422



What is planned?

Hopefully in about 48 hours Aaron will get a tar ball copy of the fully reworked Tuner code to me. This, among other things, is supposed to have threading and a working decoder for the packets, awesome!. Who knows what else it may have in it :-)

For the firmware, 0.0.19 is due out in early January with goals including :

• A revised serial specification and implementation
• A fully documented serial interface and data map
• Restructuring and tidying up of the overall code base
• Multiple datalog types including super fast scope and logic analyser functions
• Other documentation like serial implementation, freemind mind map, readme etc etc updated
• Documented hardware setup design

Of course, all of that is subject to change and re-evaluation, but this is the current plan of attack!

Thanks for reading and your interest in this project and indeed the whole movement!

Regards,

Fred.

fe3tcourier

It's time for another update!


New firmware release : 0.0.19 Doxygenated

Three weeks ago I released the 19th version of FreeEMS into the wild with the name Doxygenated. This release contained almost no further functionality but, significantly, is fairly completely documented in the source code and other sections. I hope to grow this documentation and keep it up to date as the code matures and becomes more functional.

You can find the documentation here :

http://freeems.aaronb.info/docs/doxygen-html/

Note the related pages section which contains some good information on a various aspects of the system. Many of these pages are still in draft form, but as mentioned they will grow and mature with time.

Included in the new documentation scheme are online release notes and change logs :

Release Notes

Change Logs

All previous change log and release notes entries are available linked from the same pages :

Previous Change Logs

Which reminds me, the Makefile no longer works on Windows without cygwin (that didn't last long) AND the Makefile now builds multiple output files with a different wheel decoder each. Only two of these do anything at this time, but that number is sure to grow a bunch in the medium term. I find this situation vastly superior to having to configure one from 20 and being able to mess up the selection and configurations surrounding it. Each file is named appropriately such that you can't possibly put the wrong thing on your controller. Less configuration and smaller code size FTW!



Slow pace of development so far in 2009

Since January I've been working on a new project at work. I was keen to make an impression and do an excellent job so I've been putting in a lot of hours on it to make sure it all goes 100% right.

I've managed to get two successful releases out to the client since then and brought the project into line with all of the best practices that I know of. The release before I joined the team was generated by hand using eclipse and no versioning or tags etc. The next one was built by maven two but manually adjusted to use different library jars and a config manually updated. The last one was built by maven two including libararies with only the manual config change. The next one will be 100% automated meaning better repeatability and reliability and exposure of all metrics surrounding the code.

They seem to be liking what I am doing as I'm now in charge of all technical aspects of the system, officially in charge of 3 of the devs and unofficially in charge of another two.

Hopefully the pressure is off a bit now that we have the system more or less under control. The remaining work is BAU stuff like adding features and removing bugs and making it faster and more usable. This means more time working on FreeEMS again.



The FreeEMS development team

I'd like to welcome Philip Johnson to the project. He has already written a basic 36-1 missing tooth decoder and picked up the use of Git to achieve integration of that into the core branch. Some of you may remember Phil as the man that ported the B&G MS2 code from the broken CodeWarrior compiler to GCC forming the basis of what is now MS2Extra. We should all be thankful to Phil for that achievement as everyone knows MS2Extra J&K >>>> MS2 B&G. I'm really looking forward to working with Phil to produce a really good system that gives people no reason to not use it.

The addition of Phil to the team means that we now have :

• 3 Firmware devs
• 3 Tuning app devs
• 8 People with TA card hardware

Plus the large group of interested parties contributing ideas and constructive criticism to the discussions on the DIYEFI.org forums. One further firmware developer is due to start writing Subaru code any day now and with a bit of luck AbeFM will get stuck into some quality PID code and an NB decoder too ;-)

These numbers are about to increase as four days ago the Helsinki University of Technology's Formula SAE team, "Otaniemi Flying Finns", announced that they intend to use FreeEMS to power and control their FSAE car in the 2009 UK competition at the Silverstone race track. I wish them the very best of luck with their racing endeavours and FreeEMS development too.

In other news, the network graph on github is quite interesting at the moment :





Material contributions

As I'm sure you are aware, running a website and buying all sorts of parts and tools for development costs money. Additionally, my time is valuable and I contribute almost all of my free time to making FreeEMS a success. A few people have decided to acknowledge that and donate to the project cause.

One generous individual anonymously donated 500 USD to the FreeEMS project using the pledgie campaign site and for this I am most grateful. This will make getting the bits I need for development a lot easier. Thank you very much! The same person donated a TA card to our tuning author for testing purposes. Again, thanks for that, most useful!

Alan To from http://www.14point7.com donated two JAW wideband kits (1.03 and 1.041) to me for testing purposes. I intend to assemble one of these fairly shortly and install it on the test vehicle before I try to use FreeEMS to run the engine. Again, thank you very much for this, Alan, it is most appreciated.

If you don't have a clue what you are doing when it comes to software or hardware but have some spare cash and want to help the pledgie site is available to assist you doing this :

• My firmware campaign - http://pledgie.org/campaigns/2414
• Aaron's tuner campaign - http://pledgie.org/campaigns/2496
• Sean's firmware campaign - http://pledgie.org/campaigns/2857

I would like to see Jared and Phil have accounts listed there too such that donations can be directed where you feel they should go.

Any funds that I receive will go towards the following things :

• Web site running costs - domain names and hosting etc.
• Electronic supplies - Components, PCBs and sensors etc.
• Providing test rigs to intelligent and interested but poor potential contributors.
• Tools - meters, scopes, logic analysers and soldering equipment etc.
• Fuel and replacement engines (assuming the worst) for testing purposes.

In that order. In the future we could add a bounty system where you request a feature, put a price on it and someone can pick that work up and get paid to do it. The whole community benefits from that sort of interaction so it is a very good thing to do. For now though we need to focus on the basics and getting them 100% right.



Git Pecha Kucha Presentation

I decided to do a presentation on Git to a group of people from the company I work for in London... Well, just my luck, 1/3 of the way through I started getting a cough and could barely breath or speak due to it and trying not to cough loudly. This threw my confidence off and when I left the front I was sweating quite a lot. It was quite hot in there, but not that hot. Fortunately the video looks a LOT better than I felt, so I'm not too embarrassed to post it up. Audience was about 50 developers and business consultants in the financial sector, central London.

The video is available here :

http://www.youtube.com/watch?v=Uu2ySkRP3DA

The slides in M$ PPT format (I had to...) are available from here :

http://downloads.sourceforge.net/fre...ip?use_mirror=

I'll add the OO version when I get a chance.



What is planned?

A lot of the stuff that was planned for 0.0.19 has been pushed forward to 0.0.20 due to time issues. Additionally I intend to have a scheduling implementation completed before 0.0.20 is out. This combined with shared inline function code for the actuation of fuel and ignition channels and a split out timer init function will pave the way for decoder contributions from anyone that wants to step up and help.

0.0.20 will released when it is logical to do so. I expect that there will only be a few more 0.0.X versions released because as soon as an engine runs on FreeEMS a landmark version 0.1.0 will be released. I was originally planning end of February for engine running time, but a few things got in the way so it has been delayed slightly.

The next 6 months should be a VERY exciting time for Free and Open Source Software in the automotive arena as months of hard work start to come to fruition for everyone's benefit :-)

Regards,

Fred.

Oxide_Zer0yome

pretty sick