I hear people say the program on the main in "Ops mode" and I also read in the NMRA standard about Service mode vs Operations mode. Is "Ops Mode programming" a topic that is addressed in the NMRA standard? Or is it something decoder companies have introduced outside what is documented on the NMRA site?
Ops Mode was something I first saw in my Digitrax manual, but maybe I first encountered it in a post by Randy because he was as active in answering DCC questions back when I first joined as he is today (thankfully...). In discussions about programming, most seem to understand what it means. Some call it "programming on the main", meaning full power to the rails and not on a diminished/limited voltage programming track isolated from the rest of the tracks on the layout. POM/Ops Mode are the same thing where, under full power to the rails, a selected/designated decoder is targetted for a CV input change. Usually this is a locomotive put out to pasture with the others, but it being addressed or acquired on the throttle means only that designated decoder will effect the changes you wish.
https://nmra.org/sites/default/files/s-9.2.3_2012_07.pdf
The above clearly states that Service Mode is on a separate track and used to test or to manipulate decoders. So, it's not Ops Mode or POM.
Ops Mode is mentioned and detailed in the instruction below:
https://nmra.org/sites/default/files/s-9.3.2_2012_12_10.pdf
Thanks very much. I had never looked at 9.3.2.
Basic Question: When programming on the main, can you only have one loco on the main? The packet structure in the Service Mode (which I'm more familiar with) doesn't contain any decoder address.
No. Read 9.3.2. Ops Mode is directed to a specific loco address. Unless you send the commands to address 00, which is the broadcast address, only the addressed loco will respond to Ops Mode programming instructions. It will not program all locos on the track - outside of using address 0. Service mode WILL program anything connected to the programmign outputs - on some systems this IS the same connections as the main track and so service mode does require removing all locos from the track, or otherwise isolating a section of track from the rest of the layout. Service mode is always broadcast.
--Randy
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
passenger1955 Thanks very much. I had never looked at 9.3.2. Basic Question: When programming on the main, can you only have one loco on the main? The packet structure in the Service Mode (which I'm more familiar with) doesn't contain any decoder address.
Think of POM or Ops Mode, they're the same thing, as targetting one decoder, even though others are active on the same powered rails. You have an SW8 which you have previously addressed as 908 because that happens to be the number decaled on the cab side. If you select Ops Mode and change V-Start in CV2 to anything other than what it currently is, only the decoder active on your paddle will be changed when you press 'enter'. If that was locomotive 908, it will make the double scoot and let you know it took the change. If you forget and had locomotive 1245 active on the throttle, you have a D'Oh!! moment, but you can undo it and get the correct address and change it.
On the other hand, in Service or Paged Mode, they broadcast the changes to all addresses, so any other locos getting power from the rails will change their CV values at the same time as the change you entered in the decoder in locomotive 908...or any other active decoder getting power at the time. If you think mis-addressing in Ops Mode is a pain, imagine having six active decoders making the came CV2 change the instant you effect it by pressing enter for locomotive 908 in Paged Mode, or Servicing! Every locomotive on the layout getting power will do its scoot and you'll have to change every one of them back again....except this time you'll remember to enter Ops Mode first.
Great. I'm learning a lot here.
So thumbing through S 9.3.2, it seems like the packet structure for programming on the main is more related to the structure for sending a RailCom signal than it is to the Service Mode direct methods described in 9.2.3. Is that correct?
It's all piggy-backed on the extended packet format, which has enough spare opcodes to add extra features. RailCom came much later, but since this time someone was thinking and didn;t just say "hey, we have 4 features we want to add, so let's use 2 bits to select them" and instead went with more bits so there would be space for future add-ons without coming up with yet another packet format to try and fit within the existing specs. The way they piggybacked extra features on in general does not require the older decoder not supporting the feature to do anything with the newer packets. It may do odd things, like the headlight on/off with the wrong speed steps configured, but it generally runs. Only the newer decoder supporting the newer feature has to specifically decoder the extra bits and decide what to do. It's all pretty neat that they made it work - if only they had set *A* standard for long vs short addressing....
Randy, I'm glad you mentioned the Long Address thing.
So the basic structure for packets is:
{preamble} 0 [ AAAAAAAA ] 0 {instruction-bytes} 0 EEEEEEEE 1
Is the basic structure for long addresses like this?
{preamble} 0 [ 00AAAAAA ] [ AAAAAAAA ] 0 {instruction-bytes} 0 EEEEEEEE 1
The first address byte contains 8 bits of address information. If the most significant bits of the address are "11"and the remaining bits are not “111111”, then a second address byte must immediately follow. This second address byte 70 will then contain an additional 8 bits of address data. When 2 bytes of address information are present they are separated by a "0" bit. The most significant bit of two byte addresses is bit 5 of the first address byte. (bits #6 and#7 having the value of "1" in this case.
So maybe I need to change this to:
{preamble} 0 [ 11AAAAAA ] [ AAAAAAAA ] 0 {instruction-bytes} 0 EEEEEEEE 1
Although DCC Wiki (Extended Address Range) has two zeros in their examplehttp://www.dccwiki.com/Address_Range
That is because the first byte cannot be $FF. Any combination is possible as long as it doesn't equal that value. That is why the largest address cannot be larger than $27FF. If bits 6 and 7 are set to 11, the decoder knows that it will be an extended address, and bit 5 (value 2) is the MSD for the address.
However there are also other reserved ranges - by just this part of the standards, an address of 11111110 11111111b would be valid - all bits of the first byte are NOT 1, and the first two bits are 11. That would be address 16127 decimal.
The old explanation of CV17 and CV18 used to involve all the calculations, dividing by 256 and taking the modulus and all that stuff. Now sites I look at have come around to the simple explanation - convert the address to binary, set the two highest bits (left) to 1s, and then divide it into two 8 bit chunks. Left 8 bits is CV17, right 8 bits is CV18. Much simpler then dividing and using modulus math.
address 1234 = 0000010011010010, change left 2 bits = 1100010011010010
break into 2 parts: 11000100 11010010 convert back to decimal 196 210
rrinker No. Read 9.3.2. Ops Mode is directed to a specific loco address. Unless you send the commands to address 00, which is the broadcast address, only the addressed loco will respond to Ops Mode programming instructions. It will not program all locos on the track - outside of using address 0.
No. Read 9.3.2. Ops Mode is directed to a specific loco address. Unless you send the commands to address 00, which is the broadcast address, only the addressed loco will respond to Ops Mode programming instructions. It will not program all locos on the track - outside of using address 0.
I have used the same address for more than one loco in locos that have both a motor decoder and a sound decoder because my NCE system does not handle advanced consisting well in such circumstances.
Rich
Alton Junction