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

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

Expand Messages
  • wolf_dl4yhf
    Hello Joel, There is no NMEA- file writer in Spectrum Lab for the software-based UART yet. SL can export the GPS coordinates along with other data by means of
    Message 1 of 9 , May 14, 2013
    • 0 Attachment
      Hello Joel,

      There is no NMEA-"file writer" in Spectrum Lab for the software-based UART yet.
      SL can export the GPS coordinates along with other data by means of the user-defined export functions, but not as plain NMEA.

      To get an impression about the percentage of false decodes (which happen occasionally here, due to electrical interference / transients), I simply check the amount of "other" messages on the GPS receiver control panel (menu Options, GPS Receiver), 'Diagnostics' tab.
      The streaming PC has been running for weeks, and decoded thousands of 'known' NMEA sentences, plus a few 'unknown' messages which appear as garbage characters in the text display field. Per day, there are only one or two such events.

      Another possibility (if the problem is not the decoding of NMEA sentences via software UART but the precise detection of the sync pulse) is under 'Components' / 'Sampling Rate Detector' / 'Debug' tab. If there are error messages, you can copy/paste them into an email for further examination.

      All the best,
        Wolf .
        (just finished the goddamn income tax declaration.. now back to more creative work, hooray..!)

      Am 14.05.2013 19:01, schrieb kg4inu:
       

      Hi Wolf and group,

      I was wondering if I'm able to "log to file" the NMEA packets being decoded by SpecLab via the soundcard from within the program. I'm seeing some strange jumps in time stamps being streamed online and would like to see if the GPS unit is the issue or maybe the decoding of the packets. Right now I'm using V2.77 B18, but also was running V2.88 b33 recently.

      Thanks
      Joel


    • kg4inu
      Thanks Wolf, I will keep an eye on the other and unkn fields as well as the debug window from now on. For whatever reason in the past week I ve sent time
      Message 2 of 9 , May 14, 2013
      • 0 Attachment
        Thanks Wolf,

        I will keep an eye on the "other" and "unkn" fields as well as the debug window from now on. For whatever reason in the past week I've sent time stamps with very far in the future dates which stop the streaming server until the real time reaches that date and time. Strange, I'll keep monitoring.

        Thanks
        Joel
      • kg4inu
        Hi Wolf, I received a few errors in the debug window today. It didn t lock up the streaming server I don t think, but I wanted to run them by you just in case.
        Message 3 of 9 , May 15, 2013
        • 0 Attachment
          Hi Wolf,

          I received a few errors in the debug window today. It didn't lock up the streaming server I don't think, but I wanted to run them by you just in case.

          2013-05-15 14:08:09 Measured SR too far off (-354834.71 ppm)
          2013-05-15 14:08:10 Measured SR too far off (-1000000.00 ppm)
          2013-05-15 14:08:11 Measured SR too far off (1000165.72 ppm)
          2013-05-15 14:08:11 Timestamp didn't pass plausibility check !
          2013-05-15 14:08:12 Samplerate too far off (1000165.72 ppm) !
          2013-05-15 14:08:12 Timestamp didn't pass plausibility check !

          Thanks
          Joel
        • wolf_dl4yhf
          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
          Message 4 of 9 , May 16, 2013
          • 0 Attachment
            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 .

            Am 16.05.2013 01:52, schrieb kg4inu:
             

            Hi Wolf,

            I received a few errors in the debug window today. It didn't lock up the streaming server I don't think, but I wanted to run them by you just in case.

            2013-05-15 14:08:09 Measured SR too far off (-354834.71 ppm)
            2013-05-15 14:08:10 Measured SR too far off (-1000000.00 ppm)
            2013-05-15 14:08:11 Measured SR too far off (1000165.72 ppm)
            2013-05-15 14:08:11 Timestamp didn't pass plausibility check !
            2013-05-15 14:08:12 Samplerate too far off (1000165.72 ppm) !
            2013-05-15 14:08:12 Timestamp didn't pass plausibility check !

            Thanks
            Joel


          • kg4inu
            Hi Wolf, That sounds good. We ll keep at it here. Cheers Joel
            Message 5 of 9 , May 18, 2013
            • 0 Attachment
              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 6 of 9 , Aug 12, 2013
              • 0 Attachment
                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 7 of 9 , Aug 17, 2013
                • 0 Attachment
                  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 8 of 9 , Aug 17, 2013
                  • 0 Attachment
                    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.