I finally had a chance to play with Nistune on the dyno. Here are some comments.
- So far the nvram seems to work fine. Didnt notice any real problems but I also need double check the bin file to make sure its still correct. One thing I did notice is that when I make some timing changes under steady state load I get a quick misfire or something. Maybe it's too much for the ecu or its having an issue because its reading the cell at the same time I'm changing it?
- The live TP and RPM values on the fuel/timing maps update to slow. When I'm trying to reach a certain area of the map it's easiest to watch those numbers. They dont seem to update as fast as the values on the gauge display.
- I couldnt figure out the fill function. Is it still working? Am I just stupid? Ctrl-F?
- The trail function doesnt seem to work right. If you go back over a section that has already been marked it seems to erase the mark. I think this may have already been mentioned.
- I think you might already know this but I dont think the cursor follow works. I couldnt figure it out at least.
- Over all feel of using the mouse to select cells could use some improvement. This is hard to explain and maybe the problem is because I'm using a laptop. Basically, when I try to select a group of cells by holding the mouse button and dragging the cursor it often happens that I end up dragging a cell as if to copy it. Also, when trying to select a cell that's already highlighted I think you have to unhighlight it before you can select it again. I also had some instances where I was using -/+ to change values and it looked like changed over so it wanted me to type in an actual number. Again, these could be due to finger flubs on my laptop but maybe you've noticed the same things.
- When I make changes to large sections of the maps it takes a while to make them before I can make more. I realize this is probably an nvram limitation so I'm going to try it with the romulator.
Did some playing on the dyno. Comments on Nistune.
Moderator: Matt
thanks for the feedback
- I'll have to look into the timing changes causing the misfire. Around what RPMs/load was it noticed? It shouldn't be too much for the ecu to handle
- Can look into refreshing the maptracing window at a faster rate than currently performed
- F1 displays the options, Ctrl-F will fill previously selected cells with the current highlighted cell
- I'll try out the cursor follow again
- Laptops are a lot harder to use, especially when you are sitting there in the car in a more difficult environment. I find that keyboard short cuts to replace some funcitonality may help. I'll add improvements based on this thread to my bug list and see what we can do to improve this
- Highlighting a lot of cells and pressing +/- will perform an update for each cell. It is done the same for romulator but that could be quicker somewhat . What may be quicker overall is just uploading the entire map each time, when more than say 10 cells are selected. This will shave a lot of time from the upload process.
- I'll have to look into the timing changes causing the misfire. Around what RPMs/load was it noticed? It shouldn't be too much for the ecu to handle
- Can look into refreshing the maptracing window at a faster rate than currently performed
- F1 displays the options, Ctrl-F will fill previously selected cells with the current highlighted cell
- I'll try out the cursor follow again
- Laptops are a lot harder to use, especially when you are sitting there in the car in a more difficult environment. I find that keyboard short cuts to replace some funcitonality may help. I'll add improvements based on this thread to my bug list and see what we can do to improve this
- Highlighting a lot of cells and pressing +/- will perform an update for each cell. It is done the same for romulator but that could be quicker somewhat . What may be quicker overall is just uploading the entire map each time, when more than say 10 cells are selected. This will shave a lot of time from the upload process.
I tried things with using the romulator instead of the nvram. With the romulator the updates happen much much faster. It also seems that selecting things is a bit easier. Maybe I'm just imagining things. More testing to come.
On a side note, it seems that it's very easy to accidentally load a rom that isnt what's actually on the ecu and therefore start using the wrong base image to make live changes. Do you think it might be a good idea to have a function that compares what's on the nvram/romulator to the currently open bin before live changes are made and then alert the user if there is a difference? I know it seems like holding people's hands too much but I think it would save me and others from making stupid mistakes.
On a side note, it seems that it's very easy to accidentally load a rom that isnt what's actually on the ecu and therefore start using the wrong base image to make live changes. Do you think it might be a good idea to have a function that compares what's on the nvram/romulator to the currently open bin before live changes are made and then alert the user if there is a difference? I know it seems like holding people's hands too much but I think it would save me and others from making stupid mistakes.
i think i might have to do that.... was something i had thought about a while ago but forgot to do
because as you mention it is possible to have a mismatch between image in the NVRAM/romulator and the currently selected image in nistune (remembering there are 5 images possible to be loaded)
what can change for USBconsult/eXtended consult is that after connection, reconcile the maps/tables/constants to a temporary area and compare against the current image in nistune and inform of a mismatch
prevent chagnes to the live image until a reconcile to the ECU is performed, or a reconcile to the PC is performed.
if the currently selected image is changed to another one, then if changes are attempted, then the user will be informed that the current image does not match the live image
i need to also made reconcile accessible for the romulator but new boards will not be supporting romulator any more - only NVRAM (thats okay i have 8 boards here still to be sold that still do, and can make more using the latest PCB changes if there is demand)
because as you mention it is possible to have a mismatch between image in the NVRAM/romulator and the currently selected image in nistune (remembering there are 5 images possible to be loaded)
what can change for USBconsult/eXtended consult is that after connection, reconcile the maps/tables/constants to a temporary area and compare against the current image in nistune and inform of a mismatch
prevent chagnes to the live image until a reconcile to the ECU is performed, or a reconcile to the PC is performed.
if the currently selected image is changed to another one, then if changes are attempted, then the user will be informed that the current image does not match the live image
i need to also made reconcile accessible for the romulator but new boards will not be supporting romulator any more - only NVRAM (thats okay i have 8 boards here still to be sold that still do, and can make more using the latest PCB changes if there is demand)
the other thing is that NVRAM can be sped up with map based updates to hopefully get close to the romulator speed. i've got it on my list as an optimisation once i've finished getting the latest hardware working (currently testing out CA18 and S14 SR20 ecus with our new board)
single byte updates at 115200 bytes are quicker than USB1 packets being fed to a 4Mhz ECU containing single byte changes which is why the romulator is quicker
single byte updates at 115200 bytes are quicker than USB1 packets being fed to a 4Mhz ECU containing single byte changes which is why the romulator is quicker