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

Re: uCAN: A protocol stack for microcontroller networking

Reply #270 –
[quote author="nickjohnson"][quote author="Folknology"]Also by designating those pins for upstream downstream detection in the standard also rules out there use for other possibilities.

(In our case we may use them for power in certain situations)[/quote]

5v power, or more cores for 12-24V power? To avoid issues with galvanic coupling, if one pin of a pair is going to be used for power, the other one should be too (and for the same rail!)[/quote]


Most likely pin3 +Vaux and 6 GND, for low powered segments +Vaux could be +5v and for higher power then +CAN supply, both of these would fit well enough with current wiring.

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #271 –
[quote author="Folknology"][quote author="nickjohnson"][quote author="Folknology"]Also by designating those pins for upstream downstream detection in the standard also rules out there use for other possibilities.

(In our case we may use them for power in certain situations)[/quote]

5v power, or more cores for 12-24V power? To avoid issues with galvanic coupling, if one pin of a pair is going to be used for power, the other one should be too (and for the same rail!)[/quote]


Most likely pin3 +Vaux and 6 GND, for low powered segments +Vaux could be +5v and for higher power then +CAN supply, both of these would fit well enough with current wiring.[/quote]

I'd strongly suggest using both 3 and 6 for an additional supply, and using the existing ground wires. Otherwise you're back to shorting out magjacks if accidentally plugged into one.

Re: uCAN: A protocol stack for microcontroller networking

Reply #272 –
Yeah you may be right, it would be safer

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #273 –
[quote author="Folknology"]OK updated my design and for the upstream socket I have tied pin 6 to the uCan supply and pin 3 to ground. On the downstream connector I have tied pin 3 to uCan supply and pin 6 to ground.

regards
Al[/quote]

How do you disable the termination on this design?

Re: uCAN: A protocol stack for microcontroller networking

Reply #274 –
Well one would add bidirectional switches on the termination resistors and drive them with a wired OR (2 diodes) and a FET probably (Not shown on the circuit). However we are questioning the idea about active termination, as it adds a burden on the spec. I am likely not to use it at all and will probably revert to manual termination.

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #275 –
Ok. I thought your schematic was final, and I didn't see any switches to remove the 60ohm resistors.

Re: uCAN: A protocol stack for microcontroller networking

Reply #276 –
Just to clarify, here is my final version, it uses manual termination via a plug in terminator on the 4 pin header (or line termination). The 4 pin header is also useful for testing both signal and lazy connections to bench based can devices.

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #277 –
My notifications seem to be acting up, missed a lot of the conversation. I'm not arguing in favor of any particular way to do things, I'd just like to offer some datapoints about how we went about some of the stuff mentioned;

- Power: we used both "RJ45" (8P8C) and "RJ9" (4P4C) connectorts: devices used the 4-wire RJ9 (CanH, CanL, Gnd, 24V) only, "hubs" used RJ45 (CanH, CanL, 3xGnd, 3x24V) as backbone, RJ9 as "branches" for devices. Power on each RJ9 branch is limited to 0.4A by a PTC resettable fuse. Hubs have their own DC inputs - if it's energized, an intenal relay routes that to supply 24V to devices and the downstream backbone. If it isn't, the power incoming from the upstream backbone passes through.

- Termination: both device ports are equivalent (connected 1:1 in parallel), a simple jumper connects a 120 Ohm terminator between CanH and CanL if fitted. Obviously, we remove it from everywhere except the end of the line. We may move on to resistors crimped directly into RJ9 plugs to phase them out.

- Addressing: using 8 bits as address, we have a convention that 1-127 are unicast / individual addresses, 128 is broadcast (all devices have one of their filters set to listen to that), and 129-255 are "group addresses" - any device can be configured to listen to several of those (depending on how many filters are left available after the one for the unicast address and the other for the broadcast one), ie. a device can be set up as "member" of group, say, 130, 151 and 200 - sending any command to any of those is executed _and_ replied to by all group members simultaneously. CAN arbitration sorts out the ensuing storm of replies. Zero is reserved as the address all unconfigured devices come with, although our network doesn't really care specifically.

- Bulk data: I'm sure there will be valid uses for that, but I wouldn't expect streaming audio to be one of them. Believe it or not we actually tried that at one point, and at 125Kbaud the band was _just barely_ enough to carry a _mono_ stream of GSM-codec-encoded voice stream. To put it differently - we deride 128kbps mp3s today, but 125kbaud won't even get anywhere near that in actual data throughput...

Re: uCAN: A protocol stack for microcontroller networking

Reply #278 –
The maximum throughput of the CAN bus is <49% of the bitrate (50% overhead plus interframe spacing). So at 1 Mbps you could more than likely manage a 128kbps stream depending on the priority and contention.

Edit: CAN FD has a max effective bitrate of about 4Mbps, if you had something like the XMOS chips you could do a high speed hub<->hub connection.

Re: uCAN: A protocol stack for microcontroller networking

Reply #279 –
I have had a long hard think about using those spare pins for power, I think the best thing we can do that is safe for Ethernet and means we get some kind of benefit is to connect both pins 3 and 6 to ground. This has a few advantages:

1) It should be safe for Ethernet as the there is no potential difference across magnetics
2) It helps on the power side by reducing line losses on the return path
3) It helps reduce noise picked up on those lines
4) It doesn't add any galvanic interference
5) It makes routing of these pins simpler on PCBs
6) It reduces ground resistance

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #280 –
[quote author="bharrisau"]The maximum throughput of the CAN bus is <49% of the bitrate (50% overhead plus interframe spacing). So at 1 Mbps you could more than likely manage a 128kbps stream depending on the priority and contention.[/quote]
Ah, sure, I was just assuming we're talking about the 125Kbaud speed that has been talked about earlier, which gives you some range. Faster speeds reduce maximum cable length rather quickly "building size" (VSCP quotes ~25m for 1Mbaud - less of a problem for short-ish "hub-connected" segments, of course).

Re: uCAN: A protocol stack for microcontroller networking

Reply #281 –
[quote author="Folknology"]I have had a long hard think about using those spare pins for power, I think the best thing we can do that is safe for Ethernet and means we get some kind of benefit is to connect both pins 3 and 6 to ground. This has a few advantages:

1) It should be safe for Ethernet as the there is no potential difference across magnetics
2) It helps on the power side by reducing line losses on the return path
3) It helps reduce noise picked up on those lines
4) It doesn't add any galvanic interference
5) It makes routing of these pins simpler on PCBs
6) It reduces ground resistance

regards
Al[/quote]

None of those points are especailly compelling. Keep them reserved for now, a good use for them may present itself once the rest has been sorted out and products are actually using the pins.

I've just summaried the VSCP events. 6-bits for the uCAN subtype (VSCP type) is enough to support all the currently defined VSCP classes.
There are 34 currently defined VSCP classes, 7-bits for the uCAN type field allows ~41% of the VSCP classes to keep their original number. And the 7-bit means 73% of the address space is available.

From that, I think the best use of the 18bits in the ID field would be 7 bits for the type, 6 bits for the subtype and 5 bits for the zone/topic (defined by the type). That alows for 32 zones - I haven't used zones before in anything, but I think for the target audience 32 should be heaps.

I know this is only a tiny change from your 7-7-4, but the 7 for subtype will probably go to waste (based on the work VSCP has done), and 16 feels a lot smaller than 32.

Re: uCAN: A protocol stack for microcontroller networking

Reply #282 –
[quote author="bharrisau"][quote author="Folknology"]I have had a long hard think about using those spare pins for power, I think the best thing we can do that is safe for Ethernet and means we get some kind of benefit is to connect both pins 3 and 6 to ground. This has a few advantages:

1) It should be safe for Ethernet as the there is no potential difference across magnetics
2) It helps on the power side by reducing line losses on the return path
3) It helps reduce noise picked up on those lines
4) It doesn't add any galvanic interference
5) It makes routing of these pins simpler on PCBs
6) It reduces ground resistance

regards
Al[/quote]
None of those points are especailly compelling. Keep them reserved for now, a good use for them may present itself once the rest has been sorted out and products are actually using the pins.
[/quote]

Well (1) is a given as we need that for safety, (2) is extremely important for efficiency for network powered devices (the bulk) this provides about 25% reduction.(3,4) Its always good to improve SNR by reducing noise and interference, (5) makes the layout more approachable for designers, (6) this is always a good idea.

Any alternative requires treating the two pins as one because we cannot have any potential difference (1), thus it's really just 1 pin. In order to make best use of that copper i.e. by using both cores then power is the obvious application, it has to be at the same potential, thus ground is therefore the safest and most efficient choice. It benefits all devices on the network. Also remember CAN has had spare/reserved pins for over a decade, guess what they never got used, they just got wasted!! I say put that expensive copper to use, there is no advantage to leaving them fallow.

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #283 –
Quote
Any alternative requires treating the two pins as one because we cannot have any potential difference (1), thus it's really just 1 pin. In order to make best use of that copper i.e. by using both pins then power is the obvious application, it has to be at the same potential, thus ground is therefore the safest and most efficient choice. It benefits all devices on the network. Also remember CAN has had spare/reserved pins for decades, guess what they never got used, they just got wasted!! I say put that expensive copper to use, there is no advantage to leaving them fallow.

Not quite true - they can't be used for anything with a persistent DC level and a low impedance. That doesn't rule out using them as separate signal conductors; it just makes them poorly suited to carrying different power rails.

Re: uCAN: A protocol stack for microcontroller networking

Reply #284 –
[quote author="nickjohnson"]
Quote
Any alternative requires treating the two pins as one because we cannot have any potential difference (1), thus it's really just 1 pin. In order to make best use of that copper i.e. by using both pins then power is the obvious application, it has to be at the same potential, thus ground is therefore the safest and most efficient choice. It benefits all devices on the network. Also remember CAN has had spare/reserved pins for decades, guess what they never got used, they just got wasted!! I say put that expensive copper to use, there is no advantage to leaving them fallow.

Not quite true - they can't be used for anything with a persistent DC level and a low impedance. That doesn't rule out using them as separate signal conductors; it just makes them poorly suited to carrying different power rails.[/quote]

I stand corrected, however the benefits I believe out way the disadvantages.

regards
Al