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

Re: [SpectrumLabUsers] requesting TCP/IP protocol

Expand Messages
  • David Fields
    Do you have plans, or even a specification of the RASDR protocol already ? Hi Wolf, Thanks for the quick reply. We were thinking that we d go with the current
    Message 1 of 12 , Jan 18, 2012
    • 0 Attachment


      Do you have plans, or even a specification of the RASDR protocol already ?
      Hi Wolf,
      Thanks for the quick reply.

      We' were thinking that we'd go with the current Spectrum Lab TCP/IP protocol, since we're ready to start testing the streaming, thinking of RASDR as server.  Of course we didn't realize that we'd need to do compression.  We want (ideally) to do fast, uncompressed, rapid streaming through the USB cable. How about a fixed 16 bit header (timestamp/sample rate) followed by a stream of 16 bit interleaved I/Q data (one I value, then one Q value, etc.).  We can start with whatever you suggest though, and let you know how it works.

      Cheers,
      David


      -----Original Message-----
      From: wolf_dl4yhf <dl4yhf@...>
      To: SpectrumLabUsers <SpectrumLabUsers@yahoogroups.com>
      Sent: Wed, Jan 18, 2012 3:00 pm
      Subject: Re: [SpectrumLabUsers] requesting TCP/IP protocol

       
      Hi David,

      Since Spectrum Lab is currently undergoing some major changes (under the
      hood, not for the user interface) the structures used to describe an
      audio stream will change very soon. At the moment, TCP/IP is only
      functional for compressed audio streams, compatible with the Ogg
      container / Vorbis audio format which is nicely described at their website.

      Of course, for the sake of simplicity and given the bandwidth of a LAN
      (i.e. local), the old non-compressed native streaming format still has
      its advantages so it will be made functional again in the next major
      release. This will be anounced here, hopefully soon, but I cannot tell
      exactly when. Also, I haven't made up my mind if Spectrum Lab should be
      the client, or the server, or both, for the new TCP/IP-based protocol.
      Do you have plans, or even a specification of the RASDR protocol already ?

      Cheers,
      Wolf .

    • David Fields
      16 bit header Hi Wolf, I should have said 16 BYTE header for timestamp, sample rate and format/station id . Thanks go to my colleague Bogdan for pointing out
      Message 2 of 12 , Jan 19, 2012
      • 0 Attachment

        16 bit header
        Hi Wolf,
        I should have said "16 BYTE header for timestamp, sample rate and format/station id".  Thanks go to my colleague Bogdan for pointing out my error. We can even try to compress the data to get it into Spectrum Lab, if Ogg/Vobis will work.  If you can point us to some version of Spectrum lab and a TCP/IP protocol that functions well with it, then we will try to make it work.

        Cheers,
        David 


        -----Original Message-----
        From: David Fields <fieldsde@...>
        To: SpectrumLabUsers <SpectrumLabUsers@yahoogroups.com>
        Sent: Wed, Jan 18, 2012 4:16 pm
        Subject: Re: [SpectrumLabUsers] requesting TCP/IP protocol

         


        Do you have plans, or even a specification of the RASDR protocol already ?
        Hi Wolf,
        Thanks for the quick reply.

        We' were thinking that we'd go with the current Spectrum Lab TCP/IP protocol, since we're ready to start testing the streaming, thinking of RASDR as server.  Of course we didn't realize that we'd need to do compression.  We want (ideally) to do fast, uncompressed, rapid streaming through the USB cable. How about a fixed 16 bit header (timestamp/sample rate) followed by a stream of 16 bit interleaved I/Q data (one I value, then one Q value, etc.).  We can start with whatever you suggest though, and let you know how it works.

        Cheers,
        David


        -----Original Message-----
        From: wolf_dl4yhf <dl4yhf@...>
        To: SpectrumLabUsers <SpectrumLabUsers@yahoogroups.com>
        Sent: Wed, Jan 18, 2012 3:00 pm
        Subject: Re: [SpectrumLabUsers] requesting TCP/IP protocol

         
        Hi David,

        Since Spectrum Lab is currently undergoing some major changes (under the
        hood, not for the user interface) the structures used to describe an
        audio stream will change very soon. At the moment, TCP/IP is only
        functional for compressed audio streams, compatible with the Ogg
        container / Vorbis audio format which is nicely described at their website.

        Of course, for the sake of simplicity and given the bandwidth of a LAN
        (i.e. local), the old non-compressed native streaming format still has
        its advantages so it will be made functional again in the next major
        release. This will be anounced here, hopefully soon, but I cannot tell
        exactly when. Also, I haven't made up my mind if Spectrum Lab should be
        the client, or the server, or both, for the new TCP/IP-based protocol.
        Do you have plans, or even a specification of the RASDR protocol already ?

        Cheers,
        Wolf .

      • wolf_dl4yhf
        Hi David, The Vorbis compressed input (and output) via TCP/IP is only implemented in the latest beta :
        Message 3 of 12 , Jan 20, 2012
        • 0 Attachment
          Hi David,

          The Vorbis compressed input (and output) via TCP/IP is only implemented in the "latest beta" :

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

          The "protocol" is ridiculously simple: Spectrum Lab simply opens a raw TCP connection to whatever IP + port number you like.
          It then expects an endless Ogg/Vorbis stream pouring in. No HTTP, no M3U redirectors if you set the "protcol" field in the source (or destination) URL to "rawtcp". A few examples are given here:

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

          Note that, at the moment, Spectrum Lab acts as the client, which means it initiates the TCP connection but doesn't "listen" for incoming requests. In other words, an external program (possibly running on a different PC) must act as the server, i.e. listen on a TCP port of your choice, and wait until being connected via LAN or Internet.

          As mentioned in the manual, the timestamp channel is optional. A "normal" Ogg audio stream will do. When used over the internet, it greatly reduces the required bandwidth. With a normal DSL connection (DSL 6000), the *upstream* bandwidth is usually not sufficient to send an uncompressed stream at any decent sample rate. MP3 is plagued by software patents, thus the decision to use Ogg / Vorbis.

          There are a number of examples for Vorbis audio on http://www.vorbis.com  .  I can publish a few more details about the format of the logic stream for the timestamps if you like, but they are all specified in the VLF Receiver Toolkit by Paul Nicholson running under Linux (link given in the SL manual, see link above). Actually, the format used in SL is (and must be) compatible with Paul's RX toolkit because it is used to provide real-time data from remote receiver sites.

          In "C", the timestamp uses the following structures :

          //
          //  Stream header: to be sent once at start of stream
          //
          struct VT_OGG_HDR   /* compatible with Paul's VLF Tools -  don't modify ! */
          {                   // This is the INITIAL special header.
             int32_t magic;
             int32_t chans;         // Number of samples per frame
             int32_t rate;          // Nominal sample rate
             int32_t spare;
          };

          #define HDR_MAGIC 0x1996c3a3  /* by Paul Nicholson - don't modify ! */

          //
          //  Data block: sent whenever new timestamp data comes in on the SR stream
          //

          struct VT_OGG_BLK   /* compatible with Paul's VLF Tools -  don't modify ! */
          {
             int32_t magic;
             int32_t tbreak;     // Timestamp discontinuity detected
             uint64_t posn;      // Frame count (sample index) to which the rest of this data applies
             int32_t spare1;
             int32_t spare2;
             int32_t secs;       // Timestamp, seconds
             int32_t nsec;       // and nanoseconds  (ex: microseconds)
             double srcal;       // Sample rate calibration factor (ideally 1.0)
             double glat;        // Geographic coordinates
             double glong;
             double gasl;        // Metres above sea level
          };

          #define BLK_MAGIC 0x4f60f817  /* by Paul Nicholson - don't modify ! */

          The timestamp use Unix time (number of seconds passed since January 1st, 1970, in UTC).

          All the best,
             Wolf .



          Am 19.01.2012 22:17, schrieb David Fields:
           


          16 bit header
          Hi Wolf,
          I should have said "16 BYTE header for timestamp, sample rate and format/station id".  Thanks go to my colleague Bogdan for pointing out my error. We can even try to compress the data to get it into Spectrum Lab, if Ogg/Vobis will work.  If you can point us to some version of Spectrum lab and a TCP/IP protocol that functions well with it, then we will try to make it work.

          Cheers,
          David 


          -----Original Message-----
          From: David Fields <fieldsde@...>
          To: SpectrumLabUsers <SpectrumLabUsers@yahoogroups.com>
          Sent: Wed, Jan 18, 2012 4:16 pm
          Subject: Re: [SpectrumLabUsers] requesting TCP/IP protocol

           


          Do you have plans, or even a specification of the RASDR protocol already ?
          Hi Wolf,
          Thanks for the quick reply.

          We' were thinking that we'd go with the current Spectrum Lab TCP/IP protocol, since we're ready to start testing the streaming, thinking of RASDR as server.  Of course we didn't realize that we'd need to do compression.  We want (ideally) to do fast, uncompressed, rapid streaming through the USB cable. How about a fixed 16 bit header (timestamp/sample rate) followed by a stream of 16 bit interleaved I/Q data (one I value, then one Q value, etc.).  We can start with whatever you suggest though, and let you know how it works.

          Cheers,
          David


          -----Original Message-----
          From: wolf_dl4yhf <dl4yhf@...>
          To: SpectrumLabUsers <SpectrumLabUsers@yahoogroups.com>
          Sent: Wed, Jan 18, 2012 3:00 pm
          Subject: Re: [SpectrumLabUsers] requesting TCP/IP protocol

           
          Hi David,

          Since Spectrum Lab is currently undergoing some major changes (under the
          hood, not for the user interface) the structures used to describe an
          audio stream will change very soon. At the moment, TCP/IP is only
          functional for compressed audio streams, compatible with the Ogg
          container / Vorbis audio format which is nicely described at their website.

          Of course, for the sake of simplicity and given the bandwidth of a LAN
          (i.e. local), the old non-compressed native streaming format still has
          its advantages so it will be made functional again in the next major
          release. This will be anounced here, hopefully soon, but I cannot tell
          exactly when. Also, I haven't made up my mind if Spectrum Lab should be
          the client, or the server, or both, for the new TCP/IP-based protocol.
          Do you have plans, or even a specification of the RASDR protocol already ?

          Cheers,
          Wolf .


        • Fieldsde
          Wolf, Many thanks!! We ll give this a try. Too bad we are hampered by the software patents. Cheers, David (from small digital RF device)
          Message 4 of 12 , Jan 20, 2012
          • 0 Attachment
            Wolf,
            Many thanks!! We'll give this a try.  Too bad we are hampered by the software patents.

            Cheers,
            David
            (from small digital RF device)

            On Jan 20, 2012, at 8:56, wolf_dl4yhf <dl4yhf@...> wrote:

             

            Hi David,

            The Vorbis compressed input (and output) via TCP/IP is only implemented in the "latest beta" :

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

            The "protocol" is ridiculously simple: Spectrum Lab simply opens a raw TCP connection to whatever IP + port number you like.
            It then expects an endless Ogg/Vorbis stream pouring in. No HTTP, no M3U redirectors if you set the "protcol" field in the source (or destination) URL to "rawtcp". A few examples are given here:

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

            Note that, at the moment, Spectrum Lab acts as the client, which means it initiates the TCP connection but doesn't "listen" for incoming requests. In other words, an external program (possibly running on a different PC) must act as the server, i.e. listen on a TCP port of your choice, and wait until being connected via LAN or Internet.

            As mentioned in the manual, the timestamp channel is optional. A "normal" Ogg audio stream will do. When used over the internet, it greatly reduces the required bandwidth. With a normal DSL connection (DSL 6000), the *upstream* bandwidth is usually not sufficient to send an uncompressed stream at any decent sample rate. MP3 is plagued by software patents, thus the decision to use Ogg / Vorbis.

            There are a number of examples for Vorbis audio on http://www.vorbis.com  .  I can publish a few more details about the format of the logic stream for the timestamps if you like, but they are all specified in the VLF Receiver Toolkit by Paul Nicholson running under Linux (link given in the SL manual, see link above). Actually, the format used in SL is (and must be) compatible with Paul's RX toolkit because it is used to provide real-time data from remote receiver sites.

            In "C", the timestamp uses the following structures :

            //
            //  Stream header: to be sent once at start of stream
            //
            struct VT_OGG_HDR   /* compatible with Paul's VLF Tools -  don't modify ! */
            {                   // This is the INITIAL special header.
               int32_t magic;
               int32_t chans;         // Number of samples per frame
               int32_t rate;          // Nominal sample rate
               int32_t spare;
            };

            #define HDR_MAGIC 0x1996c3a3  /* by Paul Nicholson - don't modify ! */

            //
            //  Data block: sent whenever new timestamp data comes in on the SR stream
            //

            struct VT_OGG_BLK   /* compatible with Paul's VLF Tools -  don't modify ! */
            {
               int32_t magic;
               int32_t tbreak;     // Timestamp discontinuity detected
               uint64_t posn;      // Frame count (sample index) to which the rest of this data applies
               int32_t spare1;
               int32_t spare2;
               int32_t secs;       // Timestamp, seconds
               int32_t nsec;       // and nanoseconds  (ex: microseconds)
               double srcal;       // Sample rate calibration factor (ideally 1.0)
               double glat;        // Geographic coordinates
               double glong;
               double gasl;        // Metres above sea level
            };

            #define BLK_MAGIC 0x4f60f817  /* by Paul Nicholson - don't modify ! */

            The timestamp use Unix time (number of seconds passed since January 1st, 1970, in UTC).

            All the best,
               Wolf .



            Am 19.01.2012 22:17, schrieb David Fields:

             


            16 bit header
            Hi Wolf,
            I should have said "16 BYTE header for timestamp, sample rate and format/station id".  Thanks go to my colleague Bogdan for pointing out my error. We can even try to compress the data to get it into Spectrum Lab, if Ogg/Vobis will work.  If you can point us to some version of Spectrum lab and a TCP/IP protocol that functions well with it, then we will try to make it work.

            Cheers,
            David 


            -----Original Message-----
            From: David Fields <fieldsde@...>
            To: SpectrumLabUsers <SpectrumLabUsers@yahoogroups.com>
            Sent: Wed, Jan 18, 2012 4:16 pm
            Subject: Re: [SpectrumLabUsers] requesting TCP/IP protocol

             


            Do you have plans, or even a specification of the RASDR protocol already ?
            Hi Wolf,
            Thanks for the quick reply.

            We' were thinking that we'd go with the current Spectrum Lab TCP/IP protocol, since we're ready to start testing the streaming, thinking of RASDR as server.  Of course we didn't realize that we'd need to do compression.  We want (ideally) to do fast, uncompressed, rapid streaming through the USB cable. How about a fixed 16 bit header (timestamp/sample rate) followed by a stream of 16 bit interleaved I/Q data (one I value, then one Q value, etc.).  We can start with whatever you suggest though, and let you know how it works.

            Cheers,
            David


            -----Original Message-----
            From: wolf_dl4yhf <dl4yhf@...>
            To: SpectrumLabUsers <SpectrumLabUsers@yahoogroups.com>
            Sent: Wed, Jan 18, 2012 3:00 pm
            Subject: Re: [SpectrumLabUsers] requesting TCP/IP protocol

             
            Hi David,

            Since Spectrum Lab is currently undergoing some major changes (under the
            hood, not for the user interface) the structures used to describe an
            audio stream will change very soon. At the moment, TCP/IP is only
            functional for compressed audio streams, compatible with the Ogg
            container / Vorbis audio format which is nicely described at their website.

            Of course, for the sake of simplicity and given the bandwidth of a LAN
            (i.e. local), the old non-compressed native streaming format still has
            its advantages so it will be made functional again in the next major
            release. This will be anounced here, hopefully soon, but I cannot tell
            exactly when. Also, I haven't made up my mind if Spectrum Lab should be
            the client, or the server, or both, for the new TCP/IP-based protocol.
            Do you have plans, or even a specification of the RASDR protocol already ?

            Cheers,
            Wolf .


          • Jurgen Bartels
            ... Last year I was looking for a streaming codec routine and considered Ogg. Then I found VLC (for streaming and receiving) and exmined it there. To my
            Message 5 of 12 , Jan 20, 2012
            • 0 Attachment
              > The Vorbis compressed input (and output) via TCP/IP is only implemented
              > in the "latest beta" :

              Last year I was looking for a streaming codec routine and considered Ogg. Then
              I found VLC (for streaming and receiving) and exmined it there. To my surprise
              Ogg showed a large latency, AFAIR is was above 6 sec. So I switched to mp3 and
              got a bit above 1 sec delay (internet delay included).

              Not sure if this is an Ogg inherent problem or just the implementation in VLC.

              For SL this probably is not an issue?



              Jurgen Bartels Suellwarden, N. Germany
              Antennas hor.: 45-87MHz: 11-ele, FM: 15.11, Band-III:13-ele, UHF:48-ele,
              TV: Winradio G305 / Fly2000 + video noise filter & variable IF BW
              FM: Downconverter + Perseus + Speclab as WFM demod.
              MW: 90m bev 220°, 30 x 4m EWE 320° with JB-terminator, Winradio & Perseus
              300m staggered beverages 320° http://dx.3sdesign.de/staggered_beverage.htm
              http://zeiterfassung.3sdesign.de/station_list.htm
            Your message has been successfully submitted and would be delivered to recipients shortly.