Numerous oscillating power supplies ??

Discussion in 'C-Bus Wired Hardware' started by robj, Feb 3, 2006.

  1. robj

    robj

    Joined:
    Aug 3, 2004
    Messages:
    19
    Likes Received:
    0
    Location:
    Meath, Ireland
    I have been through the hoops with a network that has comms problems [1]. I'll open a post in hardware as previous one was toolkit/cgate.

    I bought a network analyser which has confirmed that i have a comms problem. However, the analyser gives inconsistent results i.e. The "add burden" LED flashes on (3 secs) and then off (9 secs). I have a burden on the network.

    When I add another burden the analyser flashes "Remove burden" LED.

    The analyser reference book says that "it is likely that oscillation exists on the network power supplies" and that an oscillascope will help find the source.

    I figured I could issolate the dodgy power supply by splitting up the network. However, I get a the same result from all power supplies. Even when the only thing on the network is the dimmer with supply, the anaylser and a burden.

    I even get the same result on units I had working when I was on the cbus course about 18 months ago.

    Has anybody had to do this before ?

    [1] http://www.cbusforums.com/forums/showthread.php?t=1958
     
    robj, Feb 3, 2006
    #1
  2. robj

    Newman

    Joined:
    Aug 3, 2004
    Messages:
    2,203
    Likes Received:
    0
    Location:
    Adelaide, South Australia
    The results from the Network Analyser can be very misleading when used on a tiny network. It works better when there's several units and a decent length of cable in the system. If all you have is an output unit and a PCI joined by 300mm of cable then I'd take the Network Analyser readings with a pinch of salt.

    Make sure you have 1 and only 1 burden in the system. Watch out for the hardware burdens, sometimes the heatshrink extends a little too far down the RJ Jack and can prevent the pins from making a proper connection.

    If you have a key input unit handy then I suggest that you use Learn Mode to associate the input unit to the output unit. If these two will communicate reliably then that suggests that your problem is not network comms quality.
     
    Last edited by a moderator: Feb 3, 2006
    Newman, Feb 3, 2006
    #2
  3. robj

    JasonCox

    Joined:
    Aug 17, 2004
    Messages:
    75
    Likes Received:
    0
    I had something sort of similar once and it was caused by water getting into the 750wp sensors, which weren't sealed properly on the top of the unit against the wall.

    The water had corroded the terminals and was playing games with the bus.
     
    JasonCox, Feb 3, 2006
    #3
  4. robj

    robj

    Joined:
    Aug 3, 2004
    Messages:
    19
    Likes Received:
    0
    Location:
    Meath, Ireland
    Thanks Newman. Replies below.

    I have also tried the analyser with a bigger network. 3 inputs & 6 outputs over about 100m of cable. Same result :mad:
    Thanks. Had that gotcha covered :)
    I have done that already and it works fine. I can't scan the network with the Toolkit though.
    Jason, how did you trouble shoot this ? Sounds like a nighmare to find.
     
    robj, Feb 3, 2006
    #4
  5. robj

    Don

    Joined:
    Aug 4, 2004
    Messages:
    429
    Likes Received:
    0
    Location:
    Townsville, Australia
    learn is pretty thorough

    It's good to know that "Learn" works. The Learn procedure is pretty thorough in that it tests the network for the presence of a clock, checks the burden, and tests communication. Only if all three tests pass, then the procedure will enter and do the flashing of alternate LEDs.

    The first test is for clock present. It will fail if either no clock is present or if two or more clocks are attempting to be active simultaneously and result in an invalid waveform. If a valid clock is not found, then the output unit which is used to enter learn will attempt to change the state of it's clock generation in case this fixes the problem. The unit waits quite along time between changes, so the Learn entry can take over a minute.

    The second test is burden. The initiating unit tries to send a broadcast message. If it either gets no acknowledgement, or if it gets any negative acknowledgement from any unit, it will change the state of its burden. This might still leave some burdens present, or it might leave the network without burdens, but in either case, another transmission is attempted, and if it is now successful, the unit will leave the burdens in the new condition; otherwise it will always turn off the burden (and indicate the failure).

    Once the clock and burden are sorted out (which guarantees at least one successful commmunication), the unit will issue a Learn command on the bus, and will enter the alternating "learn" mode flash.

    All of the communications required to enter learn must be sent within defined time limits, and no high-level retries will occur (toolkit will re-try sending some messages if they fail the first time), so the network must be in pretty good shape for it to pass.

    If the PC interface was present throughout the learn process and you are still having problems scanning the network, I would NOT suspect network comms, irrespective of what the network analyser might say, because clearly communication must be possible.

    Don
     
    Don, Feb 6, 2006
    #5
Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.