Can't get correct CAN ID from CAN shield V2
![userHead](https://dfimg.dfrobot.com/dfPortrait2.png)
I use two pieces of DFR0370
https://wiki.dfrobot.com/CAN-BUS_Shield_V2__SKU__DFR0370_
When I send a message with the following code, the CAD ID on the other end is always 0x1AA
What is the reason? How do I send it with the correct ID 0x1B0201AA?
code:
//------------------------------------------------------------------------------------------------------------------
if(CAN.sendMsgBuf((0x1B0201AA), 0, 8, LED_Config)==CAN_OK)
{
Serial.println("(m)0x1B0201AA LED_Config:");
for(int i=0;i< sizeof(LED_Config);i++)
{
Serial.print(LED_Config[i],HEX);
Serial.print("\t");
}
Serial.println();
Serial.println();
}
Just double checked the GitHub, I noticed that the shield also support to send the extend data frame.
You could also try to change this parameter into 1, to see if it support 0x1B0201AA as it's canID.
The extend data frame support the 29-bit CAN identifier, so it could range from 0~0x1FFFFFFF
![userHeadPic](https://dfimg.dfrobot.com/dfPortrait2.png)
At first, I thought the problem was that you were passing in arguments that were outside the scope of the parameter definition.Because your CAN id is a hexadecimal 1B0201AA, this is a large number that may exceed the data format defined by the CAN id parameters in the source code.
But after I checked the souce code posted on the GitHub.
https://github.com/DFRobot/DFRobot_MCP2515
I thought that the CAN id was define as a 32bit int format in the function you called up.
![](https://dfimg.dfrobot.com/nobody/makelog/0475605e555c578731f2e849ab72db08.png)
And then we could get back to the sendMsg() function in the first picture.
But in sendMsg(), the function that actually sends the CAN message is mcpWritecanMsg(), the others are basically functions that handle timeout exceptions.
So I gotta trace to the mcpWritecanMsg() function, what a tough job🤣. But luckly, these function name and parameters are all straightforward.
And in the mcpWritecanMsg() function, finally we called up the mcpWriteid()function to send the CAN id out.
And at here, the canID is still as a private member parameter, which is defined as a 32 bit int
![](https://dfimg.dfrobot.com/nobody/makelog/2c142e1689ddd8a247f8ac8a6a2cf3dd.png)
The 32-bit int data ranges from -2147483648 to 2147483647. And your 0x1B0201AA is 453116330 as decimal format.
So it's not a matter of parameter definition in the code.
On the contrary, I think the sample library file presented by DFRobot is well written.
Then I realized if it's the limitation of the CAN open protocal?
And I had found this artical about the CAN open:
https://copperhilltech.com/blog/controller-area-network-can-bus-tutorial-extended-can-protocol/
Here it metioned the standard format(which is the CAN shield used) only support the 11-bit identifier.
In another word, the standard format CANid could only ranges from 0x00~0x7FF
And then I checked the datasheet of the onboard chip MCP2515 to confirm my guess.
Here is the datasheet: https://www.dfrobot.com.cn/images/upload/File/DFR0370/20160406122457ihx0zy.pdf
You could see that the chip only reserve 11-bit to the canID
So you could try to set your CAN id in the range of 0x00~0xFF to see if it could solve your problem.
![userHeadPic](https://dfimg.dfrobot.com/dfPortrait2.png)