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

Support for More Than 255 Devices on CAN #5

Open
sAlexander opened this issue Apr 20, 2020 · 3 comments
Open

Support for More Than 255 Devices on CAN #5

sAlexander opened this issue Apr 20, 2020 · 3 comments
Labels

Comments

@sAlexander
Copy link

(Feature request for consideration)

With an 8 bit identifier, that leaves 256 possible device addresses, minus 1 for the reserved source/destination of 255. For many systems, this is more than sufficient. But for some, this may be a frustrating limit. In fact, the CanOpen documentation for PV applications mentions that "A PV system may consist of much more networked devices than 127". This is especially true in IoT applications, where there can be many, many devices (think: an office building).

Could ThingSet allow (but possibly not require) for more devices? Did you consider any schemes for more devices in the creation of ThingSet? Any other considerations?

@martinjaeger
Copy link
Contributor

I'm not sure if it's easily possible to physically attach more than 256 devices to one bus as each driver also adds a bit of capacitance to the bus. And if we need gateways and different bus sub-sections anyway, they might also be able to route the packages somehow...

But there is another very interesting standard written by the maintainer of the Zephyr CAN subsystem: 6LoCAN, which is basically lightweight IP protocol over CAN. This could be a suitable lower layer for ThingSet aswell instead of the custom protocol with a CAN identifier similar to SAE J1939.

The 6LoCAN could even run in parallel to CANopen on the same bus, as CANopen uses standard identifier length and 6LoCAN (like ThingSet) uses the extended identifier. The standard ID has higher priority, so control tasks could be implemented in CANopen, but slower interactions with a user interface using ThingSet via own protocol or 6LoCAN.

@sAlexander
Copy link
Author

You're right about the physical limit of the can bus. From this Q&A: "However the practical
physical limit of nodes is about 110 units per bus." It's not clear to me what baud rate was used for that statement; I would imagine that decreasing the baud rate would allow for an increased number of physical attachments.

One additional consideration: A single physical transmitter could represent multiple device addresses. For example, a hub that allows for the connection of many devices, or a single device with several somewhat independent units, such as an array of LEDs.

@sAlexander
Copy link
Author

Also, 6LoCAN looks fantastic! I'm part way through the standard, and will continue reading. Thank you for sharing.

With regards for device addressing, it seems that 6LoCAN uses a 14 bit identifier, which allows ~16,000 devices, though some of the identifiers are reserved. 0x3DEF - 0x0100 is the valid range for node ids, which would support 15599 unique ids (calculation).

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

2 participants