<r> response and timing issue.

DCCEXParser.cpp

@@ -78,8 +78,8 @@ Once a new OPCODE is decided upon, update this list.
   P, Write DCC packet
   q, Sensor deactivated
   Q, Sensor activated
-  r, Broadcast address read on programming track
-  R, Read CVs
+  r, Read cv on main (Railcom)
+  R, Read CVs response r
   s, Display status
   S, Sensor configuration
   t, Cab/loco update command
@@ -1427,7 +1427,7 @@ void DCCEXParser::callback_R(int16_t result)
 
 void DCCEXParser::callback_r(int16_t result)
 {
-    StringFormatter::send(getAsyncReplyStream(), F("<r MAIN %d %d %d >\n"), stashP[0], stashP[1], result);
+    StringFormatter::send(getAsyncReplyStream(), F("<r %d %d %d >\n"), stashP[0], stashP[1], result);
     commitAsyncReplyStream();
 }
 

DCCWaveform.cpp

@@ -168,6 +168,10 @@ void DCCWaveform::interrupt2() {
         // cutout has ended so its now possible to poll the railcom detectors
         // requiredPreambles is one higher that preamble length so
         // if preamble length is 16 then this evaluates to 5
+        // Remember address bytes of last sent packet so that Railcom can
+        // work out where the channel2 data came from.
+        railcomLastAddressHigh=transmitPacket[0];
+        railcomLastAddressLow =transmitPacket[1];
         railcomSampleWindow=true;
       } else if (remainingPreambles==(requiredPreambles-3)) {
         // cutout can be ended when read
@@ -234,13 +238,6 @@ void DCCWaveform::promotePendingPacket() {
         return;
       }
     
-    if (isMainTrack) {
-      // Remember address bytes of last sent packet so that Railcom can
-      // work out where the channel2 data came from.
-      railcomLastAddressHigh=transmitPacket[0];
-      railcomLastAddressLow =transmitPacket[1];
-    }
-    
     if (packetPending) {
         // Copy pending packet to transmit packet
         // a fixed length memcpy is faster than a variable length loop for these small lengths

Railcom.cpp

@@ -20,7 +20,9 @@
  */
 
 /** Sections of this code (the decode table constants) 
- * are taken from openmrn under the following copyright.
+ * are taken from openmrn
+ *  https://github.com/bakerstu/openmrn/blob/master/src/dcc/RailCom.cxx
+ * under the following copyright.
  * 
  * Copyright (c) 2014, Balazs Racz
  * All rights reserved.

Release_Notes/Railcom.md

@@ -48,4 +48,20 @@ Making use of Railcom data
       EITHER - The leaving loco enters another railcom block
       OR     - only ONE loco remains in the block just left.
 
+      To further support block management in railcom, two additional serial commands are available
+
+      `<K block loco >` to simulate a loco entering a block, and trigger any ONBLOCKENTER
+      `<k block loco >` to simulate a loco leaving a block, and trigger and ONBLOCKEXIT
+
+
+   Reading CV values on MAIN.
+
+      Railcom allows for the facility to read loco cv values while on the main track. This is considerably faster than PROG track access but depends on the loco being in a Railcom monitored block. 
+
+      To read from prog Track we use `<R cv>` response is `<r value>` 
+
+      To read from main track use `<r loco cv>`
+        response is `<r loco cv value>`  
+
+