hello all,
Firmware releases seem to be getting faster, but how do we find out what has been changed/updated....is anyone keeping track offically of what is happening with firmware.
Would be nice to have a changelog with firmware maybe..
It looks like we have to wait till someone finds out, then there's a new release...
Anything to make life easier...must be good.
cheers
scott
There is actually a change log on the wiki
http://www.vems.hu/wiki/index.php?page=GenBoard%2FUnderDevelopment%2FFirmwareChanges
All the recent firmwares require VemsTune and they are downloadable using the integrated firmware web tool.
Do note that the bleeding edge is for testing, and may or may not be downloadable within VemsTune before it's deemed ready for testing by a larger crowd.
I find that webpage is not updated very quickly and does not have good details of the firmware releases. Check the changelog, no details in there for instance since version 1.1.62 for all release above this in the text file of firmware zip.
1.1.66 is out on the web firmware tool but only mention of it is on a page refering to the new 6 speed gear boost DC
Once the documentation is sorted out I think VEMS would hit a greater audience
I repeat what jrussel said in another thread .
Wait for a month or two for the official release. The current (1.1.6x) releases are for development and testing, not meant for widespread use.
There is no stable firmware until a lot of things have been tested. A lot of things are happning right now and are not fully tested. Do NOT assume anything.
is this 1-2 months certain though? because tuners have been sending out VEMS ECUs with these developmental firmwares as 'new stable releases' and very few mention that they are not actually official.
Im still on 1.1.27beta6 for that reason only, because the developers say these are NOT official.
hopefully the official version will be as stable as the 1.1.27 is
1.1.62 is supposed to be the official release according to Marcell.
Anything after that I´d just wait, it´s not like people haven´t driven for years on older stuff without problems.
excactly but i would presume that if there is a definite 1.1.6x official release, there wouldnt be releases after that coming out immediatelly. That really means that even 1.1.62 is not working adequatelly.
While on the other hand 1.1.27 does not have many features on one hand, but it does work perfectly on many different cars.Thats what i call official. Introducing new features is one thing, while making one release working without bugs is more important.
1.1.27 is bug free and works absolutely fine for me.I will only change when the 1.1.6x is official.
But have you tried a 1.1.6x release though?
I was running 1.1.27 for tuning and the car runs better on 1.1.63 and now 1.1.65 than it did on 1.1.27 with the extra compensation routines built in
no i havent, and reason is that i have absolutely no problems with 1.1.27. I dont like to 'try' 1.1.6x versions esp. when i read about bugs and glitches on the forum about the versions and esp. when every 20 days or so there is a new vemstune version trial coming out. that tells me that there are areas on the firmware still not working right hence can be disastrous.
You probably didnt use 1.1.27 enough to appreciate it.I see that the new versions have lots of new features, but the car can be tuned and run properly and safely even without them. Once VEMS comes with an official new one, ill change it
1.1.6x is better than anything we had, but because the development cycle is faster than ever before it's very difficult to support users that want to try these firmwares. If you don't understand what I'm saying then I give up trying..
We are adding features, simplifying existing ones and testing them all. There will be a more stable baseline soon, but can't say when.
when that more stable version is ready, then i will try it.
You see, you as developers are doing many fast steps as you say, but VEMS users are not always spending their time in the car testing the new features. Most of them just want a properly running, safe tune for their engine. Tuners who will use VEMS will use a firmware that they are happy with and leave it as that.You think the customer will be aware or know if you have released 50 new firmwares from when their car was tuned? No one will bother, unless the version of their tune has bugs that can cause problems with running.
So all im saying, is once you have a stable 1.1.6x version, as stable as the 1.1.27 was where VEMS.hu was sending the ECUs out with, then it will be better.
What firmware is VEMS shop sending the ECU out with at this point?
Ah but what your talking about is not firmware stability but vemstune stability.
Had no problems with the firmware what so ever, only the early versions of vemstune the 8th Jan release has been solid and given no problems what so ever in connection or crashing.
well im talking about both.
can you use 1.1.6x on megatune? No. so everything is involved.
I have heard that boost control is not accurate still on the latest 1.1.6x versions. I dont fancy using manual or external boost controllers for that, and currently i have that nicely controlled on the 1.1.27.
I'll just wait a while.. no harm done. Besides, since development is that fast, once im happy with all the latest innovations from the latest versions, i may not even be interested for anything new for a long time.
By the way, latest vemstune i have downloaded only gives 1.1.63 versions to try out. How can i take advantage of 1.1.66 versions that are out? there is no base map included.I have a setup already to try on vemstune but it is on 1.1.61 version.I have downloaded firmwares all the way to 1.1.67. How can i change to the latest one, and play around with the settings there?
You can already download, upgrade, play around with and test 1.1.67 with VemsTune.
If you just want to play with it on the desktop you require a vemscfg or vemslog.
A default firmware config will not be always be available.
where can i get a vemscfg for the 1.1.67 then? as a base tune?
you can make one,
create a new project with the firmware you want to use, then save and load it, then you are free to change it and save as a new cfg file.
i dont see the option of 'create new file' in the options.
if i open vemstune, then with the latest firmware uploaded, how do i start a new cfg from scratch?
Have you created a project?
And loaded the project?
when you have that done you can save a config file.
ooook gotcha! going to play around a bit now then...
Is there a place in this forum or the VEMS wiki, where developers or other VEMS tuners can explain the differences of the new implemented features in various areas?
For example, on the megatune era, there were large documents where someone would be able to go and read, and get an idea what feature is doing what. Now with vemstune it seems that we are jumping into settings that are not explained anywhere and some need to be just tested with trial and error to see what the correct values are.
It would be interesting to have someone present a document comparing the old official version that VEMS was sold with (1.1.27) to the new versions and just add some explanations to the new features, same as it is in the VEMS wiki as the main start page of vems installation.
The list im finding so far goes like:
1) soft ignition cut
2) Partial fuelcut mode
3) accel.enrichment fadeout factor
4) accel. enrichment ign.retard at accel=reqfuel
5) fuel film
6) IAC PWM frequency
7) IAC PWM duty cycle allowed min/max
8) IAC close delay
9) refpos for mat slope (IAC)
more things may come up from other users, but a list of all these different features will help us understand how to manipulate them
thanks
also another thing that i havent clearly figured out.
I create a new project on version 1.1.67, drag and drop the settings from my 1.1.61 setup, then go to save my new config as 1.1.67 and when i reopen the new saved config, it is back to 1.1.61.
how can i save a config after having created a new project?
if i open the config first, at 1.1.61, and then load the project on 1.1.67, what i get is: firmware: 1.1.61 and project config:1.1.67.
BUT this cannot be saved as 1.1.67 config thereafter!
Quote from: AVP on February 09, 2010, 02:01:31 PM
also another thing that i havent clearly figured out.
I create a new project on version 1.1.67, drag and drop the settings from my 1.1.61 setup, then go to save my new config as 1.1.67 and when i reopen the new saved config, it is back to 1.1.61.
how can i save a config after having created a new project?
if i open the config first, at 1.1.61, and then load the project on 1.1.67, what i get is: firmware: 1.1.61 and project config:1.1.67.
BUT this cannot be saved as 1.1.67 config thereafter!
Try to edit by hand the config file header
AVP: I'm not sure what you're trying to do.
Here is my advice, don't use the project majiggytyhingy.
Just save the config (1.1.61) before you upgrade.
After upgrade open config, choose upload and go through all the complaints that the compatibility checker spits out.
Done.
im trying to setup a config with the 1.167 firmware.
but i have a previous config with the 1.1.61 firmware. So im trying to upgrade it to the new firmaware and play around with the new settings.
once i have the 1.1.67 project loaded, with my settings from 1.1.61, it doesnt seem to be able to be saved as an 1.1.67 config though.
here is an idea..
how about a 6 or 9 bin table only dedicated for idle manipulation, so that the basic tables of VE/lamda/spark can get rid of those bins and so have a larger area to play with?
just a thought...
How do you manage and detect the transition between idle and running?
i imagined it as a magnifying glass being placed on the initial bins on the VE/lamda/spark tables. So that if you have say a 6 bin table and you have bins of 500-800-1200rpm and kpa: 40-55, you can then start the VE above those values and perhaps vemstune can use that. In that case you end up with a few extra bins to use which may be usefull on lamda and spark tables which are now much smaller on vemstune.
Sorry, I can't follow. For what reason? Is there some succesive examples around? What is disadvantages of current strategy?
Gints
idle would be triggered by TPS below a surten point.
Common for many ecu´s to have separate idle maps. Especially with high cam engines or similar, I know mattias is very interested in
getting a idle specific table.
Gints,
how many of your bins on lamda control will you have to use in order to have a nice and stable idle that works 99% of the time and is not relying on ignition timing only?
Lamda as a table is so small that gives you less opportunity to fine tune something that most tuners have for granted.Thats why i suggested something like that.
on earlier versions where tables were 14x16 there was no problem since you have the flexibility to use many different bins from such a big table.But now, if half your lamda table is given to control idle, how will you have enough bins for cruising and <100kpa fine tuning?
On the other hand, in spark table you end up using at least 4-6 lines dealing with kpa values that are making that table even less accurate.I know vems is interpolating, but depending on cams and setup as gunnar says you may require as many bins as possible to make use of them.
Since ideal 'stock' like idle is possible with VEMS and we have the developers reading, i thought that a suggestion like that may make things more accurate.
a large lambda table is definitely not needed.
as you only use so many values, from 1.05 down to maybe 0.8 or so and usually in 0.5 steps, so total 6 steps.
0.8 , 0.85 , 0.9 , 0.95 , 1.0 , 1.05
And alot of the rpm´s and kpa values will use the same lambda values, so this means a 14x16 lambda table would absolutely not be needed.
I do think a 2d lambda table might be a good idea. As some engines just cant run right at idle advance when not idling , i.e very slow driving in traffic or other similar situation where non idle advance is actually needed.
Autronic uses small idle ignition timing table when TPS is about 2% or less.
Table could be small 4x4 - or just simply 4 settings.
For example, I would run 25 deg at 750 rpm, and 12 deg at 900 rpm, then 6 deg at 1000 to keep idle from racing higher.
yes i agree. Larger lamda is not needed, but for me i need 4 to 6 bins to control idle adequatelly with IAC and ignition timing,and that makes my lamda table even smaller.
Even if i dont use the lamda table at all for values higher than 100kpa since im only using the VE table there, it still is not big enough to accomodate a setting for economy driving. Im not sure about other makes, but audis seem to be able to drive nicely even on 1 lamda on up to 130kpa and 3000rpm,so i would like to take advantage of using that if i can!!
Anyway I do not understand fully.
Do you want to control idle with mixture: lower than target, then richening?
Regarding this sometimes i have sloppy lambda table : 1.05@ 1300rpm, 0.9@700Rpm and idle target somewhere in the middle.
Another point: IMO it is not possible to not use lambda table. Value from lambda is always included in fuel calculation. Border value if operation point is outside table.
Idle mixture stability from my point of view is more dependent from injector settings (delay and voltage correction).
I see the problem in ignition: idle advance coming from main table. Due to this main table is strongly deformed from desired. I think here is the way to improve economy. Sometimes most effective cruising advance is over 40deg. And it is too close to idle. Especially on high displacement engines mounted in small cars...
I suggest use just one idle advance point (not table) separated from main table, additional with current ign based idle ctrl method. And for improved driveability advance from idle to main table and back should go smoothly. Not with jump.
Gints
on the contrary i say that lamda/spark should have a small 4x4 or 6x6 dedicated table for idle. Lamda is important as well as spark, but since IAC comes into play, all those vary, as well as VE. But VE already has a large table (16x14) so there is room to be used there. The other tables that are smaller, are leaving only 1 or 2 bins for idle use only.
When i say idle i was thinking like : 800-1000-1100rpm
then: spark for that
then:lamda for those values.
on 1.1.27 i currently have 6 lower left bins on the VE/spark/lamda tables dedicated for idle control
Does VEMS spark based idle control is not enough?
NOPE!
if vems spark idle was enough, they wouldnt have gone through the bother in fitting IAC settings.
When i use only spark idle, i have idle at 1100rpm, and if i use 10deg of advance to lower it, i get 600C of EGT. Now that is something i dont like.If i use 15deg of advance,then i get sligtly lower EGTs but idle speed goes even higher.
spark idle is rock solid, i do admit,but if you are looking for ideal, then IAC has to work as well and since these guys are going through the trouble of changing everything, this might help in that department as well.
spark based idle is the easy way out of configuring it in my opinion, but even in megatune it says that it is important to use an IAC valve.
From my point of view IAC control with valve works quite OK (even with "soft" pseudo PWM if set properly), if we talking about speed-density. with additional help with advance I have many street and everyday cars tuned. Yes idle is not so perfect as nowadays cars. But in 90s OE idling was near same as VEMS.
Other thing is Alpha-N with IAC valve. Current slope alike strategy isn't sufficient. Here some small "alpha-N" table just for IAC valve could be helpful. 3x3. Test car here should be some BMW - M-engine.
I think fine lambda or VE table separated for idle will not solve some important problem: injector characteristics. Often we use bigger injectors than OE. And it works much closer to non-linear area, or on it. If something changes (winter/summer, cold/hot engine) we migrate through this non-linear area and steady VE table - no matter what resolution - not help. Current fuel calculations assume linear charasteristics of injectors.
So some 3D table for injector describing necessary. But 99% of users will not be able to fill such table with well-grounded values. May be some simplifying could help. E.g. autronic describes injectors with some cryptic values.
Gints
yes true, a 3d map would be better. Trial and error once again on this area i suppose
Andrey has code written for MT 1.1.5x firmware with simple Injector Dead Time vs Battery Voltage from 7v up to 15v.
With the newest ultra-high quality injectors available from Injector Dynamics, which are flow matched based on dynamically testing and dead time, out hobby cars should start driving as close to OEM quality as possible.
I would suggest that Andrey's dead time code be implemented ASAP into 1.1.6x and if possibly a seeting for 16v would also be added.
Here is some reading about the newest technology aftermarket injectors:
http://www.injectordynamics.com/
Quote from: lugnuts on February 17, 2010, 05:51:34 AM
Andrey has code written for MT 1.1.5x firmware with simple Injector Dead Time vs Battery Voltage from 7v up to 15v.
With the newest ultra-high quality injectors available from Injector Dynamics, which are flow matched based on dynamically testing and dead time, out hobby cars should start driving as close to OEM quality as possible.
I would suggest that Andrey's dead time code be implemented ASAP into 1.1.6x and if possibly a seeting for 16v would also be added.
Here is some reading about the newest technology aftermarket injectors:
http://www.injectordynamics.com/
This should be a high priority, the current injector settings are confusing to me, why have an option for open time if the f1 help says set it to 0, what's it's use?
Voltage and dead time correction is not what I wrote about. These can be achieved with current code if voltage is close to nominal. (not 10V or 16V). 10V and 16V problem can be solved with Andreys code. But anyway most of users will use just approximate graphs...
At small opening times injector characteristic becomes nonlinear. You can see it in graphs in injectordynamics page. On older injectors disturbed area are wider. And this leads to idling issues...
We have no way to describe this area. And this area problem can't be solved just with VE table because same point in VE table not means same injector pulse length every time.
The solution here can be to use new generation injectors (same webpage). E.g. I have case where 2400cc Siemens injectors gives good (for this size) lambda 1.0 idling. True - the only way to achieve operation of these injectors was additional peak-hold board. E85.
I suppose idling related code in OE units has large size.
I get what you are saying now.
I don't have experience tuning OEM ecu's, so I don't know about their settings.
But I would imagine that OEM get good quality, tightly batched linear injectors from their suppliers.
Anytime I put an ECU on an engine with OEM injectors, the car runs perfect. Probably 90% of the older aftermarket injectors will behave worse than oem everytime. I demo my PnP ecu on a stock car and people can't even tell that it is not a stock ECU.
Do you have any examples of OEM ecu settings for non-linear injectors?
Lugnuts, no. I do not saw any 3D injector map. IIRC Motec have something like that. But OE... It is rare to see OE with bigger than 550cc.
Now i catch why often OE idle comes low only when speed drops to zero - this could be the point where ignition map for driving is switched to idle advance. Wht you think?
I thought that OEM idle control was replicated in VEMS with ignition control and IAC ???
Forgive me if I am being blunt, but what else do you need? the IAC valve should be set such that, at idle, air can still be removed (roughly 40 steps if its a stepper). Throttle stop should be adjusted to give you your desired idle with the desired idle advance. Idle ignition thresholds set to +-5. I have never had a problem. idle PID set up however, is a tuners nightmare, as there is little explanation of what P is which means you are changing numbers to get the results, without really knowing whats going on.
I can get my engine to start and idle at 1250rpm when cold, ramping down to 850rpm when warm and controls well at 850rpm once I have tuned PID. Afterstart I see another 200rpm ramp down over 3 seconds, Turn on all the lights, wipers and rear screen heater, and the idle control sees the change in engine load and brings the rpm back up again. It replicates that which was the OEM ECU.
Now if this is not enough what else is there? Perhaps modern (read that as within the last 10 years) OEM systems work some other magic, but what you have to really consider is that you will never ever be able to control an engine anywhere near as well as ANY OEM ECU unless you buy a high end Motec or similar, even then im not sure it would be as good.
A cold start ignition map would be more important, and in recent firmwares there has been an effort to get something like.
I have had experience of Emerald, Motec and Specialist Components ECUs and im not sure i have seen an 'idle advance' map, they do have simple cold start advance maps.
I am pretty satisfied with current idle strategy. I just try to describe what most probably cause idling problems.
I suggest separate idle advance from main map. One value! Triggered by speed and TPS. With some advance changing rate limitation. And not because of idle:
Best idle quality usually is 5...15deg. But cruising area in map is very close on some engines and it often requires more than 30deg. So this is conflict. It hurts driveability a lot when advance jumps. My spark tables sacrifices one of both. Or are compromise between both.
sprocket----> did i understand correctly? you have an idle of 850rpm and once you turn on all electrics and hence get a voltage drop, the idle goes up????? how do you do that? Usually on voltage drops or when the AC kicks in the idle speed drops! it doesnt go up! the PID configuration may keep it in place to a large extent so as it doesnt stall, but i have never heard that with all electrics on the idle goes to higher level...
can you share any info on this and on which firmware you have this setup?
when the engine load increases with all the auxilary equipment turned on, the rpm will drop, obviously. As the idle ignition control adds 5 degrees in an effort to raise the engine speed, this reaches the threshold for activating IAC. the IAC adds a little more air, the engine speed rises, and ignition advance drops back within the threshold and remains there until engine load is removed. The opposite then occurs.
I set the max advance and max retard to 6 degrees and then threshold for activating IAC to 5 degrees.
works the exact same as my OEM ECU :)
Quote from: GintsK on February 18, 2010, 03:27:55 AM
I am pretty satisfied with current idle strategy. I just try to describe what most probably cause idling problems.
I suggest separate idle advance from main map. One value! Triggered by speed and TPS. With some advance changing rate limitation. And not because of idle:
Best idle quality usually is 5...15deg. But cruising area in map is very close on some engines and it often requires more than 30deg. So this is conflict. It hurts driveability a lot when advance jumps. My spark tables sacrifices one of both. Or are compromise between both.
I think you just wrote exactly what I'm thinking. It's one of the things I wish to be implemented, we have a back-log of more important issues to deal with first but I do think this will be added sooner or later.
I've seen this problem clearly when cruising around with large displacement engines and manual gearbox, BMW 3.5 litre and any larger V8 engine will have this problem. If you have a bit more radical cam profile it will definately be a problem too because you idle at a much higher rpm to keep the engine smooth and oil film intact on critical valve train components.
well at least its a thought of implementation so that is good!