Merry Christmas! Moates 2.0 hardware maptracing is now supported! Only 8 bit ECUs tested so far (HCR32, VLT and CA18)
Cells show up as a pink cursor and can be overlayed with consult maptrace
You need to upgrade your firmware to 20.6 prior to using this
Since I had the maptrace now running I made some fixes to the VQ map for CA18 tracing (see below)
Other vehicles such as VLT seem to have the hardware trace the same as the consult software trace, so I now know for sure the trace is valid. Also I checked the log playback and that looked valid for files with offsets...
One thing to note... log playback immediately after recording is noted as broken. To do a playback, after record, open the file using 'browse'. The reason is that if consult/wideband are connected then log player has to disconnect these interfaces whilst also attempting to open a file. Gets a bit confused and when they disconnect, they clear all the registers. I'm still trying to think of the best way to fix that
NIStune 0.920 version available
Moderator: Matt
NIStune 0.920 version available
- Attachments
-
- moates_hw_maptrace.JPG
- CA18 trace
- (231.54 KiB) Downloaded 2406 times
Just a matter of buying one, upgrading the firmware and plug it in
Since you are using the Type1/Rev1 board, the Moates 2.0 should plug in like the romulator used to, just upload the NT patched ROM image and the address tracing should work like it does with Rev3 that I tested CA18
You will get both hardware as well as consult maptrace with that board at the same time
Since you are using the Type1/Rev1 board, the Moates 2.0 should plug in like the romulator used to, just upload the NT patched ROM image and the address tracing should work like it does with Rev3 that I tested CA18
You will get both hardware as well as consult maptrace with that board at the same time
-
AndyStuttgart
- Posts: 30
- Joined: Thu Feb 15, 2007 7:53 am
- Location: Stuttgart/Germany
- Contact:
do i still need the daughterboard? i'd like to remove it and the pesky romulator if possible.Matt wrote:Just a matter of buying one, upgrading the firmware and plug it in
Since you are using the Type1/Rev1 board, the Moates 2.0 should plug in like the romulator used to, just upload the NT patched ROM image and the address tracing should work like it does with Rev3 that I tested CA18
You will get both hardware as well as consult maptrace with that board at the same time
You can but you will lose all your consult guages, logging etc.
Hardware maptracing provides all cells accessed during ROM reads on each grid during emulation. For 3D maps it is a four cell trace since it records address accesses which the ECU interpolates from those cells
Using consult NIStune displays four cells accessed plus highlights the closest interpolated cell and can perform cursor follow, trail etc
It also doesnt replace features such as recording trace during tune, cursor follow position
So using the Type 1 board will give you better feedback and functionality than just using an emulator alone
Hardware maptracing provides all cells accessed during ROM reads on each grid during emulation. For 3D maps it is a four cell trace since it records address accesses which the ECU interpolates from those cells
Using consult NIStune displays four cells accessed plus highlights the closest interpolated cell and can perform cursor follow, trail etc
It also doesnt replace features such as recording trace during tune, cursor follow position
So using the Type 1 board will give you better feedback and functionality than just using an emulator alone
-
RB30-POWER
- Posts: 62
- Joined: Fri Jul 20, 2007 4:43 pm
sorry i must ask,
wtf is moates, im taking it by the way you are talking, it is a hardware board/chip that needs to be installed and this allows the software to report realtime operating paramters instead of the delayed emulator output nistune currently uses?
but you said the emulator trace is the same anyway on the vlt ecu, so i should not really bother with it?
where does this hardware get purchased from?
to update firmware, doesn't that means the board need to be sent to you?
regards
Mick
wtf is moates, im taking it by the way you are talking, it is a hardware board/chip that needs to be installed and this allows the software to report realtime operating paramters instead of the delayed emulator output nistune currently uses?
but you said the emulator trace is the same anyway on the vlt ecu, so i should not really bother with it?
where does this hardware get purchased from?
to update firmware, doesn't that means the board need to be sent to you?
regards
Mick
Moates (http://www.moates.net) makes a USB emulator module called the Ostrich 2.0. It contains a SRAM chip which is battery backed up
This emulates the EPROM in a factory ECU. It can be used by itself and now provides maptracing capabilities by upgrading its firmware (attached). Note that this firmware is for their emulator, nothing to do with the NIStune board
The early small batches of NIStune Type 1 boards (Rev1,2,3) used a plug in emulator. You upload the ROM + NIStune firmware to the emulator and then consult capabilities are available. You can then make changes using those boards via the emulator, and consult feedback from the boards. Now in addition the emulators also provide the hardware trace (but this doesnt really add any benefit if you already have consult feedback)
Making changes to the emulator is the same as making changes to NIStune, the changes are made to RAM during in realtime whilst the ECU program is in operation
The moates ostrich emulator will modify its RAM whilst the ECU is not accessing that chip. If there are mulitple bytes, it will queue the writes between EPROM accesses by the ECU.
The NIStune software will also queue bytes and send upto 16 seqential bytes at a time to upload the the board, which will write on each interrupt cycle
I've made the writes smart, so that if the same memory areas are uploaded subsequent times, it will discard previous write to the same address
Really there is not that much delay between a NIStune board and emulation to be noticable
This emulates the EPROM in a factory ECU. It can be used by itself and now provides maptracing capabilities by upgrading its firmware (attached). Note that this firmware is for their emulator, nothing to do with the NIStune board
The early small batches of NIStune Type 1 boards (Rev1,2,3) used a plug in emulator. You upload the ROM + NIStune firmware to the emulator and then consult capabilities are available. You can then make changes using those boards via the emulator, and consult feedback from the boards. Now in addition the emulators also provide the hardware trace (but this doesnt really add any benefit if you already have consult feedback)
Making changes to the emulator is the same as making changes to NIStune, the changes are made to RAM during in realtime whilst the ECU program is in operation
The moates ostrich emulator will modify its RAM whilst the ECU is not accessing that chip. If there are mulitple bytes, it will queue the writes between EPROM accesses by the ECU.
The NIStune software will also queue bytes and send upto 16 seqential bytes at a time to upload the the board, which will write on each interrupt cycle
I've made the writes smart, so that if the same memory areas are uploaded subsequent times, it will discard previous write to the same address
Really there is not that much delay between a NIStune board and emulation to be noticable
- Attachments
-
- moates.zip
- Updater
- (98.97 KiB) Downloaded 110 times
I noticed just then rereading the post about delay in consult feedback. The read loop is delay of 30ms. Real world output from the Type 1 ECU is about 9 times per second (~110ms) per each output of consult data
The emulator hardware maptrace runs every 30ms also and collects currently 20 of the last address accesses in a defined window - the data area (maps, talbes etc of the ROM chip)
Those accesses can be anything, and not necessarily the tables we are looking at. We scan the entire area - so if you have say fuel map, timing map and vq on the screen, we can sample all those tables simulatenously
You are not guarateed the ECU reading from a map area that is currently on the screen each time we request it. The more samples we collect, the higher proability we get of having a trace land in say our fuel map... within that data area (as opposed to constants and other flags being accessed also in that data area). I dont have a measurable typical hit rate but I think it could be about the same (say 60 addresses read in 110ms and you get 1-2 fuel map accesses within those addresses)
What I am saying here is that the consult maptrace is always going to get your last RPM/TP value guaranteed within a latency of 110ms whilst maptracing delays are hit/miss depending on the probability of intercepting say a fuel map address read. I believe the USB consult rate rate is quite good for tracing and display, and also logging since the recent sampling updates
The emulator hardware maptrace runs every 30ms also and collects currently 20 of the last address accesses in a defined window - the data area (maps, talbes etc of the ROM chip)
Those accesses can be anything, and not necessarily the tables we are looking at. We scan the entire area - so if you have say fuel map, timing map and vq on the screen, we can sample all those tables simulatenously
You are not guarateed the ECU reading from a map area that is currently on the screen each time we request it. The more samples we collect, the higher proability we get of having a trace land in say our fuel map... within that data area (as opposed to constants and other flags being accessed also in that data area). I dont have a measurable typical hit rate but I think it could be about the same (say 60 addresses read in 110ms and you get 1-2 fuel map accesses within those addresses)
What I am saying here is that the consult maptrace is always going to get your last RPM/TP value guaranteed within a latency of 110ms whilst maptracing delays are hit/miss depending on the probability of intercepting say a fuel map address read. I believe the USB consult rate rate is quite good for tracing and display, and also logging since the recent sampling updates