Speeduino is now on Github Sponsors (Rather than Patreon): https://github.com/sponsors/noisymime
Any strange behaviour, crashing issues etc, post them here! Problems compiling the firmware should go in the General support section rather than here
User avatar
By jonathanlawley
#47819
jonathanlawley wrote:Hi, Ive been trying to work on the 6/7 trigger wheel based upon what Yoosyn has said. It seems to me that by disabling that single line of code(and bypassing the filter) that would mean the filter is too aggressive. Setting it to "10" instead of "2" may decrease sync times.
So the line will look like this:
triggerSecFilterTime = curGap2 >> 10;
[/quote]

yes that is how it should look. From my testing the code the higher the number put there means basically a less strict filter.
If you try that let me know how it works for you because that will effect how I would want to develop the progressive filter.
User avatar
By Yoosyn
#47842
jonathanlawley wrote:From my testing the code the higher the number put there means basically a less strict filter.
If you try that let me know how it works for you because that will effect how I would want to develop the progressive filter.
I have made tests. With filtering at 10 it starts every time and need same 3s of cranking.
secondary filtering disabled:
https://www.youtube.com/watch?v=jjis3DCPCTw

triggerSecFilterTime = curGap2 >> 10;
https://www.youtube.com/watch?v=jjfeamg3-FQ

Beautiful weather 8-) :D
IMG_20210126_142657.jpg
IMG_20210126_142657.jpg (262.87 KiB) Viewed 839 times
User avatar
By jonathanlawley
#47863
thats strange that its no different. Ive just ordered an oscilloscope to see if I can make a different type of filter with the code. In the mean time I made this little loop that should (hopefully) find the correct filter value for you.

Code: Select all
 if(secondaryToothCount > 1)
      {
         triggerSecFilterTime = curGap2 >> filt;
        if(filt > 1 ){
          filt--;
        }
      }
the only thing extra you have to do is just declare 'filt' at the top of the code like
Code: Select all
int filt = 10;
thanks for taking the videos it has been too wet to go outside here so I haven't tested it my self
User avatar
By Yoosyn
#47872
jonathanlawley wrote:thats strange that its no different. Ive just ordered an oscilloscope to see if I can make a different type of filter with the code. In the mean time I made this little loop that should (hopefully) find the correct filter value for you.
I will try it on saturday :) Declaration int filt = 10; should go to the up declaration lines of decoders.ino?
Take a look at init.ino

case 13:
triggerSetup_Subaru67();
triggerHandler = triggerPri_Subaru67;
triggerSecondaryHandler = triggerSec_Subaru67;
decoderHasSecondary = true;
getRPM = getRPM_Subaru67;
getCrankAngle = getCrankAngle_Subaru67;
triggerSetEndTeeth = triggerSetEndTeeth_Subaru67;

if(configPage4.TrigEdge == 0) { primaryTriggerEdge = RISING; } // Attach the crank trigger wheel interrupt (Hall sensor drags to ground when triggering)
else { primaryTriggerEdge = FALLING; }
secondaryTriggerEdge = FALLING;

attachInterrupt(triggerInterrupt, triggerHandler, primaryTriggerEdge);
attachInterrupt(triggerInterrupt2, triggerSecondaryHandler, secondaryTriggerEdge);
break;


I'm using RISING Primary trigger edge. On falling it is overadvanced 10-12 degree. Do you think I should manually change secondaryTriggerEdge = FALLING; to RISING? So both will work on RISING edge. I don't know why choice is disabled in TS.
User avatar
By jonathanlawley
#47877
Yes put the Declaration "int filt = 10;" at the to the up declaration lines of decoders.ino

for the init.ino:
I believe manually changing the code to RISING for the secondary wheel when you also have RISING for the primary wheel will just give you the same situation you had with primary FALLING and secondary FALLING. Because the way I understand how the decoder works is that it is counting the time between the trigger pulses on the primary and secondary. BUT that is assuming that the little pegs on the crank gear and cam gear are the same width. I would say try it though because it could have been an oversight from the developers.

also I see you are running parallel. how are you doing that because that is something I want to try
User avatar
By Yoosyn
#47888
I will make some tests during weekend. Here is nice thread if you miss it: http://speeduino.com/forum/viewtopic.ph ... d00d721493
jonathanlawley wrote:also I see you are running parallel. how are you doing that because that is something I want to try
Connect every needed input/output and send it.
Just kidding. If you are about to use same sensors you must get rid of calibration (pullup) resistors on CLT and IAT so OEM will see same temperature. I don't know details my brother make it. I can send you temperature calibrations for Speedy.
I have made switchable connectors for 4 injectors and 2 ignition outputs so if anything broke I can switch to OEM in minute.
You need to disconnect O2 sensor from OEM. If you don't do it will build messy fuel correction maps when fuelling is from speedy :)
OEM IACV, tacho, and other auxiliaries will work well.
So you have to provide anything for speeduino to work well and it will generate nice injector PW and ignition signals. Remember it is not modifying PW and ignition signals - It is creating your own.
By miker
#48503
Just seen this thread and wondered if i could help - i'm absolutely not an expert but have been playing with trigger patterns recently and fancy looking at something different. Having read through this thread without any other background a few things spring to mind,
  • you're playing with rising / falling. I was going to mention the page pazi88 has done but i've seen you've recently linked to that. As I understand it the high speed logger / composite logger should help identify what settings you should use and would be keen to see the output.
  • You mention about the timing advancing when you change between rising or falling. I think this is to be expected as you're getting the trigger signal at a different part of the timing wheel - basically a tooth width apart. The different you're seeing is confirmed by your post with the trigger wheels which look to be about 10 degrees here (i was googling to confirm the pattern) viewtopic.php?t=2501
  • I can see you're playing with the filtering and making a much smaller filter than normal. This instinctively doesn't feel right but its given me an indication to what the problem could be. Having looked at the code in the 2020-12 firmware i'm doubly confused as the filtering seems to have been commented out. I was expecting to see the code updating the trigger filter after every tooth, which when you've had a large gap would then cause a problem with the teeth having a small gap potentially being skipped as noise. Where can i find the current code you're testing so i can have a play on my bench setup?
  • If i've understood the comment above about size of the timing pegs being different sizes, its irrelevant. The electronics look for a signal change, from low to high or high to low. As long as there is enough metal to generate in the sensor a large enough electrical signal for the electronics to convert that 'change' into a pulse for the arduino to see its done its job. As the system always looks for the same type of signal (rising or falling) the size of the tooth is irrellevant, it doesn't see the size, just the edge. A 60-2 trigger wheel the peg is 3 degrees, on a 36-1 the peg is 5 degrees.
User avatar
By jonathanlawley
#48756
Hi, miker
ive had to sideline my contribution to this project because I just recently gotten a job that has taken up most of my time.
but just by looking at the newest release of the firmware versus what I have from a few months back the subaru 6/7 has not been touched.
I have ordered a MAX9924 Vr conditioner so I can be on the same page and because Ive heard there is the most success with that.

For the size of the timing peg thing, I think I meant that the WIDTH would essentially change the timing of the rising versus falling. As in the timing is offset by the edge location which coincides to the width. Its probably not an issue tbh but rather just a consideration for nitpicking.

For the rest of it we'll need to wait for Yoosyn to chime in about the angles because he was the one who made those posts you linked to.

:D thanks for keeping this alive
By miker
#48764
I'm migrating some trigger code thats in test to the latest release. Once thats done i'll have a proper look at this code / set up test environment. I'll only be bench testing but hopefully we can get confidence the bench version works / fix issues and then any issues are down to hardware / environment.
Boost By Gear

well good to know , I haven't seen it on github or[…]

what I can't understand is what you mean by &quo[…]

In a general sense, the reliability of things like[…]

As far as I know all NA 1.8's are sequential. Does[…]

Still can't find what you're looking for?