MSgpio.com read only forums (Jan.15,2018)

With the boards about to hit people's hands, here is the initial release version of the MegaShift trans code (attached) as a tuning software 'project folder' with the S19 and main.c included as well:
It is the same as version 1.006 released earlier, except for the changed version numbering, and the re-enabling of the warning message in the INI (which can be disabled with a single semi-colon - this is noted in the INI itself).

The full Codewarrior project has been placed on the web at: http://www.msgpio.com/manuals/mshift/4L60Ecode.html

Lance.

All,

The beta V2.000 code is now available for limited and cautious bench testing. This code adds:
- up to 8 forward speeds allowed (+P/N/R),
- optional fourth shift solenoid output4 added on spare2 (PA0/VB2/Amp12). Has 'bit-banged' PWM and refresh cycles (like output1 and output2),
- optional fourth digital shift lever input added on PE1/GPI1/Amp5,
- CAN pass-through infrastructure from latest Sequencer code added,
- user defined spark retard (up to 25.5°) for upshifts and for downshifts,
- user defined spark retard (up to 25.5°) by gear (above a user specified load threshold) for 2nd and higher gears,
- user specified output patterns for the LED outputs (especially useful for interfacing with a seven segment LED driver).

(Unfortunately the 32K Codewarrior 'special edition' limit has been exceeded (~37K).)

These are in addition to the previous functions of the V1.100 code:
- Fully user configurable automatic or manual mode, with user tables for shift speeds and line pressures a based on speed and load,
- 12x12 speed versus load target gear table,
- 12x12 speed versus load line pressure PWM table,
- User configurable output and input patterns (to adapt to many 4-speed automatic transmissions - defaults are for GM 4L60E trans),
- Speed in 0.1 mph (or kph) increments,
- Fully user configurable lock up torque converter clutch (TCC) settings,
- Odometer in 0.001 mile (kilometer) increments (in addition to a VSS tooth counter),
- Full datalogging of speed, gear, odometer, line pressure, etc., as well as main loops counter, etc.
- Provisions for 'paddle' shifters on steering wheel,
- Four LED indicators for current gear:
- Adaptive load sensing interprets your driving style and adjusts shifts to reflect 'hard' or easy' driving,
- MegaTune display of shift button status, braking, gear, TCC status, speed, load, odometer, trans temperature, etc.
- Built in code for a 0.5-4.5V line pressure sensor,
- Configurable (pulse/mile) 12V square wave hardware speedometer output for electronic speedometers (you set the pulse per mile),
- Two spare outputs that can be set by a user-specified combination of vehicle speed, engine rpm, load, or current gear (with user-set hysteresis to prevent rapidly cycling near the switch points). These can alternatively be used as 'clutch outputs' (i.e., active only during a shift),
- GM (digital inputs) or Ford style (varying voltage) shift lever determination. If the Ford style is used, the addition 2 inputs can be used to datalog voltage signals (temperatures, TPS, MAP, etc.),
- 2/4WD speedometer scaling.

The CAN pass through is tested and works with B&G code version 3.400 and higher (editted from 3.300. Get the 3.430 code here: http://www.megamanual.com/ms2/betacode.htm - note that 3.430 code will not install on many MS-II's without a bootloader upgrade. For those able and willing to test, I will upgrade the bootloader on their MS-II as necessary if they ship me their MS-II). The CAN pass-through code works with TunerStudio only. You need to set up for the CAN pass-through under TS 'File/Project Properties/CAN Devices'. The CAN ID for the MShift code has a default value of 1. Phil says, "If your MSII is the primary controller in the project you don't set it up as a CAN device, only set up the GPIO board as a CAN device. The Primary Project Controller will always use the CAN ID as defined in the ini, where the with any CAN devices TS will replace the CAN ID in all the ini commands with the ID you set for the device in the Project Properties, so Make sure you set that to the ID . So if you have a Project that has an MSII as the mainController, then a GPIO board as a CAN device on CAN ID 1, it is only the GPIO board that goes in CAN Devices list and the CAN ID should be set to 1."

You can change the CAN ID in the menus to a value up to 13 to avoid conflicts with other CAN devices - if you do change the MShift CAN ID you must also change it under 'File/Project Properties/CAN Devices'.

The timing retard functions (for shift duration and in gears) have been successfully tested with code B&G 2.891+, and the tableID and offset for the spark timing adjustment variable on MS-II, etc. are user settable so alternate code can use the spark retard feature.

The code and associated INI can be found here: http://www.msgpio.com/manuals/mshift/V2code.html

The tuning software guide is here: http://www.msgpio.com/manuals/mshift/V2tune.html

Note that Phil has made a very recent adjustment in TunerStudio to accommodate the 16-bit shift patterns, so you might need to update TunerStudio to be able to edit the shift I/O patterns. If you are still using MegaTune, you will likely need to change one line (around line 16) in the INI from: to: to prevent 'current page out of range' errors.

Lance.

All,

I have done a fair bit of testing over the past few days, and the beta code (2.000h) appears to work (at least the fundamentals like shift inputs/outputs, TCC, pressure control, CAN comms, etc.). I know some people are anxious to try this code in their vehicles. At this point, cautious, experienced, and careful users can give it a try, I suppose.

I have put a rough test procedure here:

http://www.msgpio.com/manuals/mshift/assembly.html#test

(This is also the test procedure in the build guide for any first time install.)

I have had occasional corruption issues when burning parameters using CAN. Using the gauges and datalogging appears to be fine, I have not had any problems at all with that. So for the time being, users should only use the CAN pass-though to datalog. If you need to burn parameters (the shift table, I/O patterns, etc.), do this only while stopped with the engine off, and be prepared to re-burn the code to the GPIO if required. Be sure to save your set-up as a MSQ before trying to burn parameters so you can re-load it after burning new code. I would appreciate reports by PM or in this thread of any corruption 'events' - it very well might be my set-up that is the problem (I have a USB-serial converter that might be an issue). I am also experimenting with the data rate in TunerStudio.

And speaking of TunerStudio, many, many thanks to Phil for his help in getting MShift set-up to use the CAN pass-through!

BTW, I have uploaded a new INI to the code link in the previous post. This adds no new functions, but groups the outputs by gear rather than by output. So instead of a dialogue setting output1 in each gear, you see a dialogue for 2nd gear where you can set the desired state of each output (1 to 4), for example. I find this makes more sense to me, and it's easier to see if the output pattern is what you expect in each gear. I will do the same for the inputs and post another new INI shortly.

I will continue more extensive testing here, of course.

Lance.

All,

In initial testing, it seems the corruption issue has been improved substantially, if not eliminated, with the latest code (2.000k) and corresponding INI on the site (links above). So anyone having such issues should try this code. I will continue more testing here, of course.

Lance.

All,

I spoke too soon. While there are substantially fewer corruption events (especially on burns), there are still some, and these can be caused by just opening and closing menus in TunerStudio (ie. not burning or doing anything else).

We will get this sorted, but in the meantime I would advise anyone using this code to use the GPIO's serial port for tuning and set-up (this has proven very robust in testing) and use the CAN pass-through for datalogging only (and only if you wish to datalog both MS-II and MShift at the same time, of course) for the time being. Datalogging directly off of MShift is fine too, of course.

You can still use CAN to get the engine parameters from MS-II to MShift - that works fine. It's just trying to have MS-II and MShift operating simultaneously in TunerStudio that is the problem if you are 'surfing' through the menus.

Lance.

BTW, here is a TunerStudio project for MShift2000 (for a direct connection to the GPIO serial port):
It goes in your /My Documents/TunerStudioProjects folder. I can't really give a 'one size fits all' project folder for the CAN pass-through, since this depends on the code you are running on your engine controller.

Thanks to Dave for bringing up an issue in the INI (a couple of parameters didn't appear in the menus), and Phil for spotting my formatting mistakes.

This has been fixed now and new 2.001 code (with a number of other small fixes as well - thanks for those that brought those issues to my attention) and INI are linked from the V2 code page as before: http://www.msgpio.com/manuals/mshift/V2code.html The tuning software guide is still here: http://www.msgpio.com/manuals/mshift/V2tune.html

Lance.

All,

One of the problems with using the CAN pass-through is that to date only the B&G 3.430 code had all the CAN improvements to use this properly. That wouldn't normally be an issue, you could just upgrade to 3.430.

However, the 3.4xx code uses more memory, and this required a new bootloader. This new bootloader is only installed on MicroSquirts and Sequencers from the 'factory'. So users with MS-II's couldn't use the 3.430 code without upgrading the bootloader (which requires a $100 BDM cable). That limited CAN pass-through testing to those with MicroSquirts or Sequencers (or those with BDM cables).

So what I have done, with Al's blessing, is add the latest CAN code (but not the larger memory) into the 2.900 code for MS-II to make 2.901 code. It is a beta code until fully tested, of course (though the only changes deliberately made were to the serial/CAN comms, and those appear to work great).

This 2.901 codes loads fine on MS-II's with the older bootloader (i.e. all V2 'blue' MegaSquirt-II's).

This code must use TunerStudio (both for the CAN improvements and the MAF table burning function). I am testing this code right now (and Dave is getting set up on it), and hope to release it shortly. There were some issues with TS recognizing 2.901 as 'CAN capable' that we need to sort out - Phil has sent me a fix that works great for me (TS 0.999.8d), but it doesn't work for Dave just yet - so we need to understand why.

For those that want to have a closer look, the code is here: http://www.msgpio.com/manuals/mshift/betacodeCPT.htm

Lance.

All,

The latest 2.002 code is on the beta page: http://www.msgpio.com/manuals/mshift/V2code.html

This code has a number of CAN comms improvements, thanks to Dave's input. These changes keep the CAN comms going even if the controller can't determine which position the gear shift lever is in. The code used to freeze the CAN updates if the gear lever position couldn't be determined (which should *never* happen in the vehicle, but might if testing on the bench).

Improvements were also made to the auto gear lookup, ensuring that the trans won't be stuck in a gear if the code is confused by out-of-bound inputs.

The engine brake function discussed in another thread (for diesels) was also added (but is untested at this point).

Some superfluous variables were removed from the [outputChannels]. Some of these were derived values that were then added back in as TunerStudio calculations, rather than controller calculations (so now the controller doesn't have to waste resources calculating and transmitting these). These changes improve the CAN efficiency.

There is still some work to be done on the CAN comms, but the current set-up works reliably and reasonably quickly on my bench.

Two things of note:

- TunerStudio will sometimes report the signature is incorrect, with a message something like:

expected from INI: 'MShift 2002 '
received from controller: 'MShift 2. '

or something similar. As long as the 'received' part is the first part of the 'expected' bit, I am choosing 'Connect anyways' (since this is the only controller with a signature anything like that on my CAN network) and it seems to be okay from that point. I am looking into this. <edit>In initial testing, TS 999.8f seems better for this signature issue, so users might want to upgrade TunerStudio from the beta page if they are getting signature errors.</edit>

- I often find I have to enter a value to change a parameter twice. The first often won't 'stick' or burn, but the second usually does. I am also looking into this.

Lance.

All,

I have put the latest 2.003 beta code up on the site: http://www.msgpio.com/manuals/mshift/V2code.html A few users had been reporting comms errors, and yet I wasn't seeing any until I tried changing the inputs very quickly, then I would get all sorts of errors. The issue turned out to have several small causes, and these have been sorted now (pending complete testing).

This code has a number of CAN code improvements, and one new user parameter. With this new code (and using the outmsg protocol described below), I am seeing datalog rates around 16 Hz. I haven't seen any signature errors, 'off line' dropouts, or other issues in several hours of testing.

CAN infrastructure changes provided by Al have fixed the blockingFactor issue. blockingFactor is a parameter in the INI that tells TunerStudio how many variable bytes can be sent in response to one request. Previous codes had to use 8 for this, otherwise there were all sorts of problems. The new code can use larger byte values (and thus fewer messages are transmitted). The default value in the INI is now 56.

The CAN code changes mean that the 2.003 MShift code only works with the 2.903+ MS-II/MicroSquirt code (http://www.msgpio.com/manuals/mshift/betacodeCPT.htm) which has the same changes.

Phil's insights on how TunerStudio handles comms errors were essential in sorting out the problems, so many thanks to Phil!

The 2.003 code also implements the CAN outmsg protocol. This allows MShift to grab only the 10 bytes of variables it needs from MS-II, rather than all the 112 byte outpc values. This speeds CAN comms as well. (I will be documenting the outmsg process shortly.)

The new user parameter under 'Tools/CAN Configuration/Outpc CAN message format' allows the user to select between:
- using the outmsg protocol ('Get only required vars'), or
- grabbing the entire outpc ('Get all vars').

Grabbing the entire outpc is necessary if the MS-II/MicroSquirt code doesn't have a compatible outmsg format. 2.903 and 2.003 have compatible outmsg's as defaults. TunerStudio has a utility to burn new outmsg formats to other code versions, but I haven't tested this yet.

The new code also fixes the problem where values had to be entered twice. The remaining issue is that on loading TunerStudio reports: "Warning: A null gauge was tried to be added? This is weird." I think this is an INI issue, but haven't found the cause yet. It can safely be ignored, though.

Lance.

All,

I have put the latest 2.004 MShift code on the site: http://www.msgpio.com/manuals/mshift/V2code.html

This code has CAN updates from Al, and requires MS-II v2.904+ code for CAN pass-through compatibility (or Al's soon-to-be-released 3.5xx code).

No new functions or user parameters were added in this code, but two bug fixes were implemented:
- a roll-over issue with the odometer was fixed,
- a scaling factor typo for the metric odometer was fixed.

The INI was edited, cleaned up, and a few corrections were made. This has fixed the 'A null gauge was tried to be added' warning on TunerStudio start-up.

At this point, no new functions will be added to this code. Instead there will be bug fixes only until it is released as 2.100. Any new functions will go into the subsequent beta code (which will likely be numbered 4.xxx to avoid confusion with all the other 3.xxx codes out there).

Also, it seems we are are close to reaching the critical mass for a new run of trans stims. I will get this process going. The new stim will have a number of upgrades, including a VSS signal generator, shift and brake buttons, and more outputs represented. Projected cost for a bare board is $12 (plus a few dollars for shipping). I will start a new thread when this is closer to release, so if you want one, please wait for that thread or PM me directly.

Lance.