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.
Oops - forgot to pull the PC solenoid fuse today when uploading new code for my MShift - 4L80E transmission late style solenoid.
What am I likely to have fried? The solenoid or something on the board?
This is the result of getting angry after the GPIO code was corrupted again for no apparent reason. At this rate I'm thinking about ditching it and fitting a different controller as it's getting to be more hassle than its worth
Ok, thanks Lance. Guess the only way to find out is hook up a pressure gauge and test?
The most annoying thing is that it seems so easy to corrupt the firmware, and I don't really get why.
Today it was the result of a quick power up then down while I was messing about. After that when I powered up again all of the settings were messed up. Reloaded the MSQ but the temp readings were screwy and inputs were flicking on and off or not working. Reflashed the code and loaded MSQ and its fine again now.
In thousands and thousands of hours of testing, I have *never* corrupted the firmware (and only corrupted the user parameters if the board was powered down during a flash burn).
In the reports of others, though, this seems most likely to occur when MShift is being used in pass-through mode from non-B&G code. Even then, it only seems to occur (I understand) when burning new parameters to the MShift code, not while doing normal running, etc. So it seems there is something (likely minor) in the non-B&G code or TS that doesn't properly handle the flash burns on the pass-through all the time. So I recommend those using non-B&G code to connect directly to the GPIO board using its serial port when changing parameters or tuning the trans behavior.
The other possibility is that your serial hardware is noisy (electromagnetically), or failing. Either of those can cause all sorts of issues, of course.
Lance.
"Never wrestle with pigs. You both get dirty and the pig likes it." - George Bernard Shaw
Thanks Lance - this isn't the first time it's happened to me, generally as you say it's been during settings changes. Today it was a power up/down cycle within a couple of seconds that corrupted it.
What you describe could be the case, I'm connected to it via CAN through my MS3 so that might explain it. I can easily connect directly to it for tuning though as I have the serial cable plugged in. I'm using the USB connection on the MS3 for comms. I initially struggled to get the CAN working, but reloaded the firmware on the GPIO and it started working straight away, so I've left it alone since.
I never remove the fuse on the 4L80e.
I think it is the same kind of solenoid and wiring as the 4L60e so it is OK.
And everything is still working correctly today after a lot of code loading.
For the code corrupting, when I make only little changes, it was OK to go through the MS3. but I often had problems when loading the complete msq just after a code update.
When I use directly the serial port of MSGPIO, it is OK.
Thanks. That's reassuring to hear. I'll have to see if it works when I get the motor running. I've never used the transmission - I've just completely rebuilt it with a load of trick bits from Jakes and PATC - so it'll be interesting
So what do you normally do? Make the changes via the serial connection and then when you next connect via CAN just click the 'use controller settings' option on the difference report that pops up?
No, I nearly always with CAN: for datalogging of very small parameter changes.
When I make a code update, I connect directly to the MSGPIO serial port. I connect with Tunerstudio, get the last msq and save it.
Then I close tunerstudio, I update the code.
WHen it is done, I connect with tunerstudio again and load the msq saved just before. I check that everything is working fine.
then I connect again on MS3 USB port, with CAN, I update the ini file for the CAN device in the project propoerties, I keep the settings from controller if the difference report sees a difference.
Normally it should be OK.
When I updated the settings with the difference report via CAN, I often got problems. (maybe I also did not wait long enough to shut off the car: the MSGPIO takes longer to burn than the MS3.)
