Skip to content

Conversation

@ricallinson
Copy link

Based on the last video I've added mapping tables for the intake/exhaust valves. Going to grab a Harbour Freight engine today so I can start testing.

Notes;

  • I've left the loading of the maps empty for now until I play with @Tamaren1 mapping code.
  • I'm concerned about the detection of TDC and it drifting so added resets (not sure its good or bad?).

@ricallinson
Copy link
Author

PXL_20201216_040029039
In case anyone was wondering. This why I'm so excited. Cyclekarts!


// Control constants.
const int DEG_PER_MAGNET = 6; // Number of degrees for per magnet.
const int ROTATION_TWO = 760/DEG_PER_MAGNET; // Number of interrupts in the full cycle.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should probably be 720 / DEG__PER_MAGNET. However, a 60-2 wheel has 58 trigger edges over 360 degrees. Shouldn't there 58*2 -> 116 interrupts per cycle, not 120?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, I totally messed up that maths. Why is it 60-2? One for the missing tooth and one for zero based array?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I made the assumption that he had made a standard 60-2 (60 teeth, 2 missing teeth) wheel. Re-watching the video it almost looks like a 60-1 wheel. Either way, it might be easier to define all of these in terms of teeth:

    static constexpr int NUM_TEETH = 60;
    static constexpr int NUM_MISSING_TEETH = 2;
    static constexpr int NUM_TRIGGER_EDGES = NUM_TEETH - NUM_MISSING_TEETH;
    static constexpr int DEG_PER_MAGNET = 360 / NUM_TEETH; // Number of degrees for per magnet.
    static constexpr int TRIGGERS_PER_CYCLE = NUM_TRIGGER_EDGES * 2;     // Number of interrupts in the full cycle.
    static constexpr int TRIGGERS_PER_ROTATION = NUM_TRIGGER_EDGES; // Number of interrupts in a half cycle
```.

This way if a change to the trigger wheel design is made you can just update the NUM_TEETH and NUM_MISSING_TEETH.  This would make the intake/exhaust maps a little more complicated.  This could be overcome by creating the maps on an arbitrary grid and then interpolating for the current calculated crank angle.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, rather than teeth I've used STEPS incase there is ever a different way to generate position data. It follows the conventions of stepper motors which implement a similar positioning index system.

I didn't use constexpr as I'm not sure it is a standard for the Arduino?

@valeriu-balaban
Copy link

From what I understand, you try to map the amount of valve opening (not just 0-1, open-closed) to the shaft rotation using the exhaustMap variable. If that is the case then things are more tricky since the electromagnets (or air pressure valves) have two operation modes, open and closed, and achieving partial opening would require modulation (PWM). This looks more achievable by controlling the valve with electromagnets instead of air pressure. However, I might be getting too far ahead and this might not be the intention.

I believe that just focusing on opening and closing the valve at the right time might be easier to implement and almost as efficient as being able to partially opening of the valve.

Looks like people successfully implemented pressure control using an electromagnet: https://ntrs.nasa.gov/citations/20180006153

@ricallinson
Copy link
Author

@valeriu-balaban My understanding is that 0-1, binary open-close is the benefit of this approach. After watching https://www.youtube.com/watch?v=WwlNqaz9q_0 it was clear to me that the binary open/close is why it's more performant.

@ricallinson
Copy link
Author

I think I've removed the need for any time related code. Using a second interrupt to detect each rotation it now has a clear and reliable check point.

@whitfijs-jw
Copy link

That is a good idea. Dual wheel optical cam sensors should be able to be interfaced with the crank with a little bit of work.

I've used DSM cam sensors with a trigger wheel like this in the past:
https://yoshifab.com/store/high-resolution-dsm-cas-trigger-disk.html

Also I'm currently using a AEM EPM on an Alfa Romeo ITB/EFI project. It has 2 outputs: one for cam sync and one for a crank signal. I've adapted it to a bosch distributor, but it could also be adapted to work on the 212 crank for testing:
https://www.aemelectronics.com/products/ignition-components/engine-position-module-epm

My adapter for the AEM EPM
IMG_20200917_134443

Its been a while since I've looked over dealing with nesting/concurrent interrupts on an AVR. Just as a precaution I would set the single trigger interrupt to a a higher priority and keep it as tight as possible. As long as the single trigger tooth is offset from the N-tooth trigger wheel, it shouldn't be a problem.

AVR ISR priorities are described briefly here:
https://microchipdeveloper.com/8avr:int

@james-portman
Copy link

Really interested in the project, just wanted to throw in an idea about the benefit of partial valve opening:
there is actually a BMW engine that can run without a throttle just by altering how far the valves open (lift),

it would be interesting if partial valve opening did work with the freevalve type tech because it might remove the need for a throttle, and might actually bring similar performance benefits as ITBs, as well as potentially improving low down torque (?)

@chutetearer
Copy link

Could it be possible to reach a similar effect by varying how long the valves open, in place of how far the valves open? It seems easier to implement here, though variable lift and duration would clearly be ideal.

@james-portman
Copy link

Could it be possible to reach a similar effect by varying how long the valves open, in place of how far the valves open? It seems easier to implement here, though variable lift and duration would clearly be ideal.

Sure, I think so in general.

Being specific though, it depends how much control you get over the valve opening and closing time, I made an issue to mention about that, it seems like there will be some slowness no matter what,
using pneumatics it looks like immediate 0/1 open/closed to us but in engine terms it is still quite slow to open and close the valves, depending how fast acting the solenoids and computer are.
The normal solenoids would only work up to about 3000RPM max, and would be acting about as slowly as normal camshafts to open and close at that point.

There are faster solenoids but the price starts ramping up.

So if you have less control over the minimum opening and closing times, it would be good to also control how far they open

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants