How do I calculate the CAN arbitration ID right?

[RT_1979]

Hello Again!

From my partner firm I got a scheme to calculate the extended arbitration ID. The bits are devided like this:

- 6 bit 5bit 1bit  3bit   4bit  5bit  5bit

The values got to be in decimal:

- 32-31-0-1-0-0-1

I figured out the following arbit.ID in Hex, but it seems to be wrong:

107C4001

This happend with the attached ID.

Whts wrong?

[GPIB_Guru]

From your description, that is the same arb ID that I get. How do you know it it wrong? With NI-CAN, you need to OR in an extra bit to indicate that it is an extended ID (ID1 extended is different than ID1 standard).

[RT_1979]

Sorry but what do you mean with:

"Or in an extra bit???"

can you please explain it for a dummy!

Yes, i am pretty sure about the problem, that the arbit. ID is wrong, because I  already tried all wiring possibilities ect.

thanks for further proposals

RT

[GPIB_Guru]

If you look in the NI-CAN manual for ncWriteNet.vi (which is the VI that you use to place a frame on the bus):

ArbitrationId: Specifies the arbitration ID to transmit in the CAN data frame. A standard ID (11-bit) is specified by default. In order to specify an extended ID (29-bit), OR in the bit mask 20000000 hex.

So, the special bit is 0x20000000. Sorry that I didn't spell it out to you enough. I just assumed that you had the manual and could look it up and I was giving you a pointer.

[DirkW]

Hi,

In order to have the NI CAN driver sending an extended ID, you have to set the 30th bit. This tells the driver you wish to transmit a 29 bit ID.

This can be done if you or your ID with 0x20000000. See the modified example attached.

If you receive a 29 bit extended ID the driver will set the 30th bit to inform you about the extended format. That looks in your case like this 0x307C4001.

DirkW

[RT_1979]

Thanks, now i got it!

I tried it and my boss told me to measure the bitcode with an osciloscope:

I sent the adress(before OR):

107C8001

as far as I can count, this is equal to the bit-array

1000 0011 1110 0100 0000 0000 0000 1

but the measured signal was:

1011 1110 0000 1000 1101 1111 0111 1101 1111 0011 0111 0001 0101 0010 0001

the data field was empty, so what the h... did this d. ... card send??????

P.S.: 1 means ~2.2V differential voltage....

[GPIB_Guru]

I tried to analyze your trace, but I don't see how it can be correct. Here is what I would expect to see (now, I could be wrong, but this is based on my calculations)
With your original ArbID of : 107C4001

SOF              29-bit ARB ID
 0    1 0000 0111 1100 0100 0000 0000 0001

But, the 29-bit protocol states that you send the 1st 11-bits followed by SRR and IDE (both recessive)     
SOF  1st 11-bits    SRR IDE   Remaining 18-bits
0    100 0001 1111   1      1    00 0100 0000 0000 0001

But, we need to account for bitstuffing (5 consecutive identical values results in an additional bit, deliniated with a ^ under it in my image),
so I would expect to see the following on a scope:
SOF  1st 11-bits      SRR IDE   Remaining 18-bits
0    100 00011 11101   1   1    00 0100 00010 0000 10001
            ^     ^                        ^       ^

What you saw was:
1011 1110 0000 1000 1101 1111 0111 1101 1111 0011 0111 0001 0101 0010 0001

<< Remove Bitstuffing >>
1011 111  0000  000 1101 1111  111 11 1 1111  011 0111 0001 0101 0010 0001

<< Compress, Assume you skipped the SOF and sent a 29-bit arb id >>
101 1111 0000    0   0   0 1101 1111  111 11 1 1111  011 0111 0001 0101 0010 0001
 1st 11 bits    SRR IDE   

SRR and IDE are both dominate, which violates the CAN spec for a 29-bit id. This could be an 11-bit ID, which would have SRR and IDE both dominate to send a data frame. However, afterwards you have r0 and DLC which should be recessive and <=8 respectively, which are really dominate and 13.

<< Compress, Assume you skipped the SOF and sent a 29-bit arb id >>
101 1111 0000    0   0   0 1101 1111  111 11 1 1111  011 0111 0001 0101 0010 0001
 1st 11 bits    SRR IDE  r0  DLC


So, I think you have either misinterpreted the scope or did not capture the entire transfer.

[RT_1979]

Hello Guru!

Thanks for bitshuffling and the time you spent on my problem!

I think i didn`t skip the SOF...

Further I did not leave out anything, or count wrong( see the attached picture)!

I did not realy get the part with dominant/recessive SSR IDE, as they are not listed in my arbitration calculation:

1. 6 bit reserved: 32

2. 5 bit sender adress: 31

3. 1 Errorbit

4. 3 bit Accestype: 1 for write date /2 for read data

5. 4 bit frame number: here 0

6. 5 bit Version: 0

7. 5 bit receiver adress: 1

I cant merge this with the standard ext. arbit. ID style.....

Further Ideas?

[GPIB_Guru]

The bus should be in the recessive state first.. It must be there for 11 clock cycles before a transfer can start and then there should be a negative edge (1->0) for the SOF bit. Looking at your picture, you triggered on the positive edge which probably missed the first few transactions. Can you try to capture it again with an inverted trigger pattern (falling edge)? And then we can do the re-analysis.

The SRR and IDE follow the first 11-bits of the arbitration ID in the 29-bit arbitration ID scheme to allow them to "play nicely" with the 11-bit IDs on the bus.

[RT_1979]

Now I measured again, setting the "orbit", and what I got is this:

1011 1010 0000 (1) 0010 010 1 0010 1111 1(0)110 0110 1110 1110 1001 01111

The brakets  are the bits from bitstuffing, i hope.

What do you mean by 11 clock cycles? As I have 4 micro seconds for one bit (250 kilobaud) does that mean 440 micro seconds??

Thanks so far...

P.S.: I am pretty sure I got the start.....