Announcement

Collapse
No announcement yet.

tune switching on boost chip

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • tune switching on boost chip

    I remembered a long time ago in the original motronic thread there was talk of how to used the whole second side of the code on the boost chip for a high boost/race fuel boost option. no one ever said how this second set of code was accessible or if it was even possible to access it and use it. does anyone remember how to switch to that second set of code? what im talking about is the operating code from 0x4000 to 0x7FFF. i can handle the checksum for now by disabling it on that since the tunerpro checksum plugin doesnt do that half of the chip but i feel i could modify the tunerpro plugin later to correct that half as well. anyone have any insight on this? id like to run a low/high boost setup.
    "The really good drivers got the bugs on the side windows." Walter Röhrl

  • #2
    Just switch A15 on 87c257 between high and low and you have dual boost maps.
    http://tuner.ee - http://www.facebook.com/tuner.ee

    Comment


    • #3
      Originally posted by vwnut8392 View Post
      does anyone remember how to switch to that second set of code? what im talking about is the operating code from 0x4000 to 0x7FFF.
      What is the second part of the code?

      Comment


      • #4
        Originally posted by Acki View Post

        What is the second part of the code?
        In main case - the same like first part (full copy)!!

        Comment


        • #5
          Thanks! Got it - a look into the source of prj checksum routine explained it too much V8 thinking in my head...

          Comment


          • #6
            Did somebody investigate the datastream from the boost chip? I have a "leading" 00 which isn't send from the data stream routine. Hm

            Comment


            • #7
              Have it, RAM_7E should be set to 0 and not FF at 0x19D6 (inc RAM_7E will cause 0 and mul 0 is 0 etc. pp).

              Did anyone tested a higher Hz at the boost chip? (3.97 Hz is not a lot)

              Comment


              • #8
                Originally posted by Acki View Post
                Have it, RAM_7E should be set to 0 and not FF at 0x19D6 (inc RAM_7E will cause 0 and mul 0 is 0 etc. pp).
                mul 0 is 0 etc. - it's 100% correct. This is routine for jumping to 14 sjmp for data collection from 0x1A7C which is result of 0*2=0 i.e. accumulator is loaded by 0 and jmp @A+DPTR where DPTR=0x1A7C(or where you placed the code) then from 0 to 14 (E hex) mul by 2 is offset for 3 bytes i.e. for command sjmp + destination addres you need 3 bytes (example 80 XX XX). Everything in code is Ok!!!!! Tested more than 1000 times.

                Originally posted by Acki View Post
                Did anyone tested a higher Hz at the boost chip? (3.97 Hz is not a lot)
                Yes, just rise up value and will have more often data, but this will cost more load on boost CPU. In very high RPM this may will cause a problem, because of real time ignition calculation, for this Dmitri has written couple of times in that forum.

                Comment


                • #9
                  Originally posted by d_anev View Post
                  mul 0 is 0 etc. - it's 100% correct. This is routine for jumping to 14 sjmp for data collection from 0x1A7C which is result of 0*2=0 i.e. accumulator is loaded by 0 and jmp @A+DPTR where DPTR=0x1A7C(or where you placed the code) then from 0 to 14 (E hex) mul by 2 is offset for 3 bytes i.e. for command sjmp + destination addres you need 3 bytes (example 80 XX XX). Everything in code is Ok!!!!! Tested more than 1000 times.
                  You have the RAM_49 output double caused be the following MOV SBUF, RAM_49 and the "first" JMP point.
                  I don't see the benefit to have RAM_49 2 times in the stream.
                  I don't say it's not working, I don't say that my proposal is "better" - I would like to discuss it -> I'm sure the most of the boost chip stuff I don't understand cause the code style is different to the "engine chip" (table lookup etc).

                  At the moment I'm working on a passing the datalog routine when engine isn't runing to lower transmission errors with the "engine" chip via diagnosis. RAM_23.7 is in my focus cause its the Cyl 1 detection. Unfortunatly I don't have the Cyl 1 detection perfect working at my "desk bench" - may somebody could generate a small log file for me? RAM_23 shoudl switch from 9d to 89d - could somebody confirm this?

                  Yes, just rise up value and will have more often data, but this will cost more load on boost CPU. In very high RPM this may will cause a problem, because of real time ignition calculation, for this Dmitri has written couple of times in that forum.
                  Hmm I must deactivate the passing of the passing of the "main" loops caused by missing sensors. Have it stable running at 8000rpm but I'm sure it's caused by passing the main calcs.
                  With my canchecked display I can see that a low frequency can trick you because you don't see the ignition retard by knocking. BUT too fast has the same issue - peaks are gone before you have seen them (when you log nearly each loop).

                  Comment


                  • #10
                    I can't see where is your problem!

                    Dmitri give as all tools to manage data stream.

                    Remove all data that you consider for unnecessary, change BDL driver and you are in game.

                    I did that a long time ago for daily driving with one additional custom application. The data stream is only 8 bytes. Six of them is for parameters and 2 bytes are filed with information from bit addressable Ram for some states interest for me. (like WOT, Fuel cut, Lambda sensor timers, sates of ports and etc. ) which change color or play some sounds and which don't distract me from driving to observe them.

                    Your fantasy is your limit

                    Comment


                    • #11
                      No issue - only want to optimize the code. No problem, will keep improvements for myself Thought discussions are welcome, sorry.

                      At my daily I have this https://youtu.be/a6vK7wpwaIA

                      Comment


                      • #12
                        Great !!!!!! it's look much much better than mine
                        Bravo

                        Discuss are welcome, just free time for them is limited

                        Comment


                        • #13
                          I will tell you specifically what the performance problem is, maybe one of you wants to fix it.
                          The reset is purely because of boost chip.

                          The problem is that the serial interrupt is active. Vectoring to the interrupt is expensive(!) and it interrupts critical code. I tried playing with interrupt priority, but even burying it still resets.
                          The same problem was in fuel/ign chip, but I solved it by distributing the load!

                          The solution is:
                          1. Turn off the TXD interrupt and remove all code from there.
                          2. Initiate the first byte in the main loop like now, but for 2nd byte, add in some places that are run often the check for whether the byte was transmitted already - then call the function that transmits the next byte. In the fuel chip I did this by adding the transmits to the map lookup function via a jump. I did it so that it does not require extra pushing of variables, so the cost is very low. Something like that should be done here too.
                          http://tuner.ee - http://www.facebook.com/tuner.ee

                          Comment


                          • #14
                            Is the frequency limited because of crashing or cause it's not needed faster?

                            Comment


                            • #15
                              Originally posted by Acki View Post
                              Is the frequency limited because of crashing or cause it's not needed faster?
                              Because of crashing only. If it didn't crash you can do 20hz quite reliably.

                              The way it works is, boost chip initiates the sequence. Fuel chip looks for the magic bytes, once they are received it sends it's data.
                              Timing is of some importance, but usually fuel chip can send it's data at about 40hz at 8000 rpm. So you can easily do 20hz flat.

                              The boost chip code needs to be rewritten the way I said, then there will be no crash and you will have stable 20hz logging.
                              http://tuner.ee - http://www.facebook.com/tuner.ee

                              Comment

                              Working...
                              X