[Jack Hidley]

Does anyone know what the Real Time Monitor checkbox on each of the tables in BE does? I search the site and the BE help files and didn't find anything.

[2Shaker]

I've noticed it but I don't know what its for. I'm sure Clint will answer this so hang tight. BTW, I installed your K member/coil over in my 1994 a year ago and its terrific. I wear my MM lisence plate surround proudly.

[cgrey8]

What that does is illuminates the 4 Cells you are currently referencing in the tune while you are driving...assuming you are monitoring RPM and Load. If that's checked and you are datalogging, what you'll see are 4 yellow cells that move around based on the instantanious RPM and Load.

Make sense?

[DrDirt]

No.

Shows up where?

[86GT]

Chris is right. The real time monitor is a way to see the active cells from the live data. You need to make sure you are logging the two variables that define the two axis for the given table. Not all tables work but the more common ones do. For example loag RPM and LOAD and then select a table that has load and RPM as the axis and you will see the highlighted cells. Make sure to use LOAD and not LOADX.

[DrDirt]

Ahhhhh, I see said the blind man. That's cool!

I have every confidence that some day, Clint, you will do the impossible and make this little TwEECer gizmo do real time tuning. Maybe even "AdaptiveTuning".

[cgrey8]

...I have every confidence that some day, Clint, you will do the impossible and make this little TwEECer gizmo do real time tuning. Maybe even "AdaptiveTuning".

I doubt that will be possible with the TwEECer in it's current form. But that would be nice to have in a tuning device. However to get that level of functionality requires a device that can run the car while accepting updates (from the PC or from itself). Since the TwEECer has Flash memory, updating one part of the memory from the PC while continually referencing another part of memory for the EEC to keep the engine running isn't an easy thing to do. As cheap as memory has gotten, a device that's based on some kind of high speed RAM (like what PCs use) and uses a standard Flash for tune storage like SD-Flash cards would make doing exactly what you are describing quite possible. The problem is that's multiple memory chips takes up a lot more space on the circuit board. So until the hardware developers build more than a few kb of memory into their FPGAs (the hardware/processor), getting such a device as compact as the TwEECer is a tough task. I think the largest built-in memory in an affordable FPGA is somewhere around 16kbytes. To do real-time tuning/datalogging would require 128kb (2-64kb tunes) for the 1-bank processors like GUFx and CBAZA. However ideally, a device would need 512kb so it could support the same functionality on the 2 and 4-bank EECs which are 128k & 256k respectively.

[86GT]

Chris hit it right on the head. The problem is the hardware. The CalEdit says it is possible but it is more or less a gamble. If the EEC is trying to access the same memory location that CalEdit is trying to update then the car will stumble and most likley die.

Since this was a gamble I did not implement this in the BE. I need a better fool proof way.

[Jack Hidley]

That is what I figured.

Why four cells? I would expect three areas. One being the breakpoint along the y axis, the other being the breakpoint along the x axis and the third being the actual cell that both breakpoints point to.

[cgrey8]

I'm not quite sure I follow you.

But here's my explanation of it. For this example, lets assume you are Real Time Monitoring the Sealevel Spark Table. Keep in mind that the Sealevel Spark Table's "output" at any given RPM/Load will be some weighted interpolated value that represents 4 different cells in the Sealevel Spark Table. The Real Time Checkbox is just illuminating the 4 cells that currently have a contribution to this value. When I say the value is weighted, I mean that the closer actual RPM/Load is to a specific RPM column or Load row, the more values in those cells contribute to the table's final value.

So lets say you have columns that number across as:
500__700__900__1100_1300__1500__2000__2500__3000__4000

And you have rows as follows:
75
60
50
40
30
20
10
5

Now lets say you are:

• Viewing the Sealevel Spark Table
• Datalogging RPMs & Load
• Current RPM/Load values are 3500/55%
• The Real Time Monitoring checkbox is selected

3500RPMs 1/2 way between 3000 and 4000.
55% is 1/2 way between 50% and 60%.

So the 4 cells that would illuminate would be:

1. 3000/50%
2. 4000/50%
3. 3000/60%
4. 4000/60%

In this example, you are equally distant from either RPM columns and Load Rows. Thus each cell would have roughly a 25% contribution to the final value. However if Load dropped, then the cells at 50% would have more influence than the cells at 60%. If Load dropped below 50%, then the two cells on the 60% row would turn back white and the 2 corresponding cells in the 40% row would turn yellow.

Do you follow?

[Jack Hidley]

That makes perfect sense. Other systems that I've used that show which cell is active (AEM, TEC-II) only show one cell. They don't illuminate all four cells which are contributing. They just pick the one that has the dominant influence.

The AEM system illuminates the active cell along with the X and Y breakpoint values along the axis that correspond. So for example, if you are at 35% load and 3,000rpm, the 35% text on the left row and the 3,000rpm text on the bottom column will be highlighted. This way the illuminated cell shows the independant variable (injector pulsewidth, target a/f ratio, etc) while the X and Y axis illuminate the dependant variables (load and rpm in most cases). This makes it easier to read the dependant values. Your eyes don't have to scan across/down the rows/columns while things are moving around. You just look straight at the X or Y axis to see the highlighted values.

[DrDirt]

Chris hit it right on the head. The problem is the hardware.

I was being somewhat facetious. I know that the limitation to instituting real time tuning is the TwEECer itself. I say somewhat because with the progress you have made in a very short time with BE compared to what has come out of the STKR camp in the 3-4 years that I've been fooling with this, I have learned to never discount what you might be able to do. STKR has progressed from spotty functionality and almost nonexistent support and documentation for a handful of processors to spotty functionality and almost nonexistent support and documentation for a large number of processors. I can't tell you how disappointed I was when the long awaited and much delayed new version came out from TwEECer. You, on the other hand have picked up the fumbled ball and run for touchdowns time after time. No brown nosing intended. I'm just merely impresed and grateful. In my opinion, the TwEECer hardware is great for what I want to do but the packaged software leaves soooooo much to be desired. Thanks for plugging the dike.

[86GT]

Thanks for all of the kind words. I too was in the same boat for three years. I finally could not take it any longer and had to do something.

My main beef is with the definition files. I wish Mike would make them open source. It would only increase sales if BE, CalEdit and TunerPro could help.