[help needed] More table needed

[yyj876790646]

I want to use rusefi board on a formula student engine,which is CBR600RRF5.It's high rpm to 17000 make me start to think whether 16*16 table is enough for this engine.I've alse attched a picture of motec base map of this engine.Hope my question can be solved.Thanks in advance!

[AndreyB]

High rpm does not direcly mean larger table is needed. A reminder that both rpm and load axises are configurable and keys do not have to be linear, you probably only care for specific regions. Also interpolation helps.

If you are 100% sure you absolutely need more cells you can recompile the firmware - this should be relatively doable, but this road would make your project and firmware custom thus harder for people to help.

Any pics of your formula setup? A year ago we have visited a formula honda 600 car here in New York but it never got anywhere

[yyj876790646]

High rpm does not direcly mean larger table is needed. A reminder that both rpm and load axises are configurable and keys do not have to be linear, you probably only care for specific regions. Also interpolation helps.

If you are 100% sure you absolutely need more cells you can recompile the firmware - this should be relatively doable, but this road would make your project and firmware custom thus harder for people to help.

Any pics of your formula setup? A year ago we have visited a formula honda 600 car here in New York but it never got anywhere

I haven't got to do the setup because I haven't decide to use which standalone ECU.The picture is the screnshot of motec project file I got from other Chinese college.You can download a Motec M84 ECU manager v.11 to open the file.By the way,if I want more table,how can I modify firmware to do it?

[AndreyB]

To change dimensions you start at https://github.com/rusefi/rusefi/blob/master/firmware/integration/rusefi_config.txt and invoke relevant code generators, after which you recompile.

As I said, i really doubt you need this - but you can if you want to

[yyj876790646]

To change dimensions you start at https://github.com/rusefi/rusefi/blob/master/firmware/integration/rusefi_config.txt and invoke relevant code generators, after which you recompile.

As I said, i really doubt you need this - but you can if you want to

Thanks a lot,maybe I can't do that because I don't have coding experience.

[mk e]

I want to use rusefi board on a formula student engine,which is CBR600RRF5.It's high rpm to 17000 make me start to think whether 16*16 table is enough for this engine.I've alse attched a picture of motec base map of this engine.Hope my question can be solved.Thanks in advance!

The rule is that you need enough rpm points to make a good approximation of the torque curve shape. 16 is plenty on most stock automotive engines which have smooth to torque curves but not nearly enough on a radicle race engine with a torque curve with 2 or 3 inflection points in it.....but most racers ignore mistuning in the bottom 1/2 or ever bottom 2/3 of the rpm range and focus on making the top part perfect and can live with 16 points as a result but it requires a more aware driver.....which is probably not a typical FSAE driver who will probably struggle to keep it in the right gear and deal with any stumbles. Radicle engine on the street applications where you can't ignore the lowered rpm section that often need 32 rpm points, that's what I use on my street car and what I used on the FSAE car I did years ago.

On the load/TPS/MAP/MAP axis I've never seen a setup that needed more than 16 points.

[mobyfab]

Stock and HRC ECUs use 7x16 tables, I doubt you'd need more than the current ones.

[mk e]

Stock and HRC ECUs use 7x16 tables, I doubt you'd need more than the current ones.

MAF setups I assume?

[mobyfab]

Stock and HRC ECUs use 7x16 tables, I doubt you'd need more than the current ones.

MAF setups I assume?

TPS/MAP hybrid

[mk e]

Stock and HRC ECUs use 7x16 tables, I doubt you'd need more than the current ones.

MAF setups I assume?

TPS/MAP hybrid

Ahhh bikes....the modern ones have tables that small? Even spark tables? Is there a separate GPS and map table that get combined to the 7 point load axis?

I've just never had much luck with tables that small....the rpm axis in particular, I'm 11x21 at the moment on the ferrari but I set it up to accept up to 24x32 just in case. The GM injector offset table I use is 17x33 (vbatt vs pressure)and the short pulse adder table goes to 67....tables just keep getting bigger it seems.

I did see a dyno test though on youube of a mildish MAF setup where they went from a 16x16 down to a 1x1 table and didn't lose hp......it seemed a bit like a setup though so who knows, I know I've never had much luck on that path.

[mck1117]

It's also probably not completely unreasonable to up the VE table to 24x24, I certainly wouldn't complain about more resolution near idle. Only 1280 bytes of additional ram usage, and if we switch to 24x24xuint16 for the VE table, it uses only 128 bytes more.

[i_s_64]

Hey guys,

Over the weekend I had the pleasure of messing around with a Link G4X ECU and became envious of its ability to make the maps basically any size I wanted. It gave me more constraints on how I got the car to run in idle and cruise region

So I went about looking on how to expand the 16x16 maps on RusEFI in the code. This is the reason why I've rehashed this old thread.

I originally chose to do a 32x32 table but figured that is a bit overkill for my needs, so I decided to do 24x24. (32x32 would be nice to try though)

I went into the rusefi_config.txt file, and I changed the following to 24

#define IGN_LOAD_COUNT 24
#define IGN_RPM_COUNT 24
#define FUEL_RPM_COUNT 24
#define FUEL_LOAD_COUNT 24

Then I went to compile, and at this point I came up with my first error message telling me that an array being accessed was out of bounds.

I corrected that by adding the max amount of rowValues to the lambda table

I then ran into my next error message while compiling. It is telling me my table is overflowing the ram by almost 3kb
Would this be a hard stop for me and there would be no solution to expanding the tables at this level?

After reading a few posts here, it seems to suggest that the choice of cells is covered by a floating point number (4bytes), and it would be better off if it were with int16 cells (2 bytes)

Would anyone know a potential solution to this? I don't know where to even begin on trying to change something like this. I'm not too well versed in programming, but I'd be interested in trying to figure it all out.

Thanks,

Alex

[AndreyB]

Default value logic should be improved on a case by case basis along the lines of https://github.com/rusefi/rusefi/commit/c78e3735b44f7553ee2709c7b7d9ecda8fe04d1c

Proper solution to get a bit extra ram is to use a bit better MCU like F7 which might require minor board redesign for lqft-100 boards.

[i_s_64]

Default value logic should be improved on a case by case basis along the lines of https://github.com/rusefi/rusefi/commit/c78e3735b44f7553ee2709c7b7d9ecda8fe04d1c

Proper solution to get a bit extra ram is to use a bit better MCU like F7 which might require minor board redesign for lqft-100 boards.

Thanks for the code updates

Regarding the max table size, I did change everything in my env file to F7, and compiled. It compiles just fine, even if I test it up to 64x64. I would need to get the hardware to run it though. It seems like it could be pin compatible with the F4 on the proteus (using 144pin MCU)

I am running a proteus f4 setup and would like to work with the hardware I have right now. I know it's probably quite a deep dive in the programming, but do you have any suggestions on where I should start with altering the code from float to int16? Upper byte number, lower byte fraction, to two decimal places

Thanks,

Alex

[AndreyB]

See autoscale usages in rusefi_config.txt but that's some hard-code change which might not get you the results you are looking for. Proteus F7 is in stock, yes fully compatible in lqfp-144 package you can just swap the chip.

[i_s_64]

See autoscale usages in rusefi_config.txt but that's some hard-code change which might not get you the results you are looking for. Proteus F7 is in stock, yes fully compatible in lqfp-144 package you can just swap the chip.

Well then, I just spent a half hour looking for what autoscale is in all of the files. It is used a lot in some of the txt files, but I don't know what it is and how to use it. I looked for Structures, Defines, Enums, etc

[i_s_64]

See autoscale usages in rusefi_config.txt but that's some hard-code change which might not get you the results you are looking for. Proteus F7 is in stock, yes fully compatible in lqfp-144 package you can just swap the chip.

I actually found I had an STM32F746ZG last night in some stuff I was playing around with a few years ago. I installed that in the board, but it doesn't start up with any rusefi code unfortunately. From an F7 Snapshot or official release. I know the chip is good as I'm able to compile code with STM32Cube and make the USB work, etc, and I can connect to it with STLink

So I'm about to purchase an F7 chip that is referenced here often, which is the STM32F767. But I also have quick access to an STM32F765 and I was wondering if that may work instead. Could it be something like the difference between the F429 and the F427, where the code originally works for the 429 but but works as intended on the 427 as well?

Thanks,

Alex