m10k
commented
1 year ago Hey @ghubmlafontaine,
thank you for the feature request! This seems like something other users will be interested in as well, so I will implement this in the next few weeks.
I'm thinking about implementing this by adding a rate-detection interface state to canny. When an interface is in this state, canny will behave as described in [1]:
- Put the socketCAN interface in listen-only mode
- Set the bus speed to the start value (probably 500kbps, since it's a typical setting)
- Wait for a message or bus error
- Received a message -> go to 6
- Received a bus error -> switch to next bus speed, goto 3
- Bus speed found, disable listen-only mode on socketCAN interface
When started with auto-speed (the short and long options will probably be -a and --detect-bus-speed or something like that), canny will first put all interfaces in rate-detection state. Interfaces will be placed in normal state once the bus speed has been found. If an interface is in normal state and starts receiving a lot of bus errors, the bus speed likely has changed, so it is placed in rate-detection mode.
There are also smarter methods that work by measuring the bit-timing on the transceiver, but this is not something I can do from user-space through Linux's socketCAN API (and I'm not sure if it's even possible from kernel space without hardware support).
Best regards
References
[1] https://www.can-cia.org/fileadmin/resources/documents/proceedings/2003_koppe.pdf
Environment:
CAN-over-IP tunnel Connect two CAN buses over an IP network, start canny on two different machines like the following example. Start a canny server on machine A is Canny Server (let's assume its IP is 10.0.0.1): $ canny -p 1234 Then, start canny as a client on machine B now a Canny Client: $ canny -c 10.0.0.1 -p 1234 Now, messages received on any CAN interfaces on machine A will be forwarded to all CAN interfaces of machine B, and vice-versa. Again, messages will not be forwarded between different CAN interfaces of the same machine.
Feature
It is a feature and a question at the same time… Maybe the speed already ajusts at connection time.
Add a command line parameter that will instruct canny to test and adjust the CAN bus speed of its CAN controller bus as sensed on the bus.
Use case
In some case, we use CAN bus tools(Canny Server A) that monitor different remote equipements (Canny Client B).
A self speed adjusting CAN bus on the Canny Server A would allow us to change and swap the Server side tool and not to worry about the various default speed they use as some of them are old equipment at lower speed.
A self speed adjusting CAN bus on the Canny Client B would allow us to move and connect the little RPi from CAN bus to Can bus and not to worry about the various default speed they use on their respective bus.
We trust the TCP network will play its role and transparently provide a transparent buffering of the communication between the two ends with no regards on their respective speed.
Right now, the CAN bus speed is determined by either the default or the explicit speed value provided to the MCP2515 Controller at the initiation of the drivers. In my application it is 500 kbps. It works most of the time but there are exception at 200k and new device are coming out at 1meg. For example I would like to be able to start canny like this: $ canny –as –p 12334 where –as would mean autospeed $ canny –as -c 10.0.0.1 -p 1234 where –as would mean autospeed
In that case, canny would adapt to the actual CAN bus speed: 200k 500k, 1M or whatever detected on the interface…