8InchesFlacid wrote:Well, really what would be nice is a large paintbrush for the maps - to turn every value within a square of YxZ up/down by the same value or percent, etc. It would make it so much easier to do those or rows or whatever, instead of banging shift-up/up/shift-up/right/shift-up/down/shift-up/right/shift-up...etc etc. But, it's a bit far off....
Sounds to me like you are using MT, download and have a play with MTX, then post a hows MS2 support progress coming along dave question somewhere appropriate MT is teh suck for table adjustment of bulk areas, MTX is nice
But MT can do it. You can select a region on the map and enter a single value or add or multiply. The only thing is that you have to click BETWEEN the cells to select a region. If you try by clicking ON a cell, it won't work. You also have to have 2.25p1 or later for it to work.
For datalogging time sensitive ADC stuff like shock pot that a certain individual I know swears must be monitored obscenely often, we could increase the effective rate of logging of those variables by storing 8 samples between log outputs or something similar. and transferring them all at once.
Agreed. There's no reason not to do this in general, buffer what you can, till just writing it gets to be too much. Either that or just store the peak values.
I didnt see this in here. although im sure i missed it.. What size maps are you thinking? im hopeing somthing larger then 16x16
USB support native. forget serial most computers these days dont even have a serial port any more
Firewire would be neat and diffrent but im thinking it has a cost drawback
Please use a decent connecotor to the harness, the computer cable connector used on a megasquirt was never intended to be in a car. I suggest a military spec Amphenol or Bendix atleast as an option
maybe my controbution could be to build nice cases and connector sets becouse im sure not a coder.
Serial etc : http://www.diyefi.org/forum/viewtopic.php?f=9&t=5
Serial should remain an option for those with no cash (me at the moment! lol), however serial sucks and uart > usb will be the preferred method. Please discuss it there.
I just had a good idea about syncing with a missing tooth wheel. Inspired by Matt Cramers wise words on another board. He pointed out that when you have the VR wiring backwards that you end up with 2 1.5 long gaps instead of 1 2 long gap. This could be recognised by the firmware and specifically indicated as "reversed VR wiring". The thread he posted in was about the MTX tooth logger display which I had not played with before.
Arbitrary points in space :-) I'm not the brains behind that idea though, so I can't tell you much about it. The guy(s) that are are very busy with his new girl and job and in south america with a new girl :-) Hence they haven't posted yet, but I've been discussing it a bit via email with them.
It *may* be too computationally expensive to do though, and it definitely requires a new tuning tool, of some major adaptation of existing ones. For starters at least we will use std tables, but that may not stay in the long medium term depending on how we weigh up the advantages and disadvantages of the options.
I'm posting this here on behalf of a BMW guy (obviously), who emailed me some suggestions, such that my answers can benefit everyone.
> here a a few thinks i think that should be added to the list if not there already
> minimum 20x20 fuel and spark table, 25x25 would be better to give the FI guys more resolution.
I'm not certain as to why you think you need this. Certainly the tables will be on the large side, specifically, as large as we can fit in memory without negatively impacting other aspects of the firmware. My engine was pushing 17psi, and on 12x12 I tuned it to a flat AFR throughout all conditions (on the rich side, but flat none the less) inside one hour. The engine spins to 7500rpm, and I didn't even make use of the movable bins intelligently at all. Movable bins mean much less need for such large tables. OEMs throw large tables at it to minimise setup time and use a flat bin spacing and keep a VERY tight control over emissions at all times. With more time to tune and play and typically less strict emissions requirements, using smaller tables with movable bins is more than adequate for most engines provided there are a reasonable number of bins. IF we end up using tables at all, I expect that as a minimum we will use 16x16 as a size. If AT ALL possible we will try to NOT use tables and instead model the engines curves more closely with arbitrary points in space. Basically, if you fail to get a good tune with 12x12 and movable bins and an excellent tune with 16x16 and movable bins then either your tuning skills are inadequate or your engine is particularly extreme (30psi+ with wild cams and large rpm range).
> hardware selection of high or low impedance injectors
Currently this is intended o be handled by Jean's P&H boards outside the EMS with no significant affect on code or internal hardware.
> COP
That is one of the points of the project, to do COP AND be able to control all of those accessories.
> load dependent VANOS controller for BMW's
That is an accessory function that will wait until all more generic to all engine type features are built and working. Alternatively a keen BMW dev could produce such a thing earlier.
> what is the plan for air measurement? MAP, MAF/HFM? combo of?
MAP for now, no idea what HFM is, MAF and TPS and various blends are in the master plan.
> o2? wide band? narrow band?
Wide band behaviour should/will be supported, at first simply for logging, later with AFR adjustment in real time (but probably not stored, IE, no self tune in the firmware, that belongs in the PC connected to it IMO)
I plan to explicitly exclude narrow band, as it is pretty much totally useless. Others can write code to support it if they choose to, but I won't be spending any time on something that is fundamentally useless from a performance point of view.
MT is teh suck for table adjustment of bulk areas, MTX is nice
