This I can not understand: Where I can set MAP target value???????
2012-01-30
Boost Control -> Boost vs RPM Curve.
The only difference between the Boost-target and MAP-target setting is to use the internal MAP-Sensor or use a external sensor connected to a 0-5v analog input. This is just badly written in Vemstune //Erikk.
Just to simple clarify: I have a control loop for regulating pressure with PID calculation.I have only boost refDC table(f)RPM. WHERE IS THE SETPOINT =TARGET VALUE?????? I have only %of duty cycle witch is "modified by Input pressure after PID calculation. Where I put value of target ????? (as far as I know PID is used just to achieve better the target without over/under shots) I can not see any target in any table.The boost target map is not used at all.I'm with presure sensor /vems/signal generator/osciloscope/valve compressed air /on table and I can not understand--NO ANY CHANGE ON DC For variation of Boost target values(in MAP target mode)
CLEAR that (Use MAP-target, not boost target) 10x
- On MAP target mode "boost target" table is disable(no any change added to control loop) and I have only "Boost refDC" table witch is 0-100DC.
- In Boost target mode I have not tested yet so I just suppose is boost target table with refDC table correction(or refDC table is disable??;
- if so,everything for MAP target mode is just a scaling trick
- NO. MAP-target means that in the controller, "error" term is calculated from MAP - targetvalue
- DCref=target boost P/maximum boost P*100 ?
- no. ref-DC is a "reference" hint PWM ("DC") value to start from (unless error is 0, the P, I and D terms will let the actual PWM output higher or lower)
- I'm right?
- NO.
- hints:
- read some texts about PID controller
- The controller can be used in many ways (it was used for steer-by-wire in 2661 km / 1 liter gasoline car, reactor-temperature control in producer gas powerplant, and of course boostcontrol with bottom-chamber, top-chamber, or both chambers controlled, etc...). It's easy to set up "in reverse", which won't work. Also, there are 2 boost controllers (that can be used simultaneously), a traditional PID-type boostcontrol, and a table-based "alternate-boostcontrol" (some prefer one, others like the other, but either can be set up, or even one for the bottom chamber, the other for the top chamber).
- publish your config, and the sensor+solenoid setup (including the actually used inputs and outputs), otherwise it's impossible for others to get an overview (=essential for help!) what is messed up in your setup
I use MAP sensor connected after turbo -before throttle
- that is impossible: MAP sensor (MAP=manifold absolute pressure) is by definition, after the throttle.
- one might have a pressure sensor (which then, should NOT be called "MAP" sensor because it does not measure manifold pressure) connected to the MAP signal.
- that's an unusual setup (but it can work), one should know what he's doing (and why). One needs to explain clearly when asking for help.
- I do not want to change hardware input for target boost use.At moment I want to use VEMS only to control gear boost on a Nissan with NistuneECU.
- in any case, if MAP input is used, then MAP-target must be used (even if not using a MAP sensor, but a pre-throttle boost-pressure sensor). Make sure MAP is calibrated (eg. ~101 kPa when engine off, and reading will hardly ever go below 100 kPa), target 240 kPa means 1.4 bar boost.
Use MAP-target, not boost target.
- select "MAP-target": it was always there, the first option, and actually the default (almost always this is the preferred selection). MAP signal is on atmega ADC5 (but calibrated with multiplier and offset). ADC 0-4 or 6-7 can NOT be selected, only ADC5 (which is MAP)
- of course, for 1.4 bar boost, your MAP-target will be 240 kPa
- if you need external signal, select "boost-target" and use one mcp3208 (0-7) input.
- if you like MAP, do NOT select "boost-target", but select MAP-target instead (see above)
I have v3.3 new board (serialNr=XXX) with some problems:
Stuck in bootloader.
(no communication with MegaTune and no LCD characters, just 2 lines of squares).
In BrayTerm i have <0> and the board don't respond to any command.
- Common mistake is forgetting to capitalize Man, wrong com serial port selected or some other program open that is using that serial port (MegaTune, AVR studio4 etc.)
After that i try to update the firmware .i update with psituner and afterthat with perl (perl bin/prog.pl vems.hex :COMn Etwf) 3 diferent files of vems.hex and NOTHING. WHat is my Problem Now? The boot need to be updated?(it is posible to lose some information when i connect and disconnect rapidly the board Please help
- I am definatly lower on the I.Q. rating than most people here and I have had my share of problems that I cant figure out so in my experience, if you give a very detailed list of the steps you are taking, ie.
- opened terminal program, set baud rate to 9600
- typed Man
- typed Manmcbffmcb, changed to 19200baud etc etc
- also, if you havent found it yet, see [this page] for help with uploading firware. I am not computer smart and I easily figured it out with the help of that page.
- I update 1.0.18 firmware and nothing ;the board respond only in boot mode
- you might need to edit the .bat file and remove the "t" option (from Etw or Et) if already (stuck) in bootloader (an earlier unsuccessful upgrade attempt?)
- I recommend complete package with more recent firmware, see bat files for megaloader syntax, you need to remove "t" from the syntax, as you already have it in bootloader in advance. http://media.vems.se/code/VemsMT1.0.36.zip for example
After i upload 1.0.36 file vems.hex with perl command(perl bin/prog.pl vems.hex w) in command window i have:
total serious errors during write: 0
VERIFYING...
error at page 0
255,128,0,0
137,239,205,79error at page256
0,0,0,128
0.63.52.141verified<0 101632>
total serious errors at verify: 2
FAILURE we say E
- What is the length of the vems.hex file? Isn't it empty or something because of some unzip or filesystem-permissions error ?
- Maybe you can open in wordpad or other text editor and copypaste the first line to here ?
I edit the .bat file (that becomes: )
- Copypaste the effective line from the .bat here - the command and arguments actually used, wether perl prog.pl or megaloader
Problem at verifying :
Verify flash
Error at page: 0
Error at page: 0
too many errors, bailig out
- NOW it is possible that my atmega128 be burned?
- not likely (read below), unless you tried to apply something directly to the AVR like the standard ALS switch
- but if burnt, programming via ISP is not sure to help (and involves more risk than via bootloader)
- maybe prog.pl or required "serialport.pm" API is broken ? (unlikely, it should give different error message)
- is it possible that bootloader is trashed ? (this can be fixed with 5-wire ISP from parallel port)
- yes, this is theoretically possible. While the commands we (prog.pl and megaloader) use have strong checksum, the old atmel-bootloader compatible commands are still supported and those allow trashing the flash (possibly a page in the bootloader area) with very bad luck (still unlikely, but...).
'''A: I think its more reasonable that you have a bad serialport/cable, USB adapter? //Emil Larsson
Read all document befor you tke a conclusion; i write the flash with rs232;in terminal the board respond to any command but ONLY IN BOOT MODE (and in boot mode i can enter only by loopback the board serial plug)
A bad serial adapter/cable (or broken ground in the cable) often seem to work for a few characters, but than fails in the middle of a bigger block.
Enter BOOT mode in 19200,8n1 and get answer for the following commands (all verified OK):
- S => AVREFI1
- p => S
- v => 20
- V => 20
- Than you are very likely to be able to reflash.
- i can reflash but on verifying i get error.
- Try a separate verify operation, just make sure the firmware (vems.hex or whatever you named it) is the same when you verify (that you uploaded). Verify is similar as writing, but without "w" in the command-argument
- if you tried prog.pl, try megaloader (or try prog.pl if you tried megaloader; you can even upload with one and verify with the other)
- I'm thinking of a way to read/verify your bootloader and get verbose results.
- avrdude (or uisp is another program for this) and a simple (solder in 10 minutes, or less if starting from an old PC RS232 header to connector grey flat-cable) 5-wire ISP cable is just the only simple solution I can think of at the moment. See MembersPage/MattiasSandgren/NickesBMW/AvrBootCode
What i did:
I change the pins of isp proggrammer(i use stk 200 programmer with 74ls244)
- and it works but the signature of chip is FFFFFF and in avrdude i use -F.
- why do you think it works ? If the signature is FFFFFF, that shows it does NOT work. Maybe commands from PC => AVR work, but readback from AVR => PC does not. The -F command is very dangerous if it reads FFFFFF as signature. I think it's ment to use for a new but similar device, eg. programming atmega88 flash into atmega168 (differs in flash size) would work, despite the different signature
I read the boot, reprogram the boot with avrdude and the same problem.
After that i write the flash (what exactly?) and on verify i have some erors. I tried after with avr isp , ponyprog and, errors on writing.
- After all i did a stupid thing, i set all fuses and lock bits in ponyprog. I think now is necesary to buy another atmega128
- after all? What exactly was done before you changed the fuses ?
- is it possible now to write the signature and the fuse and lock bits?
- There is a way for parallel programming that requires connection to appr 12 pins, not 5. We haven't tried it on atmega128 soldered into v3.x
- not sure what settings you wrote. Maybe the atmega128 now runs with internal RC oscillator at 1MHz ? If the bootloader code is in, communicating in 1200 baud instead of 19200 might work. But it's still hard to upload a modified "firmware" that resets the fuses (and the flash. only possible via full erase) .
Or the chip was dameged on first try.
- atmega128-16ai is not too expexsive, appr 9 euro.
- but swapping it is not fun
I change the atmega128 and now is ok.The chip was dameged on first try .(swaping is fun :))) )