NTP over DRM: http://hireme.geek.nz/NTP.html - NTP

This is a discussion on NTP over DRM: http://hireme.geek.nz/NTP.html - NTP ; NTP over DRM: http://hireme.geek.nz/NTP.html...

+ Reply to Thread
Results 1 to 11 of 11

Thread: NTP over DRM: http://hireme.geek.nz/NTP.html

  1. NTP over DRM: http://hireme.geek.nz/NTP.html


  2. Re: NTP over DRM: http://hireme.geek.nz/NTP.html

    Max Power wrote:
    > NTP over DRM: http://hireme.geek.nz/NTP.html



    I've just looked at the DAB and DRM specifications, and they both allow the
    time to be broadcast.



    --
    Steve - www.digitalradiotech.co.uk - Digital Radio News & Info

    Find the cheapest Freeview & DAB prices:
    http://www.digitalradiotech.co.uk/fr..._receivers.php
    http://www.digitalradiotech.co.uk/dab/dab_radios.php



  3. Re: NTP over DRM: http://hireme.geek.nz/NTP.html

    DAB sounds worse than FM wrote:
    > Max Power wrote:
    >> NTP over DRM: http://hireme.geek.nz/NTP.html

    >
    >
    > I've just looked at the DAB and DRM specifications, and they both allow the
    > time to be broadcast.


    :-) So does GSM, GPS, DVB-T etc.

    gr, hwh

  4. NTP over DRM: http://hireme.geek.nz/NTP.html .2

    Yes, but a BCD Time and Date is transmitted -- not NTP.
    NTP is a proven workhorse for time signal distribution -- and can be
    implemented beyond the WWW.

    "DAB sounds worse than FM" wrote in message
    news:qTOKh.11108$GI.4265@newsfe2-gui.ntli.net...
    > Max Power wrote:
    >> NTP over DRM: http://hireme.geek.nz/NTP.html

    >
    > I've just looked at the DAB and DRM specifications, and they both allow
    > the time to be broadcast.





  5. Re: NTP over DRM: http://hireme.geek.nz/NTP.html .2

    Max Power wrote:
    > Yes, but a BCD Time and Date is transmitted -- not NTP.
    > NTP is a proven workhorse for time signal distribution -- and can be
    > implemented beyond the WWW.



    Why would it be advantageous to adopt this NTP when they already broadcast
    the time?


    --
    Steve - www.digitalradiotech.co.uk - Digital Radio News & Info

    Find the cheapest Freeview & DAB prices:
    http://www.digitalradiotech.co.uk/fr..._receivers.php
    http://www.digitalradiotech.co.uk/dab/dab_radios.php



  6. Re: NTP over DRM: http://hireme.geek.nz/NTP.html .2

    In article ,
    "Max Power" writes:
    >Yes, but a BCD Time and Date is transmitted -- not NTP.
    >NTP is a proven workhorse for time signal distribution -- and can be
    >implemented beyond the WWW.


    NTP has a long history of being able to adapt to or translate
    strange formats.

    The important questions are how accurate is the time and what does
    it cost for the gear to receive it?

    --
    These are my opinions, not necessarily my employer's. I hate spam.


  7. Re: NTP over DRM: http://hireme.geek.nz/NTP.html .2

    Max,

    NPR currently uses NTP to synchronize the local broadcast time to the
    satellite feed. The crucial issue is to encapsulate the compressed audio
    in IP packets, not the other way around. I suspect PBS might do the same
    thing as well, as their programs start time deltas are be in the low
    milliseconds relative to UTC. The DRM page cited is riddled with errors.
    Somebody (me?) should send a comprehensive bug report.

    Dave

    Max Power wrote:

    > Yes, but a BCD Time and Date is t deltasansmitted -- not NTP.
    > NTP is a proven workhorse for time signal distribution -- and can be
    > implemented beyond the WWW.
    >
    > "DAB sounds worse than FM" wrote in message
    > news:qTOKh.11108$GI.4265@newsfe2-gui.ntli.net...
    >
    >>Max Power wrote:
    >>
    >>>NTP over DRM: http://hireme.geek.nz/NTP.html

    >>
    >>I've just looked at the DAB and DRM specifications, and they both allow
    >>the time to be broadcast.

    >
    >
    >
    >


  8. NTP over DRM: RDS on FM only accurate to 100ms and no tracability mechinsim exists

    NPR stations that use RDS are only accurate to within 100ms, due to RDS's
    time transmission design flaws.
    No accuracy or traceability mechanism exists for RDS-TC (Time Clock, or TS:
    Time Service) service.
    IP packets are of no meaning here, RDS cannot really encapsulate them.

    This is a non-TCP_IP use of NTP.

    NTP is a data transmission format for time separate of its IP4 and IP6
    multihop measurement mechanisms.

    NTP over DRM: http://hireme.geek.nz/NTP.html

    > NPR currently uses NTP to synchronize the local broadcast time to the
    > satellite feed. The crucial issue is to encapsulate the compressed audio
    > in IP packets, not the other way around. I suspect PBS might do the same
    > thing as well, as their programs start time deltas are be in the low
    > milliseconds relative to UTC. The DRM page cited is riddled with errors.
    > Somebody (me?) should send a comprehensive bug report.

    ==================================================
    >> Yes, but a BCD Time and Date is t deltasansmitted -- not NTP.
    >> NTP is a proven workhorse for time signal distribution -- and can be
    >> implemented beyond the WWW.






  9. Re: NTP over DRM: http://hireme.geek.nz/NTP.html .2

    David,


    David L. Mills schreef:
    > NPR currently uses NTP to synchronize the local broadcast time to the
    > satellite feed. The crucial issue is to encapsulate the compressed audio
    > in IP packets, not the other way around. I suspect PBS might do the same
    > thing as well, as their programs start time deltas are be in the low
    > milliseconds relative to UTC. The DRM page cited is riddled with errors.
    > Somebody (me?) should send a comprehensive bug report.


    My guess, the problem is that any time-system needs some way to
    determine the time-delay between the transmittor and the receiver. Over
    a bidirectional IP-network the NTP protocol does work very well, but
    over a broadcasting-network -which is unidirectional by nature- it's a
    different story.

    I see three different possibilities:

    - either the delay is known and fixed and configured in the device.

    E.g. the satellite link you mentioned, you can messure the delay once
    and -except for the variation due to the satellite moving around in its
    100x100x200 km box- that would be fixed.

    - either you try to calculate it based on the position of the receiver
    (how does it know this?) and the transmittor (OK, but what about
    transmittors in SFN-configuration?)


    - either you ignore this all and live with (say) 10 ms of error.
    ("if you need greater precision, get yourself a GPS").


    Further on, I see two other problems:

    - Even if you knew the exact location of the receiver and the
    transmittor, you do not always know the exact distance the radio-signal
    has traveled.
    For groundwave transmissions (e.g. LW and daytime MW), it's pretty easy
    to calculate but for multiple hop long-distance SW, the distance the
    radio-signal has traveled is much more difficult to predict and will not
    be the same for all listeners.



    - In the time-broadcasts on LW and SW, there is a link between the
    application (the time-information) and the OSI layer 1 characteristics.

    "The next minutes begins exactly at the beginning of the first burst".


    Using NTP, the time-information is inside an IP-stream which is
    encapsulated inside some transport-protocol. There is no direct link
    anymore between the layer 7 information (time) and the layer 1 markers.


    I don't know about DRM, but for DAB, the time-information as found in
    the FIC (i.e. the "system part" of the DAB system) does refer to the
    beginning of a the first "symbol" of each DAB-packet. (so it is related
    to a OSI layer 1 frame-marker).




    To be honest.

    The only advantage I see for encapsulating time information inside NTP
    for DAB or DRM, is the possibility to "export" it natively on a local
    LAN network.

    For the rest, as sending time-information is part of the DRM and DAB
    specs itself, I do not see any real advantage in using NTP for that.
    Just make sure the chipsets support that part of the specs, and that's it.



    > Dave

    Cheerio! Kr. Bonne.

  10. Re: NTP over DRM: http://hireme.geek.nz/NTP.html .2

    >>> In article <4600e954$0$13859$ba620e4c@news.skynet.be>, Kristoff Bonne writes:

    Kristoff> My guess, the problem is that any time-system needs some way to
    Kristoff> determine the time-delay between the transmittor and the
    Kristoff> receiver. Over a bidirectional IP-network the NTP protocol does
    Kristoff> work very well, but over a broadcasting-network -which is
    Kristoff> unidirectional by nature- it's a different story.

    ntp has a "broadcastdelay" parameter for this very case. It won't help you
    figure out the delay, but it will compensate by its value.

    H

  11. Re: NTP over DRM: RDS on FM only accurate to 100msand no tracability mechinsim exists

    Max Power wrote:
    > NPR stations that use RDS are only accurate to within 100ms, due to RDS's
    > time transmission design flaws.
    > No accuracy or traceability mechanism exists for RDS-TC (Time Clock, or TS:
    > Time Service) service.
    > IP packets are of no meaning here, RDS cannot really encapsulate them.
    >
    > This is a non-TCP_IP use of NTP.
    >


    NTP doesn't use TCP, it uses UDP. If you mean non-IP use, you cannot
    call it NTP without IP since that's the only way the protocol is
    defined. Yes it's just the transport but there are parts of the
    mechanisms that depend on the behavior.

    > NTP is a data transmission format for time separate of its IP4 and IP6
    > multihop measurement mechanisms.
    >


    Only partly.

    Danny
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


+ Reply to Thread