The MegaSquirt Project has experienced explosive growth other the years, with hundreds of new MS installations occurring every week - a phenomenal success! MegaSquirt has been successfully used in all aspects of Internal Combustion engine applications including R&D, Industry, Race, and Research. The MS project has transformed itself from a simple R&D project into a full-featured mature engine control system. To reflect this the support structure has also changed to meet the needs of MegaSquirt Users.
Moving forward, the R&D forums for MegaSquirt project are in a read-only mode - no new forum posts are accepted.
However the forums will remain available for view, they still contain a wealth of information on how MegaSquirt works, how it is installed and used. Feel free to search the forums for information, facts, and overview.While the R&D forum traffic has slowed in recent years, this is not at all a reflection of Megasquirt users, which continue to grow year after year. What has changed is that the method of MegaSquirt support today has rapidly moved to Facebook, this is where the vast majority of interaction is happening now. For those not on Facebook the msextra forums is another place for product support. Finally, for product selection assistance, all of the MegaSquirt vendors are there to help you select a system, along with all of the required pieces to make it complete.
A forum for discussing applications and implementations of the MegaShift transmission controller code for the GPIO from B&G. This can control up to 8-speeds and 6 shift solenoids (plus a 16x9 table for controlling a PWM line pressure valve). It has manual and fully automatic modes (16x9 load x speed table), with under and over rev-limit protection, and full data logging of all inputs and outputs (among many other abilities). A TransStim to test your completed board is also available.
If the SP1% is reporting properly, the problem is unlikely to be with the code or the settings. That's because the SP1% value is derived solely from the current state of the PWM period for SP1. So it almost certainly does reflect the actual state of the output pin, unless the processor pin has been damaged (possibly by flyback voltage when running without a recirculation diode) or the code is corrupt. As a check, dd you try the code I posted?
If this was mine, I would put a scope on the 25x2 header for SP1 (PT7/VB1) to verify the processor is producing the correct output. If you have a scope, that's the thing to try next.
If you don't have a scope, you should look over the circuit very, very carefully (including the AMP connector soldering and wiring) to look for any shorts, then you should probably re-load the code.
If that doesn't work, I would desolder the PT7-VB1 jumper wire at one end, and tape it up so it can't contact anything on the board. That should prevent the VB1 circuit from grounding. If the circuit still grounds your device, you definitely have a problem in the circuit or the wiring (or the device itself).
If none of that works, and another spare port is free, you might try using it instead.
Lance.
"Never wrestle with pigs. You both get dirty and the pig likes it." - George Bernard Shaw
I believe I may have found an issue with the spare ports. I don't think this is directly related to your issue, but it might be. I will put a fix in the code and post it here shortly.
Lance.
"Never wrestle with pigs. You both get dirty and the pig likes it." - George Bernard Shaw
This code fixes a few issues:
- the PWM% value was only being updated when the On/Off condition(s) was met, and
- when PWM'd, the off condition would sometimes hang in the 100% on state (and this might be what was causing your issue, though it only happened about 20% of the time on my bench).
BTW, I was wrong above about the PWM state being observed directly, that is only true for sp0 and sp3 at this point. sp1 and sp2 are bit-banged, so there is some calculation involved.
Lance.
"Never wrestle with pigs. You both get dirty and the pig likes it." - George Bernard Shaw
Okay thanks Lance I will try the new code. The last time I attempted this code the pressure control wouldn't reflect the instantaneous value on the table due to some type of smoothing input. The spare inputs also did not work with V5, but this was 2 weeks ago and I will try the new code posted.
And I have an Oscope so that will be next if this doesn't work... the clutch button is holding in there lol
You were exactly right about the problem with the PC duty cycle. It was being set according to the short-term load average, rather than the instantaneous load. That is fixed in the attached code (and all future codes, of course!). Thanks for spotting this and bringing it up.
This problem, and many of the other little problems, spring out of substantially re-arranging the interrupts to accommodate the new serial format (the infrastructure is in place in the 5.09x code, but will only be implemented in the otherwise identical 6.09x codes due soon). The new serial format will be worth implementing (it will make the MShift code more compatible with TS and MS3 and B&G microsquirt code). The opportunity was taken to also make the interrupts run more efficiently. But the degree of changes meant that there was bound to be some teething issues, unfortunately. Please accept my apologies for the hassle.
Lance.
"Never wrestle with pigs. You both get dirty and the pig likes it." - George Bernard Shaw
Loaded up the code you gave me, the PC looks good, but now the spare port 1 (clutch) is acting real strange... it blips on for a split second every time I shift, but does not stay applied for the entirety of the shift.
Very odd.. I am uploading my tune and the data log now. And it took me 4 days to do this because my MegaSquirt started to misfire
