Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Standard frames are cut at 10th bit, instead of 11th #1689

Open
IrisCrimson opened this issue Nov 13, 2023 · 4 comments
Open

Standard frames are cut at 10th bit, instead of 11th #1689

IrisCrimson opened this issue Nov 13, 2023 · 4 comments
Labels

Comments

@IrisCrimson
Copy link

Describe the bug

If standard frames are tried to send, the can id is cut at the 10th bit instead of 11th bit

To Reproduce

send a message with can id 0x7FF (any data), and set the property is_extended_id to False -> at the can output the id is set to 0x3FF instead of 0x7FF.

Expected behavior

id must be 0x7FF

Additional context

OS and version: Raspbian GNU/Linux 11 (bullseye)
Python version: 3.9.2
python-can version: 4.2.2
python-can interface/s (if applicable):

Traceback and logs
def func():
    return "hello, world!"
@zariiii9003
Copy link
Collaborator

Can you provide more information? Which interface do you use for sending? And how do you receive the message?

@IrisCrimson
Copy link
Author

IrisCrimson commented Nov 13, 2023 via email

@zariiii9003
Copy link
Collaborator

@lumagi Could you take a look at this? I'm a Windows user 😬

@lumagi
Copy link
Collaborator

lumagi commented Nov 16, 2023

This might be a tricky one to debug :D

I have several questions:

  • You're using the python-can SocketCAN interface, right?
  • Do you have a sample code?
  • How do you set up your device? (ip link ....)?
  • Which kernel version are you using?
  • Did you also encounter this behavior in the past? Or did it happen after an update?
  • Does it also happen if you use cansend to send the frame?
  • Can you send me the output of lsmod?
  • can you see the incorrect CAN ID only on the CerboGx or also on the Pi when you use candump?

If you're really using SocketCAN, then my guess is that this is a problem with the MCP2515 kernel driver. If it was with python-can or the generic SocketCAN code, we would have probably heard about it more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants