Announcement

Collapse
No announcement yet.

Idle Packets: Do they exist?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Idle Packets: Do they exist?

    To all,

    I hate contradictions which is the reason for this post.

    I have read that some systems, when having no new information to transmit, send idle packets which were defined as regular packets with no instruction byte(s).

    I have also read that when there are no new instructions to send, the command station will simply transmit already sent packets to keep the track supplied with power. The key in this paragraph is that we are talking about real, full length packets.

    So my question is: Do Idle Packets Exist?

    Thanks in advance,

    Bob Guercio

  • #2
    Bob - I will be the first to admit I don't know the details of DCC, but if there are instructions to reverse some condition, for example something like "reverse current direction", these instructions couldn't be sent out repeatedly just because there was nothing else to do.

    Idle packets would make more sense to me. Another way of doing it would be to enter a "marking" state when idle, not really sending packets but just sending the bare minimum, like all zeroes or something.

    Is your glass half empty or half full .. or just too big?
    Which box am I susposed to think outside of?

    Comment


    • #3
      quote:



      Bob - I will be the first to admit I don't know the details of DCC, but if there are instructions to reverse some condition, for example something like "reverse current direction", these instructions couldn't be sent out repeatedly just because there was nothing else to do.



      id=quote>id=quote>

      Agreed but I don't believe that "reverse" instructions exist. As an example, there are instructions for the locomotive to go forward or to go backwards but there is not an instruction to reverse direction.
      Bob Guercio

      Comment


      • #4
        quote:


        I have read that some systems, when having no new information to transmit, send idle packets which were defined as regular packets with no instruction byte(s).


        I have also read that when there are no new instructions to send, the command station will simply transmit already sent packets to keep the track supplied with power. The key in this paragraph is that we are talking about real, full length packets.



        id=quote>id=quote>Bob,
        NMRA Standards and Recommended Practices precisely define valid DCC packets. See:

        http://www.tttrains.com/nmradcc/index.html

        The latest proposed revisions are at:

        http://www.tttrains.com/nmradcc/draf...rdsandrps.html

        S-9.1 states:


        quote:


        The baseline method for providing the power to operate locomotives and accessories, which shall be supported by all Digital Command Stations and Digital Decoders, is by full-wave rectification of the bi-polar NMRA digital signal within the Digital Decoder. To facilitate this form of power transmission, bits must be sent continuously, in order to maintain power to the Digital Decoders.(emphasis added.)


        id=quote>
        id=quote>
        The bits sent continuously by an NMRA DCC command station in the baseline signal either make up a validly defined NMRA DCC packet or they do not. There is no in between. An "idle" packet is by definition a valid packet. A sequence of bits that does not comply precisely with the definitions for a valid DCC packet is not an NMRA DCC packet of any kind, it is just part of the baseline power signal and will be ignored by a decoder. Bits but not packets are required to "keep the track supplied with power."

        NMRA S-9.2 provides:


        quote:


        Digital Decoder Idle Packets ... are optional for Command Stations, and required for decoders.

        * * *

        A three byte packet, whose first byte contains eight "1"s, whose second byte contains eight "0"s and whose third and final byte contains eight "1"s, is defined as a Digital Decoder Idle Packet. Upon receiving this packet, Digital Decoders shall perform no new action, but shall act upon this packet as if it were a normal digital packet addressed to some other decoder.


        id=quote>
        id=quote>

        Also,

        quote:


        Packets sent to Digital Decoders should be repeated as frequently as possible, as a packet may have been lost due to noise or poor electrical conductivity between wheels and rails.
        * * *

        Manufacturers of decoders are encouraged to provide automatic conversion for a variety of power signals and command control formats in addition to the NMRA digital signal, provided that automatic conversion to these alternate power signals can be disabled. If automatic conversion is enabled, Digital Decoders must remain in digital mode and not convert to using any alternate power signal so long as the time between Packet Start Bits is less than or equal to 30 milliseconds in duration. If automatic conversion is disabled, Digital Decoders must remain in digital mode regardless of the timing of Packet Start Bits. It shall be possible to configure Digital Command Stations to transmit at least one complete packet every 30 milliseconds as measured from the time between packet start bits.



        id=quote>
        id=quote>If a DCC decoder stops receiving DCC packets and power conversion is enabled, it will revert to DC operation. (A possible runaway?). As stated in S-9.2 at Fn. 11:

        quote:


        Some DCC decoders manufactured prior to the NMRA standards require a valid baseline packet be received every 30 milliseconds to prevent analog power conversion.


        id=quote>
        id=quote>

        Hence the need for packets even when no new instructions are sent.
        Tom Sz.



        Check out:



        http://groups.yahoo.com/group/DCC-Sound/



        http://groups.yahoo.com/group/Zimo-DCC/

        Comment


        • #5
          You would have to have some means of decoding DCC packets to a computer screen to be sure but I imagine that the idle packet is implemented. As Thomas mentioned you have to keep feeding decoders with valid DCC packets to keep them in DCC mode. If they stop seeing valid DCC packets they will revert to DC if they are enabled for power conversion otherwise they go into some failsafe mode and wait for a valid packet. Under most conditions a command station will resend the last valid command it recieved from each throttle just as a failsafe to make sure the message got through. However if the system has just been powered up, or if you have released all your locomotive to throttle assignments what will the command station send then? Idle packets, I presume.

          It is a bit of a misnomer to say that either DCC bits or packets are required to provide power to a DCC decoder. If the track voltage is greater than about 5 V and of either polarity, the decoders on the layout are receiving power. If this wasn't true, decoders could not operate on DC layouts. Purely from a power standpoint a DCC system could "park" the track voltage at 14 V DC (or whatever track voltage you run on your system) when it had nothing new to send and all the decoders would be powered up. Of course any that were enabled for conversion to DC power would take off at full speed and the rest would drop out of DCC mode (and coast to a stop I believe) but they would receive power. This would be a stupid thing to do but philosopically it is neither the bits nor the packets but the fact the track voltage is always (except for brief transitions between the two) at + or - 14 V (or whatever track voltage that you use) that provides power to the decoders.

          Even though the NMRA verbiage says otherwise, DCC bits and packets are "merely" an agreed upon protocol for sending information over the rails.

          Ken

          Edited by - khutch on 04/08/2002 09:38:49

          Comment

          Working...
          X