You can't disconnect the lower impedance gound and leave the signal
alone. This is the best way how to destroy the input stage.

Use a transformer to isolate the input from any ground-loop. I use
common-mode ferrite chokes for this.

I tried the EMU0202 download link but it is gone. They show a newer(?)
device, the 0204. Any idea what is newer there? Better ADC/DAC?


There is a potential way to higher sampling-rates at 384KHz in the audio
scene. Is there a device on the market meanwhile? In the background
there is my project for a higher sampling DIY card.


Thanks -
Henry


Alan schrieb:
> ----- Original Message -----
> Subject: Re: [SpectrumLabUsers] EMU0202 ground lifter
>
>
>> Many thanks also from this side. I had also wondered what the "ground
>> lift"-thing actually does.
>> Simply disconnect the ground so the external device would only be
>> connected to the signal line but to nothing else didn't make sense to
>> me.
>
>  Wolf,
>
> But I'm fairly sure that is all it does.
> The best way to eliminate a ground loop might be to disconnect the ground at
> one end of the audio cable. I think that is all those switches do.
> I use soundcard SDR and often have to reduce ground loop effects. Usually
> making the audio grounds the only ground connection is the most effective
> way. But those switches give the option of removing the ground connection at
> the soundcard end. With the USB device there is a potential return via the
> USB ground. The audio ground is normally connected to the USB socket shield.


--
ehydra.dyndns.info

I'm using a version of a SID rcvr "user configuration" that I got from somewhere
(can't remember where).  In this configuration there are only 3 channels.  It's
not that they're turned off in "Channels & Colors", there just aren't any more
channels.  None show up in the Watch List.

I would like to know how I can add more channels to the Watch List?

Thanks in advance.

John

 

I'm using a version of a SID rcvr "user configuration" that I got from somewhere (can't remember where). In this configuration there are only 3 channels. It's not that they're turned off in "Channels & Colors", there just aren't any more channels. None show up in the Watch List.

I would like to know how I can add more channels to the Watch List?

Thanks in advance.

John

I bought a used SignaLink USB at a hamfest just in time for the ARRL FMT. I
rushed the setup but everything calibrated just fine, one test tone, set cal,
then checked it on another tone, and repeated several time till there were no
significant differences; all was good. Did the FMT, got my dates wrong for
turning in results: but all my results were within .05hz of the published
frequencies.

This all sounds good, Right? Wrong.

I began playing with the SignaLink and notice there is a 1000hz tone that wasn't
noticed in my haste before. Not sure why I didn't notice it before, it's not
something anywhere near the noise floor.

Signalink noise floor is -104db between 100-1000hz then tapers off to -130db  at
1300hz. The mystery 1000hz is -84db. Interestingly that is where the noise
begins tapering.

My PC soundcard noise is 122db at 100hz and tapers uniformally to -120db at
1300hz. No mystery tone.

With the Signalink connected to PC but unconnected from the Radio, tone is still
there.

Change to internal PC soundcard and NO tone. Switch back to Signalink and tone
is there.

I have not open up the signalink and start tracing with a scope yet. Wanted to
find out if anyone else has come across this type of problem. I'm not sure if my
head is still off a tic toc from the FMT.

SpecLab is setup as follows:

Audio: 16bit 48000 1dec

FFT: 32768 16dec Hann
Effect of FFT settings with fs= 48.0000 kHz:
Width of one FFT-bin: 91.5527 mHz
Equiv. noise bandwidth: 137.329 mHz
Max freq range: 0.00000 Hz .. 1.50000 kHz
FFT window time: 10.923 s
Overlap from scroll interval: 99.1 %

Norm

----- Original Message -----

Subject: Re: [SpectrumLabUsers] EMU0202 ground lifter


> You can't disconnect the lower impedance gound and leave the signal
> alone. This is the best way how to destroy the input stage.
>
> Use a transformer to isolate the input from any ground-loop. I use
> common-mode ferrite chokes for this.
> I tried the EMU0202 download link but it is gone.

Did this not work?
http://support.creative.com/manuals/download.aspx?nDownloadId=11575&prodName=020\
2_USB_Web%20manual
Click on "Agree" at the bottom and wait.
Or this link seems to go straight to it.
<http://ccftp.creative.com/Manuals/TSD/11575/0x6FF24E6A/0202_USB_Web_Manual.pdf>
They talk about breaking the ground loop.
Form your own opinion. What do the switches do? As I tested there is a
resistive leak to dissipate any static but there is no direct connection
from the input ground when the switches are operated. Creative give no
warnings so I presume they do no consider damage is likely.
Removing ground loops involves leaving just one low impedance ground.
Transformers should not be necessary, maybe they help but can cause other
problems especially if you are using frequencies up to 96KHz..


  They show a newer(?)
> device, the 0204. Any idea what is newer there? Better ADC/DAC?

I do not know, does it say on the Creative site?

Alan

Wolf:

I suspected it was something simple.  I just wasn't seeing it!

Many thanks for your help.

John

--- In SpectrumLabUsers@yahoogroups.com, wolf_dl4yhf <dl4yhf@...> wrote:
>
> Hi John,
>
> It's on the 'Memory,Misc.' tab of the watch/plot window. The number of
> channels entered there will become effective when creating a new buffer
> file: In the plotter's menu, select 'Plotter'..Erase Data Memory. After
> that, you will have more channels in the 'Watch List' .
>
> HTH,
>    Cheers,
>        Wolf .
>
> Am 14.05.2012 17:53, schrieb thb201:
> >
> > I'm using a version of a SID rcvr "user configuration" that I got from
> > somewhere (can't remember where). In this configuration there are only
> > 3 channels. It's not that they're turned off in "Channels & Colors",
> > there just aren't any more channels. None show up in the Watch List.
> >
> > I would like to know how I can add more channels to the Watch List?
> >
> > Thanks in advance.
> >
> > John
> >
> >
>

I'm feeling quite stupid now, but I still don't get it to work. The
error is still the same: PPS peaks are ok, but the timestamp fails the
plausibility check. Time is taken from the GPS-station itsself via a
helper utility by the stations manufacturer (My last resort is, that
this utility might introduce a lag > 500 ms). I would have tried the
PTB-timeserver instead, but the computer used for measurement does not
have internet access. Is there any possibility of viewing the difference
between system-time and "GPS-PPS-time" (the corresponding field is not
shown when the plausibility check fails)?

Best wishes
Christoph

Am Mittwoch, den 18.04.2012, 20:06 +0000 schrieb dl4yhf:
>
> I have slightly modified the GPS-based sampling rate calibrator a
> little in SL V2.78 b04 (which is, at the moment, the latest "beta").
>
> The option "GPS without NMEA" seems to work now, with a Garmin GPS 18x
> LVC, but the PC's system time must be quite accurate (otherwise the
> program assigns the "wrong" timestamp to a 1-second-pulse).
>
> No comparison with the "GPS with NMEA output" configuration were made
> yet. The latter is my favourite because I trust the output of a GPS
> receiver more than an internet-based time sync service... even though
> *shortly* after such a synchronisation (here: using Dimension 4,
> because the stuff integrated in windows XP didn't seem to work at all)
> the difference between GPS time (which is actually UTC, decoded from
> the GPS receiver's NMEA output) and the system time (also in UTC) was
> only a few ten milliseconds.
>
> As usual, the latest "beta" is here:
>
> http://dl4yhf.ssl7.com/speclab/install_speclab_beta.zip
>
> Beware: Keep a copy of your recent version ! Chances are that there a
> a couple of bugs lurking in the 'beta' version, especially now because
> the format of the internal samples has been changed. Formerly samples
> were scaled to +/-32767 which was handy for 16-bit A/D converters, but
> now everything is internally scaled to +/- 1.0. So if a measured
> amplitude, or voltage, or power is suddenly off by about 90 dB in the
> new 'beta', this modified audio sample range may be the reason.
> So if the 'beta' doesn't work for your special application, you may
> have to switch back to the older (but working) version.
>
> All the best,
> Wolf .
>
> --- In SpectrumLabUsers@yahoogroups.com, Christoph Maurer
> <christoph.maurer@...> wrote:
> >
> > Hello,
> >
> > a few days ago i discovered the new SpecLab version with "GPS
> without
> > NMEA"-support. I tried to use it to calibrate my sampling rate, and
> the
> > PPS-Pulses are indeed reported to be ok as before, but the timestamp
> > didn't pass the plausibility check. I supposed this to be related to
> the
> > required initial accuracy of the systems clock.
> >
> > My GPS station does not have a COM-port but USB and emulates a
> COM-port
> > via a driver from the USB-input (That isone reason why I cannot use
> the
> > advised GPS-NMEA-combo - I would also like to measure with a
> > GPS-calibrated SpecLab and a GPS-calibrated UltraMSK simultaneously
> and
> > I'm quite sure UltraMSK will not accept the PPS-NMEA-signal). It HAS
> a
> > utility that sets the system clock with the USB output from the GPS
> > station, but this did not help either. I don't see any possibility
> of
> > setting my system time more accurate.
> >
> > So my questions are:
> >
> > Is the error i encounter mean what I think it means?
> >
> > Do you have any suggestions for helping me?
> >
> >
> > Best regards and thanks in advance
> >
> > Christoph
> >
> >
> > PS: I'm currently writing an interim report (I'm halfway through the
> > master's-thesis-year) where I described the
> phase-and-amplitude-monitor
> > as implemented in Speclab. The manual was the only source I found,
> and I
> > think I worked out how it is done. @Wolf: Is it okay for you if I
> cite
> > your manual?
> >
> > --
> > Christoph Maurer B.Sc.
> >
> > Technische Universität Darmstadt
> > Institut für Kernphysik
> > AG Strahlen- und Kernphysik
> > -Kosmische Plasmaphysik
> > Schlossgartenstr. 9
> > 64289 Darmstadt
> >
> > Office: S2|14-107
> > Tel.: (+49) 6151 16 4426
> >
>
>
>
>
>

--
Christoph Maurer B.Sc.

Technische Universität Darmstadt
Institut für Kernphysik
AG Strahlen- und Kernphysik
  -Kosmische Plasmaphysik
Schlossgartenstr. 9
64289 Darmstadt

Office: S2|14-107
Tel.: (+49) 6151 16 4426

 

I'm feeling quite stupid now, but I still don't get it to work. The
error is still the same: PPS peaks are ok, but the timestamp fails the
plausibility check. Time is taken from the GPS-station itsself via a
helper utility by the stations manufacturer (My last resort is, that
this utility might introduce a lag > 500 ms). I would have tried the
PTB-timeserver instead, but the computer used for measurement does not
have internet access. Is there any possibility of viewing the difference
between system-time and "GPS-PPS-time" (the corresponding field is not
shown when the plausibility check fails)?

Best wishes
Christoph

Am Mittwoch, den 18.04.2012, 20:06 +0000 schrieb dl4yhf:
>
> I have slightly modified the GPS-based sampling rate calibrator a
> little in SL V2.78 b04 (which is, at the moment, the latest "beta").
>
> The option "GPS without NMEA" seems to work now, with a Garmin GPS 18x
> LVC, but the PC's system time must be quite accurate (otherwise the
> program assigns the "wrong" timestamp to a 1-second-pulse).
>
> No comparison with the "GPS with NMEA output" configuration were made
> yet. The latter is my favourite because I trust the output of a GPS
> receiver more than an internet-based time sync service... even though
> *shortly* after such a synchronisation (here: using Dimension 4,
> because the stuff integrated in windows XP didn't seem to work at all)
> the difference between GPS time (which is actually UTC, decoded from
> the GPS receiver's NMEA output) and the system time (also in UTC) was
> only a few ten milliseconds.
>
> As usual, the latest "beta" is here:
>
> http://dl4yhf.ssl7.com/speclab/install_speclab_beta.zip
>
> Beware: Keep a copy of your recent version ! Chances are that there a
> a couple of bugs lurking in the 'beta' version, especially now because
> the format of the internal samples has been changed. Formerly samples
> were scaled to +/-32767 which was handy for 16-bit A/D converters, but
> now everything is internally scaled to +/- 1.0. So if a measured
> amplitude, or voltage, or power is suddenly off by about 90 dB in the
> new 'beta', this modified audio sample range may be the reason.
> So if the 'beta' doesn't work for your special application, you may
> have to switch back to the older (but working) version.
>
> All the best,
> Wolf .
>
> --- In SpectrumLabUsers@yahoogroups.com, Christoph Maurer
> <christoph.maurer@...> wrote:
> >
> > Hello,
> >
> > a few days ago i discovered the new SpecLab version with "GPS
> without
> > NMEA"-support. I tried to use it to calibrate my sampling rate, and
> the
> > PPS-Pulses are indeed reported to be ok as before, but the timestamp
> > didn't pass the plausibility check. I supposed this to be related to
> the
> > required initial accuracy of the systems clock.
> >
> > My GPS station does not have a COM-port but USB and emulates a
> COM-port
> > via a driver from the USB-input (That isone reason why I cannot use
> the
> > advised GPS-NMEA-combo - I would also like to measure with a
> > GPS-calibrated SpecLab and a GPS-calibrated UltraMSK simultaneously
> and
> > I'm quite sure UltraMSK will not accept the PPS-NMEA-signal). It HAS
> a
> > utility that sets the system clock with the USB output from the GPS
> > station, but this did not help either. I don't see any possibility
> of
> > setting my system time more accurate.
> >
> > So my questions are:
> >
> > Is the error i encounter mean what I think it means?
> >
> > Do you have any suggestions for helping me?
> >
> >
> > Best regards and thanks in advance
> >
> > Christoph
> >
> >
> > PS: I'm currently writing an interim report (I'm halfway through the
> > master's-thesis-year) where I described the
> phase-and-amplitude-monitor
> > as implemented in Speclab. The manual was the only source I found,
> and I
> > think I worked out how it is done. @Wolf: Is it okay for you if I
> cite
> > your manual?
> >
> > --
> > Christoph Maurer B.Sc.
> >
> > Technische Universität Darmstadt
> > Institut für Kernphysik
> > AG Strahlen- und Kernphysik
> > -Kosmische Plasmaphysik
> > Schlossgartenstr. 9
> > 64289 Darmstadt
> >
> > Office: S2|14-107
> > Tel.: (+49) 6151 16 4426
> >
>
>
>
>
>

--
Christoph Maurer B.Sc.

Technische Universität Darmstadt
Institut für Kernphysik
AG Strahlen- und Kernphysik
-Kosmische Plasmaphysik
Schlossgartenstr. 9
64289 Darmstadt

Office: S2|14-107
Tel.: (+49) 6151 16 4426

Hi,

the first possibility (sampling rate too far off) is unlikely, since a
calibration via DCF77 with the same tolerance works.

The screenshots (as well as a screenshot of the settings window is in
the attachment, the syncd input has already been zoomed)

Thanks
Christoph

Am Dienstag, den 15.05.2012, 19:34 +0200 schrieb wolf_dl4yhf:
>
> Hello Christoph,
>
> The plausibility check usually fails because the measured sampling
> rate (based on two consecutive pulses) is too far off the nominal
> value. In those cases it may help to increase the tolerance ("Max.
> deviation from initial sample rate").
> In other cases, the edge detection failed because the input signal
> overloaded the A/D converter, or clipping occurred in the soundcard's
> analog input. In those cases, the 'synchronized input waveform'
> displayed on the calibrator's scope tab looked strange, and the
> interpolated PPS signal looked even worse. Can you upload screenshots
> from the scope in one or both of these modes ?
>
> At the moment, it's impossible to display the difference between
> system time and GPS time, as long as the program has not found the
> "valid" edges of the sync pulses.
>
> All the best,
>    Wolf .
>
> Am 15.05.2012 18:24, schrieb Christoph Maurer:
> >
> >
> > I'm feeling quite stupid now, but I still don't get it to work. The
> > error is still the same: PPS peaks are ok, but the timestamp fails
> > the
> > plausibility check. Time is taken from the GPS-station itsself via a
> > helper utility by the stations manufacturer (My last resort is, that
> > this utility might introduce a lag > 500 ms). I would have tried the
> > PTB-timeserver instead, but the computer used for measurement does
> > not
> > have internet access. Is there any possibility of viewing the
> > difference
> > between system-time and "GPS-PPS-time" (the corresponding field is
> > not
> > shown when the plausibility check fails)?
> >
> > Best wishes
> > Christoph
> >
> > Am Mittwoch, den 18.04.2012, 20:06 +0000 schrieb dl4yhf:
> > >
> > > I have slightly modified the GPS-based sampling rate calibrator a
> > > little in SL V2.78 b04 (which is, at the moment, the latest
> > "beta").
> > >
> > > The option "GPS without NMEA" seems to work now, with a Garmin GPS
> > 18x
> > > LVC, but the PC's system time must be quite accurate (otherwise
> > the
> > > program assigns the "wrong" timestamp to a 1-second-pulse).
> > >
> > > No comparison with the "GPS with NMEA output" configuration were
> > made
> > > yet. The latter is my favourite because I trust the output of a
> > GPS
> > > receiver more than an internet-based time sync service... even
> > though
> > > *shortly* after such a synchronisation (here: using Dimension 4,
> > > because the stuff integrated in windows XP didn't seem to work at
> > all)
> > > the difference between GPS time (which is actually UTC, decoded
> > from
> > > the GPS receiver's NMEA output) and the system time (also in UTC)
> > was
> > > only a few ten milliseconds.
> > >
> > > As usual, the latest "beta" is here:
> > >
> > > http://dl4yhf.ssl7.com/speclab/install_speclab_beta.zip
> > >
> > > Beware: Keep a copy of your recent version ! Chances are that
> > there a
> > > a couple of bugs lurking in the 'beta' version, especially now
> > because
> > > the format of the internal samples has been changed. Formerly
> > samples
> > > were scaled to +/-32767 which was handy for 16-bit A/D converters,
> > but
> > > now everything is internally scaled to +/- 1.0. So if a measured
> > > amplitude, or voltage, or power is suddenly off by about 90 dB in
> > the
> > > new 'beta', this modified audio sample range may be the reason.
> > > So if the 'beta' doesn't work for your special application, you
> > may
> > > have to switch back to the older (but working) version.
> > >
> > > All the best,
> > > Wolf .
> > >
> > > --- In SpectrumLabUsers@yahoogroups.com, Christoph Maurer
> > > <christoph.maurer@...> wrote:
> > > >
> > > > Hello,
> > > >
> > > > a few days ago i discovered the new SpecLab version with "GPS
> > > without
> > > > NMEA"-support. I tried to use it to calibrate my sampling rate,
> > and
> > > the
> > > > PPS-Pulses are indeed reported to be ok as before, but the
> > timestamp
> > > > didn't pass the plausibility check. I supposed this to be
> > related to
> > > the
> > > > required initial accuracy of the systems clock.
> > > >
> > > > My GPS station does not have a COM-port but USB and emulates a
> > > COM-port
> > > > via a driver from the USB-input (That isone reason why I cannot
> > use
> > > the
> > > > advised GPS-NMEA-combo - I would also like to measure with a
> > > > GPS-calibrated SpecLab and a GPS-calibrated UltraMSK
> > simultaneously
> > > and
> > > > I'm quite sure UltraMSK will not accept the PPS-NMEA-signal). It
> > HAS
> > > a
> > > > utility that sets the system clock with the USB output from the
> > GPS
> > > > station, but this did not help either. I don't see any
> > possibility
> > > of
> > > > setting my system time more accurate.
> > > >
> > > > So my questions are:
> > > >
> > > > Is the error i encounter mean what I think it means?
> > > >
> > > > Do you have any suggestions for helping me?
> > > >
> > > >
> > > > Best regards and thanks in advance
> > > >
> > > > Christoph
> > > >
> > > >
> > > > PS: I'm currently writing an interim report (I'm halfway through
> > the
> > > > master's-thesis-year) where I described the
> > > phase-and-amplitude-monitor
> > > > as implemented in Speclab. The manual was the only source I
> > found,
> > > and I
> > > > think I worked out how it is done. @Wolf: Is it okay for you if
> > I
> > > cite
> > > > your manual?
> > > >
> > > > --
> > > > Christoph Maurer B.Sc.
> > > >
> > > > Technische Universität Darmstadt
> > > > Institut für Kernphysik
> > > > AG Strahlen- und Kernphysik
> > > > -Kosmische Plasmaphysik
> > > > Schlossgartenstr. 9
> > > > 64289 Darmstadt
> > > >
> > > > Office: S2|14-107
> > > > Tel.: (+49) 6151 16 4426
> > > >
> > >
> > >
> > >
> > >
> > >
> >
> > --
> > Christoph Maurer B.Sc.
> >
> > Technische Universität Darmstadt
> > Institut für Kernphysik
> > AG Strahlen- und Kernphysik
> > -Kosmische Plasmaphysik
> > Schlossgartenstr. 9
> > 64289 Darmstadt
> >
> > Office: S2|14-107
> > Tel.: (+49) 6151 16 4426
> >
> >
> >
> >
>
>
>
>
>

--
Christoph Maurer B.Sc.

Technische Universität Darmstadt
Institut für Kernphysik
AG Strahlen- und Kernphysik
  -Kosmische Plasmaphysik
Schlossgartenstr. 9
64289 Darmstadt

Office: S2|14-107
Tel.: (+49) 6151 16 4426

On Tue, 15 May 2012 09:24:10 -0700, Christoph Maurer
<christoph.maurer@...> wrote:

> I'm feeling quite stupid now, but I still don't get it to work. The
> error is still the same: PPS peaks are ok, but the timestamp fails the
> plausibility check. Time is taken from the GPS-station itsself via a
> helper utility by the stations manufacturer (My last resort is, that
> this utility might introduce a lag > 500 ms). I would have tried the
> PTB-timeserver instead, but the computer used for measurement does not
> have internet access. Is there any possibility of viewing the difference
> between system-time and "GPS-PPS-time" (the corresponding field is not
> shown when the plausibility check fails)?
>
> Best wishes
> Christoph

I just finished up a project that uses NMEA 0183 GPS to find a correction
number to the RTC speed. If you have PPS by itself, how do you get GPS
time ? I have peeked at TSIP and SIRF and even Motorola protocols. I have
not seen a method of getting GPS time by use of the PPS. Can some one
explain this ?

By the way, every GPS engine I have used, Motorola, Trimble, Rockwell and
a couple of SIRF chipsets put out a 1 PPS even though there is no antenna
connected.

Mike KD7TS

Hi Mike,

my station (a Trimble) has a USB-output, which can either output TSIP
(Trimbles own protocol) or NMEA by an emulated COM-Port. Trimble
provides a tool for adjusting the system time from this output. So, to
answer your question: I indeed have access to an NMEA-output, but I
would have to route it through a USB-COM-converter and use the
PPS-NMEA-merger described on the SpecLab-manual. This however would most
likely render UltraMSK (which is specified to work with the raw
PPS-signal) useless - and validating SpecLabs PAM-function by comparing
it with UltraMSKs output is my goal.

Best Regards
Christoph

Am Dienstag, den 15.05.2012, 11:25 -0700 schrieb kd7ts:
>
> On Tue, 15 May 2012 09:24:10 -0700, Christoph Maurer
> <christoph.maurer@...> wrote:
>
> > I'm feeling quite stupid now, but I still don't get it to work. The
> > error is still the same: PPS peaks are ok, but the timestamp fails
> the
> > plausibility check. Time is taken from the GPS-station itsself via a
> > helper utility by the stations manufacturer (My last resort is, that
> > this utility might introduce a lag > 500 ms). I would have tried the
> > PTB-timeserver instead, but the computer used for measurement does
> not
> > have internet access. Is there any possibility of viewing the
> difference
> > between system-time and "GPS-PPS-time" (the corresponding field is
> not
> > shown when the plausibility check fails)?
> >
> > Best wishes
> > Christoph
>
> I just finished up a project that uses NMEA 0183 GPS to find a
> correction
> number to the RTC speed. If you have PPS by itself, how do you get
> GPS
> time ? I have peeked at TSIP and SIRF and even Motorola protocols. I
> have
> not seen a method of getting GPS time by use of the PPS. Can some one
> explain this ?
>
> By the way, every GPS engine I have used, Motorola, Trimble, Rockwell
> and
> a couple of SIRF chipsets put out a 1 PPS even though there is no
> antenna
> connected.
>
> Mike KD7TS
>
>
>
>
>

--
Christoph Maurer B.Sc.

Technische Universität Darmstadt
Institut für Kernphysik
AG Strahlen- und Kernphysik
  -Kosmische Plasmaphysik
Schlossgartenstr. 9
64289 Darmstadt

Office: S2|14-107
Tel.: (+49) 6151 16 4426

BTW: There is a way to check if the GPS-station sees enough satellites
via the TSIP-protocol (see screenshot)

Am Dienstag, den 15.05.2012, 11:25 -0700 schrieb kd7ts:
>
> On Tue, 15 May 2012 09:24:10 -0700, Christoph Maurer
> <christoph.maurer@...> wrote:
>
> > I'm feeling quite stupid now, but I still don't get it to work. The
> > error is still the same: PPS peaks are ok, but the timestamp fails
> the
> > plausibility check. Time is taken from the GPS-station itsself via a
> > helper utility by the stations manufacturer (My last resort is, that
> > this utility might introduce a lag > 500 ms). I would have tried the
> > PTB-timeserver instead, but the computer used for measurement does
> not
> > have internet access. Is there any possibility of viewing the
> difference
> > between system-time and "GPS-PPS-time" (the corresponding field is
> not
> > shown when the plausibility check fails)?
> >
> > Best wishes
> > Christoph
>
> I just finished up a project that uses NMEA 0183 GPS to find a
> correction
> number to the RTC speed. If you have PPS by itself, how do you get
> GPS
> time ? I have peeked at TSIP and SIRF and even Motorola protocols. I
> have
> not seen a method of getting GPS time by use of the PPS. Can some one
> explain this ?
>
> By the way, every GPS engine I have used, Motorola, Trimble, Rockwell
> and
> a couple of SIRF chipsets put out a 1 PPS even though there is no
> antenna
> connected.
>
> Mike KD7TS
>
>
>
>
>

--
Christoph Maurer B.Sc.

Technische Universität Darmstadt
Institut für Kernphysik
AG Strahlen- und Kernphysik
  -Kosmische Plasmaphysik
Schlossgartenstr. 9
64289 Darmstadt

Office: S2|14-107
Tel.: (+49) 6151 16 4426

On Tue, 15 May 2012 11:45:43 -0700, Christoph Maurer
<christoph.maurer@...> wrote:

> BTW: There is a way to check if the GPS-station sees enough satellites
> via the TSIP-protocol (see screenshot)

I have a similar program from Trimble, and it allows setting the PC clock
to the GPS time. This operates through a RS232 COM port.

I just installed the BETA to look at the GPS documentation, so this is a
new idea to me.

Good luck, and thanks for the info.

Mike

Alan schrieb:
> ----- Original Message -----
>
> Subject: Re: [SpectrumLabUsers] EMU0202 ground lifter
>
>
>> You can't disconnect the lower impedance gound and leave the signal
>> alone. This is the best way how to destroy the input stage.
>>
>> Use a transformer to isolate the input from any ground-loop. I use
>> common-mode ferrite chokes for this.
>> I tried the EMU0202 download link but it is gone.
>
> Did this not work?
>
http://support.creative.com/manuals/download.aspx?nDownloadId=11575&prodName=020\
2_USB_Web%20manual
> Click on "Agree" at the bottom and wait.

Another guy sent it to me, thanks. The manual itself is not more helpful
but recognize that in the spec sheet they explicitly say: differential ADC !


> Or this link seems to go straight to it.
>
<http://ccftp.creative.com/Manuals/TSD/11575/0x6FF24E6A/0202_USB_Web_Manual.pdf>
> They talk about breaking the ground loop.
> Form your own opinion. What do the switches do? As I tested there is a
> resistive leak to dissipate any static but there is no direct connection
> from the input ground when the switches are operated. Creative give no
> warnings so I presume they do no consider damage is likely.
> Removing ground loops involves leaving just one low impedance ground.

For audio people a "ground loop" is the 50/60Hz tone they recognize.
They don't care about current or voltage. The problem is a voltage shift
between two devices from a very low impedance loop. If the switch is
opened, the current cannot circulate anymore but then you have a bigger
voltage between BOTH inputs of the differential input AND ground!!
Because the input is differential as long as the common input range is
not exceeded the effective voltage at the ADC or OpAmp stage is then
substracted and so zero.

What I try to say: I think we say the same but with different words!

When the switch is open in the technical circuit sense, probably
something like 100K // 1nF is effective between case ground and one of
the differential inputs, otherwise shortened.

Maybe someday I will make a circuit diagram of important parts of the
EM0202 here. I wonder that I didn't found any try at the web.


Another interesting point is that this sound-card switches the cut-off
frequency of the analog input stage low-pass filters according of the
chosen sampling frequency. Maybe not in the 192KHz case but in the lower
sampling frequency options.
So if you choose lower bandwidth the S/N should go a little higher.


> Transformers should not be necessary, maybe they help but can cause other
> problems especially if you are using frequencies up to 96KHz..
>

I don't see any intermodulation distortion but didn't investigated this
very careful. Interesting question when the ferrite will go crazy??

Most times the scope is the only ground here.


>
>  They show a newer(?)
>> device, the 0204. Any idea what is newer there? Better ADC/DAC?
>
> I do not know, does it say on the Creative site?
>

Not amused to see all the marketenderizing ;-) So just leaved the site.


- Henry

--
ehydra.dyndns.info

 

Hi,

the first possibility (sampling rate too far off) is unlikely, since a
calibration via DCF77 with the same tolerance works.

The screenshots (as well as a screenshot of the settings window is in
the attachment, the syncd input has already been zoomed)

Thanks
Christoph

I have added Spectrum Lab to my Linux Platform via WINE 1.3.  I can open
the program, however, I can't find any of the sound cards in the computer. I get
the following message " Audio Thread stuck in 8869".

The sound cards available are:

Onboard sound Gigabyte GA-7vax Realtek ALC650
I/O port 0xe400-oxe4ff (RW)

Auzentech Creative SB X-fi  I/O port 0xd000-0xd01f (RW)

The above are not listed in sound cards found window in Spectrum Lab.

Any help appreciated....thanks,

Tom N8TL

 

Hi Tom,

 

Are you running the most recent beta version of SpectrumLab, version 2.78?  After upgrading from 2.77 to 2.78 on a straight Windows-XP platform, I've been having a similar "Audio thread stuck in line xxxx" error where the waterfall will lock up and I have to exit the program altogether; it is upon exiting the program that I get the error message.  I found that if the filter component isn't running in the circuit window, the problem doesn't occur.  I have earlier versions of 2.77 installed, and they run without any problem.  I first noticed the problem in 2.78 build 4, and also build 7.   When SpectrumLab exits and shuts down various components, I see another "Audio thread stuck in line xxxx" message flash up on the screen very briefly, but way too fast to catch the line number.  I checked the SpectrumLab error log that gets generated, but these errors don't show up in the log.  I suspect something in the filter routine is causing the program to hang.  I've been using a tweaked version of SAQReceiver to downconvert 20+kHz signals to audio, so the filter gets employed in that configuration.  If I start from "scratch" with SpectrumLab's default configuration and configure the sample rate, FFT settings, waterfall "band limits", etc. without the filter engaged, everything works fine.  Once I enable the filter, the waterfall stops progressing and the program fails to respond.  Upon exiting, you see the various messages as SpectrumLab shuts down various processes, and ends with the error message you noted.

 

I think the "stable version" available for download on Wolf's website is version 2.77.  You might try that one running on your Linux platform.

 

Ken, WB0OCV
Norton, MA USA
41.959546N, 71.133996W

From: Tom <n8tl@...>
To: SpectrumLabUsers@yahoogroups.com
Sent: Sunday, May 20, 2012 1:30 PM
Subject: [SpectrumLabUsers] Spectrum Lab and Linux Ubuntu 10.04 LTS

 

I have added Spectrum Lab to my Linux Platform via WINE 1.3. I can open
the program, however, I can't find any of the sound cards in the computer. I get the following message " Audio Thread stuck in 8869".

The sound cards available are:

Onboard sound Gigabyte GA-7vax Realtek ALC650
I/O port 0xe400-oxe4ff (RW)

Auzentech Creative SB X-fi I/O port 0xd000-0xd01f (RW)

The above are not listed in sound cards found window in Spectrum Lab.

Any help appreciated....thanks,

Tom N8TL

Hi,

I would like to subtract the right channel audio from the left channel (or vice
versa) and have SL display the difference.  I can't figure out if this is
possible through all the various filter and DSP options.

I basically have an audio source that's supposed to be stereo but sounds quite
monophonic to me.  Because of this, I'd like to configure SL to show me the
difference of the two channels to prove it truly is a mono (or stereo) source. 
Is this possible?

Thanks for the help again,
-Scott

 

Hi all,

 

I'm still getting level glitches in the watch window - anyone have any ideas?

 

I monitor 9 frequencies constantly and once every couple of days there is a level glitch in

most of the frequencies, either up or down. This makes it a bit tricky when you are looking for SIDs...

 

Mark

 

Hi,

I would like to subtract the right channel audio from the left channel (or vice versa) and have SL display the difference. I can't figure out if this is possible through all the various filter and DSP options.

I basically have an audio source that's supposed to be stereo but sounds quite monophonic to me. Because of this, I'd like to configure SL to show me the difference of the two channels to prove it truly is a mono (or stereo) source. Is this possible?

Thanks for the help again,
-Scott

Thanks Wolf!

Exactly what I was looking for.  I was having a difficult time understanding how
to use all that flexibility and the text cleared it up for me.  It's good to
hear that my ears weren't lying to me about the mono broadcast...now to convince
the people at the radio station that they have a problem with their stream.

Thanks once again!
-Scott

--- In SpectrumLabUsers@yahoogroups.com, wolf_dl4yhf <dl4yhf@...> wrote:
>
> Hi Scott,
>
> You can use the 'amplifiers' in the circuit window to subtract one
> channel from another, and connect the spectrum analyser to the result
> (which will usually be L5).
> Details : http://www.qsl.net/dl4yhf/speclab/circuits.htm#output_amplifiers
>
> Quoted from there:
>
>
>  >A little gimmick: With both cross-coupling amplifiers set to "-1"
> (which means subtract left channel from right, and subtract right
> channel from left), it is sometimes possible to remove the vocals from a
> music recording ...
> <
>
> Cheers,
>    Wolf .
>
> Am 21.05.2012 22:06, schrieb aa7sr:
> >
> > Hi,
> >
> > I would like to subtract the right channel audio from the left channel
> > (or vice versa) and have SL display the difference. I can't figure out
> > if this is possible through all the various filter and DSP options.
> >
> > I basically have an audio source that's supposed to be stereo but
> > sounds quite monophonic to me. Because of this, I'd like to configure
> > SL to show me the difference of the two channels to prove it truly is
> > a mono (or stereo) source. Is this possible?
> >
> > Thanks for the help again,
> > -Scott
> >
> >
>

Wolf and Ken:

Re msg 788....I removed 2.75 and installed 2.77 on Linux 10.04 LTS w/
wine.  Now the program loads okay and the "audio thread stuck in 8869"
error does not show.  However, I still cannot select a computer
sound card from audio source menu.  Apparently wine 1.3 cannot see
the cards .e.g. (Creative X-fi) or EMU0202).

Has anyone been successful in operating Spectrum lab from WINE??
What version?? Can we edit a wine file to make it happen???

Thanks,

Tom N8TL

On Wednesday, May 23, 2012 01:19:04 AM you wrote:
> Wolf and Ken:
>
> Re msg 788....I removed 2.75 and installed 2.77 on Linux 10.04 LTS w/
> wine.  Now the program loads okay and the "audio thread stuck in 8869"
> error does not show.  However, I still cannot select a computer
> sound card from audio source menu.  Apparently wine 1.3 cannot see
> the cards .e.g. (Creative X-fi) or EMU0202).
>
> Has anyone been successful in operating Spectrum lab from WINE??
> What version?? Can we edit a wine file to make it happen???
>
> Thanks,
>
> Tom N8TL

Well, that's an ancient version of WINE and likely Pulseaudio too.

There have been some WINE changes. New versions no longer support Pulse
directly but use the ALSA plugin to Pulse.

A recent WINE works fine here and I can select any ALSA input I want.

Your distro is pretty old too. A lot has changed in the audio area since then.

RIck Kunath, k9ao

Hi,

as an Ubuntuuser myself (although I use a windows-machine for SpecLab) I
can tell you that his version is NOT pretty old. 10.04 is a Long Time
support version which will be supported until next year. The new
LTS-version, 12.04 is looked at... controversial but I don't want to go
into details.

Tom, have you tried using this PPA

https://launchpad.net/~ubuntu-wine/+archive/ppa?field.series_filter=lucid

for the newest release? althoug it is not mentioned in the list on this
site, a wine1.4-entry appeared for me after I activated the PPA.

Greetings
Christoph

Am Dienstag, den 22.05.2012, 22:13 -0400 schrieb Rick Kunath:
>
> On Wednesday, May 23, 2012 01:19:04 AM you wrote:
> > Wolf and Ken:
> >
> > Re msg 788....I removed 2.75 and installed 2.77 on Linux 10.04 LTS
> w/
> > wine. Now the program loads okay and the "audio thread stuck in
> 8869"
> > error does not show. However, I still cannot select a computer
> > sound card from audio source menu. Apparently wine 1.3 cannot see
> > the cards .e.g. (Creative X-fi) or EMU0202).
> >
> > Has anyone been successful in operating Spectrum lab from WINE??
> > What version?? Can we edit a wine file to make it happen???
> >
> > Thanks,
> >
> > Tom N8TL
>
> Well, that's an ancient version of WINE and likely Pulseaudio too.
>
> There have been some WINE changes. New versions no longer support
> Pulse
> directly but use the ALSA plugin to Pulse.
>
> A recent WINE works fine here and I can select any ALSA input I want.
>
> Your distro is pretty old too. A lot has changed in the audio area
> since then.
>
> RIck Kunath, k9ao
>
>
>
>

--
Christoph Maurer B.Sc.

Technische Universität Darmstadt
Institut für Kernphysik
AG Strahlen- und Kernphysik
  -Kosmische Plasmaphysik
Schlossgartenstr. 9
64289 Darmstadt

Office: S2|14-107
Tel.: (+49) 6151 16 4426

Hi!

I know that SL shows the frequency of max. amplitude point in the
spectrum shown.
Is it possible to let it auto-calculate the Q of a amplitude peak?
And maybe then the circuit parameters R, L and C at this point?

This would be a great tool to optimize ferrit antennas loaded with a
resonating cap.

Maybe the first step would be to find the sqrt(2) points fL and fR to
calculate the Q. Possibility finding next the noise floor or just
another two point more distanced from peak. I think this all we need to
calculate then all three parameters for a RLC circuit.


Thanks -
Henry

--
ehydra.dyndns.info

 

Wolf,

I am getting some behavior that I don't quite understand.  I am feeding a very pure reference signal into speclab (exactly 500.00000000 hz).  I am measuring and recording a peak_f(499.5,500.5) every second with a FFT length 131072 with no decimation at a nominal sample rate of 5512...  I have the frequency error compensation set to a bandwidth of 1 hz... 30s ud and 200 average.  I am consistently getting refsig measured like 77 microhertz higher than peak_f.  I guess the question is.. why are those two readings different?  shouldn't they tend toward each other?  If not why not and where is my conceptual error?



--
Doc

Bill Dailey
KXØO