Skip to main content
Topic: uCAN: A protocol stack for microcontroller networking (Read 135053 times) previous topic - next topic

Re: uCAN: A protocol stack for microcontroller networking

Reply #120
Quote
That only matters if the wire is terminated at one end with an Ethernet switch. Building wiring terminates with a patch panel, though, and there's no obligation to plug it into a switch - you can just as easily plug it into another wire, or into anything else.

Actually I was thinking more the other end, user have a nasty habit of just plugging their PCs/laptops into vacant RJ45 sockets expecting them to just work, many are now Gbit interfaces.

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #121
[quote author="Folknology"]
Quote
That only matters if the wire is terminated at one end with an Ethernet switch. Building wiring terminates with a patch panel, though, and there's no obligation to plug it into a switch - you can just as easily plug it into another wire, or into anything else.

Actually I was thinking more the other end, user have a nasty habit of just plugging their PCs/laptops into vacant RJ45 sockets expecting them to just work, many are now Gbit interfaces.

regards
Al[/quote]

Well, then the obvious solution would be to not have any CAN bus plugged in there when it's not in use - which would be a bad idea for termination reasons anyway. :)

Re: uCAN: A protocol stack for microcontroller networking

Reply #122
Quote
I've considered doing that, too. It would have other advantages, such as reducing the restrictions on bus length, even if you just repeat all messages to all segments. It's a lot more complicated, though.

Well the complexity will be more than just a few logic gates clearly and I have some ideas about getting the cost of that down given a simple enough Publish/subscribe events scheme. Compared to a simple CAN network or even one with simple repeaters it is more scalable. With just CAN or CAN + Repeaters the traffic adds up and congests making prioritisation and arbitration less and less effective. Although repeaters buy you greater length they also introduce other problems like delays or deadlocks. With an intelligent approach you effectively have more tools in the box to shape you network. That's what makes a smart approach more attractive to me personally.

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #123
[quote author="Folknology"]Well the complexity will be more than just a few logic gates clearly and I have some ideas about getting the cost of that down given a simple enough Publish/subscribe events scheme. Compared to a simple CAN network or even one with simple repeaters it is more scalable. With just CAN or CAN + Repeaters the traffic adds up and congests making prioritisation and arbitration less and less effective. Although repeaters buy you greater length they also introduce other problems like delays or deadlocks. With an intelligent approach you effectively have more tools in the box to shape you network. That's what makes a smart approach more attractive to me personally.[/quote]

It's definitely worth consideration - but it requires you to discard the super simple broadcast event system that things like VSCP use, which has a lot of attractive advantages. It also introduces issues with routing and discovery that could complicate the protocol a lot!

Do you have a rough sketch for how you'd like such a system to work?

Re: uCAN: A protocol stack for microcontroller networking

Reply #124
[quote author="nickjohnson"]Do you have a rough sketch for how you'd like such a system to work?[/quote]

Not really as such it's mostly in my head, one of the key requirements however would be a distributed publish and subscribe registry. This could exist on switches and or individual µC (segment master nodes).

regards
Al

 

Re: uCAN: A protocol stack for microcontroller networking

Reply #125
I think that when we have a first network working we can see some points that underestimated and other that not.

At this point it´s possible that and intelligent switch would be a very clever solution and his cost wouldn´t a problem. In my particular case with an intelligent repeater I can replace a hub or a switch because I have a lot of traffic that it´s only interesting to a stub or sub net of nodes and can be filter to the primary bus. With a ucontroller with two can ports I can use the filters in the stack to determine message forwarding. This is clean, simple and relatively cheap in cost and software. But I not know that this is appropriate in general.

Re: uCAN: A protocol stack for microcontroller networking

Reply #126
[quote author="nickjohnson"][quote author="magetoo"]Well, there are splitters for running two 100Mbit Ethernet connections over one cable, but I don't know if using those would be a good idea.  Of course, if one wanted to go that route, we should do the exact opposite of what I said previously, and standardize on the two Ethernet pairs, so that there is cheap adapters available.  On the other hand, it wouldn't be that hard or expensive building your own either.[/quote]
That doesn't seem unreasonable, actually. Being able to reuse existing cabling is good.[/quote]
As long as one is making own hardware in the form of nodes, and putting RJ45 connectors on those, building one's own splitters doesn't seem too much of a step.  Especially if there's going to be some custom PoE-like adapter involved anyway.

Quote
[quote author="magetoo"]I don't know about the CAN RJ45 pinout you mention since I want to go with something custom, but according to Wikipedia, PoE can run on the same cable pairs Ethernet uses for signalling, simultaneously.  I don't see why we couldn't duplicate that.  (I was thinking straight up 48V without the complicated handshake though.)
We can't really do that because of the way CAN works - there's no obvious way to piggyback power on the data pair, especially with it having 60 ohm termination between + and -![/quote]
PoE can use a (non-obvious?) scheme where each pair is also one conductor for the power side.  With two pairs, you have power and ground, while differential signalling on those pairs is also simultaneously used for data.  That's what I had in mind.  That might mean running the CAN network without a ground, the implications of which I'm not sure about.  But I don't see why it wouldn't work - how complicated it will be to build, and how much of the Ethernet design one can reuse is the question.


Regarding repeaters and topologies and such; interesting stuff.  Nothing to add except I hope it's still going to be simple and cheap.  :-)

Re: uCAN: A protocol stack for microcontroller networking

Reply #127
[quote author="magetoo"][quote author="nickjohnson"][quote author="magetoo"]Well, there are splitters for running two 100Mbit Ethernet connections over one cable, but I don't know if using those would be a good idea.  Of course, if one wanted to go that route, we should do the exact opposite of what I said previously, and standardize on the two Ethernet pairs, so that there is cheap adapters available.  On the other hand, it wouldn't be that hard or expensive building your own either.[/quote]
That doesn't seem unreasonable, actually. Being able to reuse existing cabling is good.[/quote]
As long as one is making own hardware in the form of nodes, and putting RJ45 connectors on those, building one's own splitters doesn't seem too much of a step.  Especially if there's going to be some custom PoE-like adapter involved anyway.[/quote]

Using ethernet pairs would allow running both Ethernet and CAN on the same wires, though, with a standard splitter at both ends.

Quote
Quote
[quote author="magetoo"]I don't know about the CAN RJ45 pinout you mention since I want to go with something custom, but according to Wikipedia, PoE can run on the same cable pairs Ethernet uses for signalling, simultaneously.  I don't see why we couldn't duplicate that.  (I was thinking straight up 48V without the complicated handshake though.)
We can't really do that because of the way CAN works - there's no obvious way to piggyback power on the data pair, especially with it having 60 ohm termination between + and -!
PoE can use a (non-obvious?) scheme where each pair is also one conductor for the power side.  With two pairs, you have power and ground, while differential signalling on those pairs is also simultaneously used for data.  That's what I had in mind.  That might mean running the CAN network without a ground, the implications of which I'm not sure about.  But I don't see why it wouldn't work - how complicated it will be to build, and how much of the Ethernet design one can reuse is the question.[/quote]

CAN doesn't actually use differential signalling (or transformer isolation); it uses a pair with an impedance of 60 ohms and relies on current flow through the terminator to establish a reliable signal. I don't think there's a way you can piggyback power on that.

Re: uCAN: A protocol stack for microcontroller networking

Reply #128
[quote author="nickjohnson"]Using ethernet pairs would allow running both Ethernet and CAN on the same wires, though, with a standard splitter at both ends.[/quote]
We're in agreement there.  But I don't believe that will save much (work, money) in practice, perhaps we're coming at this from different perspectives.

Quote
CAN doesn't actually use differential signalling (or transformer isolation); it uses a pair with an impedance of 60 ohms and relies on current flow through the terminator to establish a reliable signal. I don't think there's a way you can piggyback power on that.
I'm trying to see what you're getting at, but I'm kind of lost.  Are you saying that the nodes sense the current that is going through the bus, not the voltage?  Would be grateful if you would explain where exactly things would fail.

Re: uCAN: A protocol stack for microcontroller networking

Reply #129
[quote author="magetoo"][quote author="nickjohnson"]Using ethernet pairs would allow running both Ethernet and CAN on the same wires, though, with a standard splitter at both ends.[/quote]
We're in agreement there.  But I don't believe that will save much (work, money) in practice, perhaps we're coming at this from different perspectives.

Quote
CAN doesn't actually use differential signalling (or transformer isolation); it uses a pair with an impedance of 60 ohms and relies on current flow through the terminator to establish a reliable signal. I don't think there's a way you can piggyback power on that.
I'm trying to see what you're getting at, but I'm kind of lost.  Are you saying that the nodes sense the current that is going through the bus, not the voltage?  Would be grateful if you would explain where exactly things would fail.[/quote]

The nodes sense the voltage on the CANH and CANL lines, relative to each other and ground - they're still ground referenced, so not truly differential.


Re: uCAN: A protocol stack for microcontroller networking

Reply #131
[quote author="nickjohnson"]The nodes sense the voltage on the CANH and CANL lines, relative to each other and ground - they're still ground referenced, so not truly differential.[/quote]
As I have understood things, in a (Hi-speed) CAN network, nodes can fall back to comparing with ground in the event that one of the CANx lines is faulty, but the whole thing works just fine without it, and is designed to operate primarily by sensing a differential on the CANx lines.  That's how you get the noise immunity after all.

For the things I have in mind (indoors, non-critical), I don't really see the need for the level of fault tolerance that would come with having a signal ground line there as backup.  And if one of the CANx lines is gone, the other probably is too..

Re: uCAN: A protocol stack for microcontroller networking

Reply #132
[quote author="magetoo"][quote author="nickjohnson"]The nodes sense the voltage on the CANH and CANL lines, relative to each other and ground - they're still ground referenced, so not truly differential.[/quote]
As I have understood things, in a (Hi-speed) CAN network, nodes can fall back to comparing with ground in the event that one of the CANx lines is faulty, but the whole thing works just fine without it, and is designed to operate primarily by sensing a differential on the CANx lines.  That's how you get the noise immunity after all.

For the things I have in mind (indoors, non-critical), I don't really see the need for the level of fault tolerance that would come with having a signal ground line there as backup.  And if one of the CANx lines is gone, the other probably is too..[/quote]

You're probably right, but I'm still not sure how you'd provide power over CAN. The drivers typically drive the CAN lines between their ground and +5v rails; how would you transport power over the same lines with standard CAN interfaces?

Re: uCAN: A protocol stack for microcontroller networking

Reply #133
I think that magetoo propouse use the other pair of the RJ-45 to power device, not the same wires. A friend need to use one RJ45 for ethernet, 12 volt and CAN and all work OK for three years. It´s dirty, but works.