Class Dcc4PcSensorManager.ActiveBoard

java.lang.Object
jmri.jmrix.dcc4pc.Dcc4PcSensorManager.ActiveBoard
Enclosing class:
Dcc4PcSensorManager

  • Field Details

  • Constructor Details

  • Method Details

    • setAddress

      void setAddress(int address)
    • addFailedRequests

    • clearFailedRequests

    • setDoNotPoll

      void setDoNotPoll(boolean poll)
    • doNotPoll

      boolean doNotPoll()
    • addSensor

      void addSensor(int port, Dcc4PcSensor sensor)
    • getEncodingAsString

    • setDescription

      void setDescription(String description)
    • getSensorAtIndex

    • getNumEnabledSensors

    • addReporter

      void addReporter(int port, Dcc4PcReporter reporter)
    • getReporterAtIndex

    • setEnabledInputs

      void setEnabledInputs(List<Integer> enabled)
    • isSynced

      boolean isSynced()
    • requestResync

      void requestResync(String reason)
      Stop decoding and ask the reader to start its Raw encoding stream again. Decoding resumes once the reader acknowledges the Reset Encoding State.
      Parameters:
      reason - why, for the log
    • resendResetIfNeeded

      Send another Reset Encoding State unless one is already waiting for its reply.
    • checkSpeedTimeout

      Give up on a speed change that never got an answer, so polling can start at 8 kbps.
    • speedCheckDone

      void speedCheckDone(boolean ok)
      The Get Info that follows a speed change has been answered or has failed.
      Parameters:
      ok - true if the board answered at the new speed
    • resetReplied

      void resetReplied(boolean ok)
      The reader answered a Reset Encoding State.
      Parameters:
      ok - true if it was accepted
    • restartAfterReconnect

      Forget the old link state and change speed again from 8 kbps, after the port was reopened.
    • retrySpeedIfDue

      Called from the poll loop: if a speed change fell back to 8 kbps (often because track power was still off), try 62.5 kbps again once the retry time has come.
    • processRawReply

      Decode one Get Data reply and update the sensors and reporters. Called on the packet processor thread, in the order the replies arrived.
      Parameters:
      r - the reply
    • forgetPomPackets

      Forget the POM packets seen so far, after packets were lost to an overflow. A lost packet may have been a newer POM packet, so a later answer may be for a CV we never saw; crediting it to the last one seen would give that CV the wrong answer (2026-10-15). Answers count again from the next POM packet seen.
    • decodeDCCPacket

      void decodeDCCPacket(int[] packet)
    • decodeDCCPacket

      void decodeDCCPacket(int[] packet, long now)
      Decode the DCC packet a RailCom cutout followed: sets addr, dcc_addr_type and cvNumber.

      A decoder may answer a POM packet in the cutout after a later packet to it, not the POM packet itself. With only one loco in the command station's refresh that is nearly always the case (2026-10-15: the answer to "write CV 31" followed a speed packet). So after any packet to a loco, cvNumber is the CV of the last POM packet seen for it, if that was within POM_ANSWER_WINDOW.

      Except the first STALE_CUTOUTS cutouts to the loco from the first POM packet for a new CV: there the decoder may still send its previous answer (2026-10-16, ESU LokSound 5: usually exactly one stale cutout). Crediting them gave every CV the value of the one read before. After an overflow, any POM packet counts as new, as a newer one may have been lost.

      Parameters:
      packet - the DCC packet bytes
      now - the current time in ms
    • getInputs

      int getInputs()
    • getDescription

    • getVersion