Do you have any photo's relating to AMSAT-UK?  if so upload them to the AMSAT-UK
photo Gallery. http://tinyurl.com/5vvpsk5
Have a nice Weekend!

A new free release of WRplus, 1.05 is available for download from
www.wrplus.altervista.org .

Happy Independence Day, to all our American members.

Rob,

Thanks for the kind thoughts.  We colonials are finding that taxation WITH
representation isn't much fun, either.  ;)

73s,

Alan
WA4SCA

Hi Alberto, I wont try and answer the clever stuff :-)) but I would have
thought that a 1 sec "sweep" for a 60 to 2000Mhz spectrum is not unusable. I
personally would be quite happy to live with that a test facility.
Presumably from your calculations narrower sweeps would be able to be
faster. However I do think there is a issue with the settling time of the LO
PLL, and one would not want to start using the output when the LO was still
unlocked. I suspect this could add your timings as I suspect the settling
time will be of the order of msecs (at best).

I am also unsure of how useful a full sweep would be with that resolution.
If you consider say a single carrier within the 1.25MHz, it would be lost
when the energy was averaged out over the bandwidth. In this case a peak
reading might be more useful.  I would expect more use to be made of
narrower sweeps within a band of interest maybe even a s little as 1 or
10MHz

Best Wishes
Alan G3NYK

 

Hi Alberto, I wont try and answer the clever stuff :-)) but I would have
thought that a 1 sec "sweep" for a 60 to 2000Mhz spectrum is not unusable. I
personally would be quite happy to live with that a test facility.

Presumably from your calculations narrower sweeps would be able to be
faster. However I do think there is a issue with the settling time of the LO
PLL, and one would not want to start using the output when the LO was still
unlocked. I suspect this could add your timings as I suspect the settling
time will be of the order of msecs (at best).

I am also unsure of how useful a full sweep would be with that resolution.
If you consider say a single carrier within the 1.25MHz, it would be lost
when the energy was averaged out over the bandwidth. In this case a peak
reading might be more useful.

I would expect more use to be made of narrower sweeps within a band of interest maybe even a s little as 1 or 10MHz

An idea would be not to scan the whole band but only interesting qrg(s)
Say you have an am running on 70 megs ... set fcd to the harmonics and scan
only those ... say you squeeze one 80kc band in a 1 cm wide square ...
Set "stepping soft to 70, 140, 210 etc and put those "bands" one after the
other on the screen ... you see the amp and its harmonics as spikes in the
center of the squares ... that should work fast enough
Okay not a real spectrum analyzer ... but a workaround that could be used
for tuning your amp (or the bandpassfilters)
No need to scan the whole band for that application
Or if you wanna see witch fm local radiostations are transmitting
No need to scan each hz of the whole band from 88 to 108 megs
Set the stepper to 100 kc and and let it run in a loop from 88 to 108
We can not use the fcd as a real spectrum analyzer ... but we can use a
clever built soft for "works similar as" a spectrumanalyzer
Dg9bfc
Sigi


> -----Ursprüngliche Nachricht-----
> Von: FCDevelopment@...
> [mailto:FCDevelopment@...] Im Auftrag von Alberto I2PHD
> Gesendet: Montag, 4. Juli 2011 15:47
> An: FCDevelopment@...
> Betreff: Re: [FCDevelopment] A couple of technical questions
>
>
>
> On 7/4/2011 4:32 PM, Alan Melia wrote:
>
>
>
>  Hi Alberto, I wont try and answer the clever stuff :-)) but I would
> have
>  thought that a 1 sec "sweep" for a 60 to 2000Mhz spectrum is not
> unusable. I
>  personally would be quite happy to live with that a test facility.
>
>
>
> Hi Alan,
>
>    thanks for your answer. Well, it all depends on the usage you do of the
> spectrum analyzer... if, e.g., you want to look at the relative amplitudes
> of the various harmonics of an oscillator or amplifier, while you are
> trimming some components of it, it is frustrating to slightly rotate,
> let's say,  a capacitive trimmer, then wait one or more seconds to see the
> effects, and so on...  in such a circumstance you would like to have a
> real time display fast enough to follow your adjustment...
>
>
>
>
>  Presumably from your calculations narrower sweeps would be able to
> be
>  faster. However I do think there is a issue with the settling time
> of the LO
>  PLL, and one would not want to start using the output when the LO
> was still
>  unlocked. I suspect this could add your timings as I suspect the
> settling
>  time will be of the order of msecs (at best).
>
>
>
> Yes, narrower spans wold give faster times. And I agree with you about the
> settling time of the PLL ( not sure if it is a hardware PLL or a software
> NCO inside the chip). That's why I made the post, to know a bit more from
> those "in the know" ...
>
>
>
>
>  I am also unsure of how useful a full sweep would be with that
> resolution.
>  If you consider say a single carrier within the 1.25MHz, it would be
> lost
>  when the energy was averaged out over the bandwidth. In this case a
> peak
>  reading might be more useful.
>
>
> Yes, probably that should be a user-selectable option, quite easy to
> implement.
>
>
>
>  I would expect more use to be made of narrower sweeps within a band
> of interest maybe even a s little as 1 or 10MHz
>
>
>
> Once set the skeleton, then the flexibility of the software allows for
> many choices...  :-)
>
> Best 73s
>
>
> --
> Alberto I2PHD
>
>

And expanding the idea from Sigi's idea, the comment/question/request i've
noticed popping up every now and then, is at least some sort of scanning feature
for the FCD, as none exist at the moment, in any of the compatible progs, to my
knowlegde at least.

I mean the feature found on all scanners, ie. set the freq range and stepping,
and let it run, either logging or stopping on freqs that have traffic.

When we have that part working, it's easier to expand from that, towards the
(more real) spectrum analyzer.


-- Sami


--- In FCDevelopment@..., "Siegfried Jackstien"
<siegfried.jackstien@...> wrote:
>
> An idea would be not to scan the whole band but only interesting qrg(s)
> Say you have an am running on 70 megs ... set fcd to the harmonics and scan
> only those ... say you squeeze one 80kc band in a 1 cm wide square ...
> Set "stepping soft to 70, 140, 210 etc and put those "bands" one after the
> other on the screen ... you see the amp and its harmonics as spikes in the
> center of the squares ... that should work fast enough
> Okay not a real spectrum analyzer ... but a workaround that could be used
> for tuning your amp (or the bandpassfilters)
> No need to scan the whole band for that application
> Or if you wanna see witch fm local radiostations are transmitting
> No need to scan each hz of the whole band from 88 to 108 megs
> Set the stepper to 100 kc and and let it run in a loop from 88 to 108
> We can not use the fcd as a real spectrum analyzer ... but we can use a
> clever built soft for "works similar as" a spectrumanalyzer
> Dg9bfc
> Sigi
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: FCDevelopment@...
> > [mailto:FCDevelopment@...] Im Auftrag von Alberto I2PHD
> > Gesendet: Montag, 4. Juli 2011 15:47
> > An: FCDevelopment@...
> > Betreff: Re: [FCDevelopment] A couple of technical questions
> >
> >
> >
> > On 7/4/2011 4:32 PM, Alan Melia wrote:
> >
> >
> >
> >  Hi Alberto, I wont try and answer the clever stuff :-)) but I would
> > have
> >  thought that a 1 sec "sweep" for a 60 to 2000Mhz spectrum is not
> > unusable. I
> >  personally would be quite happy to live with that a test facility.
> >
> >
> >
> > Hi Alan,
> >
> >    thanks for your answer. Well, it all depends on the usage you do of the
> > spectrum analyzer... if, e.g., you want to look at the relative amplitudes
> > of the various harmonics of an oscillator or amplifier, while you are
> > trimming some components of it, it is frustrating to slightly rotate,
> > let's say,  a capacitive trimmer, then wait one or more seconds to see the
> > effects, and so on...  in such a circumstance you would like to have a
> > real time display fast enough to follow your adjustment...
> >
> >
> >
> >
> >  Presumably from your calculations narrower sweeps would be able to
> > be
> >  faster. However I do think there is a issue with the settling time
> > of the LO
> >  PLL, and one would not want to start using the output when the LO
> > was still
> >  unlocked. I suspect this could add your timings as I suspect the
> > settling
> >  time will be of the order of msecs (at best).
> >
> >
> >
> > Yes, narrower spans wold give faster times. And I agree with you about the
> > settling time of the PLL ( not sure if it is a hardware PLL or a software
> > NCO inside the chip). That's why I made the post, to know a bit more from
> > those "in the know" ...
> >
> >
> >
> >
> >  I am also unsure of how useful a full sweep would be with that
> > resolution.
> >  If you consider say a single carrier within the 1.25MHz, it would be
> > lost
> >  when the energy was averaged out over the bandwidth. In this case a
> > peak
> >  reading might be more useful.
> >
> >
> > Yes, probably that should be a user-selectable option, quite easy to
> > implement.
> >
> >
> >
> >  I would expect more use to be made of narrower sweeps within a band
> > of interest maybe even a s little as 1 or 10MHz
> >
> >
> >
> > Once set the skeleton, then the flexibility of the software allows for
> > many choices...  :-)
> >
> > Best 73s
> >
> >
> > --
> > Alberto I2PHD
> >
> >
>

Some meory channels in sdr soft and squeezing each channel in a small square
of the spectrum would fit most needs
Dg9bfc
Sigi


> -----Ursprüngliche Nachricht-----
> Von: FCDevelopment@...
> [mailto:FCDevelopment@...] Im Auftrag von tinkatoy2003
> Gesendet: Montag, 4. Juli 2011 17:43
> An: FCDevelopment@...
> Betreff: [FCDevelopment] Re: A couple of technical questions
>
>
>
> And expanding the idea from Sigi's idea, the comment/question/request i've
> noticed popping up every now and then, is at least some sort of scanning
> feature for the FCD, as none exist at the moment, in any of the compatible
> progs, to my knowlegde at least.
>
>
> I mean the feature found on all scanners, ie. set the freq range and
> stepping, and let it run, either logging or stopping on freqs that have
> traffic.
>
> When we have that part working, it's easier to expand from that, towards
> the (more real) spectrum analyzer.
>
> -- Sami
>
> --- In FCDevelopment@...
> <mailto:FCDevelopment%40yahoogroups.co.uk> , "Siegfried Jackstien"
> <siegfried.jackstien@...> wrote:
> >
> > An idea would be not to scan the whole band but only interesting qrg(s)
> > Say you have an am running on 70 megs ... set fcd to the harmonics and
> scan
> > only those ... say you squeeze one 80kc band in a 1 cm wide square ...
> > Set "stepping soft to 70, 140, 210 etc and put those "bands" one after
> the
> > other on the screen ... you see the amp and its harmonics as spikes in
> the
> > center of the squares ... that should work fast enough
> > Okay not a real spectrum analyzer ... but a workaround that could be
> used
> > for tuning your amp (or the bandpassfilters)
> > No need to scan the whole band for that application
> > Or if you wanna see witch fm local radiostations are transmitting
> > No need to scan each hz of the whole band from 88 to 108 megs
> > Set the stepper to 100 kc and and let it run in a loop from 88 to 108
> > We can not use the fcd as a real spectrum analyzer ... but we can use a
> > clever built soft for "works similar as" a spectrumanalyzer
> > Dg9bfc
> > Sigi
> >
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: FCDevelopment@...
> <mailto:FCDevelopment%40yahoogroups.co.uk>
> > > [mailto:FCDevelopment@...
> <mailto:FCDevelopment%40yahoogroups.co.uk> ] Im Auftrag von Alberto I2PHD
> > > Gesendet: Montag, 4. Juli 2011 15:47
> > > An: FCDevelopment@...
> <mailto:FCDevelopment%40yahoogroups.co.uk>
> > > Betreff: Re: [FCDevelopment] A couple of technical questions
> > >
> > >
> > >
> > > On 7/4/2011 4:32 PM, Alan Melia wrote:
> > >
> > >
> > >
> > > Hi Alberto, I wont try and answer the clever stuff :-)) but I would
> > > have
> > > thought that a 1 sec "sweep" for a 60 to 2000Mhz spectrum is not
> > > unusable. I
> > > personally would be quite happy to live with that a test facility.
> > >
> > >
> > >
> > > Hi Alan,
> > >
> > > thanks for your answer. Well, it all depends on the usage you do of
> the
> > > spectrum analyzer... if, e.g., you want to look at the relative
> amplitudes
> > > of the various harmonics of an oscillator or amplifier, while you are
> > > trimming some components of it, it is frustrating to slightly rotate,
> > > let's say, a capacitive trimmer, then wait one or more seconds to see
> the
> > > effects, and so on... in such a circumstance you would like to have a
> > > real time display fast enough to follow your adjustment...
> > >
> > >
> > >
> > >
> > > Presumably from your calculations narrower sweeps would be able to
> > > be
> > > faster. However I do think there is a issue with the settling time
> > > of the LO
> > > PLL, and one would not want to start using the output when the LO
> > > was still
> > > unlocked. I suspect this could add your timings as I suspect the
> > > settling
> > > time will be of the order of msecs (at best).
> > >
> > >
> > >
> > > Yes, narrower spans wold give faster times. And I agree with you about
> the
> > > settling time of the PLL ( not sure if it is a hardware PLL or a
> software
> > > NCO inside the chip). That's why I made the post, to know a bit more
> from
> > > those "in the know" ...
> > >
> > >
> > >
> > >
> > > I am also unsure of how useful a full sweep would be with that
> > > resolution.
> > > If you consider say a single carrier within the 1.25MHz, it would be
> > > lost
> > > when the energy was averaged out over the bandwidth. In this case a
> > > peak
> > > reading might be more useful.
> > >
> > >
> > > Yes, probably that should be a user-selectable option, quite easy to
> > > implement.
> > >
> > >
> > >
> > > I would expect more use to be made of narrower sweeps within a band
> > > of interest maybe even a s little as 1 or 10MHz
> > >
> > >
> > >
> > > Once set the skeleton, then the flexibility of the software allows for
> > > many choices... :-)
> > >
> > > Best 73s
> > >
> > >
> > > --
> > > Alberto I2PHD
> > >
> > >
> >
>
>
>
>

Any one with time on their hands? We are looking for some one to write a
Wikipedia entry for the FUNcube & FUNcube Dongle.
contact me for more details at m0tfo at amsat.org
Many Thanks
Rob
AMSAT-UK

Sounds like a great job for you Rob.

Mike

--- In FCDevelopment@..., "Rob M0TFO" <robpegs@...> wrote:
>
> Any one with time on their hands? We are looking for some one to write a
> Wikipedia entry for the FUNcube & FUNcube Dongle.
> contact me for more details at m0tfo at amsat.org
> Many Thanks
> Rob
> AMSAT-UK
>

http://en.wikipedia.org/wiki/Wikipedia:Articles_for_creation
you should start here (as far as i know)
dg9bfc
sigi


> -----Ursprüngliche Nachricht-----
> Von: FCDevelopment@...
> [mailto:FCDevelopment@...] Im Auftrag von Rob Styles
> Gesendet: Montag, 11. Juli 2011 19:48
> An: FCDevelopment@...
> Betreff: Re: [FCDevelopment] Re: Funcube Wikipedia
>
>
>
> Forgot to add, I would not know where to start with Wikipedia !
>
>
> On 11 Jul 2011, at 20:40, mike.willis@... wrote:
>
>
>
>
>  Sounds like a great job for you Rob.
>
>  Mike
>
>  --- In FCDevelopment@...
> <mailto:FCDevelopment%40yahoogroups.co.uk> , "Rob M0TFO" <robpegs@...>
> wrote:
>  >
>  > Any one with time on their hands? We are looking for some one to
> write a
>  > Wikipedia entry for the FUNcube & FUNcube Dongle.
>  > contact me for more details at m0tfo at amsat.org
>  > Many Thanks
>  > Rob
>  > AMSAT-UK
>  >
>
>
>
>
>

What are valid ranges for DC I Offset, DC Q Offset, IQ Phase Balance and
IQ Gain Balance?

I am adding sliders to play with to the GNU Radio Companion interface and don't
know what the upper and lower bounds are for those.

Ed

Further to that - these are in reality 2 byte integers so the range is limited
to that resolution i.e. there are about 65k values. Alex has put this range into
a +-1.0 float. Generally, the full range is not needed, only perhaps 1/10th of
it.

Mike

--- In FCDevelopment@..., Alexandru Csete <oz9aec@...> wrote:
>
> On Mon, Jul 18, 2011 at 11:50 PM, phoneguin <ed@...> wrote:
>
> > What are valid ranges for DC I Offset, DC Q Offset, IQ Phase Balance and
> > IQ Gain Balance?
> >
> > I am adding sliders to play with to the GNU Radio Companion interface and
> > don't know what the upper and lower bounds are for those.
> >
> >
> Hi Ed,
>
> The range is -1.0 to +1.0
> The info is included in the documentation of the source code and the GRC
> block, which should be visible in the properties box for the FCD block.
>
> Alex
>

Hi,

If you've got a story to tell about applying the FCD to a task or general
operation we would love to hear about it at the AMSAT Colloquium in Guildford
this weekend.

I've got a couple of short sessions (20-30 mins) available for presentations

Please contact g4dpz@...

http://www.uk.amsat.org/colloquium-2011

Regards

- Dave, G4DPZ

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

From: David Johnson

To: FCDevelopment@...

Sent: Monday, July 25, 2011 12:51 PM

Subject: [FCDevelopment] Tell us your experiences of FCD at the AMSAT Colloquium

 

Hi,

If you've got a story to tell about applying the FCD to a task or general operation we would love to hear about it at the AMSAT Colloquium in Guildford this weekend.

I've got a couple of short sessions (20-30 mins) available for presentations

Please contact g4dpz@...

http://www.uk.amsat.org/colloquium-2011

Regards

- Dave, G4DPZ

Greetings,

Gqrx SDR for the Funcube Dongle is now available as an alpha release:
http://www.oz9aec.net/index.php/gnu-radio/gqrx-sdr
It is powered by GNU Radio sdr core and Qt user interface.

Source an binary packages for linux have been uploaded to sourceforge:
http://sourceforge.net/projects/gqrx/files/1.9.158/

The binary packages for Linux include the necessary GNU Radio
libraries so you don't need to build it from scratch. All other
dependencies (listed in the README) are available via the package
manager of your distribution.

I might have a mac bundle soon but don't hold your breath.

Have fun and feel free to fork me on Github https://github.com/csete/gqrx

73
Alex OZ9AEC

Alex,

Looks really good. Please release a Mac version soon:)



On Jul 30, 2011, at 3:47 PM, Alexandru Csete wrote:

> Greetings,
>
> Gqrx SDR for the Funcube Dongle is now available as an alpha release:
> http://www.oz9aec.net/index.php/gnu-radio/gqrx-sdr
> It is powered by GNU Radio sdr core and Qt user interface.
>
> Source an binary packages for linux have been uploaded to sourceforge:
> http://sourceforge.net/projects/gqrx/files/1.9.158/
>
> The binary packages for Linux include the necessary GNU Radio
> libraries so you don't need to build it from scratch. All other
> dependencies (listed in the README) are available via the package
> manager of your distribution.
>
> I might have a mac bundle soon but don't hold your breath.
>
> Have fun and feel free to fork me on Github https://github.com/csete/gqrx
>
> 73
> Alex OZ9AEC
>

If you attended or watched the AMSAT-UK Colloquium Via WebStream , Please take
our short Survey.

http://amsat-uk.limeask.com/
Regards

Hi Guys,

I've just downloaded the precompiled Qthid 3.0 for Mac OS X and it crashes on
startup if my FUNCube dongle is plugged in.  If I start Qthid without the
FUNCube plugged in it starts fine and crashes as soon as I insert my FUNCube
dongle.  I went back and tried the 2.2 and 2.1 precompiled versions of Qthid and
these also crash when the dongle is plugged in.

I have tried version 3.0 on my Snow Leopard Mac Mini and it works fine.  I used
this machine to verify that I am running the 18f firmware. Do I need to upgrade
to 18h?

I suspect it might be to do with some of the new security features of Lion.  The
crash dump looks like it might be something to do with the stack guard.

Has anyone else tried Qthid on Lion and got it working?

Thanks,

Matt
VK6MR

I've had a further look at the crash report and it is consistently crashing in
hid_report_callback with an EXC_BAD_ACCESS (SIGSEGV) exception.

Not seeing anything obviously wrong with that subroutine, perhaps IOKit has
changed slightly between Snow Leopard and Lion.

Matt
VK6MR

--- In FCDevelopment@..., Rob Styles <robpegs@...> wrote:
>
> Hi Matt
> 18f is fine, I've just gone over to Lion so will try it an a couple of hours,
only 6.30am here
> I will let you know my findings.
> Rob M0TFO
> On 6 Aug 2011, at 06:19, Matthew wrote:
>
> > Hi Guys,
> >
> > I've just downloaded the precompiled Qthid 3.0 for Mac OS X and it crashes
on startup if my FUNCube dongle is plugged in. If I start Qthid without the
FUNCube plugged in it starts fine and crashes as soon as I insert my FUNCube
dongle. I went back and tried the 2.2 and 2.1 precompiled versions of Qthid and
these also crash when the dongle is plugged in.
> >
> > I have tried version 3.0 on my Snow Leopard Mac Mini and it works fine. I
used this machine to verify that I am running the 18f firmware. Do I need to
upgrade to 18h?
> >
> > I suspect it might be to do with some of the new security features of Lion.
The crash dump looks like it might be something to do with the stack guard.
> >
> > Has anyone else tried Qthid on Lion and got it working?
> >
> > Thanks,
> >
> > Matt
> > VK6MR
> >
> >
>

I've got a feeling this is a  X86 64Bit issue

Rob

OK, so I've been playing with a small test harness that uses fcd.c and hidmac.c
to do try various things.

Once I start making more than a couple of calls to various fcd functions I get
segmentation faults.  I have tried compiling as both 32 bit and 64 bit and both
have issues.

I began to think that the problem might be something to do with continually
opening and closing the FCD, using fcdOpen and fcdClose, so I modified fed.c so
that fcdOpen reuses a previously opened connection and fcdClose is a no-op.

My test harness now seems to run without issues every time.

I am no expert with IOKit but what I think is happening is that fcd.c opens the
HID device in IOKit, quickly does its thing and then closes the HID device.
Sometime after this IOKit is coming along with a callback to hidmac.c but the
device has already been closed and  this generates the segfault.

This feels to me like a bug in IOKit but as I say I'm no expert.  It might be a
bug in hidapi, I don't think it is a bug in Qthid but it might be possible to
mitigate the problem in Qthid by reusing the hid device rather than
opening/closing it for every query to the device.

I'm not sure I can do much more as I don't want to get into rebuilding qthid
from scratch as I don't want to have to deal with the Qt toolchain.

HTH,

Matt

--- In FCDevelopment@..., "Rob M0TFO" <robpegs@...> wrote:
>
> I've got a feeling this is a  X86 64Bit issue
>
> Rob
>