question

clay123 avatar image
clay123 asked

Can I use a long cable run from CCGX to DMC ?

Hi everyone,

I am currently in the process of designing a system and wanted to know if a 120m run for a CAT5e cable from the CCGX to the DMC would be alright?

The reason for this long run is that the system will be situated in the storage room 100m away from the main house. This area currently has unreliable network/internet connection, so the decision was to have the monitoring system hardwired into the main house for ease of system access.

The system consists of a 5kVA Multiplus II, charge controller, CCGX and gel batteries.

Any advise or suggestions would be much appreciated.

Multiplus-IICCGX Color ControlmonitoringDigital Multi Controlrj45 cable
1 comment
2 |3000
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

matthias-nagel avatar image matthias-nagel commented ·
As you may see from the different answers below some discussion went on wether it works or not. It really depends on the communication protocol. For Ethernet it won't work, for VE.Bus it will most likely work. Hence, it all depends on where you plan to plug the Cat 5e into. If you look at the manual of the CCGX, you will find that the CCGX provides several RJ-48 connectors which all use Cat 5e as cable type, but provide different communication protocols. I recommend to update yot your question as this information is crucial for a proper answer.
0 Likes 0 ·
2 Answers
Michelle Konzack avatar image
Michelle Konzack answered ·

Ethernet cable can not be longer the 100m under best conditions.


Better buy a set of Media-Converter (FiberOptic Singel Mode to Ethernet) for 20€ from www.aliexpress.com and an appropriated Outdoor FiberOptic cable (e.G. www.fs.com) which can be as long as 20km...

4 comments
2 |3000
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

dennibu avatar image dennibu commented ·

Ich stimme dem zu. Mit Glasfaser haben Sie auch kein Problem mit möglichen Verzögerungen oder Blitzeinschlägen und Überspannungen im Nachhinein.

0 Likes 0 ·
Show more comments
matt1309 avatar image
matt1309 answered ·

Hi @Clay123

Not a concrete answer but just sharing something that might help. I've not used a DMC before so not sure what type of connection it uses. If the connection protocol is TCP/IP, then 100m tends to be the limit of what most cables note. You may get away with it with high quality shielded cable but can't imagine it's guarantied.

If it's Ve.CAN protocol which I think is just built on normal CAN bus then I've seen comments on here noting that 200m is fine as long as termination resistors are installed.

And for longer runs using high quality shielded cable is recommended. I'll share some old posts I've seen regarding Ve.CAN communication:

Maximum length for VE. Can - Victron Community (victronenergy.com)


5 comments
2 |3000
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

matthias-nagel avatar image matthias-nagel commented ·
If the connection protocol is TCP/IP, then 100m tends to be the limit of what most cables note. You may get away with it with high quality shielded cable but can't imagine it's guarantied.

The limiting factor is not electromagnatic interference, and hence even optimtal shielding won't help you to overcome the 100m limit. The 100m-limit is dictated by the Ethernet frame format (56bit of preamble), the collision detection algorithm CSMA/CD, the clockrate (125 MBd for Fast Ethernet) and the speed of light.

In short: The sender "allocates" the wire by sending out a 56bit 0/1 meander. One must ensure that the first bit reaches the receiver, before the sender has tranmitted the last (i.e. 56th) bit of that meander. Given the clock rate one can calculate the time which the sender requires to sent out all 56 bits, and how far the first bit has been travelling during that time period. You end up with something about 102m. No shielding will change that fact.

0 Likes 0 ·
matt1309 avatar image matt1309 matthias-nagel commented ·

Hi @Matthias Nagel

Thanks for that technical info. Apologies i assumed it was shielding that these companies used to get longer than 100m.

This company seem to have pulled off ethernet (IP) longer than 100m. (not tested but heard good things).

GameChanger Cable | Datacom Solutions (paigedatacom.com)

Might be an option if the DMC does use that protocol, I don't know enough about CAN/Ve.CAN to comment on if it'll help with that also if that is what DMC uses.


0 Likes 0 ·
matthias-nagel avatar image matthias-nagel matt1309 commented ·

Yes, it is possible to extend an Ethernet connection beyond the 100m limit. It might work (if Ethernet traffic is low enough). But it is not recommended at all, out of specification and a lot of unpredictable things may happen.

Ethernet uses Twisted Pair cables as a shared medium. I.e. only one party is allowed to send a frame at once otherwise a "collision" may occur.

Here is an analogy from real-world traffic: Imagine a single lane which is shared by vehicles in both direction. At every moment of time, traffic can either run from A to B or B to A, but not both or otherwise the vehicles will crash somewhere in the middle. Now, someone installs traffic lights at both ends which either permit traffic from A to B or vice versa. This means the single lane is a one-way lane with alternating directions. (A typical setup on construction sites.) When one traffic light switches from green to red, the other traffic light must not switch from red to green immediately. There must be a delay during which both traffic lights are red such that the last car which has entered the single lane on one side gets a chance to exit the lane on the other side, before the first car enters the single lane from the other direction. (Cars are "digital bits" in this case). Obviously, the delay in traffic light switching must be chosen in accordance to speed limit and length of the lane.

Now, what happens if you exceed the 100m limit for Ethernet? If both parties decide to start trasnmitting at the same time, then they might put an Ethernet frame onto the wire without noticing that the opposite party does the same. The Ethernet frames will "collide" in the middle and annihilate each other.

If Ethernet traffic is low, the chance of having two Ethernet frames on the wire at the same time might be low. In terms of the analogy above: If the construction site is in a rural area with low to none car traffic, the chance for two cars to meet in the middle of the single lane are low, too.

If you use TCP which provides reliable transport on top of Ethernet, you have something which is called "acknowledgement and re-sending". (This doesn't work for real cars though.) Hence, if a collision has occured and the sending party notices that no acknowledgement comes back, it will re-send the packet again. With some luck, it will go trough this time. (Unless the opposed party tries to re-send its packet at the same time again.) Luckily, timeout for resending is randomized. However, resending of lost packets increases the traffic and thus may increase the chance for collisions. But for some amount, TCP might be able to compensate for lost packages.

In summary: I would never do it. Even if it works for a certain use case now, it might not work later if you add more to the system, the protocol changes or whatever. This ugly hack will shoot back at you sooner than later.

However, VE.Bus is not Ethernet-based. So everything said is rather off-topic.

0 Likes 0 ·
matthias-nagel avatar image matthias-nagel matthias-nagel commented ·

Addendum: The connection is not Ethernet-based, but uses VE.Bus which in turn is based on RS485. So any considerations regarding the 100m-limit imposed by Ethernet are obsolete. See my comment on the other answer above.

0 Likes 0 ·
matt1309 avatar image matt1309 matthias-nagel commented ·
Sorry i should've specified TCP/IP when sharing that cable link.

My only use cases for ethernet cable have been TCP/ip and RS485 so i forget other might use it for something else.


0 Likes 0 ·