[Flexradio] Console Graphics - maybe mode-specific? http://sourceforge.net/projects/pyerlbridge/

[Allen Boehm]

gt;> e) The action will send messages to the DSP and Controller nodes and
>>> also form an update message to send to the GUI.
>>> f) The DSP and Controller do the necessary. The GUI updates its e.g.
>>> current frequency display because that's what the command told it to do.
>> 
>> OK, I think I see where there's an impedance mismatch between our
>> concepts.
>> 
>> What you're calling the GUI, I'm thinking of as a node in a whole
>> subgraph which I call the UI. That subgraph has only one bidirectional
>> edge to the kernel, so for convenience I blur the internals and call it
>> a single node. If I understand right, for you, the GUI is really only
>> the collection of widgets, and the VR encompasses the data structures
>> that the GUI manipulates, but which reside in a separate node.
>> 
>> If we can agree that everything in the User Interface arena has in the
>> end only one path into and out of the message-handling kernel
>> (irrespective of what we think the exact protocol would be), then we're
>> in substantial agreement.
>> 
> This is I think the crux of the issue. Yes the VR contains the complete
> model of the whole system, so yes it contains all the data that the UI
> displays, it has static data, it has dynamic data and it has
> configuration data and it persists and restores that data. This data is
> required in various quantities by all nodes of the system, not just the
> UI. In this role it feeds the data to the UI along with commands to tell
> it what to with that data. I can't see at the moment how you escape it
> having this responsibility. I can't see how you move that back to the UI
> without having duplicate data and a lot of issues.
>  
>>> 3. I think we diverge on what the VR does and how its implemented. I
>>> would therefore want the VR to simply be a node that can be replaced as
>>> easily as any other and not woven into the fabric.
>> 
>> That criterion would be satisfied by the one-edge restriction, I think.
>> 
> I don't understand in implementation terms what that means (see above).
> 
> PS I'm going through the Erlang tutorials so there's a real danger I
> might get to like the language!
> 
> 73 de Bob
> 
> ___
> FlexRadio mailing list
> FlexRadio@flex-radio.biz
> http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
> Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/
> FlexRadio Homepage: http://www.flex-radio.com
> 




-- next part --
An HTML attachment was scrubbed...
URL: 
/pipermail/flexradio_flex-radio.biz/attachments/20060827/b32df8e8/attachment.html
 
___
FlexRadio mailing list
FlexRadio@flex-radio.biz
http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/
FlexRadio Homepage: http://www.flex-radio.com

Re: [Flexradio] Console Graphics - maybe mode-specific?

[Frank Brickle]

On Sun, 2006-08-27 at 23:10 +0100, Bob Cowdery wrote:

> Ok. But something in this system has to be *the* application.

Yes, we're on very different wavelengths, because I don't see this at
all, not at all. I see the system as a collection of services, and the
VR is merely a convenient way of coordinating them from the user's
standpoint.

This whole discussion is starting to resemble arguments over whether
consciousness is simply an emergent phenomenon, so you're right, we'd
better stop here :-)

73
Frank
AB2KT



___
FlexRadio mailing list
FlexRadio@flex-radio.biz
http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/
FlexRadio Homepage: http://www.flex-radio.com

Re: [Flexradio] Console Graphics - maybe mode-specific?

[Bob Cowdery]

On Sun, 2006-08-27 at 16:56 -0400, Frank Brickle wrote:
> On Sun, 2006-08-27 at 20:38 +0100, Bob Cowdery wrote:
> 
> > I haven't seen anything for Python apart from the ports tutorial that
> > uses pipes.
> 
> Have a look at py_interface, which is an all-native-Python
> implementation of an Erlang node, linked to from
> 
> 

This is a node implementation. I really don't see the point of
implementing an Erlang node in another language. All the advantages of
Erlang are lost by doing this. For me it has to be local integration at
the node.

73 de Bob

___
FlexRadio mailing list
FlexRadio@flex-radio.biz
http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/
FlexRadio Homepage: http://www.flex-radio.com

Re: [Flexradio] Console Graphics - maybe mode-specific?

[Bob Cowdery]

On Sun, 2006-08-27 at 16:11 -0400, Frank Brickle wrote:
> On Sun, 2006-08-27 at 20:38 +0100, Bob Cowdery wrote:
> 
> > I can't see how you move that back to the UI
> > without having duplicate data and a lot of issues.
> 
> To expand on the last point just a little, the UI also has a much more
> complex idea of what the VFO wants to be (VFO A+B, switching, RIT,
XIT,
> etc.) than any of the other functional nodes need to know. There's no
> information there that needs to be spread outside the UI. It still all
> funnels down into a single "tune-to" request to the kernel.
> 
Agreed, but its all part and parcel of my application model and tied up
with the application logic which is implemented in my state machine.
Regardless of whether you consider it to be part of the UI I want the
application to live it it's own node and the UI to be just the
presentation layer and nothing more. In fact its more appropriate to
drop the term UI or GUI and refer instead to the presentation and
application layers. What I don't want is these layers to be forced into
the same node or into some subnet which would have to include CAT and
goodness knows what else.
 
73 de Bob

___
FlexRadio mailing list
FlexRadio@flex-radio.biz
http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/
FlexRadio Homepage: http://www.flex-radio.com

Re: [Flexradio] Console Graphics - maybe mode-specific?

[Bob Cowdery]

On Sun, 2006-08-27 at 16:01 -0400, Frank Brickle wrote:
> On Sun, 2006-08-27 at 20:38 +0100, Bob Cowdery wrote:
> 
> > I've done a bit more digging. There seems to be three options for
> > integration:
> > 1. The arms length pipes (I think this can be TCP/IP as well and
> > possibly some others (according to some papers I read)). Pipes only work
> > for *nix so it means an extra sockets hop under Windows on the same
> > machine.
> 
> The situation is expanded considerably if the messaging transpires among
> distributed Erlang nodes, which communicate only locally with clients in
> other languages. I think this was the generally-understood model.
> 
Distribution is transparent so I don't see that it make a difference if
the nodes are distributed or not. Yes I was only considering the
language integration to be local. Logically its a single node although
the bulk of the work is being done outside of Erlang. The point was
simply that under Windows you have to go through a socket connection
albeit on the same machine to achieve that integration.

> It's advantageous secondarily in that the distributed Erlang nodes are
> much more versatile in their error handling and propagation capabilities
> than the local C or C# or Python nodes would be.
> 
I was only considering Erlang as the nodes with integration to another
language where necessary within a node. I don't much like the idea of
implementing an Erlang node in a different language as that seems to
completely defeat the object to me.

> > 2. Port Drivers which are effectively shared libraries .so or .dll for
> > *nix and Windows. This seems to be limited to languages that can create
> > proper shared libraries, predominantly aimed at C.
> 
> It certainly brings Python, C#, Ruby, and PHP into the fold.

It's not pretty though. These are exactly the integration issues I was
trying to get away from.
> 
> > 3. C Nodes which are definitely C only and receive native Erlang
> > messages.
> 
> Once again, wrapping up the C interfaces for other environments like
> Python and C# is straightforward. I believe I have the Python version
> living on this machine somewhere.
> 
It might be, but I want single language nodes or a clean way to
integrate any language with the messaging infrastructure.

> > ...Yes the VR contains the complete
> > model of the whole system, so yes it contains all the data that the UI
> > displays, it has static data, it has dynamic data and it has
> > configuration data and it persists and restores that data.
> 
> Here we part company. In my view the VR is simply the syntax and
> vocabulary of the messages acceptable to the radio kernel. In this
> sense, then, the radio kernel corresponds neatly with a microkernel, in
> that it's responsible for very little more than message passing and
> protocol handling, and maintaining just enough state to economize on the
> former and enable the latter.
> 
Ok. But something in this system has to be *the* application. If it's
not the radio kernel (we seem to have introduced another term here, is
this different from the VR?) and it's not the UI because that puts me
back to square one where we have multiple UI's with screeds of code in
them, then it's simply another node. Lets call it the Application Node
for want of a better term. All the VR does for me then is slightly
reduce the complexity of my Application Node. However I now need the
ability for the Application Node to talk to the UI WITHOUT going through
the VR which I think you would disallow from previous discussion. In
fact most nodes like CAT for example would now want to talk to the
Application Node and only the Application Node would talk to the VR. I
don't think this is what you have in mind at all!
 
> > This data is
> > required in various quantities by all nodes of the system, not just the
> > UI.
> 
> On this I could not agree less. The goal is to minimize the visibility
> of the nodes among one another. That's proportional to minimizing the
> bandwidth requirements for controlling the nodes.
> 
> > I can't see how you move that back to the UI
> > without having duplicate data and a lot of issues.
> 
> You talk about this as if it were a bad thing. Duplication of data is to
> be desired, especially in a distributed system, as long as there's some
> mechanism for assuring consistency. What we have a lot of is memory.
> What's potentially in short supply is bandwidth. The more we hold on to
> locally, the less we have to send around as data, if we've made up an
> adequately rich shorthand vocabulary.

> Jst as with the VFO example, the UI's notion of a VFO has very little in
> common with the DSP's and the hardware's, except a single number. The UI
> wants to remember that number. The DSP and the hardware don't need to
> remember it, they just need to obey the commands that effect it. I am
> unclear what advantage there is in any other arrangement.
> 
Sorry, but I'm really unmovable on having a model. It's the central
underpinning of the applicat

Re: [Flexradio] Console Graphics - maybe mode-specific?

[Frank Brickle]

On Sun, 2006-08-27 at 20:38 +0100, Bob Cowdery wrote:

> I haven't seen anything for Python apart from the ports tutorial that
> uses pipes.

Have a look at py_interface, which is an all-native-Python
implementation of an Erlang node, linked to from



73
Frank
AB2KT




___
FlexRadio mailing list
FlexRadio@flex-radio.biz
http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/
FlexRadio Homepage: http://www.flex-radio.com

Re: [Flexradio] Console Graphics - maybe mode-specific?

[Frank Brickle]

On Sun, 2006-08-27 at 20:38 +0100, Bob Cowdery wrote:

> I can't see how you move that back to the UI
> without having duplicate data and a lot of issues.

To expand on the last point just a little, the UI also has a much more
complex idea of what the VFO wants to be (VFO A+B, switching, RIT, XIT,
etc.) than any of the other functional nodes need to know. There's no
information there that needs to be spread outside the UI. It still all
funnels down into a single "tune-to" request to the kernel.

73
Frank
AB2KT



___
FlexRadio mailing list
FlexRadio@flex-radio.biz
http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/
FlexRadio Homepage: http://www.flex-radio.com

Re: [Flexradio] Console Graphics - maybe mode-specific?

[Frank Brickle]

On Sun, 2006-08-27 at 20:38 +0100, Bob Cowdery wrote:

> I've done a bit more digging. There seems to be three options for
> integration:
> 1. The arms length pipes (I think this can be TCP/IP as well and
> possibly some others (according to some papers I read)). Pipes only work
> for *nix so it means an extra sockets hop under Windows on the same
> machine.

The situation is expanded considerably if the messaging transpires among
distributed Erlang nodes, which communicate only locally with clients in
other languages. I think this was the generally-understood model.

It's advantageous secondarily in that the distributed Erlang nodes are
much more versatile in their error handling and propagation capabilities
than the local C or C# or Python nodes would be.

> 2. Port Drivers which are effectively shared libraries .so or .dll for
> *nix and Windows. This seems to be limited to languages that can create
> proper shared libraries, predominantly aimed at C.

It certainly brings Python, C#, Ruby, and PHP into the fold.

> 3. C Nodes which are definitely C only and receive native Erlang
> messages.

Once again, wrapping up the C interfaces for other environments like
Python and C# is straightforward. I believe I have the Python version
living on this machine somewhere.

> ...Yes the VR contains the complete
> model of the whole system, so yes it contains all the data that the UI
> displays, it has static data, it has dynamic data and it has
> configuration data and it persists and restores that data.

Here we part company. In my view the VR is simply the syntax and
vocabulary of the messages acceptable to the radio kernel. In this
sense, then, the radio kernel corresponds neatly with a microkernel, in
that it's responsible for very little more than message passing and
protocol handling, and maintaining just enough state to economize on the
former and enable the latter.

> This data is
> required in various quantities by all nodes of the system, not just the
> UI.

On this I could not agree less. The goal is to minimize the visibility
of the nodes among one another. That's proportional to minimizing the
bandwidth requirements for controlling the nodes.

> I can't see how you move that back to the UI
> without having duplicate data and a lot of issues.

You talk about this as if it were a bad thing. Duplication of data is to
be desired, especially in a distributed system, as long as there's some
mechanism for assuring consistency. What we have a lot of is memory.
What's potentially in short supply is bandwidth. The more we hold on to
locally, the less we have to send around as data, if we've made up an
adequately rich shorthand vocabulary.

Jst as with the VFO example, the UI's notion of a VFO has very little in
common with the DSP's and the hardware's, except a single number. The UI
wants to remember that number. The DSP and the hardware don't need to
remember it, they just need to obey the commands that effect it. I am
unclear what advantage there is in any other arrangement.

73
Frank
AB2KT



___
FlexRadio mailing list
FlexRadio@flex-radio.biz
http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/
FlexRadio Homepage: http://www.flex-radio.com

Re: [Flexradio] Console Graphics - maybe mode-specific?

[Bob Cowdery]

On Sun, 2006-08-27 at 13:33 -0400, Frank Brickle wrote:
> On Sun, 2006-08-27 at 16:13 +0100, Bob Cowdery wrote:
> 
> > 2> I don't know if this is a real difference in topology or not. I
> > didn't envisage a central service but more a peer-to-peer network where
> > the VR is just a node even if that node is 'hidden' in the sense that
> > all commands from other nodes route to the VR node by default.
> 
> There is certainly a difference of expression if not conception here. In
> the scenario I'm imagining, the only thing visible to any of the nodes
> except the kernel, is the kernel. However the kernel sees all nodes (at
> this level of abstraction). Furthermore the only node directly visible
> to the user is the UI node.
> 
I think it's only a difference in expression, the semantics are the
same. There may be a difference in implementation terms but I'm not sure
what it is.

> > ...One of the VR's responsibilities is
> > definitely to understand what needs to be done (in terms of what
> > messages need to be sent to other nodes) to complete a request...
> 
> To put it a little more emphatically: the kernel is the interface
> between the front end (the UI) and the back end (the DSP and hardware).
> It's the kernel's job to implement vocabularies that the front end can
> use and the back end can understand. The mapping between front end and
> back end vocabularies is complex and potentially many-to-one in either
> direction.
> 
> > 2> I've looked at the ports tutorial and as far as I can tell the
> > underlying interface is pipes which talk to external processes via
> > stdin/stdout...
> 
> That is the simplest form. On the other hand, several languages
> including C, Python, and Java (I think) have libraries which let them
> behave as if they were native Erlang nodes.
> 
I've done a bit more digging. There seems to be three options for
integration:
1. The arms length pipes (I think this can be TCP/IP as well and
possibly some others (according to some papers I read)). Pipes only work
for *nix so it means an extra sockets hop under Windows on the same
machine.
2. Port Drivers which are effectively shared libraries .so or .dll for
*nix and Windows. This seems to be limited to languages that can create
proper shared libraries, predominantly aimed at C.
3. C Nodes which are definitely C only and receive native Erlang
messages.

There is mention of the Erl_Interface for C and Java. I think these are
C Node implementations, not sure how Java is done.

I haven't seen anything for Python apart from the ports tutorial that
uses pipes.

All in all and no surprise it's harder on Windows.

> > To take this a bit further, ports don't define a protocol or a data
> > format. So both these issues are still open...
> 
> It depends on whether you are relying on the simple or the native
> realization. There are also native Erlang libraries which let Erlang
> masquerade as XML-RPC, which would be my personal favorite as a
> syntactic wrapper.
> 
Its another possibility.

> > The interface consists of two asychronous paths. An outgoing event path
> > when the user perform some interaction and an incoming update path. The
> > GUI has absolutely zero intelligence it just does what it's told...
> > 2> I think this is a significant difference in what we see in the VR...
> > a) The CAT node is a separate node on the network, it listens for both
> > external (virtual or real serial port) and internal messages on the
> > network.
> > b) An external message arrives to change freq
> ency. It packages and
> > dispatches this message over the network.
> > c) The message is received by the VR node and unpacked. The message is
> > in fact very similar to that which the GUI would generate. The event
> > name would be different to distinguish the different actions required of
> > GUI and CAT commands.
> > d) The VR decides if this event has an associated action in its current
> > state. If not a warning message is returned. Otherwise the action is
> > called.
> > e) The action will send messages to the DSP and Controller nodes and
> > also form an update message to send to the GUI.
> > f) The DSP and Controller do the necessary. The GUI updates its e.g.
> > current frequency display because that's what the command told it to do.
> 
> OK, I think I see where there's an impedance mismatch between our
> concepts.
> 
> What you're calling the GUI, I'm thinking of as a node in a whole
> subgraph which I call the UI. That subgraph has only one bidirectional
> edge to the kernel, so for convenience I blur the internals and call it
> a single node. If I understand right, for you, the GUI is really only
> the collection of widgets, and the VR encompasses the data structures
> that the GUI manipulates, but which reside in a separate node.
> 
> If we can agree that everything in the User Interface arena has in the
> end only one path into and out of the message-handling kernel
> (irrespective of what we think the exact protocol would be), then we're
> i

Re: [Flexradio] I/Q imbalance and calibration

[Jim Lux]

At 10:27 AM 8/27/2006, Ahti Aintila wrote:
>Jim,
>
>Thank you very much for your mathematical treatment of the I/Q
>balancing matters.

Just you wait.. I'm in the middle of writing up a paper on a calibration 
model for the SDR1000.  The DDS filter analysis was just something that was 
needed in that process.


>That is really the weak point of the otherwise
>excellent SDR-1000.

More a weakness in the software, not in the hardware, which is a "good 
thing" because it means that it might be correctible in software.  The one 
thing I wish the hardware had was a way to run the Tx and Rx 
simultaneously, so you could loop the Tx modulator into the receiver.  I 
realize that there are some good, practical reasons why it's not done this way.


>Now that I have been experimenting with "Active Integrating Quadrature
>Sampling Detectors" (ISD for short and simplicity) I can clearly see a
>slanting noise floor graph on the display, raising up towards the
>increasing negative frequencies, i.e. towards the "DC-frequencies".
>When using 96 or 192 kHz sampling there is a narrower or wider hump
>visible on the display at around 11 kHz. I have been thinking that the
>hump is due to higher phase and amplitude erros at low IF-frequencies
>and due to sampling pulse errors at higher RF-frequencies.

I think you're right.  I haven't looked at the audio chain yet, but 
certainly, for the RF, the sampling error is going to get bigger at higher 
frequencies (at least measured as phase), because they are probably "time" 
offsets (propagation delays, etc.)


>Just came into my mind, do we actually need any lowpass filters after
>the DDS and do we need sinus and cosine outputs? Would just accurately
>controlled quadrature 180° wide clocking pulses do the trick with a
>lot less of critical filter components?

Yes, but it turns out that the easiest way to generate them is to generate 
a sine with a DDS, filter it, and then threshold.  At first glance, it 
seems that you could take the MSB of the NCO output and use that, but that 
would mean that your timing resolution is limited to the DDS clock (i.e. 5 
ns in the SDR1000 case), so spurs would increase.  The use of low order 
bits essentially provide interpolation to finer than DDS clock rate.


>Then there is some more complication in the QSD circuits. Most of them
>sample the signal in four short 90° narrow slices when it can be
>handled by two 180° wide pulses. That is the way I'm sampling in my
>IDS experiments.

I'm not sure it makes a huge difference.  You give up 3dB(?) in energy.

It's using +,+,-,-,+,+,-,-,... as the LO waveform rather than 
+,0,-,0,+,0,-,0,...

There's some difference in the harmonic content of the output of the mixer 
too, but I'm not sure what the impact of that is.  That's something that 
someone has to have analyzed before.



Jim, W6RMK 



___
FlexRadio mailing list
FlexRadio@flex-radio.biz
http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/
FlexRadio Homepage: http://www.flex-radio.com

Re: [Flexradio] Console Graphics - maybe mode-specific?

[Frank Brickle]

On Sun, 2006-08-27 at 16:13 +0100, Bob Cowdery wrote:

> 2> I don't know if this is a real difference in topology or not. I
> didn't envisage a central service but more a peer-to-peer network where
> the VR is just a node even if that node is 'hidden' in the sense that
> all commands from other nodes route to the VR node by default.

There is certainly a difference of expression if not conception here. In
the scenario I'm imagining, the only thing visible to any of the nodes
except the kernel, is the kernel. However the kernel sees all nodes (at
this level of abstraction). Furthermore the only node directly visible
to the user is the UI node.

> ...One of the VR's responsibilities is
> definitely to understand what needs to be done (in terms of what
> messages need to be sent to other nodes) to complete a request...

To put it a little more emphatically: the kernel is the interface
between the front end (the UI) and the back end (the DSP and hardware).
It's the kernel's job to implement vocabularies that the front end can
use and the back end can understand. The mapping between front end and
back end vocabularies is complex and potentially many-to-one in either
direction.

> 2> I've looked at the ports tutorial and as far as I can tell the
> underlying interface is pipes which talk to external processes via
> stdin/stdout...

That is the simplest form. On the other hand, several languages
including C, Python, and Java (I think) have libraries which let them
behave as if they were native Erlang nodes.

> To take this a bit further, ports don't define a protocol or a data
> format. So both these issues are still open...

It depends on whether you are relying on the simple or the native
realization. There are also native Erlang libraries which let Erlang
masquerade as XML-RPC, which would be my personal favorite as a
syntactic wrapper.

> The interface consists of two asychronous paths. An outgoing event path
> when the user perform some interaction and an incoming update path. The
> GUI has absolutely zero intelligence it just does what it's told...
> 2> I think this is a significant difference in what we see in the VR...
> a) The CAT node is a separate node on the network, it listens for both
> external (virtual or real serial port) and internal messages on the
> network.
> b) An external message arrives to change frequency. It packages and
> dispatches this message over the network.
> c) The message is received by the VR node and unpacked. The message is
> in fact very similar to that which the GUI would generate. The event
> name would be different to distinguish the different actions required of
> GUI and CAT commands.
> d) The VR decides if this event has an associated action in its current
> state. If not a warning message is returned. Otherwise the action is
> called.
> e) The action will send messages to the DSP and Controller nodes and
> also form an update message to send to the GUI.
> f) The DSP and Controller do the necessary. The GUI updates its e.g.
> current frequency display because that's what the command told it to do.

OK, I think I see where there's an impedance mismatch between our
concepts.

What you're calling the GUI, I'm thinking of as a node in a whole
subgraph which I call the UI. That subgraph has only one bidirectional
edge to the kernel, so for convenience I blur the internals and call it
a single node. If I understand right, for you, the GUI is really only
the collection of widgets, and the VR encompasses the data structures
that the GUI manipulates, but which reside in a separate node.

If we can agree that everything in the User Interface arena has in the
end only one path into and out of the message-handling kernel
(irrespective of what we think the exact protocol would be), then we're
in substantial agreement.

> 3. I think we diverge on what the VR does and how its implemented. I
> would therefore want the VR to simply be a node that can be replaced as
> easily as any other and not woven into the fabric.

That criterion would be satisfied by the one-edge restriction, I think.

73
Frank
AB2KT



___
FlexRadio mailing list
FlexRadio@flex-radio.biz
http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/
FlexRadio Homepage: http://www.flex-radio.com

Re: [Flexradio] I/Q imbalance and calibration

[Ahti Aintila]

Jim,

Thank you very much for your mathematical treatment of the I/Q
balancing matters. That is really the weak point of the otherwise
excellent SDR-1000. To me personally, it means so much that as soon as
I realised this more than about 3 years ago I refused to transmit
before manually correcting the I/Q balance at the frequency. You know,
I am mentally sick in this respect long time! Since the early days of
SSB when the signal was generated by home made equipment I had for
"convenience" even front panel controls for phase and balance
adjustments!

Now that I have been experimenting with "Active Integrating Quadrature
Sampling Detectors" (ISD for short and simplicity) I can clearly see a
slanting noise floor graph on the display, raising up towards the
increasing negative frequencies, i.e. towards the "DC-frequencies".
When using 96 or 192 kHz sampling there is a narrower or wider hump
visible on the display at around 11 kHz. I have been thinking that the
hump is due to higher phase and amplitude erros at low IF-frequencies
and due to sampling pulse errors at higher RF-frequencies.

Just came into my mind, do we actually need any lowpass filters after
the DDS and do we need sinus and cosine outputs? Would just accurately
controlled quadrature 180° wide clocking pulses do the trick with a
lot less of critical filter components?

Then there is some more complication in the QSD circuits. Most of them
sample the signal in four short 90° narrow slices when it can be
handled by two 180° wide pulses. That is the way I'm sampling in my
IDS experiments.

Please, wise answers to my silly questions!

73,  Ahti OH2RZ



On 27/08/06, Jim Lux <[EMAIL PROTECTED]> wrote:
> Put some analysis of the variability of the DDS LO filters out on my website.
> It's a draft still: comments appreciated.
>
> http://home.earthlink.net/~w6rmk/sdr1000/index.htm
>
>
> Take home message so far.. At least from the DDS LO side of things, you
> don't need a huge number of calibration points across the HF band in order
> to get good image rejection. {of course, this depends on what you think
> "good" is...}
>
> While there can be pretty substantial differences in phase between I and Q
> sides due to component variations, once you know what the difference is
> (e.g. by calibrating), the difference doesn't change a lot over the entire
> range.
>
> If someone has any information on the temperature characteristics of the
> components (in particular, what's the temperature coefficient of the caps),
> I can roll that into the analysis.
>
> Jim Lux, W6RMK
>
>
>
> ___
> FlexRadio mailing list
> FlexRadio@flex-radio.biz
> http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
> Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/
> FlexRadio Homepage: http://www.flex-radio.com
>

___
FlexRadio mailing list
FlexRadio@flex-radio.biz
http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/
FlexRadio Homepage: http://www.flex-radio.com

[Flexradio] I/Q imbalance and calibration

[Jim Lux]

Put some analysis of the variability of the DDS LO filters out on my website.
It's a draft still: comments appreciated.

http://home.earthlink.net/~w6rmk/sdr1000/index.htm


Take home message so far.. At least from the DDS LO side of things, you 
don't need a huge number of calibration points across the HF band in order 
to get good image rejection. {of course, this depends on what you think 
"good" is...}

While there can be pretty substantial differences in phase between I and Q 
sides due to component variations, once you know what the difference is 
(e.g. by calibrating), the difference doesn't change a lot over the entire 
range.

If someone has any information on the temperature characteristics of the 
components (in particular, what's the temperature coefficient of the caps), 
I can roll that into the analysis.

Jim Lux, W6RMK



___
FlexRadio mailing list
FlexRadio@flex-radio.biz
http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/
FlexRadio Homepage: http://www.flex-radio.com

Re: [Flexradio] Console Graphics - maybe mode-specific?

[Bob Cowdery]

Frank

Firstly, thank you for the reply and secondly thank you for leaving an
open discussion. I have been labouring in the garden all morning but as
that occupies only my muscles and not my brain I have a response in my
head which goes something like this.

1. I will put aside the issue of language integration when talking about
the logical architecture as this is an implementation issue and has no
effect on the logical architecture. I will talk about it where
appropriate.
2. Identify everything which is the same in our logical architecture
model and where I think there may be differences. I will try and use
your terminology.
3. Briefly explain what my GUI node implementation is as it helps
explain some other aspects.
4. Go through a simple use case.

I apologise, it's going to be quite a long post. In the comments I have
started each one with n> where n is 1-4 above.

On Sat, 2006-08-26 at 22:21 -0400, Frank Brickle wrote:
> Bob --
> 
> It's very good you brought this up, because the issues are truly
> important.
> 
> > I have an onion skin model of what I want to do...
> 
> I think we're imagining different topologies. The model we've been
> assuming is a graph. The various different processing components (DSP,
> hardware control, UI, other things) are the nodes. The edges are the
> communication paths among the nodes.
> 
2> I probably explained it badly but this is precisely what I had in
mind.

> With the "virtual radio" we've been talking about, the topology is a
> star with the "kernel" at the center. All communication among the other
> nodes takes place through the kernel.
> 
2> I don't know if this is a real difference in topology or not. I
didn't envisage a central service but more a peer-to-peer network where
the VR is just a node even if that node is 'hidden' in the sense that
all commands from other nodes route to the VR node by default.

> The reason we describe the kernel as the virtual radio is that it alone
> understands messages couched in high-level terms like "VFO" and "CW
> filter." The kernel is reponsible for translating those terms into
> low-level instructions and data that the processing nodes (the DSP and
> the hardware) understand and conform to. The only place the VFO exists,
> for example, is in the state and translation procedure within the
> kernel. In the implementation, the virtual VFO is spread across the DSP
> and the hardware, neither of which is aware of the other. Only the
> kernel knows that tuning the virtual VFO may require separate commands
> to two otherwise-independent components.
> 
2> No problem with that at all. One of the VR's responsibilities is
definitely to understand what needs to be done (in terms of what
messages need to be sent to other nodes) to complete a request. I think
we may differ in terms of what other responsibilities I would like the
VR to have.

> If the kernel is in Erlang, the platform itself is language-agnostic,
> since it is designed to be able to send and receive Erlang-native
> messages to alien nodes via simple standard paths, called "ports." There
> is no reason other than convenience to write any particular node (DSP or
> hardware control or UI) in any particular language. The only real
> penalty for having a non-Erlang node as part of the network is that a
> non-Erlang node is limited in its ability to trap and absorb errors in
> other nodes. A native Erlang node can be set up to absorb propagation of
> error conditions and protect the remainder of the network.
> 
2> I've looked at the ports tutorial and as far as I can tell the
underlying interface is pipes which talk to external processes via
stdin/stdout. I'm assuming this will work on any platform. A couple of
observations. On the language issue there are good reasons to support
pretty much any language for the GUI, the DSP and Controller are in 'C'
and I would think there would be little point in moving these to Erlang
in the near future. The rest could arguably be in Erlang but for certain
parts other languages might be more appropriate. Therefore a good
language integration layer is necessary.

To take this a bit further, ports don't define a protocol or a data
format. So both these issues are still open. I can see that in my model
I would convert messages into a standard format at the sending point
whereas in an Erlang implementation I would convert them at the
receiving point before passing to the external process. Both these
models are equally viable. The only difference I see is that if I used
JSON in both cases as the common encoding format in the first case I
would have ASCII on the wire and in the second some binary format. The
only advantage of the former is if we go through firewalls it's easy to
turn into HTTP requests and easy to see what's on the wire for
debugging.  

> The Erlang language itself leans strongly towards finite state machines,
> stepped by the receipt and transmission of messages among asynchronous
> processes. There is no special prejudice towa