CAN Broadcast parameters

http://jbperf.com/io_extender/index.html
http://jbperf.com/io_extender/tinyIOx.html for the TinyIOx

CAN Broadcast parameters

Postby dontz125 » Tue Jul 17, 2018 6:57 am

Hi, Jean.

I've looked at the MS-CAN protocol manual; I've looked at the sheets for standard 11- and 29-bit CAN frames. I've looked at your intro post to the 0.1.1 firmware. What I have yet to determine is the slightest correlation between the 4 bytes on the CAN broadcast page with their default values, and an 11-bit identifier - or the 2-byte identifiers used for CAN broadcasting by the MS2 or MS3, for that matter.

"8 bytes payload starting with AD0" for ADC0-3 is easy, but I'm sitting here with a blank look for the rest of it!

I also noticed a discussion about the 'CANIN' bits being switched from poll-mode to broadcast receive. I assume this would be set up the same way, except that instead of "8 bytes from adc0", it would be "1 byte from portx" (where x is the digital output port). Close?

Am I correct that CANEGO1-4 is also sent this way, with "8 bytes from aux_data1"?
dontz125
 
Posts: 199
Joined: Mon Feb 22, 2010 10:27 pm

Re: CAN Broadcast parameters

Postby jbelanger » Tue Jul 17, 2018 1:35 pm

Don,

Yeah, this is not an obvious feature. I made it to be flexible but to also keep code development short. That would require more user support but I think this is the first actual question I've had since it's been available.

So the 4 bytes correspond to the internal way the CAN identifier is done in the processor. You can find it in the datasheet but also in the MS CAN protocol document in section 3.1. An 11-bit identifier uses the upper 11 bits of the 32-bit field (in bytes 0 and 1: same as the offset field in the MS protocol) and all the rest of the bits are set to 0. A 29-bit field is set as per the MS protocol document where the 29 bits are mapped to the 32-bit field starting at bit 1 (in byte 3) and where the bits SRR and IDE are always 1 (RTR or bit 0 is 0). Also, the values in TS are in hexadecimal for the 4 bytes.

That's probably still not clear so let me know and I'll do a small spreadsheet to map normal decimal 11-bit or 29-bit IDs to the needed 4 bytes.

The easiest way to look at the payload is to use the ini file and look at the OutputChannels section. The "Start from" field simply corresponds to the offset of the first byte to send. So as you said, for ADC0-3 you use AD0 so for ADC4-7 you would need to use AD4 and so forth. What is confusing when you look at the drop down menu in TS is that it is in alphabetical order instead of the ini offset order that you need. And you're correct about the CANEGO.

Concerning CANIN, it is not switched from polling to broadcast but rather it is made available for receiving broadcast data. All of this CAN broadcast/receiving discussion is to add more flexibility in what the MS3 can do; it is not designed to impose switching anything or removing previous CAN options. The MS CAN protocol and all its options/features are still there and fully usable with the IOx/TIOx. It's only that if you start using non-MS CAN devices which use 29-bit CAN IDs then you need to disable the MS protocol to make sure you don't end up with unintended side effects (which can be bad). Then you can only use CAN broadcasting/receiving to transfer data from/to the MS3 so the more you can do with CAN broadcasting/receiving the better.

Another advantage of using CAN broadcasting is in lowering the CAN bus traffic since there is no need to poll. That means you almost halve the traffic since polling requires a request message for each data message. And if you use 11-bit headers instead of 29-bit, you also save some bits of traffic in each message. So even without other non-MS CAN devices on the bus, broadcasting can be an advantage.

Please note that the IOx currently cannot disable its MS CAN protocol. So if it is used on a bus with devices that send 29-bit messages, you have to know if these will be read as messages addressed to the IOx. If they are, that will not work safely. Otherwise there won't be an issue. And the way to know if it is an issue is to use the CAN protocol document and see if the CAN message IDs used by the non-MS device map to something with a "To ID" that correspond to the IOx CAN id (default is 5). The other bits may also make it a non-issue but it is still safer to avoid potential conflicts.

Jean
Image
jbelanger
 
Posts: 3633
Joined: Sat Oct 03, 2009 12:24 pm
Location: Quebec, Canada

Re: CAN Broadcast parameters

Postby dontz125 » Wed Jul 18, 2018 10:53 am

OK - let's see if I followed that correctly ...

In an 11-bit message, byte 0 is [ From ID ][ To ID ]; byte 1 is [ Table bits 0-3 ] [ Table bit 4 ] [ Spare ] [ RTR = 0 ]. Bytes 2 & 3 = 0.
If you only have the table ID, how do you specify the offset?

I may have been confused by a comment in the MS3 TS manual, but whether 1520 ( = $05F0) or $1520 ( = 5408), it's still only 2 bytes!

CANIN - oops. Yeah, I had assumed that this was an addidtional option, but there seems to have been noise on the mind-keyboard interface. May have to upgrade to CAN protocol ... :D Was I correct that it would be "1 byte from portx" (where x is the digital output port)?
dontz125
 
Posts: 199
Joined: Mon Feb 22, 2010 10:27 pm

Re: CAN Broadcast parameters

Postby dontz125 » Wed Jul 18, 2018 11:04 am

Looking again at the MS CAN protocol and the standard 29-bit chart, I don't see why it was changed. I don't see that anything is gained. All the info in the MS CAN header is in the standard header; 4 bytes are sent. ???

Can the MS2 and MS3 receive standard 29-bit (SRR, IDE, RTR) format frames? Can they *send* standard format frames?
dontz125
 
Posts: 199
Joined: Mon Feb 22, 2010 10:27 pm

Re: CAN Broadcast parameters

Postby jbelanger » Wed Jul 18, 2018 12:31 pm

Ok, there is some confusion and I did not help by referring to the MS protocol document. When using standard CAN broadcasting (either 11-bit or 29-bit), the ID is just a number; there is no specific meaning to different sets of bits as there is in the MS protocol. When you receive (or send) a message with ID 1520, everyone on the bus has to know that this number means a certain specified data content.

And the protocol has not changed. Using standard CAN broadcasting is an additional feature that allows the MS devices to be compatible with the rest of the automotive CAN devices. No one else uses the MS CAN protocol so that can be limiting. And even for MS-compatible devices, there is the advantage of reduced bus bandwidth as I mentioned above.

As for 11-bit IDs, they are represented on 2 bytes but only 3 bits are used in the second byte. So anything above 2047 or $07FF is not an 11-bit message ID (but a value below 2048 can be a 29-bit message ID). And the internal representation I referred to in the MS protocol document, is only that: an internal representation (I have attached the spreadsheet that will give you the values to use in the IOx). When using CAN broadcast, you have to ignore the different bit fields and only consider the ID number. And the actual data sent on the CAN bus will be different in that not all 4 bytes are sent if you use an 11-bit message ID. And if you use a 29-bit message ID for CAN broadcasting, it will be a standard 29-bit message.

Actually, even the MS protocol messages are "standard" 29-bit CAN messages but it's just that this is interpreted differently inside MS-compatible devices. Look at the MS protocol document and the other CAN devices will see a number that corresponds to the the packed representation (but will not see the different bit fields because the don't mean anything outside the MS world).

I hope that makes is clearer and not more confusing.

And yes, you can use 1 byte from portx for CANIN. You would usually try to get more than 1 byte of data in a message but in this case the data close to it may not be relevant.

Jean

EDIT: Corrected the spreadsheet
Attachments
can_broadcast_settings.xls
CAN broadcast settings in the IOx
(15.5 KiB) Downloaded 15 times
Image
jbelanger
 
Posts: 3633
Joined: Sat Oct 03, 2009 12:24 pm
Location: Quebec, Canada

Re: CAN Broadcast parameters

Postby dontz125 » Thu Jul 19, 2018 10:12 am

"the ID is just a number" - and THERE's the source of the confusion! :lol:

Alrighty, then. Looking at TS for MS3 1.5.1 under 'CAN Receiving', it would appear that the ID number is ... almost randomly selectable; so long as the broadcaster and receiver use the same ID for the same things, it seems to be practically Dealer's Choice. Obviously, confusion and corruption by using existing 11-bit IDs, or using an ID that dupkicates an MS-CAN 29-bit message function that wipes the entire flash memory needs to be avoided. Other than the IDs in the 'CAN Broadcasting' function, is there a list of IDs to avoid? Is there a function / means to avoid MS-CAN messages?

I may thinking too hard on the MS-CAN issue - will an 11-bit message even register as an MS-CAN 'format the hard drive' command?

Back to TS and the CAN receiving: am I correct that - having set the ADCs in the IOx to 10-bit - all ADC / AFR values from the IOx are 2-byte Big-Endian Unsigned?
dontz125
 
Posts: 199
Joined: Mon Feb 22, 2010 10:27 pm

Re: CAN Broadcast parameters

Postby jbelanger » Thu Jul 19, 2018 12:41 pm

An 11-bit message will never interfere with MS CAN because it is filtered out; only 29-bit messages can be a problem. And the same spreadsheet I posted above has a decode tab where you can enter an ID value and it will show you all the fields from the MS CAN protocol; that will tell you if there is a potential conflict (the few IDs in there are some of the ones AEM uses).

And the only limitation on what you use as an 11-bit ID comes from what is connected to the CAN bus. You need to know what each device is sending and make sure they don't send messages with the same ID. If you control the IDs from each device, you can use anything from 0 to 2047.

And you're correct about the format for receiving ADC/AFR values.

Jean
Image
jbelanger
 
Posts: 3633
Joined: Sat Oct 03, 2009 12:24 pm
Location: Quebec, Canada

Re: CAN Broadcast parameters

Postby dontz125 » Fri Jul 20, 2018 5:34 pm

Excellent - understood so far! The identifier and offset settings in IOx Broadcasting and MS3 CAN Receiving are now quite clear - thank you.

Just one or two more q's ...
- I don't see an option to set Baud rate. Is this fixed at 500k?
- The "Base Settings" [outmsg] option has always confused me. Does this have anything to do with the topic at hand?

- In the MS3 1.5.1 TS "CAN EGO, GPS" settings, the 'Generic' setting allows reading of 11-bit broadcasts, but specifies that "The input value must be converted to give Lambda * 10000." Does that mean under the 'CAN Receiving' setting, the 'Divide' field should be set to 10000? I seem to recall that the output from the SLCs etc was 'Lambda' - correct?
dontz125
 
Posts: 199
Joined: Mon Feb 22, 2010 10:27 pm

Re: CAN Broadcast parameters

Postby jbelanger » Fri Jul 20, 2018 6:21 pm

dontz125 wrote:Excellent - understood so far! The identifier and offset settings in IOx Broadcasting and MS3 CAN Receiving are now quite clear - thank you.

Just one or two more q's ...
- I don't see an option to set Baud rate. Is this fixed at 500k?

Yes with the current IOx code, it is fixed at 500k which is the MS CAN fixed rate.

dontz125 wrote: - The "Base Settings" [outmsg] option has always confused me. Does this have anything to do with the topic at hand?

That's a completely different subject. That's a feature from an obscure MS CAN mode that has been implemented on the IOx and MS3 which would allow a more efficient CAN transfer but that is so complicated to use that no one has put the effort in promoting it. Additional support from TunerStudio could make it almost transparent to the user but that's not going to happen.

dontz125 wrote: - In the MS3 1.5.1 TS "CAN EGO, GPS" settings, the 'Generic' setting allows reading of 11-bit broadcasts, but specifies that "The input value must be converted to give Lambda * 10000." Does that mean under the 'CAN Receiving' setting, the 'Divide' field should be set to 10000? I seem to recall that the output from the SLCs etc was 'Lambda' - correct?

That generic CAN receiving is for some other unknown device (unknown to me at least). The IOx uses the Innovate format for all the AFR data (Innovate and 14point7 controllers) so that's what you need to use there. When the next MS3 version is out, the CAN receiving will have a new mode for CANEGT messages and that's the one you will need for 11-bit messages from the IOx.

Jean
Image
jbelanger
 
Posts: 3633
Joined: Sat Oct 03, 2009 12:24 pm
Location: Quebec, Canada

Re: CAN Broadcast parameters

Postby dontz125 » Fri Jul 20, 2018 7:07 pm

Perfect - thank you!
dontz125
 
Posts: 199
Joined: Mon Feb 22, 2010 10:27 pm

Re: CAN Broadcast parameters

Postby dontz125 » Fri Jul 20, 2018 9:03 pm

There's something odd with the spreadsheet vs the TS for the IOx. Byte 1 and byte 0 seem to reversed between the two; 1520 => 0 = $BE, 1 = $00 in the spreadsheet, but byte 1 in TS has a minimum value of $18, meaning that byte 0 has to be the $00. More confusion ensues when I use the calculator, and 1520 => $05F0; one RoL (because bit 0 is the RTR) and I get $0BE0 - slightly different from either $BE00 or $00BE.

Also, the minimum setting to byte 1 in TS of $18 ( => byte 0 in spreadsheet ) means a minimum ID value of 192. Is this supposed to work that way?

What am I missing?
dontz125
 
Posts: 199
Joined: Mon Feb 22, 2010 10:27 pm

Re: CAN Broadcast parameters

Postby jbelanger » Sat Jul 21, 2018 12:10 am

That minimum value is what is needed to send a 29-bit message. It's been a long time since I've implemented this so I will have to check if this can be fixed simply by a new ini file which will allow also for 11-bit messages. By the way, this $18 comes from the SRR and IDE bits being both set to 1 for a 29-bit message.

And the 11-bit message is not located in bytes 2 and 3 but bytes 0 and 1 (please note that the byte numbering is done such that byte 0 is the highest byte and byte 3 is the lowest byte as shown in the MS CAN protocol document and the datasheet; I know that this is not how you would normally number the bytes but this is the case here to keep it consistent with the documents). It is located in the same location as the offset bit field higher than the SRR and IDE bits (which are both 0 for an 11-bit message) so you need to shift by 5 not 1. If you have a look at the spreadsheet again, you will see that the 11-bit message will be in bytes 0 ($BE) and 1 ($00) while the 29-bit message will be $00 $18 $0B $E0 which is what you were expecting except for the $18 needed for the 29-bit definition.

So I will have a look at the code to see if it is possible to simply change the ini to allow either 11 or 29 bit messages. If I remember correctly that should be the case but I need to make sure. And the spreadsheet is correct so you can rely on it if the 11-bit messages can be used with the current code (and once I provide a new ini).

Jean
Image
jbelanger
 
Posts: 3633
Joined: Sat Oct 03, 2009 12:24 pm
Location: Quebec, Canada

Re: CAN Broadcast parameters

Postby jbelanger » Sat Jul 21, 2018 12:34 am

Ok, I checked the code and it simply needs a new ini file. See attached. With this one you can do either 11-bit or 29-bit messages; you simply need to fill in the 4 bytes as per the spreadsheet.

Jean
Attachments
io_extender_11bit.ini
IOx ini file which allows 11-bit CAN broadcast
(283.08 KiB) Downloaded 13 times
Image
jbelanger
 
Posts: 3633
Joined: Sat Oct 03, 2009 12:24 pm
Location: Quebec, Canada

Re: CAN Broadcast parameters

Postby dontz125 » Sat Jul 21, 2018 8:44 am

And the 11-bit message is not located in bytes 2 and 3 but bytes 0 and 1
Yeah, I had that figured out; I got confused when 'Byte 1' refused to accept / allow a $00 value. :?

Ok - the new ini is allowing anything and everything put up by the spreadsheet. Thanks!

Heh - once I wrapped my brain around the fact that I was confusing myself with the byte 1 - byte 0 issue, the whole 'packing the ID' format also finally made sense.
Going from 0bxxxxx210 and 0b76543210 to 0b21076543 and 210RIRDD, where DD => DLC3 & DLC2 and everything after the 3 ID bits are all 0, took a bit of grasping, but it's one of those things where you stop and say, "Well of COURSE that's how it works!"

Ahhhh ... nuts. I think there's still a problem, or I'm still really confused. I just entered ID 1, which I *think* should be (unpacked) 0bxxxxx000 + 0b00000001 and (packed) 0b00000000 + 00100000 = $0020. The spreadsheet is telling me $0001. Like you said - dec to hex, then 5 RoL. Interestingly, Byte 2 & 3 for the 29-bit are $0002 for ID 1, which should translate to $0020 for an 11-bit.
dontz125
 
Posts: 199
Joined: Mon Feb 22, 2010 10:27 pm

Re: CAN Broadcast parameters

Postby jbelanger » Sat Jul 21, 2018 12:17 pm

You are indeed correct. I have posted the corrected spreadsheet in the post above. I actually had forgotten to do the shift (duh!!!).

Jean
Image
jbelanger
 
Posts: 3633
Joined: Sat Oct 03, 2009 12:24 pm
Location: Quebec, Canada

Re: CAN Broadcast parameters

Postby dontz125 » Sat Jul 21, 2018 3:37 pm

:D
dontz125
 
Posts: 199
Joined: Mon Feb 22, 2010 10:27 pm

CAN Broadcast parameters - Set-up Procedure

Postby dontz125 » Mon Jul 23, 2018 5:34 pm

To summarize the previous several many posts:

11-bit and 29-bit CAN Broadcast

ID number:
The 11-bit and 29-bit CAN ID is purely an identifying number. Unlike the 29-bit MS-CAN protocol, there is no inherent meaning or data value to the number. So long as all devices on the CAN-Bus understand and agree on what a particular ID number represents, the actual ID for a given data set can be anything within the range.

11-bit Setup:

1. Choose an ID number from 0-2047. Note that the MS3 has various predetermined 11-bit broadcast ID numbers. It is strongly advised to not use any of these IDs.
2. Using the CAN Broadcast Settings spreadsheet, enter the number into the CAN ID field. The spreadsheet will return the hexadecimal values corresponding to the different bytes in an 11-bit ID.
3. With an IOx project open in Tuner Studio, open [Extended Control] [CAN Broadcast], and select [Enable] in the "CAN Broadcast" drop-down box.
4. Decide which Frame (1-8) will transmit using the ID number chosen above, and activate it by selecting [Enable] in the "Activate" drop-down box for that frame. Enter the 4 byte values from step #2 above into the ID byte fields.
5. Specify which data byte(s) will be transmitted as part of this frame by choosing the starting field and the number of data bytes to be transmitted. Note that although the TS 'Start from' drop-down box has the fields arranged in alphanumerical order, the fields are actually made available per the [Output Channels] list in the .ini. Most fields are 2 bytes, while there are a few each of 1 and 4 bytes in length. The frame payload size setting determines how many data bytes are sent, which in turn selects how many data fields are transmitted.The data bytes are taken in consecutive order from the 'Start from' point.
e.g. If ad0 is selected as a start point and the payload size is set to 4 bytes, then ad0 (2 bytes) and ad1 (2 bytes) are sent as the payload of that frame. As the payload can be up to 8 bytes, it is possible that ad2 and ad3 could be made part of this frame. Since the data bytes must be consecutive, it is not possible to transmit ad0, ad6, and port2 in the same frame.


29-bit Setup:

1. The process is essentially identical to that described above, except that the upper limit noted in step 1 doesn't apply. The spreadsheet has a list of 29-bit message IDs used by various vendors. Wherever possible, avoid applying a known-used ID to your own frames.
2. Ensure to select the hexadecimal values provided by the spreadsheet in the 29-bit column to the IOx project in TS.
3. Using the 29-bit decode tab in the spreadsheet, ensure that the proposed 29-bit ID does not correspond to a 29-bit MS-CAN message that could cause corruption or data loss to the flash memory in the MS3 processor or other MS-CAN devices on the bus.
Attachments
io_extender_11bit.ini
This revised .ini is needed to broadcast 11-bit messages.
(283.08 KiB) Downloaded 7 times
CAN Broadcast Settings.xls
(25.5 KiB) Downloaded 14 times
dontz125
 
Posts: 199
Joined: Mon Feb 22, 2010 10:27 pm


Return to I/O Extender

Who is online

Users browsing this forum: No registered users and 2 guests

cron