Loading ...
Sorry, an error occurred while loading the content.
 

Re: Logging NMEA packets to file when using GPS time sync option

Expand Messages
  • kg4inu
    Hi Wolf, That sounds good. We ll keep at it here. Cheers Joel
    Message 1 of 9 , May 18, 2013
      Hi Wolf,

      That sounds good. We'll keep at it here.

      Cheers
      Joel

      --- In SpectrumLabUsers@yahoogroups.com, wolf_dl4yhf <dl4yhf@...> wrote:
      >
      > Hi Joel,
      >
      > Thanks for the info.
      >
      > Looks like a lost block of samples, which irritated the sampling rate
      > detector... these huge errors in the sampling rate are too large to be
      > caused by a 'missed' sync pulse from the GPS. For a future release, the
      > SR detector will reset itself in such cases, which hopefully leads to a
      > faster resynchronisation of the timestamped stream.
      >
      > All the best,
      > Wolf .
    • kg4inu
      Hi Wolf, I m still having an issue here with timing breaks being sent on the VLF19 stream to abelian.org. I ve noticed that the time breaks are worse when I
      Message 2 of 9 , Aug 12, 2013
        Hi Wolf,

        I'm still having an issue here with timing breaks being sent on the VLF19 stream to abelian.org. I've noticed that the time breaks are worse when I use the newer versions of SpecLab. For exeample, I'm using V2.79 b04 and when I first start the stream I get time breaks like the ones below:

        00:38:10.9 Connected to rawtcp://**.**.**.**:****
        00:38:11.0 Created audio logfile
        00:39:02.9 Vorbis output: timing break, d=344088585.24999481 s !
        00:39:02.9 Vorbis output: timing break, d=344088585.24999481 s !
        00:39:02.9 Vorbis output: timing break, d=344088585.24999481 s !
        00:39:03.2 Vorbis output: timing break, d=-1032265755.74998438 s !
        00:39:03.9 Vorbis output: timing break, d=-0.59894759 s !
        00:39:04.0 Vorbis output: timing break, d=-0.59894759 s !
        00:39:04.0 Vorbis output: timing break, d=-0.59894759 s !
        00:39:04.2 Vorbis output: timing break, d=1.79625777 s !
        00:39:04.2 Vorbis output: timing break, d=-0.00014626 s !
        00:39:04.3 Vorbis output: timing break, d=-0.00014626 s !
        00:39:04.3 Vorbis output: timing break, d=-0.00014626 s !
        00:39:04.7 Vorbis output: timing break, d=0.00043879 s !

        What's happening is that those really high timing breaks are locking up the VLF19 stream on the server end untill that point in time is reached which is some time in the future.

        I've noticed that version 2.77 b18 is not doing this as bad so I've downgraded for the time being.

        I don't know if there is a remedy for this, but wanted to run it by you.

        Thanks
        Joel
      • wolf_dl4yhf
        Thanks Joel, My own VLF stream is also using an older version, so I didn t notice a problem with the GPS timing there. Most likely this is related with the
        Message 3 of 9 , Aug 17, 2013
          Thanks Joel,
          My own VLF stream is also using an older version, so I didn't notice a problem with the GPS timing there.
          Most likely this is related with the soundcard interface (software) which I had modified a couple of months ago.
          I consider 'undoing' those changes since they did have the desired effect (improving the stability with certain SDRs which I don't use myself anyway), but this will take time since I'm busy from other tasks, which are not related with programming at all.. :o)

          All the best,
            Wolf .

          Am 13.08.2013 02:53, schrieb kg4inu:
           



          Hi Wolf,

          I'm still having an issue here with timing breaks being sent on the VLF19 stream to abelian.org. I've noticed that the time breaks are worse when I use the newer versions of SpecLab. For exeample, I'm using V2.79 b04 and when I first start the stream I get time breaks like the ones below:

          00:38:10.9 Connected to rawtcp://**.**.**.**:****
          00:38:11.0 Created audio logfile
          00:39:02.9 Vorbis output: timing break, d=344088585.24999481 s !
          00:39:02.9 Vorbis output: timing break, d=344088585.24999481 s !
          00:39:02.9 Vorbis output: timing break, d=344088585.24999481 s !
          00:39:03.2 Vorbis output: timing break, d=-1032265755.74998438 s !
          00:39:03.9 Vorbis output: timing break, d=-0.59894759 s !
          00:39:04.0 Vorbis output: timing break, d=-0.59894759 s !
          00:39:04.0 Vorbis output: timing break, d=-0.59894759 s !
          00:39:04.2 Vorbis output: timing break, d=1.79625777 s !
          00:39:04.2 Vorbis output: timing break, d=-0.00014626 s !
          00:39:04.3 Vorbis output: timing break, d=-0.00014626 s !
          00:39:04.3 Vorbis output: timing break, d=-0.00014626 s !
          00:39:04.7 Vorbis output: timing break, d=0.00043879 s !

          What's happening is that those really high timing breaks are locking up the VLF19 stream on the server end untill that point in time is reached which is some time in the future.

          I've noticed that version 2.77 b18 is not doing this as bad so I've downgraded for the time being.

          I don't know if there is a remedy for this, but wanted to run it by you.

          Thanks
          Joel


        • kg4inu
          Hi Wolf, No problem, the issue doesn t seem to be a problem with the older version of SpecLab so I ll just continue to use it. Thanks for your reply and I hope
          Message 4 of 9 , Aug 17, 2013
            Hi Wolf,

            No problem, the issue doesn't seem to be a problem with the older version of SpecLab so I'll just continue to use it.

            Thanks for your reply and I hope all is well there.

            Cheers
            Joel

            --- In SpectrumLabUsers@yahoogroups.com, wolf_dl4yhf <dl4yhf@...> wrote:
            >
            > Thanks Joel,
            > My own VLF stream is also using an older version, so I didn't notice a
            > problem with the GPS timing there.
            > Most likely this is related with the soundcard interface (software)
            > which I had modified a couple of months ago.
            > I consider 'undoing' those changes since they did have the desired
            > effect (improving the stability with certain SDRs which I don't use
            > myself anyway), but this will take time since I'm busy from other tasks,
            > which are not related with programming at all.. :o)
            >
            > All the best,
            > Wolf .
          Your message has been successfully submitted and would be delivered to recipients shortly.