MS3 pre-1.4 alpha 1 released

[Activate]

Installed it today.

Runs good, the only thing I had to change wat the req. feul, it must be .1 higher, nothing else for me.

Thanks and greetings,

Erik.

[nismoautoxr]

I am now on this FW. Nothing has been changed in the 4 days since I put it on. I came from the last RC FW before release. I might have noticed a leaner hot restart a couple time since but not sure and not dramatic enough to be concerned ....just an observation.

[shaodome]

Already on to 1.4! You guys waste no time.

Is this the stream meaning 1.4X where we might see launch control and nitrous not being mutually exclusive?

I see another user has requested this feature, along with the ability to have nitrous on when the trans brake is active.

Any updates on this part? This is a REALLY big deal for smaller displacement drag racers. The engines don't make enough torque to fully get up on the stall and aren't large enough to spool the turbo on the trans brake alone.

[thokes82]

Can Broadcasting is working good. But for what reason do we not get OBD2 compatible broadcasting? I am not talking about faking emission data. Just sending the PIDs in Mode 01.
I just think that OBD adapters for displaying data are around everywhere.
http://en.wikipedia.org/wiki/OBD-II_PIDs

[MWPau]

Ok, now on FW 1.4a1 and TS 2.6.01.

A bug... ?

The new can broadcast settings are now there, but enabling them breaks CAN coms with the TinyIOx im also using.
On enabling broadcasting, the MS3 restarts a few times (?) before TS displays a dialog about loosing coms with the TinyIOx.

[jsmcortina]

The new can broadcast settings are now there, but enabling them breaks CAN coms with the TinyIOx im also using.
On enabling broadcasting, the MS3 restarts a few times (?) before TS displays a dialog about loosing coms with the TinyIOx.

(I moved this post over here.)
The CAN broadcasting ought not interfere with other comms as it is using 11bit headers and the "Al-CAN" uses the 29bit headers. The CAN message includes a bit to differentiate them and should allow the IO-x to ignore them. If you post up your MSQs I can test it out here.

James

[jsmcortina]

Can Broadcasting is working good. But for what reason do we not get OBD2 compatible broadcasting?

Did you read http://www.msextra.com/forums/viewtopic ... 25&t=53291 ?

James

[thokes82]

Did you read http://www.msextra.com/forums/viewtopic ... 25&t=53291 ?

Yes. I did. decision made, right?

[MWPau]

The new can broadcast settings are now there, but enabling them breaks CAN coms with the TinyIOx im also using.
On enabling broadcasting, the MS3 restarts a few times (?) before TS displays a dialog about loosing coms with the TinyIOx.

(I moved this post over here.)
The CAN broadcasting ought not interfere with other comms as it is using 11bit headers and the "Al-CAN" uses the 29bit headers. The CAN message includes a bit to differentiate them and should allow the IO-x to ignore them. If you post up your MSQs I can test it out here.
James

Attached (i hope, my first time putting up MSQs).
This project/car is not running yet, so dont be surprised if you see some odd tuning values, etc.

Can broadcast is disabled, enabling it (either new or old style) will create the problem.

Thanks.

[jsmcortina]

Please post a copy of your TunerStudioAppDebug.txt file with comms logging enabled.

Procedure:
1. Turn on Megasquirts
2. Quit TunerStudio
3. Find and delete the TunerStudioAppDebug.txt file. (Inside TunerStudioProjects directory.)
4. Start TunerStudio
5. On Comms menu enabled Comms debug logging
6. Turn on Megasquirts and replicated fault.
7. Quit TunerStudio
8. Find the TunerStudioAppDebug.txt file and upload it as an attachment here.

James

[MWPau]

Attached.

I tried just "Second,PW1,PW2,RPM" at 50Hz to begin with which made the TinyIOx data rate noticeably slow down (tinyiox adc value update rate was about 1/4 speed than normal).
Changing from 50Hz to 100Hz, and then also enabling a second broadcast at 50Hz produced the TinyIOx coms errors.
After a few coms error dialogs, i disabled broadcasting and everything went back to normal.

Thanks.

[edit]
I have the ability to dump all data on the can bus using a separate tool (http://www.msextra.com/forums/viewtopic ... 69#p400969) if that would be of some help?

[MWPau]

Attached is a can bus dump.
This is with the MS3 & TinyIOx using the above MSQ's, with realtime broadcast enabled, and "seconds,pw1,pw2,rpm" set at 20Hz.
Dump is produced using the linux tool "candump can0 -tz".

[jsmcortina]

It looks like the CAN passthrough data is getting scrambled. At 032.130 in the .txt file the response from the IO-x has 16 bytes (0x0143 x of garbage before the correct data stream.

Later reply packets suffer similar corruption - the correct data is starting 0x00 0x10 0x03 0xfe or similar.

It is very complicated to understand what is going on.

James

[MWPau]

Hmmm, i wonder if the CAN handling code in the TinyIOx isnt liking the 11bit ID CAN packets so much.
Any idea where those packets with 0 ID and 0 length are coming from?
They only appear when broadcasting is enabled.

[jsmcortina]

Peter Florance spotted the zero length and zero ID packets also, I wasn't able to observe them using an MS3 as a CAN sniffer.

The log extract you posted doesn't _appear_ to contain any passthrough transactions. I'm seeing CAN polling requests from the MS3 to the IOx and the replies (at 10ms intervals) and 0x5F0 11bit messages every 100ms.

Here's a the start of a piece of code to convert the CANid in your log into their meaning.

Code: Select all

#include <stdio.h>

int main(int argc, char *argv[])
{

    unsigned int can_hdr;
    unsigned int var_offset, msg_type, from_id, to_id, var_blk, msg_x,
        myvarblk, myvaroff, varbyt;

    can_hdr = strtol(argv[1], NULL, 0);

    printf("29bit CAN header = 0x%x\n", can_hdr);

    /* this is the header bits exclusing SRR, IDE, RTR */
    var_blk = ((can_hdr & 0x78) >> 3) | ((can_hdr & 0x4) << 2);
    to_id = (can_hdr & 0x780) >> 7;
    from_id = (can_hdr & 0x7800) >> 11;
    msg_type = (can_hdr & 0x38000) >> 15;
    var_offset = (can_hdr & 0x1ffc0000) >> 18;

    printf("var_blk = 0x%x\n", var_blk);
    printf("to_id = 0x%x\n", to_id);
    printf("from_id = 0x%x\n", from_id);
    printf("msg_type = 0x%x\n", msg_type);
    printf("var_offset = 0x%x\n", var_offset);


return 0;
}

./can29bit 0x00288238
29bit CAN header = 0x288238
var_blk = 0x7
to_id = 0x4
from_id = 0x0
msg_type = 0x1
var_offset = 0xa

James

[racingmini_mtl]

Hmmm, i wonder if the CAN handling code in the TinyIOx isnt liking the 11bit ID CAN packets so much.

The 11-bit ID packets are completely ignored by the TinyIOx. So that won't be an issue.

What could be an issue is the increased bus traffic. And having 2 devices trying to take control at the same time will lower the effective bandwidth because there is some negotiation done at the CAN level.

Do you have this problem even when TS is not communicating with the MS3?

Jean

EDIT: I should add that I have done some tests with an MS2 (running the alpha code) and IOx and there is no issue using CAN broadcasting. But there was no CAN passthrough either.

[MWPau]

James,
I could have done with that little bit of code a day or so ago, would have saved me some time.
Thanks for that anyway though

It interesting you mention that the can pass through data is missing... i guess thats why a couple of my TinyIOx TS gauges have stopped working.
They have been working fine previously (not sure when they stopped).
Any idea where i would look to get them working again?

Jean,
Ok, thanks for clarifying that.
Yeah, im thinking it might be too much bus traffic.
Ill get the problem happening again, then see if i can work out the data bit rate using the candump.
Im not sure how i could test for the problem without being connected to TS?

On another matter...
Wow, parsing the TS INI for the page data names, locations, etc is horrible!
I think ive got it pretty much sorted other than a few lines:
"cel_warmtime = scalar, U16, 316 "mins", 0.01666, 9, 1, 20,1"
"qfrtfielddata= array, U16, 0 [ 256], "", 1.0000, 0.00000, 0.00, 65535, 0, noMsqSave"
They are missing the commas after the offset.

... if youre interested, im working towards a Qt based dash on these: http://www.crystalfontz.com/product/CFA921TS

[racingmini_mtl]

Im not sure how i could test for the problem without being connected to TS?

If you have a TS project that is only for the MS3 (no CAN device), there won't be any CAN passthrough data. I don't think you need to change any settings on the TinyIOx for your tests and you can see the data you poll in the MS3 data.

With this setup, you should only have the MS3 polling data, the TinyIOx responses and the MS3 CAN broadcasting. If that then works, we at least know that the passthrough messages are either the problem or simply increase the data rate over what the bus can support.

Jean

[MWPau]

If you have a TS project that is only for the MS3 (no CAN device), there won't be any CAN passthrough data.

Well, the TinyIOx is listed in the TS project CAN devices. In that dialog "Disable Runtime Data" is not checked, and Config Settings->Serial is Deactivated.
The TinyIOx can be selected in the small "Device" drop down box (left of the drop-down menu buttons).
If i look at the real-time display for the TinyIOx, all read 0.

[racingmini_mtl]

In that dialog "Disable Runtime Data" is not checked

That means you have CAN passthrough messages when the project is open.

Jean