Announcement

Collapse
No announcement yet.

LV direct burial splices

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #16
    We do a lot of control work in various capacities, but I still can't get over the fact this sounds like terrible design using a direct buried control cable with direct buried splices.

    I always ask myself when something gets way out in left field, is this standard procedure or am I trying to reinvent the wheel?

    The only way I could even feel a little good about something like this, is if it was in conduit and spliced in a vault/handhole with DB or submersible rated splices.

    But to each their own, hopefully a few years down the road you aren't wondering why you're not getting any signals from your devices.

    Comment


      #17
      We do a lot of control work in various capacities, but I still can't get over the fact this sounds like terrible design using a direct buried control cable with direct buried splices.

      I went for 1-Wire because of the variety of inexpensive sensors available, and I need the "reach" given lengths from the building. (I am not going to even consider mounting the electronics out in the woods near the wells, and getting power and telemetry to/from same.)

      The constraints/issues I see are:

      a) The sensors are going to be buried because the well lines will be.
      b) The wells & their lines are buried to limit the thermal losses from the piping back to the compressors.
      c) The issue of the stub lengths and the signal degradation they cause.

      IF we were to put buried conduit and junction boxes near the surface, then we could dig down to each splice box for repairs. But getting down to the wells themselves to replace failed sensors is another issue. One solution there is to over-deploy sensors, so you can lose a few and not suffer that badly. I do plan to split them between the three available loops with such losses in mind.

      Comment


        #18
        Open Neutral:
        I did not say it was RS232 or 185 (whatever that is).
        Sorry, fatfingered RS-485 there. But you started talking 1200 vs. 9600 Baud, and I don't know how they relate to 1-Wire performance. It has one standard speed, and an optional "overdrive" of ~10X that.
        The Dallas 1-wire system at a minimum can work with 2 wires, common and data/power. Overall I think it is a better system when it is 3 wire with data and power separated.

        The Dallas 1-wire communication is asynchronous serial data in a half duplex mode on a single unbalanced bidirectional bus at some predefined baud rate. Because a single bus is used only one communication path in one direction can exist at one time. When data and power are combined, then only one of power or data can exist at a time.
        I think I can use one common power for all three channels; I'll look into that. (i.e. 3 pairs of CAT5 for 3 channels; power on both of 4th pair.) As I said, there's no need for speed on this tasking, an update every 5-10 minutes would be more than enough.
        But RS 232 is not good for long cable lengths, nor is 1-wire. RS 422 is much better on long cables.
        But the supply of direct RS 422 temperature probes is far more constrained; I've not seen any. And re: noise, this is not inside a steel mill with arc furnaces; it is out in the woods. The bridge manufacturer talks of 1000 ft. runs. (BTW, as far as I know, Dallas sold everything 1-Wire to Maxim some time ago.)
        You definitely want to stick with the base bit rate (to some extent bit and baud can be treated the same, but when doing so bit can not be considered as data bit rate).
        Turns out the Embedded bridge *can* do overdrive with some low-level commands but I neither need nor want same.
        If a bus cable, connection to the bus, or the sensor fails how will you fix the failure?
        Do without or dig it up.

        Comment


          #19
          Originally posted by Open Neutral View Post

          Do without or dig it up.
          Assuming it fails in a way that does not disable the data bus!

          Comment


            #20
            Originally posted by GoldDigger View Post
            Assuming it fails in a way that does not disable the data bus!
            Hence three buses.

            Comment

            Working...
            X