Regarding missing osmocom source

[Rozana Alam]

Hello community,
I want to generate simple continuous wave with bladeRF using gnu radio and
am a Linux user.but in the gnu platform I am not getting any osmocom
source.i have downloaded the gnu from ppa .is there any supplement of
osmocom source to generate signal by bladeRF?
Your suggestions are highly appreciated.
Best regards,
Rozana.

Re: Regarding missing osmocom source

[Christophe Seguinot]

  
  
Hi
You must install gr-osmosdr to use SDR dongle ( I don't use Blade
  RF and don't know if there are other gr tools for Blade RF
  source/sink )
at the end of september, for Linux distribution (Ubuntu 20.04 in
  my case):


  gr-osmosdr is not compatible with GR 3.9 (see some recent mail
on this list) so don't use GR 3.9 (Some guys are trying to port
gr-osmosdr to 3.9 )
  
  3.8.2 is the default GR version under Ubuntu 20.04 (using
ppa:gnuradio/gnuradio-releases)
  
  if you install gr-osmosdr from package, it won't work under
  GR
  
  if you build gr-osmosdr from source, you can get a working
  GR3.8 with osmo-sdr sources as well as GQRX too. 
  

See my email on this list https://lists.gnu.org/archive/html/discuss-gnuradio/2020-09/msg00124.html
  for furter information
Sincerely 

On 04/11/2020 09:39, Rozana Alam wrote:


  
  

  

  

  
Hello community,
  I want to generate simple
continuous wave with bladeRF using gnu radio and
am a Linux user.but in the gnu platform I am not
getting any osmocom source.i have downloaded the
gnu from ppa .is there any supplement of osmocom
source to generate signal by bladeRF?
  Your suggestions are highly
appreciated.
  Best regards,
  Rozana.



  

  

  
  

  

  

  




  

  

  

  

  

  

Re: explaining i/q

[Fons Adriaensen]

On Wed, Nov 04, 2020 at 12:38:27AM +0100, Kristoff wrote:
 
> So, what is iq-sampling?
> IQ-sampling is like sampling a normal ("real") signal -i.e. what most people
> are familiar with-, ... except that you sample the data twice for each
> period: once at timer "t" and a second time 1/4 sampling period later. (*)

This is fundamentally wrong, and you will do your audience
a very bad service.

What are you going the answer if anyone in your audience
asks the obvious question:

   So, it's the same as having four times the sample rate,
   and then throwing away half of the samples ? Why would
   I want to do that ?

The 'spinning dancer' is really the right intuitive model.

You look at a rotating object from two points, the second at
90 degrees from the first. This allows you to find out in 
which sense it rotates.

For example it allows you to know if some frequency is in
the upper or lower sideband, even if the signal shifted to
zero carrier frequency.

There is another good reason to use complex-valued signals:
it really simplifies all DSP theory. A lot of strange factors
of 2, corner cases at or around DC,  and other anomalies that
occur with real-valued signals just disappear.  

Whenever I have to explain some DSP principles, I start with
the complex valued version, and then showing the real-valued
one as a special case.

-- 
FA

Re: Regarding missing osmocom source

[Rozana Alam]

Thank you for the information. I have installed GRC byUbuntu ppa and I
believe that it has installed the latest version.in that case should I
delete and build the GRC from the beginning from source? please guide me.

On Wed, 4 Nov 2020, 6:58 pm Christophe Seguinot, <
christophe.segui...@orange.fr> wrote:

> Hi
>
> You must install gr-osmosdr to use SDR dongle ( I don't use Blade RF and
> don't know if there are other gr tools for Blade RF source/sink )
>
> at the end of september, for Linux distribution (Ubuntu 20.04 in my case):
>
>- gr-osmosdr is not compatible with GR 3.9 (see some recent mail on
>this list) so don't use GR 3.9 (Some guys are trying to port gr-osmosdr to
>3.9 )
>- 3.8.2 is the default GR version under Ubuntu 20.04 (using
>ppa:gnuradio/gnuradio-releases)
>- if you install gr-osmosdr from package,* it won't work under GR*
>- if you build gr-osmosdr from source, *you can get a working GR3.8
>with osmo-sdr sources as well as GQRX too*.
>
> See my email on this list
> https://lists.gnu.org/archive/html/discuss-gnuradio/2020-09/msg00124.html
> for furter information
>
> Sincerely
> On 04/11/2020 09:39, Rozana Alam wrote:
>
> Hello community,
> I want to generate simple continuous wave with bladeRF using gnu radio and
> am a Linux user.but in the gnu platform I am not getting any osmocom
> source.i have downloaded the gnu from ppa .is there any supplement of
> osmocom source to generate signal by bladeRF?
> Your suggestions are highly appreciated.
> Best regards,
> Rozana.
>
>
>

Re: Regarding missing osmocom source

[Mohamed Yaaseen]

Hello,

Yes, as Christiophe mentioned i don't think we have a working version of gr
osmocom that is compatible with gnuradio 3.9.
If your ppa version of gnuradio that you have downloaded is 3.8.2 then you
just need to build osmocom sdr by pulling from its master branch.
You can find the gnuradio version by using the command
"gnuradio-config-info"
I have been using bladeRF for quite some time now. Currently running
gnuradio 3.8.2 with osmocom under ubuntu 20.04 LTS. Both of them build from
source.  BladeRF is running seamlessly.
You can also try soapySDR to get BladeRF support.


Cheers,
Yaseen



On Wed, 4 Nov 2020, 1:24 pm Rozana Alam,  wrote:

> Thank you for the information. I have installed GRC byUbuntu ppa and I
> believe that it has installed the latest version.in that case should I
> delete and build the GRC from the beginning from source? please guide me.
>
> On Wed, 4 Nov 2020, 6:58 pm Christophe Seguinot, <
> christophe.segui...@orange.fr> wrote:
>
>> Hi
>>
>> You must install gr-osmosdr to use SDR dongle ( I don't use Blade RF and
>> don't know if there are other gr tools for Blade RF source/sink )
>>
>> at the end of september, for Linux distribution (Ubuntu 20.04 in my case):
>>
>>- gr-osmosdr is not compatible with GR 3.9 (see some recent mail on
>>this list) so don't use GR 3.9 (Some guys are trying to port gr-osmosdr to
>>3.9 )
>>- 3.8.2 is the default GR version under Ubuntu 20.04 (using
>>ppa:gnuradio/gnuradio-releases)
>>- if you install gr-osmosdr from package,* it won't work under GR*
>>- if you build gr-osmosdr from source, *you can get a working GR3.8
>>with osmo-sdr sources as well as GQRX too*.
>>
>> See my email on this list
>> https://lists.gnu.org/archive/html/discuss-gnuradio/2020-09/msg00124.html
>> for furter information
>>
>> Sincerely
>> On 04/11/2020 09:39, Rozana Alam wrote:
>>
>> Hello community,
>> I want to generate simple continuous wave with bladeRF using gnu radio
>> and am a Linux user.but in the gnu platform I am not getting any osmocom
>> source.i have downloaded the gnu from ppa .is there any supplement of
>> osmocom source to generate signal by bladeRF?
>> Your suggestions are highly appreciated.
>> Best regards,
>> Rozana.
>>
>>
>>

Re: explaining i/q

[Kristoff]

Jef,


Concerning the term "slope". Well, I also have my doubts about it. I 
think that for a lot of people, this would create the assumption that 
the signal then goes from the 'i' value to the 'q' value in a straight 
line, which is -as we know- not the case.


Sometimes it helps to -at first- give a very basic mental image of 
something, and -at the end, when people understand the topic- "correct" 
that image with a more correct one, or just point them to some youtube 
video that explains the topic in more detail.



Anycase,this is indeed all an interesting exercise in braking down 
concepts into very small steps.


The amateur-radio community is a bit strange as most people do have a 
technical background, but for a large number of hams, that is mainly 
based on assumptions or "that's what they said in the ham-radio 
courses", without understanding the full technical details, especially 
topics that are highly based on math.
For most hams, "SDR" is just "that piece of software you install on your 
computer to look at  waterfall graphs".


So we have a very long way to go. :-)


73
kristoff - ON1ARF



On 4/11/2020 02:21, Jeff Long wrote:
It's more important to give people some mental picture than to make 
sure it's completely correct. But, I would not use the "slope" 
terminology. The important things are, as you've said, (1) with the 
complex type, you can have a signal at baseband that is not symmetric, 
and (2) the price for this is doubling the amount of data needed. The 
signal you deal with at baseband is the same signal that is seen 
centered on the RF carrier.


I don't see a great way to talk about "phase" without going into the 
math. It is important to get into "phase" when you talk about any 
modulation fancier than slow FSK.


Good luck. Hope you find the right balance between useful, digestible, 
and correct.


On Tue, Nov 3, 2020 at 7:20 PM David Hagood > wrote:


I am sorrowful that you have decided you are going to stick with an
explanation that is fundamentally incorrect. I know how direct
conversion systems work - I design the software for them for a
living.
What you are basing your mental model on is an optimization for
the case
where the system is both sub-sampling the signal and going digital in
the same operation. However, in many extremely high sample rate
systems,
the signal is brought down to baseband by mixing it with analog
quadrature signals - that's the place where I and Q come from - and I
assure you the only "delay by 90 degrees" is in the creation of the
quadrature LO signals, not in the sampling of the actual data. But
I've
been around the Sun enough times to know that since you have decided
upon this course and don't seem to want to change, there's no
point in
continuing to try to help.

Re: Regarding missing osmocom source

[Christophe Seguinot]

  
  
Hi
Yes this is correct ( was correct in september 2020). You must
  first uninstall gr-osmocom if you installed it from ppa, then
  compile from source as indicated in the attached PDF file here https://lists.gnu.org/archive/html/discuss-gnuradio/2020-09/msg00124.html
In fact, first test your GR version since both 3.8 and 3.9 are in
  PPA (using the command "gnuradio-config-info")
If I remember correctly, some people on this list were trying to
  port gr-osmocom to GR 3.9 (one month ago)
Regards 



On 04/11/2020 13:44, Mohamed Yaaseen
  wrote:


  
  Hello,


Yes, as Christiophe mentioned i don't think we
  have a working version of gr osmocom that is compatible with
  gnuradio 3.9.
If your ppa version of gnuradio that you have
  downloaded is 3.8.2 then you just need to build osmocom sdr by
  pulling from its master branch.
You can find the gnuradio version by using the
  command
"gnuradio-config-info"
I have been using bladeRF for quite some time
  now. Currently running gnuradio 3.8.2 with osmocom under
  ubuntu 20.04 LTS. Both of them build from source.  BladeRF is
  running seamlessly.
You can also try soapySDR to get BladeRF
  support.




Cheers,
Yaseen





  On Wed, 4 Nov 2020, 1:24 pm
Rozana Alam, 
wrote:
  
  
Thank you for the information. I have
  installed GRC byUbuntu ppa and I believe that it has
  installed the latest version.in
  that case should I delete and build the GRC from the
  beginning from source? please guide me.


  On Wed, 4 Nov 2020, 6:58
pm Christophe Seguinot, 
wrote:
  
  

  Hi
  You must install gr-osmosdr to use SDR dongle ( I
don't use Blade RF and don't know if there are other
gr tools for Blade RF source/sink )
  at the end of september, for Linux distribution
(Ubuntu 20.04 in my case):
  
  
gr-osmosdr is not compatible with GR 3.9 (see
  some recent mail on this list) so don't use GR 3.9
  (Some guys are trying to port gr-osmosdr to 3.9 )

3.8.2 is the default GR version under Ubuntu
  20.04 (using ppa:gnuradio/gnuradio-releases)

if you install gr-osmosdr from package, it
won't work under GR

if you build gr-osmosdr from source, you can
get a working GR3.8 with osmo-sdr sources as
well as GQRX too. 

  
  See my email on this list https://lists.gnu.org/archive/html/discuss-gnuradio/2020-09/msg00124.html
for furter information
  Sincerely 
  
  On 04/11/2020 09:39, Rozana Alam wrote:
  
  

  

  

  

  Hello community,
I want to generate
  simple continuous wave with
  bladeRF using gnu radio and am a
  Linux user.but in the gnu platform
  I am not getting any osmocom
  source.i have downloaded the gnu
  from ppa .is there any supplement
  of osmocom source to generate
  signal by bladeRF?
Your suggestions are
  highly appreciated.
Best regards,
Rozana.
  
   

  

  


  

  

  

 

Re: explaining i/q

[Christophe Seguinot]

  
  
Hi 

I do agree with Jeff Long. 

You will have to distinguish Sampling and IQ: 


  Complex signal are not related to sampling, even if sampled
signals in GR are generally complex 
  
  Complex signal come from the baseband equivalent
representation of  passband signal (modulated). Explaining that
with at least some background in complex number, phase of a
modulated signal, and/or ID modulator and demodulator.
  
  Sampling is an operation which  aims at giving an approximate
representation of time continuous signals. It is applied to real
signal as well as complex signals. Continuous signal can't be
represented in a computer. 
  

Regards, Christophe 



On 04/11/2020 13:50, Kristoff wrote:

Jef,
  
  
  
  Concerning the term "slope". Well, I also have my doubts about it.
  I think that for a lot of people, this would create the assumption
  that the signal then goes from the 'i' value to the 'q' value in a
  straight line, which is -as we know- not the case.
  
  
  Sometimes it helps to -at first- give a very basic mental image of
  something, and -at the end, when people understand the topic-
  "correct" that image with a more correct one, or just point them
  to some youtube video that explains the topic in more detail.
  
  
  
  Anycase,this is indeed all an interesting exercise in braking down
  concepts into very small steps.
  
  
  The amateur-radio community is a bit strange as most people do
  have a technical background, but for a large number of hams, that
  is mainly based on assumptions or "that's what they said in the
  ham-radio courses", without understanding the full technical
  details, especially topics that are highly based on math.
  
  For most hams, "SDR" is just "that piece of software you install
  on your computer to look at  waterfall graphs".
  
  
  So we have a very long way to go. :-)
  
  
  
  73
  
  kristoff - ON1ARF
  
  
  
  
  On 4/11/2020 02:21, Jeff Long wrote:
  
  It's more important to give people some
mental picture than to make sure it's completely correct. But, I
would not use the "slope" terminology. The important things are,
as you've said, (1) with the complex type, you can have a signal
at baseband that is not symmetric, and (2) the price for this is
doubling the amount of data needed. The signal you deal with at
baseband is the same signal that is seen centered on the RF
carrier.


I don't see a great way to talk about "phase" without going into
the math. It is important to get into "phase" when you talk
about any modulation fancier than slow FSK.


Good luck. Hope you find the right balance between useful,
digestible, and correct.


On Tue, Nov 3, 2020 at 7:20 PM David Hagood
 wrote:


    I am sorrowful that you have decided you are going to stick
with an

    explanation that is fundamentally incorrect. I know how
direct

    conversion systems work - I design the software for them for
a

    living.

    What you are basing your mental model on is an optimization
for

    the case

    where the system is both sub-sampling the signal and going
digital in

    the same operation. However, in many extremely high sample
rate

    systems,

    the signal is brought down to baseband by mixing it with
analog

    quadrature signals - that's the place where I and Q come
from - and I

    assure you the only "delay by 90 degrees" is in the creation
of the

    quadrature LO signals, not in the sampling of the actual
data. But

    I've

    been around the Sun enough times to know that since you have
decided

    upon this course and don't seem to want to change, there's
no

    point in

    continuing to try to help.



  
  
  

  

Re: explaining i/q

[Anon Lister]

> On Nov 4, 2020, at 07:13, Fons Adriaensen  wrote:
> 
> Whenever I have to explain some DSP principles, I start with
> the complex valued version, and then showing the real-valued
> one as a special case.

This is absolutely correct here. If they are learning gnuradio, they obviously 
want to do digital signal processing. Much of DSP is far easier when you have a 
center frequency of 0hz and your visible bandwidth is = to your sample rate. 
(Not 2x as required by real sampling)

How about a view of how you convert one representation to the other:
Take the real values(sampled to meet nyquist, at 2x the desired bandwidth, or 
max frequency), and insert a 0 every other sample. Treat every pair real, 0 as 
a one complex sample.

There is fundamentally no change here yet except to double the data storage 
requirement. These however are now complex values. 

Now, since you can “use” the negative frequency space, since it no longer is 
required to be mirror image of the positive, you can(circularly!) shift all 
frequencies by -1/4 the sampling rate. 

This will give still not alter the actual information present, merely shift all 
frequencies present halfway into the now usable negative frequency axis. They 
are NO LONGER MIRRORS. 

Now decimate by two since you have two empty halves of visible bandwidth at the 
edges. You now represent a range (complex)[-bandwidth/2, bandwidth/2] as 
opposed to (real)[0, bandwidth*2]

This process is entirely reversible, just do the steps backwards, (interpolate 
by 2, shift by Fs/4, drop the complex part (now 0)).

Both require the same storage, and can view the same bandwidth. Real needs 2x 
samples per bandwidth, in complex visible bandwidth = sample rate, but you 
store two values per sample. 

From a storage perspective, they are entirely equivalent. It’s not that you are 
taking extra samples or whatever you said. To use ham numbers: instead of 
storing a 48khz real file representing 24khz of visible bandwidth from 0 to 
48000hz, you store a 24k file representing -12k to 12k. In both cases you have 
24k of usable bandwidth, and use the same number of bytes to store it. 

The advantage of using complex is that the maths behind many DSP operations are 
vastly simplified by having the center frequency at 0 and bandwidth = to sample 
rate(and due to other properties of complex numbers). For example, most 
filtering now is simply a low pass filter, symmetric around 0 as opposed to 
band pass(composed of a low and a high). 
Am detect is just squaring the complex samples.
Fm detect is just calling atan2 on the quardrature components (and optionally 
rescaling)
Etc...

(Weather you think one representation or the other is more fundamental is 
largely due to your background. I’m of the opinion that complex is the more 
fundamental representation of an electromagnetic wave, the quantum mechanical 
representation is complex too, real is just an inconvenient projection in the 
middle introduced by the fact that we measure via electrical voltage on a wire, 
necessitating doubling our sample rate to recover the underlying wave(still 
with a phase ambiguity), but that’s opinion)

-
Anon

Re: Regarding missing osmocom source

[Christophe Seguinot]

  
  
Sorry the link was wrong see https://lists.gnu.org/archive/html/discuss-gnuradio/2020-09/msg00123.html


On 04/11/2020 14:22, Christophe
  Seguinot wrote:


  
  Hi
  Yes this is correct ( was correct in september 2020). You must
first uninstall gr-osmocom if you installed it from ppa, then
compile from source as indicated in the attached PDF file here https://lists.gnu.org/archive/html/discuss-gnuradio/2020-09/msg00124.html
  In fact, first test your GR version since both 3.8 and 3.9 are
in PPA (using the command "gnuradio-config-info")
  If I remember correctly, some people on this list were trying
to port gr-osmocom to GR 3.9 (one month ago)
  Regards 
  
  
  
  On 04/11/2020 13:44, Mohamed Yaaseen
wrote:
  
  

Hello,
  
  
  Yes, as Christiophe mentioned i don't think we
have a working version of gr osmocom that is compatible with
gnuradio 3.9.
  If your ppa version of gnuradio that you have
downloaded is 3.8.2 then you just need to build osmocom sdr
by pulling from its master branch.
  You can find the gnuradio version by using the
command
  "gnuradio-config-info"
  I have been using bladeRF for quite some time
now. Currently running gnuradio 3.8.2 with osmocom under
ubuntu 20.04 LTS. Both of them build from source.  BladeRF
is running seamlessly.
  You can also try soapySDR to get BladeRF
support.
  
  
  
  
  Cheers,
  Yaseen
  
  
  
  
  
On Wed, 4 Nov 2020, 1:24
  pm Rozana Alam, 
  wrote:


  Thank you for the information. I have
installed GRC byUbuntu ppa and I believe that it has
installed the latest version.in that case should
I delete and build the GRC from the beginning from
source? please guide me.
  
  
On Wed, 4 Nov 2020,
  6:58 pm Christophe Seguinot, 
  wrote:


  
Hi
You must install gr-osmosdr to use SDR dongle ( I
  don't use Blade RF and don't know if there are
  other gr tools for Blade RF source/sink )
at the end of september, for Linux distribution
  (Ubuntu 20.04 in my case):


  gr-osmosdr is not compatible with GR 3.9 (see
some recent mail on this list) so don't use GR
3.9 (Some guys are trying to port gr-osmosdr to
3.9 )
  
  3.8.2 is the default GR version under Ubuntu
20.04 (using ppa:gnuradio/gnuradio-releases)
  
  if you install gr-osmosdr from package, it
  won't work under GR
  
  if you build gr-osmosdr from source, you
  can get a working GR3.8 with osmo-sdr sources
  as well as GQRX too. 
  

See my email on this list https://lists.gnu.org/archive/html/discuss-gnuradio/2020-09/msg00124.html
  for furter information
Sincerely 

On 04/11/2020 09:39, Rozana Alam wrote:


  

  

  

  
Hello community,
  I want to generate
simple continuous wave with
bladeRF using gnu radio and am a
Linux user.but in the gnu
platform I am not getting any
osmocom source.i have downloaded
the gnu from ppa .is there any
supplement of osmocom source to
generate signal by bladeRF?
  Your suggestions
are highly appreciated.
  Best regards,
  

Re: explaining i/q

[Anon Lister]

Oops small correction, prior to decimate by 2 in the conversion, you have to 
low pass filter by fs/4. (Or use a decimating filter)

Whoops.

-
Anon

> On Nov 4, 2020, at 08:47, Anon Lister  wrote:
> 
> Now decimate by two since you have two empty halves of visible bandwidth at 
> the edges.

Re: explaining i/q

[Don Wade]

Here’s a YouTube video that’s got a bit of pencil math (so it doesn’t drone on) 
and oscilloscopes (for the ham guys), so it’s got a bit for everyone .

https://m.youtube.com/watch?list=PLvOgjCaG0WzDAF1Um894vv95mrcyortOB&v=h_7d-m1ehoY

> On Nov 4, 2020, at 7:52 AM, Kristoff  wrote:
> 
> Jef,
> 
> 
> Concerning the term "slope". Well, I also have my doubts about it. I think 
> that for a lot of people, this would create the assumption that the signal 
> then goes from the 'i' value to the 'q' value in a straight line, which is 
> -as we know- not the case.
> 
> Sometimes it helps to -at first- give a very basic mental image of something, 
> and -at the end, when people understand the topic- "correct" that image with 
> a more correct one, or just point them to some youtube video that explains 
> the topic in more detail.
> 
> 
> Anycase,this is indeed all an interesting exercise in braking down concepts 
> into very small steps.
> 
> The amateur-radio community is a bit strange as most people do have a 
> technical background, but for a large number of hams, that is mainly based on 
> assumptions or "that's what they said in the ham-radio courses", without 
> understanding the full technical details, especially topics that are highly 
> based on math.
> For most hams, "SDR" is just "that piece of software you install on your 
> computer to look at  waterfall graphs".
> 
> So we have a very long way to go. :-)
> 
> 
> 73
> kristoff - ON1ARF
> 
> 
> 
>> On 4/11/2020 02:21, Jeff Long wrote:
>> It's more important to give people some mental picture than to make sure 
>> it's completely correct. But, I would not use the "slope" terminology. The 
>> important things are, as you've said, (1) with the complex type, you can 
>> have a signal at baseband that is not symmetric, and (2) the price for this 
>> is doubling the amount of data needed. The signal you deal with at baseband 
>> is the same signal that is seen centered on the RF carrier.
>> 
>> I don't see a great way to talk about "phase" without going into the math. 
>> It is important to get into "phase" when you talk about any modulation 
>> fancier than slow FSK.
>> 
>> Good luck. Hope you find the right balance between useful, digestible, and 
>> correct.
>> 
>> On Tue, Nov 3, 2020 at 7:20 PM David Hagood > > wrote:
>> 
>>I am sorrowful that you have decided you are going to stick with an
>>explanation that is fundamentally incorrect. I know how direct
>>conversion systems work - I design the software for them for a
>>living.
>>What you are basing your mental model on is an optimization for
>>the case
>>where the system is both sub-sampling the signal and going digital in
>>the same operation. However, in many extremely high sample rate
>>systems,
>>the signal is brought down to baseband by mixing it with analog
>>quadrature signals - that's the place where I and Q come from - and I
>>assure you the only "delay by 90 degrees" is in the creation of the
>>quadrature LO signals, not in the sampling of the actual data. But
>>I've
>>been around the Sun enough times to know that since you have decided
>>upon this course and don't seem to want to change, there's no
>>point in
>>continuing to try to help.
>> 
>> 
> 
> 

Re: explaining i/q

[Kristoff]

David, all,


Well, I had also been thinking about this.

I do like the idea of the spinning doll. It provides a model for 
positive and negative frequencies: if it spins one way, the frequency is 
positive, if it spins in the other direction, it is a negative frequency.


And, it does also give a 'hint' at the issue that a frequency in the 
"real" domain is both a positive and a negative frequency in the complex 
frequency domain>




However, the problem is that people associate "spinning" with movement, 
i.e. a change of the location of an object in time, or -in this case- a 
rotation around an axis -which also includes an element of time-.


Now, unless I am completely wrong, the model you use captures both the I 
and the Q samples at the same time. This means that there is no element 
of 'time'.
In electronics, this works fine, due to the nature of mixing and a 
difference of phase of the two Local-Oscillators.
But that's not how people see the spinning doll. Our eyes do not see a 
difference in phase of light. For us humans, the object is spinning due 
to the element of "time": multiple observations.



For us, "even if we would be able to look at a rotating object up-front 
and from a 90 degrees angle at the same time, if the object would be 
frozen in time we would still not be able to determine if the doll 
rotates left of right".
(except perhaps that we will probably make a assumptions as the doll 
leans slightly backwards). (*)


(*) https://en.wikipedia.org/wiki/Spinning_dancer



Now, I completely agree that the model I used (taking two samples, 1/4 
sample-period apart), is indeed based on only one of the architectures 
of a SDR-receiver.  And, yes, other SDR receiver architectures exist 
that are not based on that model. But at least it provides something 
that is not that far from our daily experience: detecting the direction 
of a movement by two observations at difference times.


Small sidenote:
That particular receiver-architecture does happen to be one that is used 
in most amateur-radio DIY receiver-kits. So if a student of the workshop 
gets to see a schematics of an SDR receiver- it IQ mixing-part should at 
least ring a bell.




Anycase, don't get me wrong. I really appreciate your feedback.

What you say is completely correct.
The question however is how to "package" your model into something that 
is easy to understand.




73
kristoff - ON1ARF



On 4/11/2020 02:58, David Hagood wrote:

Like I said previously:

Think of the spinning dancer illusion. It works because you only see 
from one vantage point. If you saw a real doll spinning, and assuming 
you have two eyes and normal binocular vision, you will have parallax, 
and that will allow you to determine in reality which way the figure 
is spinning, because each eye will have a different view of what is 
going on, and so can work out what direction the figure is spinning in.


I/Q is like that - it allows the SDR to see have "parallax" - to have 
2 points of view on the signal at the same time, and so it can "see" 
which way the signal is rotating - whether the signal is spinning 
clockwise (negative frequencies, cause math) or counter-clockwise 
(positive frequencies).


There - no advanced math, short, and yet accurate.

Re: explaining i/q

[David Hagood]

Now, unless I am completely wrong, the model you use captures both the 
I and the Q samples at the same time. This means that there is no 
element of 'time'.
In electronics, this works fine, due to the nature of mixing and a 
difference of phase of the two Local-Oscillators.
But that's not how people see the spinning doll. Our eyes do not see a 
difference in phase of light. For us humans, the object is spinning 
due to the element of "time": multiple observations.


Do you have 2 eyes? or one?

You see the model from 2 perspectives at once - left eye, right eye. 
Just like you have I and Q. Each eye sees the model from a different 
perspective - maybe not as dramatic as 90 degrees, but a different 
perspective.


I made that point repeatedly.

Did it not sink in?

Or are you just trying to argue against anything that isn't what you 
already planned on doing?





OpenPGP_0x5B9DC79986207D69.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

REMINDER: GR Amateur Radio video meeting

[Barry Duggan]

For those interested in using GNU Radio in amateur radio applications, 
we have set up an On-line video meeting
** I will present a program on Frequency Shift Keying, with a live 
On-the-Air demonstration of radioteletype

** It will be on **Saturday 7 November 16:00 UTC**
** see the details at https://wiki.gnuradio.org/index.php/User:Duggabe

* We have a Ham Radio chat room on Matrix
** server: https://chat.gnuradio.org
** or via the Homeserver in a matrix app: gnuradio.matrix.ungleich.cloud
** room: #HamRadio:gnuradio.org

73,
---
Barry Duggan KV4FV
https://github.com/duggabe

Re: explaining i/q

[Kristoff]

Don,


A small (slightly) remark about this video, and about hams.

When I gave my first video-presentation for the Belgian SDR Meetup (in 
September), I have a presentation on GR (an example of an RTTY decoder).
But, to keep the presentation on topic, I first posted a "list of 
interesting things to view so you can better understand the 
presentation" (the video you mentioned, three of the videos by Michael 
Ossmann, ...).


When I asked the audience during the presentation who had taken the time 
to actually do this, I did not get any positive answers.


You know,, ...last time when we did a workshop in a hackerspace on a 
certain topic and asked the people to do some preparation, I think that 
more then 3/4 did do that.

The same when I organise a workshop at work.


Yeah ... Hams .. (sigh) :-(



73
kristoff - ON1ARF


On 4/11/2020 15:22, Don Wade wrote:
Here’s a YouTube video that’s got a bit of pencil math (so it doesn’t 
drone on) and oscilloscopes (for the ham guys), so it’s got a bit for 
everyone .


https://m.youtube.com/watch?list=PLvOgjCaG0WzDAF1Um894vv95mrcyortOB&v=h_7d-m1ehoY


On Nov 4, 2020, at 7:52 AM, Kristoff  wrote:

Jef,


Concerning the term "slope". Well, I also have my doubts about it. I 
think that for a lot of people, this would create the assumption that 
the signal then goes from the 'i' value to the 'q' value in a 
straight line, which is -as we know- not the case.


Sometimes it helps to -at first- give a very basic mental image of 
something, and -at the end, when people understand the topic- 
"correct" that image with a more correct one, or just point them to 
some youtube video that explains the topic in more detail.



Anycase,this is indeed all an interesting exercise in braking down 
concepts into very small steps.


The amateur-radio community is a bit strange as most people do have a 
technical background, but for a large number of hams, that is mainly 
based on assumptions or "that's what they said in the ham-radio 
courses", without understanding the full technical details, 
especially topics that are highly based on math.
For most hams, "SDR" is just "that piece of software you install on 
your computer to look at  waterfall graphs".


So we have a very long way to go. :-)


73
kristoff - ON1ARF



On 4/11/2020 02:21, Jeff Long wrote:
It's more important to give people some mental picture than to make 
sure it's completely correct. But, I would not use the "slope" 
terminology. The important things are, as you've said, (1) with the 
complex type, you can have a signal at baseband that is not 
symmetric, and (2) the price for this is doubling the amount of data 
needed. The signal you deal with at baseband is the same signal that 
is seen centered on the RF carrier.


I don't see a great way to talk about "phase" without going into the 
math. It is important to get into "phase" when you talk about any 
modulation fancier than slow FSK.


Good luck. Hope you find the right balance between useful, 
digestible, and correct.


On Tue, Nov 3, 2020 at 7:20 PM David Hagood > wrote:


   I am sorrowful that you have decided you are going to stick with an
   explanation that is fundamentally incorrect. I know how direct
   conversion systems work - I design the software for them for a
   living.
   What you are basing your mental model on is an optimization for
   the case
   where the system is both sub-sampling the signal and going digital in
   the same operation. However, in many extremely high sample rate
   systems,
   the signal is brought down to baseband by mixing it with analog
   quadrature signals - that's the place where I and Q come from - and I
   assure you the only "delay by 90 degrees" is in the creation of the
   quadrature LO signals, not in the sampling of the actual data. But
   I've
   been around the Sun enough times to know that since you have decided
   upon this course and don't seem to want to change, there's no
   point in
   continuing to try to help.

Re: explaining i/q

[david vanhorn]

You can lead a horse to water...

Then there's hams like this: https://g3rbj.co.uk/


On Wed, Nov 4, 2020 at 12:04 PM Kristoff  wrote:

> Don,
>
>
> A small (slightly) remark about this video, and about hams.
>
> When I gave my first video-presentation for the Belgian SDR Meetup (in
> September), I have a presentation on GR (an example of an RTTY decoder).
> But, to keep the presentation on topic, I first posted a "list of
> interesting things to view so you can better understand the
> presentation" (the video you mentioned, three of the videos by Michael
> Ossmann, ...).
>
> When I asked the audience during the presentation who had taken the time
> to actually do this, I did not get any positive answers.
>
> You know,, ...last time when we did a workshop in a hackerspace on a
> certain topic and asked the people to do some preparation, I think that
> more then 3/4 did do that.
> The same when I organise a workshop at work.
>
>
> Yeah ... Hams .. (sigh) :-(
>
>
>
> 73
> kristoff - ON1ARF
>
>
> On 4/11/2020 15:22, Don Wade wrote:
> > Here’s a YouTube video that’s got a bit of pencil math (so it doesn’t
> > drone on) and oscilloscopes (for the ham guys), so it’s got a bit for
> > everyone .
> >
> >
> https://m.youtube.com/watch?list=PLvOgjCaG0WzDAF1Um894vv95mrcyortOB&v=h_7d-m1ehoY
> >
> >> On Nov 4, 2020, at 7:52 AM, Kristoff  wrote:
> >>
> >> Jef,
> >>
> >>
> >> Concerning the term "slope". Well, I also have my doubts about it. I
> >> think that for a lot of people, this would create the assumption that
> >> the signal then goes from the 'i' value to the 'q' value in a
> >> straight line, which is -as we know- not the case.
> >>
> >> Sometimes it helps to -at first- give a very basic mental image of
> >> something, and -at the end, when people understand the topic-
> >> "correct" that image with a more correct one, or just point them to
> >> some youtube video that explains the topic in more detail.
> >>
> >>
> >> Anycase,this is indeed all an interesting exercise in braking down
> >> concepts into very small steps.
> >>
> >> The amateur-radio community is a bit strange as most people do have a
> >> technical background, but for a large number of hams, that is mainly
> >> based on assumptions or "that's what they said in the ham-radio
> >> courses", without understanding the full technical details,
> >> especially topics that are highly based on math.
> >> For most hams, "SDR" is just "that piece of software you install on
> >> your computer to look at  waterfall graphs".
> >>
> >> So we have a very long way to go. :-)
> >>
> >>
> >> 73
> >> kristoff - ON1ARF
> >>
> >>
> >>
> >> On 4/11/2020 02:21, Jeff Long wrote:
> >>> It's more important to give people some mental picture than to make
> >>> sure it's completely correct. But, I would not use the "slope"
> >>> terminology. The important things are, as you've said, (1) with the
> >>> complex type, you can have a signal at baseband that is not
> >>> symmetric, and (2) the price for this is doubling the amount of data
> >>> needed. The signal you deal with at baseband is the same signal that
> >>> is seen centered on the RF carrier.
> >>>
> >>> I don't see a great way to talk about "phase" without going into the
> >>> math. It is important to get into "phase" when you talk about any
> >>> modulation fancier than slow FSK.
> >>>
> >>> Good luck. Hope you find the right balance between useful,
> >>> digestible, and correct.
> >>>
> >>> On Tue, Nov 3, 2020 at 7:20 PM David Hagood  >>> > wrote:
> >>>
> >>>I am sorrowful that you have decided you are going to stick with an
> >>>explanation that is fundamentally incorrect. I know how direct
> >>>conversion systems work - I design the software for them for a
> >>>living.
> >>>What you are basing your mental model on is an optimization for
> >>>the case
> >>>where the system is both sub-sampling the signal and going digital
> in
> >>>the same operation. However, in many extremely high sample rate
> >>>systems,
> >>>the signal is brought down to baseband by mixing it with analog
> >>>quadrature signals - that's the place where I and Q come from - and
> I
> >>>assure you the only "delay by 90 degrees" is in the creation of the
> >>>quadrature LO signals, not in the sampling of the actual data. But
> >>>I've
> >>>been around the Sun enough times to know that since you have decided
> >>>upon this course and don't seem to want to change, there's no
> >>>point in
> >>>continuing to try to help.
> >>>
> >>>
> >>
> >>
>
>

-- 
K1FZY (WA4TPW) SK  9/29/37-4/13/15

Re: explaining i/q

[Fons Adriaensen]

On Wed, Nov 04, 2020 at 05:14:00PM +0100, Kristoff wrote:
 
> For us, "even if we would be able to look at a rotating object up-front and
> from a 90 degrees angle at the same time, if the object would be frozen in
> time we would still not be able to determine if the doll rotates left of
> right".

The way complex samples are treated in theory means that the I and Q
parts refer to the same time, They are considered to be a single
sample having a complex value.

But you can never detect rotation (or a frequency in DSP terms) from
a single sample, be it real or complex. You always need a sequence.

A sequence of real valued samples (either I or Q separately) allows
you to detect the rotation, but the sense remains ambiguous. Having
both the I and Q sequences resolves that ambiguity. 

You could object that using complex samples requires twice the 
memory for the same sample rate, since every sample consists of
two numerical values. But since you can now separate positive
and negative frequencies, you get twice the bandwidth as well. 
So there is no penalty for using complex signals.

-- 
FA

Re: explaining i/q

[david vanhorn]

"Twice the bandwidth" but that doesn't account for the 0 Hz "hole" where
the incoming signal is exactly at the sampling rate.
Or am I missing something?

On Wed, Nov 4, 2020 at 3:28 PM Fons Adriaensen  wrote:

> On Wed, Nov 04, 2020 at 05:14:00PM +0100, Kristoff wrote:
>
> > For us, "even if we would be able to look at a rotating object up-front
> and
> > from a 90 degrees angle at the same time, if the object would be frozen
> in
> > time we would still not be able to determine if the doll rotates left of
> > right".
>
> The way complex samples are treated in theory means that the I and Q
> parts refer to the same time, They are considered to be a single
> sample having a complex value.
>
> But you can never detect rotation (or a frequency in DSP terms) from
> a single sample, be it real or complex. You always need a sequence.
>
> A sequence of real valued samples (either I or Q separately) allows
> you to detect the rotation, but the sense remains ambiguous. Having
> both the I and Q sequences resolves that ambiguity.
>
> You could object that using complex samples requires twice the
> memory for the same sample rate, since every sample consists of
> two numerical values. But since you can now separate positive
> and negative frequencies, you get twice the bandwidth as well.
> So there is no penalty for using complex signals.
>
> --
> FA
>
>
>

-- 
K1FZY (WA4TPW) SK  9/29/37-4/13/15

Re: explaining i/q

[David Hagood]

On 11/4/20 6:26 PM, david vanhorn wrote:
"Twice the bandwidth" but that doesn't account for the 0 Hz "hole" 
where the incoming signal is exactly at the sampling rate.

Or am I missing something?

What "hole" are you referring to? There is the "zero bang", which occurs 
because most systems aren't perfect and have a DC component to the LOs 
and mixing system, but a "perfect" system with zero DC in the LOs will 
resolve a DC signal. The imperfection of the implementation doesn't mean 
the concept is imperfect.





OpenPGP_0x5B9DC79986207D69.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature