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

GPS Problem

Expand Messages
  • larskindermann2000
    Dear Wolf, thanks again for SpecLab. It is definitely a most significant tool for our PALAOA project! SpecLab is running here in multiple instances for years
    Message 1 of 5 , Jun 8, 2012
      Dear Wolf,

      thanks again for SpecLab. It is definitely a most significant tool for our PALAOA project! SpecLab is running here in multiple instances for years now. Have a look at my new "near realtime interface" at http://www.awi.de/fileadmin/user_upload/PALAOA/spectrumpics.html

      Unfortunately, like usually I only write when I need help...

      I try to setup the latest SpecLab (2.78 b07) remotely on a small embedded PC out there on the Antarctic Ice shelf in the PALAOA container. Trying out the GPS functionality (via RS232) for the first time I encounter a problem. SpecLab receives the $GPGGA and $GPZDA strings which my GPS provides but seems to interpret them incompletely.

      Look at the screenshots in http://tech.groups.yahoo.com/group/SpectrumLabUsers/files/temp%20upload/GPSProblem.jpg

      Any chance to correct this? I cannot provide $GPRMC strings but the $GPZDA contains time and date with 10ms accuracy related to the transmission of the "$" character...

      Best Regards, Lars
    • wolf_dl4yhf
      Hi Lars, Thanks for the interesting details about the PALAOA project - it s ... Certainly yes. The GPZDA sentence should be fairly documented somewhere on the
      Message 2 of 5 , Jun 8, 2012
        Hi Lars,

        Thanks for the interesting details about the PALAOA project - it's always fascinating to listen to the hydrophone signals. You wrote:


        I try to setup the latest SpecLab (2.78 b07) remotely on a small embedded PC out there on the Antarctic Ice shelf in the PALAOA container. Trying out the GPS functionality (via RS232) for the first time I encounter a problem. SpecLab receives the $GPGGA and $GPZDA strings which my GPS provides but seems to interpret them incompletely.

        Look at the screenshots in http://tech.groups.yahoo.com/group/SpectrumLabUsers/files/temp%20upload/GPSProblem.jpg

        Any chance to correct this?


        Certainly yes. The GPZDA sentence should be fairly documented somewhere on the web, so modifying the parser to extract the important data from is should be straightforward.
        At the moment, GPZDA is simply thrown away because when used with a 'uBlox'-based GPS receiver, it seemed to arrive at an arbitrary time so it was dropped in favour of more common sentences (like GPRMC).
        But when no GPRMC arrives at all, the next version of Spectrum Lab will use GPZDA instead.
        Looking at http://aprs.gids.nl/nmea/#zda , the format looks exactly like the sample seen in your screenshot.



        I cannot provide $GPRMC strings but the $GPZDA contains time and date with 10ms accuracy related to the transmission of the "$" character...

        The question is which unknown delay is introduced by the serial port's buffering, until the data arrive at the application and are ready for parsing. Spectrum Lab has no means to find out that delay, which is one of the reasons why we feed the NMEA signal (together with the GPS receiver's sync pulse) to the soundcard for the timestamped VLF 'natural radio' streams on Paul Nicholson's site. Anyway, one can assume that the data from the GPS arrive withing 10 milliseconds, but with windows (which doesn't care for the needs of 'hard real time' applications) you never know.

        Have a nice weekend everyone,
           Wolf .
      • wolf_dl4yhf
        Hello Lars, I have modified the NMEA parser, and added the $GPZDA sentence there. To test it, I copied the two sentences visible in your screenshot into the
        Message 3 of 5 , Jun 9, 2012
          Hello Lars,

          I have modified the NMEA parser, and added the $GPZDA sentence there.
          To test it, I copied the two sentences visible in your screenshot into
          the decoder's "Test" tab,
          and got the following results which sound plausible:

          >
          70°30'50.7"S 008°13'04.4"W

          2012-06-08 11:24:41.58

          11 Satellites, HDOP=0.7
          <

          Details about the new NMEA 'Test' panel are here :

          http://www.qsl.net/dl4yhf/speclab/gps_decoder.htm



          The re-compiled version of the audio-I/O-DLL (required for streaming via
          winamp) can be downloaded from here:

          http://www.qsl.net/dl4yhf/AudioIO/index.html


          Finally, you will need the very last 'beta' (which has *not* been
          thoroughly tested yet..) from here:

          http://dl4yhf.ssl7.com/speclab/install_speclab_beta.zip



          Out of curiosity : If the embedded PC crashes when installing a new
          software, can you push its 'Reset'-button remotely ? Hopefully none of
          your colleagues at Neumayer III must go on a long trip to reset a
          crashed PC :)

          All the best,
          Wolf .
        • Lars Kindermann
          Hi Wolf, I am certainly aware of the timing issues of RS232 inputs - not only in windows. Therefore - for timing critical applications - I use the same method
          Message 4 of 5 , Jun 10, 2012
            Hi Wolf,
             
            I am certainly aware of the timing issues of RS232 inputs - not only in windows. Therefore - for timing critical applications - I use the same method you are suggesting: feeding a combined 1pps and rs232 voltage signal into another audio channel for later offline decoding.
             
            But as I have already two (or even more) audio channels, I use a separate channel of a multichannel ASIO device (MOTU Traveler) for this which SpectrumLab cannot access - or is there a chance of acessing a third audio input for GPS processing?
             
            To get around currently, I use a program which reads NMEA via RS232 and switches a "RTS" controlled relay every full 10 minutes for 3 seconds to include occasional GPS timestamps into the audio signal channel #2 for later offline precision alignment. Do you think this could be done by scripting in SpectrumLab directly, allowing stereo audio AND precision timing? 
             
            Regarding the NMEA interpreter: The screenshot also shows that from the $GPGGA sequence only latitude seems to be decoded correctly, longitude is left at 0.0... 
             
            Best Regards, Lars

             

            From: SpectrumLabUsers@yahoogroups.com [mailto:SpectrumLabUsers@yahoogroups.com] On Behalf Of wolf_dl4yhf
            Sent: Friday, June 08, 2012 7:57 PM
            To: SpectrumLabUsers@yahoogroups.com
            Subject: Re: [SpectrumLabUsers] GPS Problem

            Hi Lars,

            Thanks for the interesting details about the PALAOA project - it's always fascinating to listen to the hydrophone signals. You wrote:


            I try to setup the latest SpecLab (2.78 b07) remotely on a small embedded PC out there on the Antarctic Ice shelf in the PALAOA container. Trying out the GPS functionality (via RS232) for the first time I encounter a problem. SpecLab receives the $GPGGA and $GPZDA strings which my GPS provides but seems to interpret them incompletely.

            Look at the screenshots in http://tech.groups.yahoo.com/group/SpectrumLabUsers/files/temp%20upload/GPSProblem.jpg

            Any chance to correct this?


            Certainly yes. The GPZDA sentence should be fairly documented somewhere on the web, so modifying the parser to extract the important data from is should be straightforward.
            At the moment, GPZDA is simply thrown away because when used with a 'uBlox'-based GPS receiver, it seemed to arrive at an arbitrary time so it was dropped in favour of more common sentences (like GPRMC).
            But when no GPRMC arrives at all, the next version of Spectrum Lab will use GPZDA instead.
            Looking at http://aprs.gids.nl/nmea/#zda , the format looks exactly like the sample seen in your screenshot.



            I cannot provide $GPRMC strings but the $GPZDA contains time and date with 10ms accuracy related to the transmission of the "$" character...

            The question is which unknown delay is introduced by the serial port's buffering, until the data arrive at the application and are ready for parsing. Spectrum Lab has no means to find out that delay, which is one of the reasons why we feed the NMEA signal (together with the GPS receiver's sync pulse) to the soundcard for the timestamped VLF 'natural radio' streams on Paul Nicholson's site. Anyway, one can assume that the data from the GPS arrive withing 10 milliseconds, but with windows (which doesn't care for the needs of 'hard real time' applications) you never know.

            Have a nice weekend everyone,
               Wolf .
          • wolf_dl4yhf
            Hi Lars and group, ... I was hoping since a couple of years that affordable external audio devices with four (or even more) simultaneously active analog
            Message 5 of 5 , Jun 10, 2012
              Hi Lars and group,

              you wrote:

               
              But as I have already two (or even more) audio channels, I use a separate channel of a multichannel ASIO device (MOTU Traveler) for this which SpectrumLab cannot access - or is there a chance of acessing a third audio input for GPS processing?

              I was hoping since a couple of years that affordable external audio devices with four (or even more) simultaneously active analog inputs, and a sampling rate of 96 kHz or more were available. In that case, I would extend SL from dual- to quadruple signal processing because this would open up a wealth of new applications - also radio related, for radio direction finding (two 'magnetic' loop antennas, one 'electric' field antenna to resolve the directional ambiguity, plus one input for the timing channel. But so far, nothing affordable and easily available has been found.

              I don't think the scripting capabilities of SL can solve the lack of a 3rd input at the moment, because the scripts are operating outside the real-time audio processing thread. Or, in other words, the scripts can examine the results of the signal analysis functions, but they cannot process the audio stream sample-by-sample. To do the latter, plugins (in the form of DLLs) can be written in "C" or other languages capable of producing a windows DLL. They can be loaded into the 'FFT-based filter', and (since a couple of months) they can not only process the audio stream in the frequency domain (series of short-time fourier transforms) but also in the time domain (i.e. sample-by-sample).

              For the GPS sync pulse, it may be possible to remove it from one of the two analog inputs by software, after the extraction of the GPS time. This has not been implemented in the software yet, but it would be possible if we don't need the precision / resolution of a few nanoseconds. Principle: The software could extract the GPS sync pulse from the analog input by means of a 'synchronized average', and subtract that waveform from the input. The amplitude of the GPS sync pulse would have to be small enough to leave enough headroom for the audio signal, but large enough to be detected reliably. This would allow to use one of the two standard soundcards inputs for the GPS sync pluse *plus* the analog input. But again, this has not been implemented yet.


               
              To get around currently, I use a program which reads NMEA via RS232 and switches a "RTS" controlled relay every full 10 minutes for 3 seconds to include occasional GPS timestamps into the audio signal channel #2 for later offline precision alignment. Do you think this could be done by scripting in SpectrumLab directly, allowing stereo audio AND precision timing? 
               
              Regarding the NMEA interpreter: The screenshot also shows that from the $GPGGA sequence only latitude seems to be decoded correctly, longitude is left at 0.0... 
              Yes, that was a bug in the old version. It is fixed in the latest beta, so the resulting decoded Lat/Lon puts your GPS receiver where (I guess) it should be - not very far from Neumayer III ...


              All the best,
                 Wolf .

            Your message has been successfully submitted and would be delivered to recipients shortly.