Package jmri.jmrix.dcc4pc
Class Dcc4PcSensorManager.ActiveBoard
java.lang.Object
jmri.jmrix.dcc4pc.Dcc4PcSensorManager.ActiveBoard
- Enclosing class:
- Dcc4PcSensorManager
-
Field Summary
FieldsModifier and TypeFieldDescription(package private) int(package private) int(package private) Dcc4PcBlockLocos(package private) int(package private) int(package private) int(package private) Dcc4PcRawDecoder(package private) String(package private) boolean(package private) int(package private) int(package private) int(package private) static final long(package private) HashMap<Integer,Dcc4PcSensor> (package private) HashMap<Integer,Dcc4PcReporter> (package private) int(package private) int[](package private) booleanTrue after the board stopped answering at all, until a reset succeeds again.(package private) static final long(package private) long(package private) static final longHow long after a POM packet is seen a POM answer that follows another packet to the same loco is still credited to that POM packet's CV.(package private) boolean(package private) int(package private) boolean(package private) boolean(package private) long(package private) long(package private) static final intHow many cutouts to a loco, starting with the one after the first POM packet for a new CV, may still carry the decoder's previous answer and so aren't credited.(package private) static final intA new input state is only shown once it has lasted this many packets in a row, so a one-packet glitch (seen: orientation B with garbage data on a block holding a loco without RailCom) doesn't reach the sensors, reporters or loco tracking.(package private) boolean(package private) static final longGoing unoccupied must also last this long.(package private) String -
Constructor Summary
Constructors -
Method Summary
Modifier and TypeMethodDescription(package private) void(package private) voidaddReporter(int port, Dcc4PcReporter reporter) (package private) voidaddSensor(int port, Dcc4PcSensor sensor) (package private) voidGive up on a speed change that never got an answer, so polling can start at 8 kbps.(package private) void(package private) voiddecodeDCCPacket(int[] packet) (package private) voiddecodeDCCPacket(int[] packet, long now) (package private) boolean(package private) voidForget the POM packets seen so far, after packets were lost to an overflow.(package private) String(package private) String(package private) int(package private) int(package private) Dcc4PcReportergetReporterAtIndex(int i) (package private) Dcc4PcSensorgetSensorAtIndex(int i) (package private) String(package private) booleanisSynced()(package private) voidDecode one Get Data reply and update the sensors and reporters.(package private) voidrequestResync(String reason) Stop decoding and ask the reader to start its Raw encoding stream again.(package private) voidSend another Reset Encoding State unless one is already waiting for its reply.(package private) voidresetReplied(boolean ok) The reader answered a Reset Encoding State.(package private) voidForget the old link state and change speed again from 8 kbps, after the port was reopened.(package private) voidCalled 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.(package private) voidsetAddress(int address) (package private) voidsetDescription(String description) (package private) voidsetDoNotPoll(boolean poll) (package private) voidsetEnabledInputs(List<Integer> enabled) (package private) voidspeedCheckDone(boolean ok) The Get Info that follows a speed change has been answered or has failed.
-
Field Details
-
inputs
int inputs -
encoding
int encoding -
version
-
description
-
address
int address -
failedRequests
int failedRequests -
doNotPoll
boolean doNotPoll -
inputPorts
-
inputReportersPorts
-
decoder
-
synced
-
resetPending
-
blockLocos
-
STATE_DEBOUNCE_PACKETS
A new input state is only shown once it has lasted this many packets in a row, so a one-packet glitch (seen: orientation B with garbage data on a block holding a loco without RailCom) doesn't reach the sensors, reporters or loco tracking. At about 70 packets a second this adds roughly 15 ms.- See Also:
-
UNOCCUPIED_HOLD_MS
Going unoccupied must also last this long. A loco crossing a block gap or dirty rail drops out for a moment (seen: J5 unoccupied and back three times in half a second), and each drop would otherwise remove its RailCom tags from the block.- See Also:
-
speedChecked
-
speedPending
-
lostContact
True after the board stopped answering at all, until a reset succeeds again. -
speedStarted
-
failedResets
int failedResets -
busSpeed
int busSpeed -
FIRST_SPEED_RETRY
- See Also:
-
MAX_SPEED_RETRY
- See Also:
-
speedRetryDelay
long speedRetryDelay -
nextSpeedRetry
-
addr
int addr -
dcc_addr_type
int dcc_addr_type -
cvNumber
int cvNumber -
speed
int speed -
lastDCCPacketSeen
int[] lastDCCPacketSeen -
POM_ANSWER_WINDOW
How long after a POM packet is seen a POM answer that follows another packet to the same loco is still credited to that POM packet's CV. Answers normally come 160-270 ms after the packet.- See Also:
-
STALE_CUTOUTS
How many cutouts to a loco, starting with the one after the first POM packet for a new CV, may still carry the decoder's previous answer and so aren't credited. Usually only the first does, but the decoder can take longer, or the reader can miss a POM packet (2026-10-16: 1.1.284 was given CV 283's value once with 1).- See Also:
-
-
Constructor Details
-
ActiveBoard
ActiveBoard(int address, String version, int inputs, int encoding)
-
-
Method Details
-
setAddress
-
addFailedRequests
void addFailedRequests() -
clearFailedRequests
void clearFailedRequests() -
setDoNotPoll
-
doNotPoll
boolean doNotPoll() -
addSensor
-
getEncodingAsString
-
setDescription
-
getSensorAtIndex
-
getNumEnabledSensors
int getNumEnabledSensors() -
addReporter
-
getReporterAtIndex
-
setEnabledInputs
-
isSynced
boolean isSynced() -
requestResync
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
void resendResetIfNeeded()Send another Reset Encoding State unless one is already waiting for its reply. -
checkSpeedTimeout
void checkSpeedTimeout()Give up on a speed change that never got an answer, so polling can start at 8 kbps. -
speedCheckDone
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
The reader answered a Reset Encoding State.- Parameters:
ok- true if it was accepted
-
restartAfterReconnect
void restartAfterReconnect()Forget the old link state and change speed again from 8 kbps, after the port was reopened. -
retrySpeedIfDue
void 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
void 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
-
decodeDCCPacket
Decode the DCC packet a RailCom cutout followed: setsaddr,dcc_addr_typeandcvNumber.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,
cvNumberis the CV of the last POM packet seen for it, if that was withinPOM_ANSWER_WINDOW.Except the first
STALE_CUTOUTScutouts 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 bytesnow- the current time in ms
-
getInputs
int getInputs() -
getDescription
-
getVersion
-