Re: [Flexradio] console

[Rob Keijzer]

You just did.


2012/10/27 AT&T Online Services 

> How do I get message to reflector?
>
> Johnnie W6HTY
> ___
> FlexRadio Systems Mailing List
> FlexRadio@flex-radio.biz
> http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
> Archives: http://www.mail-archive.com/flexradio%40flex-radio.biz/
> Knowledge Base: http://kc.flexradio.com/  Homepage:
> http://www.flexradio.com/
>



-- 
Rob Keijzer
PA3CNT
___
FlexRadio Systems Mailing List
FlexRadio@flex-radio.biz
http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Archives: http://www.mail-archive.com/flexradio%40flex-radio.biz/
Knowledge Base: http://kc.flexradio.com/  Homepage: http://www.flexradio.com/

[Flexradio] console

[AT&T Online Services]

How do I get message to reflector?
 
Johnnie W6HTY
___
FlexRadio Systems Mailing List
FlexRadio@flex-radio.biz
http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Archives: http://www.mail-archive.com/flexradio%40flex-radio.biz/
Knowledge Base: http://kc.flexradio.com/  Homepage: http://www.flexradio.com/

[Flexradio] console

[AT&T Online Services]

Hi all,
 
When I start PowerSDR I get a white horozontal line on the console. Grey above, 
black below. To get it to work I go to VAC audio tab and change the buffer, if 
it shows 1024, I change it to 2048, if it shows 2048, I change it to 1024 and 
then things work fine.
 
What do I have set wrong?
 
Thanks, 73
Johnnie W6HTY
___
FlexRadio Systems Mailing List
FlexRadio@flex-radio.biz
http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Archives: http://www.mail-archive.com/flexradio%40flex-radio.biz/
Knowledge Base: http://kc.flexradio.com/  Homepage: http://www.flexradio.com/

Re: [Flexradio] Console size change in PSDR v2.2/2.3 ???

[Jim Jannuzzo]

Gary,What works or not is dependent on the setup in your shack. I'm using 1600 
X  900 at 100% text size, on two 24 inch wide screen monitors, and PowerSDR 
fills one screen exactly.  However, I'm using AMD Catalyst software to drive a 
"5770" graphics card, and engaging GPU scaling.  I recently had to change from 
1920x1080 @ 150% when I had my RX2 installed.  Everything that fit beautifully 
at the HD resolution, no longer fit on my screen using these settings with the 
addition of RX2 panels.  Now I have a bigger panadapter area, but smaller push 
buttons.  Jim 
 > From: glhu...@msn.com
> To: FlexRadio@flex-radio.biz
> Date: Thu, 6 Oct 2011 12:23:34 -0500
> Subject: [Flexradio] Console size change in PSDR v2.2/2.3 ???
> 
> The screen resolution settings of 1680 X 1050 and 125% text size which works 
> with PSDR v2.1RC1 Console Skins will not work with PSDR v2.2 and later. 
> 
> I understand the “fix” is to reset the text size back to 100%, but am 
> reluctant to change the display for all other applications on my computer 
> just to make one application work. Still its hard for me to understand why an 
> application which was displayed properly previously no longer does so after a 
> “upgrade”. 
> 
> Whatever was changed seems to be universal in that choosing a custom skin 
> doesn’t solve the problem nor does attempting to resize the console. Is there 
> a variable in PSDR v2.3 that can be reset which will allow a 125% text size 
> screen to support the console? 
> 
> Thus far my only resolution has been to uninstall V2.2 – V2.3 and repair the 
> previously working v2.1RC1.
> 
> 73 es DX,
> 
> Gary - AB9M
> 
> ___
> FlexRadio Systems Mailing List
> FlexRadio@flex-radio.biz
> http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
> Archives: http://www.mail-archive.com/flexradio%40flex-radio.biz/
> Knowledge Base: http://kc.flexradio.com/  Homepage: http://www.flexradio.com/
  
___
FlexRadio Systems Mailing List
FlexRadio@flex-radio.biz
http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Archives: http://www.mail-archive.com/flexradio%40flex-radio.biz/
Knowledge Base: http://kc.flexradio.com/  Homepage: http://www.flexradio.com/

[Flexradio] Console size change in PSDR v2.2/2.3 ???

[CSM(r) Gary Huber]

The screen resolution settings of 1680 X 1050 and 125% text size which works 
with PSDR v2.1RC1 Console Skins will not work with PSDR v2.2 and later. 

I understand the “fix” is to reset the text size back to 100%, but am reluctant 
to change the display for all other applications on my computer just to make 
one application work. Still its hard for me to understand why an application 
which was displayed properly previously no longer does so after a “upgrade”. 

Whatever was changed seems to be universal in that choosing a custom skin 
doesn’t solve the problem nor does attempting to resize the console. Is there a 
variable in PSDR v2.3 that can be reset which will allow a 125% text size 
screen to support the console? 

Thus far my only resolution has been to uninstall V2.2 – V2.3 and repair the 
previously working v2.1RC1.

73 es DX,

Gary - AB9M

___
FlexRadio Systems Mailing List
FlexRadio@flex-radio.biz
http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Archives: http://www.mail-archive.com/flexradio%40flex-radio.biz/
Knowledge Base: http://kc.flexradio.com/  Homepage: http://www.flexradio.com/

[Flexradio] Console freeze ups - resolved

[Tim Ellison]

I thought I'd share this little bit of information with all.  Although I am 
using a very fast Core 2 Duo computer, a high performance PCIe Firewire adapter 
and my CPU utilization has always been well below 20%, I was still experiencing 
occasional freeze ups of the PowerSDR console.  Particularly if I had MS 
Outlook open.  When Outlook was open and it was receiving or sending e-mail, my 
system would experience very long duration DPCs in the +2000 uS range.  Even 
with the Firewire driver in SafeMode 1, it would still lock up.

Well I was doing some PC "house cleaning" last weekend and  found that one of 
the MicroSquish applications I had installed, but was rarely using now had 
install a light weight web server (IIS) on my PC.  As soon as I uninstalled the 
offending application (it was a .NET IDE (integrated development environment)) 
and the associated IIS installation, all instances of the console freeze up 
have stopped. Yippee!

If you are experiencing problems like this and have IIS installed, you may want 
to consider this as a prime candidate as the performance sucking black hole 
that may be lurking in your PC galaxy.

-Tim
-
W4TME


___
FlexRadio Systems Mailing List
FlexRadio@flex-radio.biz
http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Archives: http://www.mail-archive.com/flexradio%40flex-radio.biz/
Knowledge Base: http://kb.flex-radio.com/  Homepage: http://www.flex-radio.com/

Re: [Flexradio] Console resizing now in K6JCA branch of SVN

[Edwin Marzan]

Perhaps a set of assignable buttons for those of us who are not SteppIR users. 
We may want to use the space for something else.Edwin MarzanAB2VW> Date: Thu, 
17 Jan 2008 10:58:49 -0500> From: [EMAIL PROTECTED]> To: 
flexradio@flex-radio.biz> Subject: Re: [Flexradio] Console resizing now in 
K6JCA branch of SVN> > True. One could enlarge the existing non-resizable 
console and add > another row of buttons. IMO, that would be much better than 
"hiding" > SteppIR control buttons on a tab or in Setup somewhere.> > But in 
fact I think there would be room for extra buttons without making > the console 
larger if some of the read-only fields (antenna settings, > time/date) were 
moved into the title bar.> > 73> > Alan NV8A> > > On 01/16/08 04:39 pm Jeff 
Anderson wrote:> > > You don't need my "resizing" function in order to add more 
buttons. > > Whoever want to add these buttons just needs to make a larger 
console > > (or add them to either a new Tab or somewhere in the Setup menus). 
I > > added this feature because I wanted to get more panadapter resolution > > 
with my monitor that's 1280 pixels wide.> > >> It looks good.> >>> >> I assume 
that this would enable the addition of another row of > >> controls -- e.g., 
for the "normal," "180-degree" and "bi-directional" > >> buttons for SteppIR 
users.> > > ___> FlexRadio Systems 
Mailing List> FlexRadio@flex-radio.biz> 
http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz> Archives: 
http://www.mail-archive.com/flexradio%40flex-radio.biz/> Knowledge Base: 
http://kb.flex-radio.com/ Homepage: http://www.flex-radio.com/> 
_
Shed those extra pounds with MSN and The Biggest Loser!!
http://biggestloser.msn.com/
___
FlexRadio Systems Mailing List
FlexRadio@flex-radio.biz
http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Archives: http://www.mail-archive.com/flexradio%40flex-radio.biz/
Knowledge Base: http://kb.flex-radio.com/  Homepage: http://www.flex-radio.com/

Re: [Flexradio] Console resizing now in K6JCA branch of SVN

[Alan NV8A]

True. One could enlarge the existing non-resizable console and add 
another row of buttons. IMO, that would be much better than "hiding" 
SteppIR control buttons on a tab or in Setup somewhere.

But in fact I think there would be room for extra buttons without making 
the console larger if some of the read-only fields (antenna settings, 
time/date) were moved into the title bar.

73

Alan NV8A


On 01/16/08 04:39 pm Jeff Anderson wrote:

> You don't need my "resizing" function in order to add more buttons.  
> Whoever want to add these buttons just needs to make a larger console 
> (or add them to either a new Tab or somewhere in the Setup menus).   I 
> added this feature because I wanted to get more panadapter resolution 
> with my monitor that's 1280 pixels wide.

>> It looks good.
>>
>> I assume that this would enable the addition of another row of 
>> controls -- e.g., for the "normal," "180-degree" and "bi-directional" 
>> buttons for SteppIR users.


___
FlexRadio Systems Mailing List
FlexRadio@flex-radio.biz
http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Archives: http://www.mail-archive.com/flexradio%40flex-radio.biz/
Knowledge Base: http://kb.flex-radio.com/  Homepage: http://www.flex-radio.com/

Re: [Flexradio] Console resizing now in K6JCA branch of SVN

[Jeff Anderson]

Hi Alan,

You don't need my "resizing" function in order to add more buttons.  
Whoever want to add these buttons just needs to make a larger console 
(or add them to either a new Tab or somewhere in the Setup menus).   I 
added this feature because I wanted to get more panadapter resolution 
with my monitor that's 1280 pixels wide.

- Jeff

Alan NV8A wrote:
> On 01/15/08 08:15 pm Jeff Anderson wrote:
>
>> Console resizing is now in my branch (k6jca) of the SVN.  You can 
>> increase the display size both horizontally & vertically 
>> (independently).  Note, though, that larger displays will require 
>> more CPU power, so if you start hearing pops, go back to a smaller 
>> size.  Controls are in Setup>Appearance>Display.
>>
>> Console sizes range from the 'stock' size of 1024 x 624 pixels (h x 
>> 4) to 1920 x 1200 pixels.
>>
>> Please see me blog ([EMAIL PROTECTED]) for more info.  Also, please 
>> answer the *new* poll question regarding resizing!
>>
>> Let me know how it works...
>
> It looks good.
>
> I assume that this would enable the addition of another row of 
> controls -- e.g., for the "normal," "180-degree" and "bi-directional" 
> buttons for SteppIR users.
>

___
FlexRadio Systems Mailing List
FlexRadio@flex-radio.biz
http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Archives: http://www.mail-archive.com/flexradio%40flex-radio.biz/
Knowledge Base: http://kb.flex-radio.com/  Homepage: http://www.flex-radio.com/

Re: [Flexradio] Console resizing now in K6JCA branch of SVN

[Alan NV8A]

On 01/15/08 08:15 pm Jeff Anderson wrote:

> Console resizing is now in my branch (k6jca) of the SVN.  You can 
> increase the display size both horizontally & vertically 
> (independently).  Note, though, that larger displays will require more 
> CPU power, so if you start hearing pops, go back to a smaller size.  
> Controls are in Setup>Appearance>Display.
> 
> Console sizes range from the 'stock' size of 1024 x 624 pixels (h x 4) 
> to 1920 x 1200 pixels.
> 
> Please see me blog ([EMAIL PROTECTED]) for more info.  Also, please 
> answer the *new* poll question regarding resizing!
> 
> Let me know how it works...

It looks good.

I assume that this would enable the addition of another row of controls 
-- e.g., for the "normal," "180-degree" and "bi-directional" buttons for 
SteppIR users.

___
FlexRadio Systems Mailing List
FlexRadio@flex-radio.biz
http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Archives: http://www.mail-archive.com/flexradio%40flex-radio.biz/
Knowledge Base: http://kb.flex-radio.com/  Homepage: http://www.flex-radio.com/

Re: [Flexradio] Console resizing now in K6JCA branch of SVN

[FireBrick]

wow!
1620 x 1000
really fills most of my 22" monitor
and really leaves lots of console space for NEW FEATURES/CONTROLS


On 1/15/2008 7:15:10 PM, Jeff Anderson ([EMAIL PROTECTED]) wrote:
> Console resizing is now in my branch (k6jca) of the SVN.  You can
> increase the display size both horizontally & vertically
> (independently).  Note, though, that larger displays will require more
> CPU power, so if you start hearing pops, go back to a smaller size.
> Controls are in Setup>Appearance>Display.
>
> Console sizes range from the 'stock' size of 1024 x 624 pixels (h x 4)
> to 1920 x 1200 pixels.
>
> Please see me blog ([EMAIL PROTECTED]) for more info.  Also, please
> answer the *new* poll question regarding resizing!
>
> Let me know how it works...
>
> Thanks!
>
> - Jeff, k6jca
>
> ___
> FlexRadio Systems Mailing List
> FlexRadio@flex-radio.biz
> http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
> Archives: http://www.mail-archive.com/flexradio%40flex-radio.biz/
> Knowledge Base: http://kb.flex-radio.com/  Homepage: 
> http://www.flex-radio.
> com/


___
FlexRadio Systems Mailing List
FlexRadio@flex-radio.biz
http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Archives: http://www.mail-archive.com/flexradio%40flex-radio.biz/
Knowledge Base: http://kb.flex-radio.com/  Homepage: http://www.flex-radio.com/

[Flexradio] Console resizing now in K6JCA branch of SVN

[Jeff Anderson]

Console resizing is now in my branch (k6jca) of the SVN.  You can 
increase the display size both horizontally & vertically 
(independently).  Note, though, that larger displays will require more 
CPU power, so if you start hearing pops, go back to a smaller size.  
Controls are in Setup>Appearance>Display.

Console sizes range from the 'stock' size of 1024 x 624 pixels (h x 4) 
to 1920 x 1200 pixels.

Please see me blog ([EMAIL PROTECTED]) for more info.  Also, please 
answer the *new* poll question regarding resizing!

Let me know how it works...

Thanks!

- Jeff, k6jca

___
FlexRadio Systems Mailing List
FlexRadio@flex-radio.biz
http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Archives: http://www.mail-archive.com/flexradio%40flex-radio.biz/
Knowledge Base: http://kb.flex-radio.com/  Homepage: http://www.flex-radio.com/

Re: [Flexradio] Console Switching off on initial start-up

[Bernhard Hailer]

Dave,

I had a similar thing some time ago, and it got so bad that I suspected a 
problem with the radio itself. However at the end it turned out that I was 
dealing with a bad database file (powersdr.mdb). I deleted it and built it 
from scratch, and since I did that it runs like a dream.


Good luck!
Bernhard, AE6YN / DL4MHK

Also schrieb [EMAIL PROTECTED] am Freitag, 13. Oktober 2006 01:09 zum 
Thema "[Flexradio] Console Switching off on initial start-up":
| ZS6AVM wrote:
|
| I have raised this issue some time back !
| When starting PowerSDR (The Console) it switches off, even if I restart
| the Console, by clicking the On Button, it will switch on again, and
| then after a few seconds it'll switch off. The only way that it seems to
| stabilise is to close the Console and then restart it, then it stays
| operational. I'm not sure if this is a PC problem ?
| I'm using an Intel P4 (3gig CPU) Asus board, 1gig RAM, and a Delta 44
| Card
| Anyone have any ideas on this particular problem
|
| best regards
|
| Dave
|
| ***
|
|
| Disclaimer: The information contained in this communication is confidential
| and may be legally privileged.
|
| It is intended solely for the use of the individual or entity to whom it is
| addressed and others authorised to receive it.
|
| Any review, retransmission, dissemination, copying, disclosure or other use
| of, or taking of any action in reliance upon, this information by person or
| entities other then the intended recipient is prohibited.
|
| If you have received this message in error, please notify the sender
| immediately by e-mail, facsimile or telephone and return and/or destroy the
| original message and all copies from any computer.
|
|
| Denel (Pty) Ltd exercises no editorial control over e-mail messages
| originating in the organisation and does not accept any responsibility for
| either the contents of the message or any copyright laws that may have been
| violated by the person sending this message.
|
| Denel (Pty) Ltd is neither liable for the proper and complete transmission
| of the information contained in this communication nor any delay in its
| receipt.
|
| This message should not be copied or used for any purpose other than
| intended, nor should it be disclosed to any other person.
|
| ***
| -- next part --
| An HTML attachment was scrubbed...
| URL:
| /pipermail/flexradio_flex-radio.biz/attachments/20061013/86b6a447/attachmen
|t.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

___
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] Console Switching off on initial start-up

[daves]

ZS6AVM wrote:
 
I have raised this issue some time back !
When starting PowerSDR (The Console) it switches off, even if I restart
the Console, by clicking the On Button, it will switch on again, and
then after a few seconds it'll switch off. The only way that it seems to
stabilise is to close the Console and then restart it, then it stays
operational. I'm not sure if this is a PC problem ?
I'm using an Intel P4 (3gig CPU) Asus board, 1gig RAM, and a Delta 44
Card
Anyone have any ideas on this particular problem
 
best regards
 
Dave

***
 

Disclaimer: The information contained in this communication is confidential and 
may be legally privileged. 

It is intended solely for the use of the individual or entity to whom it is 
addressed and others authorised to receive it. 

Any review, retransmission, dissemination, copying, disclosure or other use of, 
or taking of any action in reliance upon, this information by person or 
entities other then the intended recipient is prohibited. 

If you have received this message in error, please notify the sender 
immediately by e-mail, facsimile or telephone and return and/or destroy the 
original message and all copies from any computer. 


Denel (Pty) Ltd exercises no editorial control over e-mail messages originating 
in the organisation and does not accept any responsibility for either the 
contents of the message or any copyright laws that may have been violated by 
the person sending this message. 

Denel (Pty) Ltd is neither liable for the proper and complete transmission of 
the information contained in this communication nor any delay in its receipt. 

This message should not be copied or used for any purpose other than intended, 
nor should it be disclosed to any other person. 

***
 
-- next part --
An HTML attachment was scrubbed...
URL: 
/pipermail/flexradio_flex-radio.biz/attachments/20061013/86b6a447/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?

[Bob Cowdery]

On Tue, 2006-08-29 at 23:32 -0400, Frank Brickle wrote:
> Bob --
> 
> If it's OK with you I'm taking the conversation public again, for the
> time being anyway.
> 
No problem with that at all.

> > Could we for example agree that there is a distributed infrastructure
> > (regardless of language, protocol or encoding formats) in which services
> > are hosted and that services communicate with each other through this
> > infrastructure by asynchronous messaging. I would like to give it a
> > name, say RSA (Radio Services Architecture) and define it properly so we
> > have a frame of reference.
> 
> We're a ways away from being able to give a name like Radio Services
> Architecture, yet, I think.
> 
Ok. On reflection defer the name until we have something to name.

> For a number of reasons, I propose we begin with what I'll call the
> Radio Space. This seem like an appropriate term? It's metaphorically
> suggestive. It's also the right concept formally, too, I believe, since
> an SDR "application" will turn out in the end to be, precisely, a
> topology on the Radio Space.
> 
Yes, I like that. Java coined the phrase Space in its Java Spaces which
is also a distributed architecture. Just to make it clear there is no
connection.

> The points in the Radio Space are the functional nodes we've been
> talking about -- the DSP, the hardware control, the audio subsystem,
> pieces of the UI, etc. We will probably find it useful to flip-flop back
> and forth as convenient between thinking of these components as points
> or as nodes, with the Space and the topology being either point sets or
> graphs.
> 
I think it would be useful, certainly for me to have a glossary of terms
as we proceed. I think we have introduced so far:

space, topology, service, process, node, point, graph, point set,
composition, orchestration, protocol, encoding format, messaging.

What about moving agreed stuff into a document as we proceed so we have
more than just a long thread at the end. This should probably be on-line
somewhere, perhaps a Wiki would be an appropriate medium.  

> So where we start is with a bunch of nodes but no edges connecting the
> nodes. There's no hierarchy or layering yet, merely a bunch of
> functional components that can be made to pass messages among one
> another.
> 
Agreed, whether the composition is flat or hierarchical and exactly how
messaging is achieved is not material at this level.

> > Services are composeable, that is they can be orchestrated to produce a
> > working application.
> 
> Yes. In these terms, a compositional grouping of components amounts to
> inducing a coarser topology on the Radio Space. In practical terms, it
> amounts to having a way to wrap them together so as to be able to deal
> with them as if they were a single functional unit.
> 
Yes, it's just levels of abstraction so people who know certain areas
well can compose those services into an abstraction that the next layer
can work with more easily.

> All right so far?
> 
Yes, excellent. I think its a good start. Of course this is not a small
subject and there are many places we could go next. Would it be sensible
to create a topics list first so we don't get bogged down on one issue.
I think working both ends towards the middle is also a good policy so
hot issues can have a proof-of-concept in parallel to the thought
process.

73
Bob
G3UKB

___
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]

Bob --

If it's OK with you I'm taking the conversation public again, for the
time being anyway.

> Could we for example agree that there is a distributed infrastructure
> (regardless of language, protocol or encoding formats) in which services
> are hosted and that services communicate with each other through this
> infrastructure by asynchronous messaging. I would like to give it a
> name, say RSA (Radio Services Architecture) and define it properly so we
> have a frame of reference.

We're a ways away from being able to give a name like Radio Services
Architecture, yet, I think.

For a number of reasons, I propose we begin with what I'll call the
Radio Space. This seem like an appropriate term? It's metaphorically
suggestive. It's also the right concept formally, too, I believe, since
an SDR "application" will turn out in the end to be, precisely, a
topology on the Radio Space.

The points in the Radio Space are the functional nodes we've been
talking about -- the DSP, the hardware control, the audio subsystem,
pieces of the UI, etc. We will probably find it useful to flip-flop back
and forth as convenient between thinking of these components as points
or as nodes, with the Space and the topology being either point sets or
graphs.

So where we start is with a bunch of nodes but no edges connecting the
nodes. There's no hierarchy or layering yet, merely a bunch of
functional components that can be made to pass messages among one
another.

> Services are composeable, that is they can be orchestrated to produce a
> working application.

Yes. In these terms, a compositional grouping of components amounts to
inducing a coarser topology on the Radio Space. In practical terms, it
amounts to having a way to wrap them together so as to be able to deal
with them as if they were a single functional unit.

All right so far?

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 20:23 -0400, Frank Brickle wrote:
> 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.
> 
I am very familiar with Service Oriented Architectures and applications
that are aggregations of services. I can see that the VR would be one
such service but it is not coordinating the application. It is as far as
I can see coordinating or aggregating two services, the DSP and the HW
Controller. I accept that as a useful part of the solution but I think
to put it over as the total solution is not accurate.

> 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 :-)
> 
If there were no differences of opinion life would be dull indeed. We
agree to differ on some points but there is also quite a lot we agree
on. In essence all I am suggesting is that the VR should not be by
default the centre of the universe but simply a service on this net. Let
people decide how they want to employ that service when aggregating
services into an application. It's a very small concession and would
make the system much more open. As it stands people can only write one
service which is the UI and everything except DSP and Controller has to
go into it. I want a much finer granularity.
  
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? http://sourceforge.net/projects/pyerlbridge/

[Bob Cowdery]

On Sun, 2006-08-27 at 21:28 -0500, Allen Boehm wrote:

>   http://sourceforge.net/projects/pyerlbridge/
> 
>I had found this site while searching Python sources. Don't know if
> it will be of help or interest, but decided to post it anyway as I was
> following the thread.
> 
 
Unfortunately the project hasn't created any packages yet.

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

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

[Allen Boehm]

On 8/27/06 2:38 PM, "Bob Cowdery" <[EMAIL PROTECTED]> wrote:

> 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.
> 
  http://sourceforge.net/projects/pyerlbridge/

   I had found this site while searching Python sources. Don't know if
it will be of help or interest, but decided to post it anyway as I was
following the thread.


> 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,

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] 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] 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

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

[Frank Brickle]

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.

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.

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.

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.

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 towards having the nodes local
or remote.

OK, that said: where are we diverging? I need to understand what
capabilities are helped or hindered under our different conceptions of
how the radio components are organized. As W. V. Quine said, the less a
science is advanced, the more it tends to rely on uncritical assumptions
of mutual understanding :-)

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 Fri, 2006-08-25 at 23:29 -0400, Robert McGwier wrote:
> Frank Brickle wrote:
> > On Wed, 2006-08-23 at 08:37 +0100, Bob Cowdery wrote:
> >   
> >> On Tue, 2006-08-22 at 22:54 -0700, Jim Lux wrote:
> >>
> >> 
> >>> I've been waiting for the long 
> >>> anticipated UI/backend split with a well defined interface, as announced, 
> >>> gosh, several times over the past couple years...
> >>>
> >>>   
> >> Am I the only one that doesn't understand this. As far as I can see
> >> there *is* a good split between the DSP and the rest of the radio.
> >> 
> >
> > *I* thought so too ;-)
> >
> >   
> >> I
> >> avoid saying UI because there is a heck of a lot of code which is
> >> neither DSP nor UI. This not inconsiderable wadge of code is what I am
> >> incorporating into a middle tier with a defined interface to the UI.
> >> 
> >
> > Just to be explicit, this wadge of code is exactly the "radio kernel"
> > we've been talking about. Bob (this Bob!) has done quite a bit of work
> > in the area already, very illuminating work one might add. There has
> > been another experimental version of this, done up in python, for over a
> > year now, as an item -- a "virtual radio" -- to contemplate and meditate
> > over, for merits and defects.
> >   
> 
> I have not found a pitfall yet.  It has taken me time to get my old 
> "write iterative C/C++" code out of my brain and shifted into recursive, 
> functional list processing but it has been worth every single hard 
> step.  This code is VERY compact.  I really do hope we do not run into 
> any serious performance issues but so far,  on Linux,  Windows, and Mac 
> OS/X,  erlc writes good code and the foreign language interface/ interop 
> to C/C++ is quite functional.   Very very few people will need to write 
> erlang.   It will be switching station for messages essentially between 
> distributed things where the core is required to learn and preserve 
> state while parsing/passing commands.
> 
> 
> 
> Bob
> 
> >   
> >> This interface will be defined in terms of JSON (www.json.org). Whether
> >> anybody else is interested in this approach is academic. I just wanted
> >> to point out I don't follow the line of thought.
> >> 
> >
> > FWIW, the DttSP radio kernel is being developed and implemented in
> > erlang. Barring unforeseen potholes, erlang will be the platform for the
> > virtual radio.

Can I explore this a little because languages and distributed systems
fascinate me and I want to understand more about whats good and whats
bad for this application. 

I have an onion skin model of what I want to do and at that level I
think its the same type of onion. I should draw a picture but lets make
do with words. At the centre is good old sockets, next up is the
messaging layer, then potentially but not necessarily language bindings.
I say not necessarily because I have two options, a common messaging
layer, say in 'C' with binding for each language I might want to interop
with or language specific libraries (which is my current preferred
route). The application layer then contains DSP, HW Control, GUI,
Virtual Radio/ Middle Tier and Management. Each of those pieces will be
a separate process interacting only through the messaging layer. There
can of course be multiples of each and each can be in virtually any
language as they are separated by process boundaries.

I've done a lot of this several times before but I've used the
capabilities of a specific language such as Pyro with Python and Opera
with Squeak. That has required me to have the same language on both
sides and therefore language bindings if I wanted the 'other' side to be
in a different language. This is an extra hop with marshalling which
adds complexity and impacts performance and in a lot of cases might not
be possible at all.

What I am aiming for now is an efficient language neutral messaging
layer where each end can have its own language specific library. At the
moment my favourite for this is JSON as being somewhat more efficient
than XML and very straight forward to implement.

This brings me to Erlang. I can see its a excellent concurrent
distributed language. If everything in the system was implemented in
Erlang or a minimal language mix I'm sure it would work great. However,
if I want to say write my middle tier in Ruby and my front end as a Java
web application with my process control layer (manager) in Python and
the backend still being in 'C'. A bit of an extreme example maybe but
it's a viable mix, I don't want to have to deal with a lot of language
integration issues.

I am drawing a big distinction here between the messaging layer and
what's being called the virtual radio. I see these as completely
separate things. The VR *is* the application and the messaging layer is
the communications infrastructure which the VR and other processes use. 

> >
> > A nice side-effect of this is the relative simplicity of talking to the
> > kernel in any old language you choose. Another nice side-e

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

[Robert McGwier]

Frank Brickle wrote:
> On Wed, 2006-08-23 at 08:37 +0100, Bob Cowdery wrote:
>   
>> On Tue, 2006-08-22 at 22:54 -0700, Jim Lux wrote:
>>
>> 
>>> I've been waiting for the long 
>>> anticipated UI/backend split with a well defined interface, as announced, 
>>> gosh, several times over the past couple years...
>>>
>>>   
>> Am I the only one that doesn't understand this. As far as I can see
>> there *is* a good split between the DSP and the rest of the radio.
>> 
>
> *I* thought so too ;-)
>
>   
>> I
>> avoid saying UI because there is a heck of a lot of code which is
>> neither DSP nor UI. This not inconsiderable wadge of code is what I am
>> incorporating into a middle tier with a defined interface to the UI.
>> 
>
> Just to be explicit, this wadge of code is exactly the "radio kernel"
> we've been talking about. Bob (this Bob!) has done quite a bit of work
> in the area already, very illuminating work one might add. There has
> been another experimental version of this, done up in python, for over a
> year now, as an item -- a "virtual radio" -- to contemplate and meditate
> over, for merits and defects.
>   

I have not found a pitfall yet.  It has taken me time to get my old 
"write iterative C/C++" code out of my brain and shifted into recursive, 
functional list processing but it has been worth every single hard 
step.  This code is VERY compact.  I really do hope we do not run into 
any serious performance issues but so far,  on Linux,  Windows, and Mac 
OS/X,  erlc writes good code and the foreign language interface/ interop 
to C/C++ is quite functional.   Very very few people will need to write 
erlang.   It will be switching station for messages essentially between 
distributed things where the core is required to learn and preserve 
state while parsing/passing commands.



Bob

>   
>> This interface will be defined in terms of JSON (www.json.org). Whether
>> anybody else is interested in this approach is academic. I just wanted
>> to point out I don't follow the line of thought.
>> 
>
> FWIW, the DttSP radio kernel is being developed and implemented in
> erlang. Barring unforeseen potholes, erlang will be the platform for the
> virtual radio.
>
> A nice side-effect of this is the relative simplicity of talking to the
> kernel in any old language you choose. Another nice side-effect is the
> way erlang makes it possible to demonstrate (if not prove formally) the
> correctness of the kernel.
>   

I have seen some really serious papers on "proof of correctness"  for 
Erlang state machines.  They are fascinating (if of limited relevance to 
our ultimate purposes).
> Although it might not be obvious, we went to considerable lengths to
> show the correctness of the concurrency in DttSP. It's taken awhile to
> clear away the weeds around the underlying model, however. Exactly the
> analogous process is now taking place in connection with the kernel.
>
>   
>> Incidentally I agree with the mode separation. The state machine I am
>> using in the middle tier is largely based on mode state, separately in
>> RX and TX. This gives the ability to finely control what happens in
>> different modes. 
>> 
>
> Thank you. This is the far and away best justification for
> one-size-doesn't-fit-all that's yet come to the fore.
>
>   
>> However I do believe the request has more to do with the ability to have
>> control over the DSP configuration, to re-sequence blocks and insert
>> user defined blocks aka GNURadio style than it is to do with separating
>> DSP and UI. If I'm way off track tell me.
>> 
>
> ...which is exactly what gnuradio is for!
>
> Except for hardware control, there's nothing standing in the way of
> using gnuradio with the SDR1K. It would be great if somebody would
> pursue it.
>
> 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
>
>   


-- 
AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats,
NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman
"You see, wire telegraph is a kind of a very, very long cat.
You pull his tail in New York and his head is meowing in Los
Angeles. Do you understand this? And radio operates exactly
the same way: you send signals here, they receive them there.
The only difference is that there is no cat." - Einstein


___
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

[Robert McGwier]

[EMAIL PROTECTED] wrote:
>  
> Slow down!  Not so fast!  
>  
> The skins do look great, but if I want to operate a radio that looks like  my 
> FT 1000, I'll turn off my SDR-1000 and turn on the black box.
>  
> I'm tired of the old paradigm.  The SDR is new, fresh and  unconventional.  
> Don't make it like all the others.
>  
> For those that want the skins, OK..  But I don't want to go back to  the 
> conventional.
>   

That is the point.  We want to have our cake and eat it to.   You will 
be able to do things in an unconventional way using the separated 
process models and those who want the fancy GUIs will be able to get 
them as "after market" add-ons (for free of course).  I even suspect we 
might find ourselves having for pay front ends eventually since it will 
be quite easy indeed to add that kind of support in our next major 
"paradigm" shift.

Bob
N4HY

>  
> Bob
> K8MLM
> Happy Flex user since MAY 05
>  
>   


-- 
AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats,
NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman
"You see, wire telegraph is a kind of a very, very long cat.
You pull his tail in New York and his head is meowing in Los
Angeles. Do you understand this? And radio operates exactly
the same way: you send signals here, they receive them there.
The only difference is that there is no cat." - Einstein


___
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?

[Jim Lux]

At 02:17 PM 8/23/2006, Bob Cowdery wrote:

> > Perhaps it's a difference between expectations and reality?
> > We've been hearing about a well defined (i.e. documented) interface 
> between
> > the realtime radio code and the control interface for some months now.
> > (Version 1.7?)
> >
> > Is there?  If you download the latest PowerSDR is there an obvious
> > interface layer between the "radio" code (dttsp, and the interface that
> > controls the SDR hardware) and everything else?  Or, does it all have to
> > get compiled together?
> >
>Jim, I fully understand what you mean. Perhaps its the starting point
>which differs. The backend I use when on Windows is the pure DSP code
>plus my own audio code packaged with a very simple interface. This makes
>it look almost the same as the Linux version (which has always had
>excellent separation, heck its a different process, how more separated
>can you get) from a programming perspective except I call a function
>with the DSP control string rather than shove it down a pipe or receive
>data from a pipe. The interface really is very simple mainly because I
>keep it at the string command level rather than enumerating all the
>possible functions as PowerSDR does.

So, what you've effectively done is define an interface abstraction layer 
that supports a subset of the dttsp functionality, and stripped away all of 
PowerSDR on top.  I've done something similar, except I use matlab for the 
dsp and I've created a command interface to the hardware that just reads 
and writes from stdin/out.

But neither of these is really PowerSDR anymore. They're a totally separate 
system (albeit sharing some commonality with PowerSDR).



>  And, yes the jumping around between
>C and C# does make it look like a complicated interface when in fact it
>isn't.

That's partly the fault of the "windows way", and I don't hold it against 
PowerSDR developers.  The problem I have is that you go into the definition 
of the interface (in dsp.cs) and you have well over 100 entrypoints 
defined, with almost nothing that tells you what they do, what the 
parameters might be, or how they fit together.
This is kind of scary when you see entry points that are clearly "flow" 
related (as opposed to set and get parameters): cwtimerfired, 
ProcessSamplesThread, etc.

A simple entity relationship diagram that showed which data is going where, 
and, in particular, the realtime flow of data in and out of dttsp would be 
handy.






>The controller is just a C module which I link and call exactly the same
>way on both platforms (in fact the C# implementation is more complete at
>this time but I've dropped using it because I don't want to bridge into
>the .NET platform). These interfaces could be defined such that people
>don't have to to search out how to use them but I'm not sure it would
>solve the problem as I'm not sure what the problem is. All it would let
>you do is write a front end which right now is an awful lot of code to
>get anywhere near the PowerSDR functionality and frankly the extra day
>you would need to spend figuring out the interface will get lost in the
>noise.

However, if the interface between the PowerSDR functionality (control and 
display-wise) were cleanly defined, one would be able to use the PowerSDR 
front end with a different backend, for instance. It's not clear just how 
tightly coupled and interdependent the front and back are.

As you say, in the *nix world, you have a distinct process, and 
interprocess communication is fairly well defined and localized.

In the current PowerSDR world, you've got a event driven UI calling 
routines in a realtime-ish backend running in a separate thread.  Part of 
the problem is the incredibly clunky threading model in VS2003, and the 
fact that the interfaces are DLL style APIs, and not interprocess style 
messaging.  And, because the interfaces have all been defined as unsafe 
public, etc., there's no real guarantee (enforced by the compiler/linker) 
that nobody is doing something evil (like looking in some other class's 
memory space)


>If you want to write front ends (and I don't think you do) then you need
>a much higher level interface at the presentation layer which hopefully
>the various efforts going on right now will eventually give you. If you
>want to plug-in user defined things either at the user interface level
>(say a new tuning control) or at the DSP level, say your own AGC
>algorithm then that's a whole different game and I defer to the guys
>that know 'the plan' for that.

Hmm. and that 'plan' is a bit vague and shifting.

For example, say one wished to run 4 SDR-1000s, with separate dsp 
instances, but have a separate controller interface that talks to each of 
the dsps (say to adjust apparent IF frequency) and then bring all 4 
(baseband) audio streams together. This is pretty darn clunky today, if 
even possible in a stable sort of way.

A well defined "radio" interface would provide a clean interface to 
"command" the

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

[Bob Cowdery]

On Wed, 2006-08-23 at 07:35 -0700, Jim Lux wrote:
> At 12:37 AM 8/23/2006, Bob Cowdery wrote:
> >On Tue, 2006-08-22 at 22:54 -0700, Jim Lux wrote:
> >
> > > I've been waiting for the long
> > > anticipated UI/backend split with a well defined interface, as announced,
> > > gosh, several times over the past couple years.  That way, I can do what
> > > *I* want to do, without having to insert it into the middle of PowerSDR,
> > > with all that entails.  I'm not the only one asking for the ability to 
> > have
> > > some well defined interface for "plug-ins", so, you'll excuse my 
> > admittedly
> > > snide RSN comment (http://en.wikipedia.org/wiki/Real_soon_now)
> > >
> >Am I the only one that doesn't understand this. As far as I can see
> >there *is* a good split between the DSP and the rest of the radio.
> 
> Perhaps it's a difference between expectations and reality?
> We've been hearing about a well defined (i.e. documented) interface between 
> the realtime radio code and the control interface for some months now. 
> (Version 1.7?)
> 
> Is there?  If you download the latest PowerSDR is there an obvious 
> interface layer between the "radio" code (dttsp, and the interface that 
> controls the SDR hardware) and everything else?  Or, does it all have to 
> get compiled together?
> 
Jim, I fully understand what you mean. Perhaps its the starting point
which differs. The backend I use when on Windows is the pure DSP code
plus my own audio code packaged with a very simple interface. This makes
it look almost the same as the Linux version (which has always had
excellent separation, heck its a different process, how more separated
can you get) from a programming perspective except I call a function
with the DSP control string rather than shove it down a pipe or receive
data from a pipe. The interface really is very simple mainly because I
keep it at the string command level rather than enumerating all the
possible functions as PowerSDR does. And, yes the jumping around between
C and C# does make it look like a complicated interface when in fact it
isn't. 

The controller is just a C module which I link and call exactly the same
way on both platforms (in fact the C# implementation is more complete at
this time but I've dropped using it because I don't want to bridge into
the .NET platform). These interfaces could be defined such that people
don't have to to search out how to use them but I'm not sure it would
solve the problem as I'm not sure what the problem is. All it would let
you do is write a front end which right now is an awful lot of code to
get anywhere near the PowerSDR functionality and frankly the extra day
you would need to spend figuring out the interface will get lost in the
noise.

If you want to write front ends (and I don't think you do) then you need
a much higher level interface at the presentation layer which hopefully
the various efforts going on right now will eventually give you. If you
want to plug-in user defined things either at the user interface level
(say a new tuning control) or at the DSP level, say your own AGC
algorithm then that's a whole different game and I defer to the guys
that know 'the plan' for that.

> There is also a plethora of little pieces that all have to work together 
> (which is how ALL real applications work at some level, so no complaints 
> there), but to me, a well defined interface would have ONE place where 
> you'd go to figure these things out.  Not, Oh, you make these DLL calls to 
> dttsp, then call this routine to control the 9854, and then, you have to 
> support this other callback to display data from the dsp, and, you also 
> have to manage pthreads and portaudio.
> 
> Where's the "abstraction layer"?
> 
I'm not going argue for or against the way its done on Windows. It's
pragmatic because of who is responsible for what. The lack of reasonable
ways to split Windows programs into processes makes life difficult. I'm
sure Bob, Frank and Eric have a way forward. Maybe erlang is the way to
bring processes to Windows. I'd only be guessing so best keep quiet.
 
> Frankly, I'm not interested in reverse engineering the architecture, 
> particularly if it's going to change in the future.
> 
> 
> >  I
> >avoid saying UI because there is a heck of a lot of code which is
> >neither DSP nor UI. This not inconsiderable wadge of code is what I am
> >incorporating into a middle tier with a defined interface to the UI.
> >This interface will be defined in terms of JSON (www.json.org). Whether
> >anybody else is interested in this approach is academic. I just wanted
> >to point out I don't follow the line of thought.
> 
> 
> This is interesting..
> 
> 
> 
> Jim 
> 
> 

___
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 Wed, 2006-08-23 at 18:16 +0100, James Courtier-Dutton wrote:

> So, a typical reason for NOT using erlang is "signal processing". Why is 
> dttsp therefore using erlang?

The kernel is not doing signal processing. That, the DSP, is in
sdr-core, in C. The kernel implements the "virtual radio" -- the idea of
VFO, bandswitching, etc. -- it *controls* the DSP. It stands as the
interface between the low-level crunching (DSP) and hardware control. As
the excerpt you very kindly provided says, that is just the sort of task
it was intended for.

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?

[James Courtier-Dutton]

Frank Brickle wrote:
> FWIW, the DttSP radio kernel is being developed and implemented in
> erlang. Barring unforeseen potholes, erlang will be the platform for the
> virtual radio.
>   
Why was erlang choosen?
The FAQ at www.erlang.org states:
<<>>
1.4. What sort of problems is Erlang not particularly suitable for?

People use Erlang for all sorts of surprising things, for instance to 
communicate with X11 at the protocol level, but, there are some common 
situations where Erlang is not likely to be the language of choice.

The most common class of 'less suitable' problems is characterised by 
performance being a prime requirement and constant-factors having a 
large effect on performance. Typical examples are image processing, 
signal processing, sorting large volumes of data and low-level protocol 
termination.

Another class of problem is characterised by a wide interface to 
existing C code. A typical example is implementing operating system 
device drivers.

Most (all?) large systems developed using Erlang make heavy use of C for 
low-level code, leaving Erlang to manage the parts which tend to be 
complex in other languages, like controlling systems spread across 
several machines and implementing complex protocol logic.

<<>>

So, a typical reason for NOT using erlang is "signal processing". Why is 
dttsp therefore using erlang?

James



___
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?

[Jim Lux]

At 12:37 AM 8/23/2006, Bob Cowdery wrote:
>On Tue, 2006-08-22 at 22:54 -0700, Jim Lux wrote:
>
> > I've been waiting for the long
> > anticipated UI/backend split with a well defined interface, as announced,
> > gosh, several times over the past couple years.  That way, I can do what
> > *I* want to do, without having to insert it into the middle of PowerSDR,
> > with all that entails.  I'm not the only one asking for the ability to 
> have
> > some well defined interface for "plug-ins", so, you'll excuse my 
> admittedly
> > snide RSN comment (http://en.wikipedia.org/wiki/Real_soon_now)
> >
>Am I the only one that doesn't understand this. As far as I can see
>there *is* a good split between the DSP and the rest of the radio.

Perhaps it's a difference between expectations and reality?
We've been hearing about a well defined (i.e. documented) interface between 
the realtime radio code and the control interface for some months now. 
(Version 1.7?)

Is there?  If you download the latest PowerSDR is there an obvious 
interface layer between the "radio" code (dttsp, and the interface that 
controls the SDR hardware) and everything else?  Or, does it all have to 
get compiled together?

There is also a plethora of little pieces that all have to work together 
(which is how ALL real applications work at some level, so no complaints 
there), but to me, a well defined interface would have ONE place where 
you'd go to figure these things out.  Not, Oh, you make these DLL calls to 
dttsp, then call this routine to control the 9854, and then, you have to 
support this other callback to display data from the dsp, and, you also 
have to manage pthreads and portaudio.

Where's the "abstraction layer"?

Frankly, I'm not interested in reverse engineering the architecture, 
particularly if it's going to change in the future.


>  I
>avoid saying UI because there is a heck of a lot of code which is
>neither DSP nor UI. This not inconsiderable wadge of code is what I am
>incorporating into a middle tier with a defined interface to the UI.
>This interface will be defined in terms of JSON (www.json.org). Whether
>anybody else is interested in this approach is academic. I just wanted
>to point out I don't follow the line of thought.


This is interesting..



Jim 



___
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 Wed, 2006-08-23 at 08:37 +0100, Bob Cowdery wrote:
> On Tue, 2006-08-22 at 22:54 -0700, Jim Lux wrote:
> 
> > I've been waiting for the long 
> > anticipated UI/backend split with a well defined interface, as announced, 
> > gosh, several times over the past couple years...
> >
> Am I the only one that doesn't understand this. As far as I can see
> there *is* a good split between the DSP and the rest of the radio.

*I* thought so too ;-)

> I
> avoid saying UI because there is a heck of a lot of code which is
> neither DSP nor UI. This not inconsiderable wadge of code is what I am
> incorporating into a middle tier with a defined interface to the UI.

Just to be explicit, this wadge of code is exactly the "radio kernel"
we've been talking about. Bob (this Bob!) has done quite a bit of work
in the area already, very illuminating work one might add. There has
been another experimental version of this, done up in python, for over a
year now, as an item -- a "virtual radio" -- to contemplate and meditate
over, for merits and defects.

> This interface will be defined in terms of JSON (www.json.org). Whether
> anybody else is interested in this approach is academic. I just wanted
> to point out I don't follow the line of thought.

FWIW, the DttSP radio kernel is being developed and implemented in
erlang. Barring unforeseen potholes, erlang will be the platform for the
virtual radio.

A nice side-effect of this is the relative simplicity of talking to the
kernel in any old language you choose. Another nice side-effect is the
way erlang makes it possible to demonstrate (if not prove formally) the
correctness of the kernel.

Although it might not be obvious, we went to considerable lengths to
show the correctness of the concurrency in DttSP. It's taken awhile to
clear away the weeds around the underlying model, however. Exactly the
analogous process is now taking place in connection with the kernel.

> Incidentally I agree with the mode separation. The state machine I am
> using in the middle tier is largely based on mode state, separately in
> RX and TX. This gives the ability to finely control what happens in
> different modes. 

Thank you. This is the far and away best justification for
one-size-doesn't-fit-all that's yet come to the fore.

> However I do believe the request has more to do with the ability to have
> control over the DSP configuration, to re-sequence blocks and insert
> user defined blocks aka GNURadio style than it is to do with separating
> DSP and UI. If I'm way off track tell me.

...which is exactly what gnuradio is for!

Except for hardware control, there's nothing standing in the way of
using gnuradio with the SDR1K. It would be great if somebody would
pursue it.

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 Tue, 2006-08-22 at 22:54 -0700, Jim Lux wrote:

> I've been waiting for the long 
> anticipated UI/backend split with a well defined interface, as announced, 
> gosh, several times over the past couple years.  That way, I can do what 
> *I* want to do, without having to insert it into the middle of PowerSDR, 
> with all that entails.  I'm not the only one asking for the ability to have 
> some well defined interface for "plug-ins", so, you'll excuse my admittedly 
> snide RSN comment (http://en.wikipedia.org/wiki/Real_soon_now)
> 
Am I the only one that doesn't understand this. As far as I can see
there *is* a good split between the DSP and the rest of the radio. I
avoid saying UI because there is a heck of a lot of code which is
neither DSP nor UI. This not inconsiderable wadge of code is what I am
incorporating into a middle tier with a defined interface to the UI.
This interface will be defined in terms of JSON (www.json.org). Whether
anybody else is interested in this approach is academic. I just wanted
to point out I don't follow the line of thought.

Incidentally I agree with the mode separation. The state machine I am
using in the middle tier is largely based on mode state, separately in
RX and TX. This gives the ability to finely control what happens in
different modes. 

However I do believe the request has more to do with the ability to have
control over the DSP configuration, to re-sequence blocks and insert
user defined blocks aka GNURadio style than it is to do with separating
DSP and UI. If I'm way off track tell me.

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

___
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]

OK, Jim. You keep writing specs. We'll keep writing radios.

It's hard to avoid the impression you haven't been keeping up with
developments.

To echo the end of your previous note, 'nuff said.

73
Frank
AB2KT

On Tue, 2006-08-22 at 22:54 -0700, Jim Lux wrote:
> "
>  > And when will those specs be published?  RSN?
> 
> As soon as you've finished them, Jim.
> "
> I don't think you want me writing specs that you'll have to conform to, 
> Frank.  Defining specifications and architectures for abstract software 
> defined radios, especially the external interface, is what I do for a 
> living these days.  Somehow, I suspect that the PowerSDR/DTTSP/SDR1000 
> world isn't quite ready for that level of rigor (and a darn good thing, 
> too...).  However, you're free to read the stuff on the Glenn Research 
> Center website (http://www.spaceref.com/news/viewsr.html?pid=19322 has the 
> links) asking for suggestions on how such radios should be described.
> 
> 
> ---
> Frank writes:
> 
> >If you want to know what's going on, make a positive, tangible
> >contribution, in the form of real, testable code.
> 
> If you're not
> interested in doing that -- your reasons for or against are your own
> business -- then you haven't even made a down payment on the price of
> admission.
> ---
> I think that reverse engineering Bob's and your undocumented code last 
> February is more than the price of admission.
> 
> As far as I know (from reading the mailing list) I am the first to have 
> published  documentation on the software flow and structure, as it existed, 
> at the time:  February, 2006. After an initial inspiration from the 
> teamspeak forum talking about future development plans,  I abandoned this 
> incredibly tedious effort when I discovered that there was dead code from 
> days gone by in the code base (why waste my time figuring out stuff you'd 
> already given up on, or more to the point, given up on, but didn't bother 
> to remove), and, the fact that "real soon now" everything is going to be 
> restructured in a better way.  Why toil to document something that's going 
> to die soon?
> 
> But then, perhaps to someone who eschews documentation and design 
> documentation, only real, testable (and totally unmaintainable and 
> modifiable by someone else) code is worthy.  I am sure the authors of the 
> texts in Linear A found in the ruins of Knossos felt the same.
> 
> 
> Frank: "Once the CVS tree is up, it will be high time to start documenting 
> the code from the standpoint of someone approaching it fresh. A Wiki sounds 
> like the ideal vehicle. "  March 3, 2005
> Bob: "I feel the cost to me (us?) for all of you putting up with our 
> lengthy development process is that we should share as much detail as 
> possible in some form of writing. We will soon have time to do just that." 
> March 4, 2005
> 
> The lack of documentation is just your and the flex community's 
> loss.  Hey.. it's a great product as it is. It works reasonably well, lots 
> of people have fun with it, it's moving forward. I'm particularly impressed 
> by the recent EME QSO. And heck, one doesn't need source code documentation 
> as long as you and Bob are alive and interested in it to maintain it.  All 
> Flex-er's though, should fear for the day that you get hit by a bus, or get 
> distracted by something else, or have a final fatal disk crash without a 
> backup, etc.  And even in that horrible scenario, I suspect that someone 
> would step in to make emergency patches as needed. And someone else will 
> create an entirely new codebase, in the time honored software tradition of 
> "we can just rewrite from scratch in less time than trying to figure out 
> what this all does".
> 
> The only real problem is that the code base, without documentation, is 
> essentially a private toy for a few to play with.  No biggie. I don't 
> aspire to tinker with the Linux kernel either (although there IS some 
> documentation for that). I don't NEED to write code for the SDR1000 to do 
> the things I want to do, and following along with the classic F/OSS model, 
> if it's not scratching an itch for me, I don't do it.
> 
> However, I DO aspire to do more sophisticated signal processing with the 
> SDR1000 platform. And to do that, I've been waiting for the long 
> anticipated UI/backend split with a well defined interface, as announced, 
> gosh, several times over the past couple years.  That way, I can do what 
> *I* want to do, without having to insert it into the middle of PowerSDR, 
> with all that entails.  I'm not the only one asking for the ability to have 
> some well defined interface for "plug-ins", so, you'll excuse my admittedly 
> snide RSN comment (http://en.wikipedia.org/wiki/Real_soon_now)
> 
> Based on past experience, all we who want such clean interfaces can hope 
> for is that someone more enlightened with a longer term vision will create 
> a new software base for the fine hardware.  For myself at work, I have 
>

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

[Jim Lux]

"
 > And when will those specs be published?  RSN?

As soon as you've finished them, Jim.
"
I don't think you want me writing specs that you'll have to conform to, 
Frank.  Defining specifications and architectures for abstract software 
defined radios, especially the external interface, is what I do for a 
living these days.  Somehow, I suspect that the PowerSDR/DTTSP/SDR1000 
world isn't quite ready for that level of rigor (and a darn good thing, 
too...).  However, you're free to read the stuff on the Glenn Research 
Center website (http://www.spaceref.com/news/viewsr.html?pid=19322 has the 
links) asking for suggestions on how such radios should be described.


---
Frank writes:

>If you want to know what's going on, make a positive, tangible
>contribution, in the form of real, testable code.

If you're not
interested in doing that -- your reasons for or against are your own
business -- then you haven't even made a down payment on the price of
admission.
---
I think that reverse engineering Bob's and your undocumented code last 
February is more than the price of admission.

As far as I know (from reading the mailing list) I am the first to have 
published  documentation on the software flow and structure, as it existed, 
at the time:  February, 2006. After an initial inspiration from the 
teamspeak forum talking about future development plans,  I abandoned this 
incredibly tedious effort when I discovered that there was dead code from 
days gone by in the code base (why waste my time figuring out stuff you'd 
already given up on, or more to the point, given up on, but didn't bother 
to remove), and, the fact that "real soon now" everything is going to be 
restructured in a better way.  Why toil to document something that's going 
to die soon?

But then, perhaps to someone who eschews documentation and design 
documentation, only real, testable (and totally unmaintainable and 
modifiable by someone else) code is worthy.  I am sure the authors of the 
texts in Linear A found in the ruins of Knossos felt the same.


Frank: "Once the CVS tree is up, it will be high time to start documenting 
the code from the standpoint of someone approaching it fresh. A Wiki sounds 
like the ideal vehicle. "  March 3, 2005
Bob: "I feel the cost to me (us?) for all of you putting up with our 
lengthy development process is that we should share as much detail as 
possible in some form of writing. We will soon have time to do just that." 
March 4, 2005

The lack of documentation is just your and the flex community's 
loss.  Hey.. it's a great product as it is. It works reasonably well, lots 
of people have fun with it, it's moving forward. I'm particularly impressed 
by the recent EME QSO. And heck, one doesn't need source code documentation 
as long as you and Bob are alive and interested in it to maintain it.  All 
Flex-er's though, should fear for the day that you get hit by a bus, or get 
distracted by something else, or have a final fatal disk crash without a 
backup, etc.  And even in that horrible scenario, I suspect that someone 
would step in to make emergency patches as needed. And someone else will 
create an entirely new codebase, in the time honored software tradition of 
"we can just rewrite from scratch in less time than trying to figure out 
what this all does".

The only real problem is that the code base, without documentation, is 
essentially a private toy for a few to play with.  No biggie. I don't 
aspire to tinker with the Linux kernel either (although there IS some 
documentation for that). I don't NEED to write code for the SDR1000 to do 
the things I want to do, and following along with the classic F/OSS model, 
if it's not scratching an itch for me, I don't do it.

However, I DO aspire to do more sophisticated signal processing with the 
SDR1000 platform. And to do that, I've been waiting for the long 
anticipated UI/backend split with a well defined interface, as announced, 
gosh, several times over the past couple years.  That way, I can do what 
*I* want to do, without having to insert it into the middle of PowerSDR, 
with all that entails.  I'm not the only one asking for the ability to have 
some well defined interface for "plug-ins", so, you'll excuse my admittedly 
snide RSN comment (http://en.wikipedia.org/wiki/Real_soon_now)

Based on past experience, all we who want such clean interfaces can hope 
for is that someone more enlightened with a longer term vision will create 
a new software base for the fine hardware.  For myself at work, I have 
enough software to control the boxes, and for now, non-real-time processing 
of the data in Matlab is sufficient.

Sure, someday it would be nice to use my home SDR1000 as an exciter with my 
phased array. But right now, my personal programming time is consumed with 
imbuing myself with "the way of Bill and his minions" with respect to the 
vagaries of WindowsXP real time programming for the phased array, rather 
than trying to un

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

[Jim Lux]

At 06:32 PM 8/22/2006, Frank Brickle wrote:
>On Tue, 2006-08-22 at 17:25 -0700, Jim Lux wrote:
>
> > The problem I see is that since there is no current specification (or even
> > preliminary detailed sketches) of a published UI/Radio interface, everyone
> > is sort of working on modifying what's there now.
>
>Jim, I have nothing but respect and admiration for your knowledge and
>accomplishments within your own sphere. In this particular area,
>however, you are speaking out of ignorance and spreading little more
>than your own confusion.
>
>If you want to know what's going on, make a positive, tangible
>contribution, in the form of real, testable code. If you're not
>interested in doing that -- your reasons for or against are your own
>business -- then you haven't even made a down payment on the price of
>admission.

I resent this, particularly in a public forum.
'nuff said.

Jim



___
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?

[Charles Greene]

Jerry,

I agree on that.  Some of the controls on the console are just used 
in one mode.  Why have a compander control in digital, or any audio 
controls in CW?  Maybe it should be standard to drop controls that 
are not used in a particular mode, and use that valuable real estate 
for a control that is used in that mode.  That should be easy to 
implement, and agreement should be easy to attain.

73,  Chas, W1CG

At 11:04 AM 8/22/2006, Jerry Flanders wrote:
>We are not operating radios - we are operating  _modes_ (i.e., ssb
>phone OR cw OR rtty OR psk31 OR ... ).
>
>An all-mode console is great when demonstrating the radio to your SWL
>friend, but when he goes home you operate your radio mostly on your
>favorite mode, and you might benefit if your console reflected this.
>
>If available, you would probably want several similar consoles, each
>with specific enhancements for a particular mode. You would use one
>at a time, of course. In a few years,  when SDR has become the
>dominant type of radio, I think ops will want and have specialized
>consoles like this.
>
>For instance, right now I want a console specific to RTTY contesting
>operations - it doesn't need the usual ANF button, but it could
>benefit from a different kind of ANF that only removes a multi-second
>long constant cw QRM. It doesn't need a CW memory keyer, but a
>built-in FFT tuning display/waterfall  like MMTTY provides would be
>very useful. It doesn't need an audio equalizer, but real FSK would help.
>
>At the present stage of development, the do-it-all console is a
>handful for any development team, but we will probably evolve more
>specific consoles as time goes on and more developers come on board.
>
>Jerry W4UK
>
>At 13:04 8/22/2006, Charles Greene wrote:
> >John,
> >
> >I was engaged in a conversation about SRDs on the Ten Tec reflector a
> >couple of days ago.  Someone stated that SDRs needed to look like
> >"real" radios in order to get wide acceptance.  These consoles
> >certainly fill that bill.  Well done.  However, I question the wisdom
> >of filling up a console with individual "radio" buttons when drop
> >down menus will do the same thing.  Take the Display selection for
> >example.  Most operators don't use all the optional displays, and to
> >dedicate the real estate for 7 "radio" buttons seems to take
> >nostalgia a bit too far.  I never liked the FT-1K or IC-7800 front
> >panels for the reason that they too complicated and the learning
> >curve is too high.  On the other hand, there is the Jupiter which
> >combines real push buttons with drop down menus, although Ten Tec's
> >choice of menus is not that intuitive.  Perhaps a console with more
> >"radio" buttons but retaining drop down menus for less frequently
> >selected functions would be a better choice.
> >
> >73  Chas W1CG
> >
> >At 11:14 AM 8/21/2006, W0UN -- John Brosnahan wrote:
> > >Dear Beppe--
> > >
> > >
> > >I LOVE the look of your front panel art for the SDR projects.  I
> > >sure hope that
> > >someone incorporates the concepts into the console software for both the
> > >FlexRadio and the SoftRock.
> > >
> > >http://www.radioamatore.it/sdr1000/mypowersdr.html
> > >
> > >Here is a link to a friend of mine who has a calculator program
> > with a similar
> > >appearance.  You can go to the VIEW and then SKINS and make changes in
> > >the appearance of the calculator.  It would be very nice to have
> > >skins to allow
> > >the colors and general appearance to be easily changed.  I can see the
> > >need for BRIGHT colors to help keep you awake late at night, especially at
> > >the end of a contest.  On the other hand there is a lot to be said for
> > >soothing colors for general operation.
> > >
> > >http://www.dreamcalc.com/
> > >
> > >This software was written by a British friend of mine in about 8 THOUSAND
> > >hours of effort.  So I have some idea of the work involved in 
> some of these
> > >projects.
> > >
> > >Just thought you might like to look at it as an idea of where to take the
> > >console's appearance.  Not only does it do scientific calculations and
> > >business calculations, it does a lot of very nice graphics presentations
> > >of the data in an appearance of your choice.
> > >
> > >
> > >73--John  W0UN
> > >
> > >
> > >___
> > >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 mailing list
>FlexRadio@flex-radio.biz
>http://mail.flex

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

[Frank Brickle]

On Tue, 2006-08-22 at 17:25 -0700, Jim Lux wrote:

> The problem I see is that since there is no current specification (or even 
> preliminary detailed sketches) of a published UI/Radio interface, everyone 
> is sort of working on modifying what's there now.

Jim, I have nothing but respect and admiration for your knowledge and
accomplishments within your own sphere. In this particular area,
however, you are speaking out of ignorance and spreading little more
than your own confusion.

If you want to know what's going on, make a positive, tangible
contribution, in the form of real, testable code. If you're not
interested in doing that -- your reasons for or against are your own
business -- then you haven't even made a down payment on the price of
admission.

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?

[Jim Lux]

At 03:00 PM 8/22/2006, Ken N9VV wrote:
>Dear Jim,
>any more options and you will surely drive many of us right off the 
>reflector and onto the Ten-Tec webpage about the new Omni-VII (TT is 
>offering a VB console example as opensource).

Hmmm.. we'll see.  The real question is whether they publish a detailed 
interface specification, or if you'll have to infer it from the VB source code.

And, of course, the interface to something like this will likely be at the 
serial port command/response style (CAT, CI-V, hamlib) sort of level of 
abstraction.  The Pegasus has a funky interface where it looks for a file 
and reads it, but ultimately, it's still a "command"/"response" style of 
interface, and that imposes certain inherent limitations on what you can do.


>Uncle! I give. The average plain-vanilla (stupid) ham like me can only 
>take so much Jim!


Naahhh... it just goes to show that it's easy to say "Let's separate the UI 
and the radio backend with an abstract interface", but very, very difficult 
to do this in practice.  Once you start to try to describe that interface, 
with a level of detail that "someone can code to it", you wind up with an 
amazingly complex construct.

Ideally, this would all be irrelevant to most users (just as most users of 
Windows applications neither know nor care about the esoterica of Windows 
Event handling and threading models).

If you use one of the programs controlling, for instance, an IC-7000, you 
don't really care what the messages going across the CI-V interface 
are.  However, the person producing that slice interface most certainly 
does, and that interface, to a certain extent, defines what's even possible 
or reasonable with the slick interface.

If all the "radio" exposed as an interface was "frequency" and "mode 
(USB/LSB)" and "bandwidth", you wouldn't be able to use a lot of the 
capability inherent in the radio.  You could do a fairly slick job of 
channel memories, scanning, etc., and maybe some audio post processing, and 
what you'd have is just like the myriad programs that control various and 
sundry scanner receivers out there, and what's worse, the UI/Radio 
combination would be no better than all those scanners.

The SDR concept gives you such wonderful flexibility, but, exposing that 
flexibility in a useful way is tough.  It's much the same as the difference 
between a GUI and a console TTY style application.  If all you get to do is 
type commands and get text output, coding is easy.. strings in, strings 
out.  But, doing things like spectrum displays is tough on a glass (or 
paper) TTY.  If you want the graphical display, you either do it with 
string commands (the old Tek 40xx graphics terminal or HP plotter approach) 
or you buy into a very rich and powerful graphics API.  The latter has a, 
shall we say, "steep learning curve".

The problem I see is that since there is no current specification (or even 
preliminary detailed sketches) of a published UI/Radio interface, everyone 
is sort of working on modifying what's there now.  Once you've bitten the 
bullet and climbed the existing learning curve, you tend to be loathe  to 
jump onto another one, especially if might disappear shortly.  Likewise, 
someone like me isn't likely to invest significant time in devising an 
interface specification:  I don't need it for myself, and without any 
guidance on whether it will be useful to others, I'd hate to invest 
significant time altruistically, for no community benefit.  Sourceforge is 
full of "wonderful partly completed ideas" that don't have sufficient value 
to anyone to make it worth climbing the initial learning curve.


>Gosh, we totally lost contact with HPSDR now that they are using exotic 
>chips and opaque software that only a TAPR Guru can possibly understand! 
>then micro-SMT (0608) washed us out of the homebrew picture.
>
> > e) an algebraic expression of arbitrary complexity defining
> > a frequency or time domain response?
>
>Now you are suggesting engineering level controls to tweak our beloved 
>SDR-1000 console at a level only you and Gerald and Bob can possibly 
>understand.


Nope.. That level of control should be hidden from the user (and of 
interest only to UI builders and radio builders). It's the mechanism by 
which the UI communicates with the radio.  Just like the Windows GUI works 
in twips.


>Will it never settle down to a shape and method that the average guy can 
>grasp?

It should, but, that's more an issue for the UI builders, not the radio 
builders.


>de ken n9vv



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

[Larry W8ER]

Bob et all, this HAS been an interesting discussion! I think no one has 
pointed out however that the GUI doesn't have to be this way or that way. 
The use of skins makes it possible for everyone to select the interface that 
pleases him (or her). Even though the GUI is subjective, it is another 
aspect of the software design that should allow the user to have it HIS way. 
The thought that Bob N4HY brought up, that is, define a skin that emulates 
an "S Line" or a Drake "C Line" or even a Kenwood TS950 SDX, gives everyone 
a chance to play with a different radio anytime he pleases. I couldn't help 
but think about a Swan skin and code that makes the DDS drift ..  :-)  ! 
Let's not inhibit the type of software development that would allow this to 
happen .. please!!!

73 -- Larry W8ER


> The discussion has been very interesting and just shows the diversity of
> opinion and of course who would expect anything else. User interfaces
> are so subjective you ain't never gonna please everyone. Heck I can't
> even agree with myself half the time on what I like and don't like and I
> have full editorial control over everything I build!
>
> My utopia is a UI so thin and formalised I can build a new one in a few
> days in any language for desktop or web deployment. Not a skin over a UI
> toolkit but a complete UI. This is the plan and its coming together.
> Will it work out, I don't know but I'm sure going to give it a good
> crack of the whip.
>
> 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?

[Jim Lux]

At 08:04 AM 8/22/2006, Jerry Flanders wrote:
>We are not operating radios - we are operating  _modes_ (i.e., ssb
>phone OR cw OR rtty OR psk31 OR ... ).


An excellent point!  (in the pro SDR world, modes are called "waveforms")

>If available, you would probably want several similar consoles, each
>with specific enhancements for a particular mode. You would use one
>at a time, of course. In a few years,  when SDR has become the
>dominant type of radio, I think ops will want and have specialized
>consoles like this.
>
>For instance, right now I want a console specific to RTTY contesting
>operations - it doesn't need the usual ANF button, but it could
>benefit from a different kind of ANF that only removes a multi-second
>long constant cw QRM. It doesn't need a CW memory keyer, but a
>built-in FFT tuning display/waterfall  like MMTTY provides would be
>very useful. It doesn't need an audio equalizer, but real FSK would help.
Precisely... the UI should display the controls/features/etc that are 
relevant to the mode in use, and the software should translate that into 
appropriate actions for the radio hardware.

The tricky aspect is where to draw that line...

Here's a concrete example:  The SDR has the ability to essentially use ANY 
arbitrary IF filter characteristic (with a few limitations).  So, should 
the interface between the UI and the "radio" be:
a) an array defining the complex weight for each frequency bin?
b) a couple numbers defining upper and lower 3dB frequencies? (but what 
about skirt steepness?)
c) a couple numbers defining center frequency and bandwidth
d) a rise and fall time spec
e) an algebraic expression of arbitrary complexity defining a frequency or 
time domain response?

If I were a "radio" builder, and I did my filtering in frequency domain 
with a fast convolution sort of approach (FFT, multiply, IFFT), I'd want 
people to give me the array of complex numbers

If I did my filtering using timedomain digital filters, I'd probably want 
some numbers to feed into a utility that calculates tap coefficients

It gets even more complex when you want to define an interface for such 
fancy (but, really, really handy) things as specifying notches as well as 
passbands, especially if the backend radio has the ability to track an 
interfering signal.

Jim

Jim




___
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

[Mark Amos]

I'm looking forward to messing with some external analog controls (as a
musician I've got a bunch of midi devices that are just itching to get some
RF under their nails.)  

Another option that I think would really open things up (and provide for
physically challenged operators) would be a voice interface: "SDR Filter 25
Hz" or "SDR up 5" or "SDR sweep up 1K" ... are some commands I'd like to
use...

There are things that are really easy to do with knobs or joysticks that are
tedious or silly to do with a mouse (like rotating a knob using the scroll
button - it's useable, but it's non-intuitive - circling the mouse is more
intuitive, but more difficult to implement.)

In any case, I agree with the goal of doing the best man-machine interface
possible (supported by dozens of years of research and experience in the
industry) for the "production version."  If it's skinnable, great!  Let the
folks that want skins, skin it.  I'd prefer a well designed interface for
day-to-day use, and then maybe a technogeek interface to impress my geeky
friends...  (Or perhaps a mid-century moderne design for when my wife's in
the shack.)

Different needs warrant different interfaces.  Some folks are drawn to the
look, others to the feel.  Of course, I'm in the "cake and eat it too"
school...





-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of W0UN -- John
Brosnahan
Sent: Monday, August 21, 2006 4:51 PM
To: FlexRadio@flex-radio.biz
Subject: Re: [Flexradio] Console Graphics

At 02:33 PM 8/21/2006, you wrote:


>>Slow down!  Not so fast!
>>
>>The skins do look great, but if I want to operate a radio that looks like
my
>>FT 1000, I'll turn off my SDR-1000 and turn on the black box.
>>
>>I'm tired of the old paradigm.  The SDR is new, fresh and  unconventional.
>>Don't make it like all the others.
>>
>>For those that want the skins, OK..  But I don't want to go back to  the
>>conventional.
>
>Bob,
>
>You are 100 percent correct here !
>
>A lot of people may not realize that the SDR Console GUI is related 
>most closely to a well established professional programming field, 
>software you see on a myriad of systems, everything from factory 
>floor automation controllers, to controllers for SMPTE driven 
>professional entertainment stage lighting systems, and everything in 
>between, and many many other jobs and tasks out there in the real 
>industrial world.  Yes, the SDR is a Ham radio, but the purpose of 
>the GUI is user control of a remoted system (the SDR black 
>box).  Writing user control interfaces whose intent is to meld the 
>human operator with the "remote -machine" is an art, but it is also 
>a well understood technical endeavor with many previous example of 
>how it is best done. Skins aren't one of them.
>I detect that there has been a very vocal element that has spoken up 
>early on and raved  to Flex about various example screen design 
>proto typing that has been done by some. I think it might be time 
>for some of us "silent onlookers" to have our say heard as well, and 
>balance out this issue.
>
>73  -Dan K6KDK



Dan, Bob --

I couldn't DISAGREE more with what you are saying!;-) Well, I 
guess I could,
because I do understand your side of the issue, but I think there is 
room for a
lot of improvement here.

The console does two things -- provides a human interface to the 
controls and gives a
sense of "feel" (comfort) to the operator.

I am certainly NOT wanting a RETRO panel from a Heath DX100, but rather a
human interface panel that is the most functional possible.  This is
especially
important in contesting where every second counts.  But I also think it
needs
to be aesthetically pleasing to maximize the comfort factor.

There is a certain "gee-whiz" look to the current crop of panels 
(read, techno-geek)
but they may not be the most efficient and/or intuitive.  BTW  I 
don't like the hassle
of MODERN (analog) radios that require you to drill down through the menus
to
make some changes either.

eg, a pull down menu with bandwidth selections is not as efficient 
(in my book, not as
elegant) as a series of push buttons (or other single-step 
selection).  Pull downs require
two actions, pulling down the menu and then selecting the 
value.  Either separate push
buttons for each BW or a slider switch would be quicker.  A slider 
gives a "graphical"
indication of selection.  A "lighted" push button can give you an 
indication of the
selection at a glance.  Much better than having to read the numbers.

(BTW  ALL of this mouse interface is not unlike the old comment about 
using a mouse
in a paint program is like using a BRICK to paint in oil.)

Re: [Flexradio] Console Graphics

[Bob Cowdery]

The discussion has been very interesting and just shows the diversity of
opinion and of course who would expect anything else. User interfaces
are so subjective you ain't never gonna please everyone. Heck I can't
even agree with myself half the time on what I like and don't like and I
have full editorial control over everything I build! 

My utopia is a UI so thin and formalised I can build a new one in a few
days in any language for desktop or web deployment. Not a skin over a UI
toolkit but a complete UI. This is the plan and its coming together.
Will it work out, I don't know but I'm sure going to give it a good
crack of the whip.

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

[Jim Lux]

At 10:12 AM 8/22/2006, you wrote:


> >>Here is a link to a friend of mine who has a calculator program with a
> >>similar
> >>appearance.  You can go to the VIEW and then SKINS and make changes in
> >>the appearance of the calculator.  It would be very nice to have
> >>skins (for the SDR...) to allow
>
>I just could not resist:
>
>I LOVE your calculator skin! I just LOVE anything that is nostalgic. I
>really don't care if it is functional or not.   I just am interested in the
>wonderful  "LOOK OF IT ALL !!!"
>
>Please, please, please have you friend make me a SKIN of my old slide rule
>that my Father gave me for my 8th birthday when I was just a tadpole.
>Nothing would make me happier that to work my current engineering problems
>on a Slide Rule Skin on my PC, you know I could move the slide around with
>my mouse, shouldn't  take too much extra time, my boss won't mind.   If my
>boss comes over to my work station and says " Dan, what's taking so long
>today?"  I would just show him the SKIN and he would LOVE it too !!!


I think there is a site out there from one of the slide rule collectors 
that has just what you're looking for. It's a sliderule implemented in Java.
There's also several E6B style calculators out there for doing wind 
triangles, etc.

Now, for a more RF-ish sort of thing, you want one of those circular 
sliderules with the Smith Chart built in, so you can do reactance 
computations with component values and frequencies.





James Lux, P.E.
Spacecraft Radio Frequency Subsystems Group
Flight Communications Systems Section
Jet Propulsion Laboratory, Mail Stop 161-213
4800 Oak Grove Drive
Pasadena CA 91109
tel: (818)354-2075
fax: (818)393-6875 



___
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

[k6kdk]

>>Here is a link to a friend of mine who has a calculator program with a
>>similar
>>appearance.  You can go to the VIEW and then SKINS and make changes in
>>the appearance of the calculator.  It would be very nice to have
>>skins (for the SDR...) to allow

I just could not resist:

I LOVE your calculator skin! I just LOVE anything that is nostalgic. I
really don't care if it is functional or not.   I just am interested in the
wonderful  "LOOK OF IT ALL !!!"

Please, please, please have you friend make me a SKIN of my old slide rule
that my Father gave me for my 8th birthday when I was just a tadpole.
Nothing would make me happier that to work my current engineering problems
on a Slide Rule Skin on my PC, you know I could move the slide around with
my mouse, shouldn't  take too much extra time, my boss won't mind.   If my
boss comes over to my work station and says " Dan, what's taking so long
today?"  I would just show him the SKIN and he would LOVE it too !!!

73s - Dan



___
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?

[Jerry Flanders]

We are not operating radios - we are operating  _modes_ (i.e., ssb 
phone OR cw OR rtty OR psk31 OR ... ).

An all-mode console is great when demonstrating the radio to your SWL 
friend, but when he goes home you operate your radio mostly on your 
favorite mode, and you might benefit if your console reflected this.

If available, you would probably want several similar consoles, each 
with specific enhancements for a particular mode. You would use one 
at a time, of course. In a few years,  when SDR has become the 
dominant type of radio, I think ops will want and have specialized 
consoles like this.

For instance, right now I want a console specific to RTTY contesting 
operations - it doesn't need the usual ANF button, but it could 
benefit from a different kind of ANF that only removes a multi-second 
long constant cw QRM. It doesn't need a CW memory keyer, but a 
built-in FFT tuning display/waterfall  like MMTTY provides would be 
very useful. It doesn't need an audio equalizer, but real FSK would help.

At the present stage of development, the do-it-all console is a 
handful for any development team, but we will probably evolve more 
specific consoles as time goes on and more developers come on board.

Jerry W4UK

At 13:04 8/22/2006, Charles Greene wrote:
>John,
>
>I was engaged in a conversation about SRDs on the Ten Tec reflector a
>couple of days ago.  Someone stated that SDRs needed to look like
>"real" radios in order to get wide acceptance.  These consoles
>certainly fill that bill.  Well done.  However, I question the wisdom
>of filling up a console with individual "radio" buttons when drop
>down menus will do the same thing.  Take the Display selection for
>example.  Most operators don't use all the optional displays, and to
>dedicate the real estate for 7 "radio" buttons seems to take
>nostalgia a bit too far.  I never liked the FT-1K or IC-7800 front
>panels for the reason that they too complicated and the learning
>curve is too high.  On the other hand, there is the Jupiter which
>combines real push buttons with drop down menus, although Ten Tec's
>choice of menus is not that intuitive.  Perhaps a console with more
>"radio" buttons but retaining drop down menus for less frequently
>selected functions would be a better choice.
>
>73  Chas W1CG
>
>At 11:14 AM 8/21/2006, W0UN -- John Brosnahan wrote:
> >Dear Beppe--
> >
> >
> >I LOVE the look of your front panel art for the SDR projects.  I
> >sure hope that
> >someone incorporates the concepts into the console software for both the
> >FlexRadio and the SoftRock.
> >
> >http://www.radioamatore.it/sdr1000/mypowersdr.html
> >
> >Here is a link to a friend of mine who has a calculator program 
> with a similar
> >appearance.  You can go to the VIEW and then SKINS and make changes in
> >the appearance of the calculator.  It would be very nice to have
> >skins to allow
> >the colors and general appearance to be easily changed.  I can see the
> >need for BRIGHT colors to help keep you awake late at night, especially at
> >the end of a contest.  On the other hand there is a lot to be said for
> >soothing colors for general operation.
> >
> >http://www.dreamcalc.com/
> >
> >This software was written by a British friend of mine in about 8 THOUSAND
> >hours of effort.  So I have some idea of the work involved in some of these
> >projects.
> >
> >Just thought you might like to look at it as an idea of where to take the
> >console's appearance.  Not only does it do scientific calculations and
> >business calculations, it does a lot of very nice graphics presentations
> >of the data in an appearance of your choice.
> >
> >
> >73--John  W0UN
> >
> >
> >___
> >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 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] Console Graphics

[Dave Muskopf]

I really don.t care what it looks like as long as it works and it DOES 
real well too. BTW the latest svn (652) seems to be more stable the the 
previous ones. Dave

___
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

[Charles Greene]

At 09:34 AM 8/22/2006, W0UN -- John Brosnahan wrote:

>What I want in an SDR is the ultimate in operator convenience and efficiency
>for the task at hand along with something that is aesthetically pleasing.
>
>I am certainly NOT wanting to emulate a "regular" radio for the sake of
>copying the "traditional" look.
>
>To me "pull downs" are just fine for SOME of the less-frequently 
>used functions.
>Push buttons and sliders seem better for the more often used functions though.
>But just MAYBE there is something even better out there that no one 
>has thought
>of yet!
>
>And part of me likes my definition of the current "techno-geek" 
>(gee-whiz) look.
>But I think there can be a console that is more efficient, very 
>functional, and
>has a more artistic appearance -- while paying homage in some respects to the
>long tradition of the familiar "radio" look.
>
>Here is an example of efficiency vs. tradition in a radio 
>look.   The current crop
>of analog radios sit low on the table with the freq display at the 
>top which makes
>it more convenient for the eyes.  It is natural to make the least used knobs
>along the bottom where they are less accessible and may even be 
>partially blocked
>by the computer keyboard.  But an SDR radio console is on the computer screen
>and to me the freq display should be LOW on the screen to minimize the amount
>of head-raising to go from the keyboard to the screen.  (I am just 
>an OK typist,
>not a total touch typist, and need to look at the keyboard for the less common
>keys.)  And the least-used controls of an SDR should be on the TOP 
>of the display,
>out of the way more.
>
>Clearly, at this point, the functionality and performance of the SDR 
>is of prime
>importance.  All I am saying is that separating the console from the "radio"
>is the way to allow the console to be improved without writing a whole new
>radio.  And I am glad this is being done.
>
>So my list of priorities is:
>
>1)  Performance
>2)  Functionality
>3)  Appearance
>
>I like the ability to "assemble" the console in a way that works for 
>me.  And I like
>the artistic look of Beppe's designs.
>
>Performance programers are probably NOT the people you want designing
>the ergonomic and artistic parts of the radio, in the same way that artistic
>designers may not be all that great with the design of algorithms needed for
>performance.
>
>73  John  W0UN
John,

To move various major portions of the console around has merit.  I 
use MixW and major portions of it's console can be moved to where 
ever you want.  However, I disagree on placing the display at the 
bottom of the screen for several reasons, one which is that I place 
MixW on the bottom of the screen and with the display near the top 
and I can see both displays at the same time.  Some of the other 
reasons involve economy of mouse movement.  You don't move the mouse 
to the top of the screen now but to the bottom of the screen where 
most of the controls are.  We should keep most used controls near the 
center of the screen, both for mouse movement and for vision.  If we 
had to ability to move major parts of the console around, then both 
of us would be happy. Yes, you need a "human factors" group of 
designers to design the console.  A degree from RISD is helpful in this regard.

Chas

   



___
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

[W0UN -- John Brosnahan]

At 08:04 AM 8/22/2006, Charles Greene wrote:
>John,
>
>I was engaged in a conversation about SRDs on the Ten Tec reflector 
>a couple of days ago.  Someone stated that SDRs needed to look like 
>"real" radios in order to get wide acceptance.  These consoles 
>certainly fill that bill.  Well done.  However, I question the 
>wisdom of filling up a console with individual "radio" buttons when 
>drop down menus will do the same thing.  Take the Display selection 
>for example.  Most operators don't use all the optional displays, 
>and to dedicate the real estate for 7 "radio" buttons seems to take 
>nostalgia a bit too far.  I never liked the FT-1K or IC-7800 front 
>panels for the reason that they too complicated and the learning 
>curve is too high.  On the other hand, there is the Jupiter which 
>combines real push buttons with drop down menus, although Ten Tec's 
>choice of menus is not that intuitive.  Perhaps a console with more 
>"radio" buttons but retaining drop down menus for less frequently 
>selected functions would be a better choice.


Chas--

What I want in an SDR is the ultimate in operator convenience and efficiency
for the task at hand along with something that is aesthetically pleasing.

I am certainly NOT wanting to emulate a "regular" radio for the sake of
copying the "traditional" look.

To me "pull downs" are just fine for SOME of the less-frequently used 
functions.
Push buttons and sliders seem better for the more often used functions though.
But just MAYBE there is something even better out there that no one has thought
of yet!

And part of me likes my definition of the current "techno-geek" 
(gee-whiz) look.
But I think there can be a console that is more efficient, very 
functional, and
has a more artistic appearance -- while paying homage in some respects to the
long tradition of the familiar "radio" look.

Here is an example of efficiency vs. tradition in a radio look.   The 
current crop
of analog radios sit low on the table with the freq display at the 
top which makes
it more convenient for the eyes.  It is natural to make the least used knobs
along the bottom where they are less accessible and may even be 
partially blocked
by the computer keyboard.  But an SDR radio console is on the computer screen
and to me the freq display should be LOW on the screen to minimize the amount
of head-raising to go from the keyboard to the screen.  (I am just an 
OK typist,
not a total touch typist, and need to look at the keyboard for the less common
keys.)  And the least-used controls of an SDR should be on the TOP of 
the display,
out of the way more.

Clearly, at this point, the functionality and performance of the SDR 
is of prime
importance.  All I am saying is that separating the console from the "radio"
is the way to allow the console to be improved without writing a whole new
radio.  And I am glad this is being done.

So my list of priorities is:

1)  Performance
2)  Functionality
3)  Appearance

I like the ability to "assemble" the console in a way that works for 
me.  And I like
the artistic look of Beppe's designs.

Performance programers are probably NOT the people you want designing
the ergonomic and artistic parts of the radio, in the same way that artistic
designers may not be all that great with the design of algorithms needed for
performance.

73  John  W0UN

-- next part --
An HTML attachment was scrubbed...
URL: 
/pipermail/flexradio_flex-radio.biz/attachments/20060822/d5eebe6c/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

[Charles Greene]

John,

I was engaged in a conversation about SRDs on the Ten Tec reflector a 
couple of days ago.  Someone stated that SDRs needed to look like 
"real" radios in order to get wide acceptance.  These consoles 
certainly fill that bill.  Well done.  However, I question the wisdom 
of filling up a console with individual "radio" buttons when drop 
down menus will do the same thing.  Take the Display selection for 
example.  Most operators don't use all the optional displays, and to 
dedicate the real estate for 7 "radio" buttons seems to take 
nostalgia a bit too far.  I never liked the FT-1K or IC-7800 front 
panels for the reason that they too complicated and the learning 
curve is too high.  On the other hand, there is the Jupiter which 
combines real push buttons with drop down menus, although Ten Tec's 
choice of menus is not that intuitive.  Perhaps a console with more 
"radio" buttons but retaining drop down menus for less frequently 
selected functions would be a better choice.

73  Chas W1CG

At 11:14 AM 8/21/2006, W0UN -- John Brosnahan wrote:
>Dear Beppe--
>
>
>I LOVE the look of your front panel art for the SDR projects.  I 
>sure hope that
>someone incorporates the concepts into the console software for both the
>FlexRadio and the SoftRock.
>
>http://www.radioamatore.it/sdr1000/mypowersdr.html
>
>Here is a link to a friend of mine who has a calculator program with a similar
>appearance.  You can go to the VIEW and then SKINS and make changes in
>the appearance of the calculator.  It would be very nice to have 
>skins to allow
>the colors and general appearance to be easily changed.  I can see the
>need for BRIGHT colors to help keep you awake late at night, especially at
>the end of a contest.  On the other hand there is a lot to be said for
>soothing colors for general operation.
>
>http://www.dreamcalc.com/
>
>This software was written by a British friend of mine in about 8 THOUSAND
>hours of effort.  So I have some idea of the work involved in some of these
>projects.
>
>Just thought you might like to look at it as an idea of where to take the
>console's appearance.  Not only does it do scientific calculations and
>business calculations, it does a lot of very nice graphics presentations
>of the data in an appearance of your choice.
>
>
>73--John  W0UN
>
>
>___
>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

Re: [Flexradio] Console Graphics

[Giuseppe Campana]

Hi Folks,

more than one year ago I have proposed my graphics to the Flex user group.

My "dream SDR" looking like a "old"  japan Radio was a simple provocation
to the sw programmes, with a lot of discussions and all stories here:

http://www.flex-radio.com/forums/viewtopic.php?t=1510&highlight=&sid=377eec9a496cad8bdb15b6656357ea19

and here:

http://www.flex-radio.com/forums/viewtopic.php?t=1534&highlight=&sid=377eec9a496cad8bdb15b6656357ea19

The last idea was to propose a more simple work to make a CAT interface 
using a GUI, for all
user do not need the panadapter in normal QSOs, making a very normal radio 
to play every day
with the FULL POWER of the great SDR-1000.

This way can be very simple to have: a "simple" code (only serial port 
control and graphics) running
with backgrounded PowerSDR, like others CAT software es. HamRadio Deluxe.
The PowerSDR's CAT protocol is full commands set for a total control of 
SDR-1000, without
panadapter of course.and we can make any radio-style-look we want.

Sorry but I'm not a software man, I'm only a designer.

The full story here:

http://www.flex-radio.com/forums/viewtopic.php?t=1810&highlight=&sid=377eec9a496cad8bdb15b6656357ea19




A brief personal consideration:

I'm the official distributor of Flex's products for Italy, making meetings 
and presentations
to a lot of HAM operators, all of them give me a "cold feedback" to 
GUI-style of PowerSDR
very close to look like a TEST SET, not a RADIO.

A lot of them prefer a "traditional knob in hand" and a GUI like proposed 
by me would make
a lot of business..or no ?

An important step in this direction will be available like described in the 
last TO DO LIST by
Gerald & friends, separating  the RADIO from the GUI but.how many 
time/work again ?

Folks, please look at the "enormous" world of the VST plug-in for audio 
applications, look
at the incredible graphics of these softwarewhy ?

73 Beppe
IK3VIG



___
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

[Duane - N9DG]

--- W0UN -- John Brosnahan <[EMAIL PROTECTED]> wrote:
> There is a certain "gee-whiz" look to the current crop of
> panels (read, techno-geek)
> but they may not be the most efficient and/or intuitive. 
> BTW  I  don't like the hassle
> of MODERN (analog) radios that require you to drill down
> through the menus to make some changes either.

I'm with you on this one.
 
> eg, a pull down menu with bandwidth selections is not as
> efficient (in my book, not as
> elegant) as a series of push buttons (or other single-step 
> selection).  Pull downs require
> two actions, pulling down the menu and then selecting the 
> value.  Either separate push
> buttons for each BW or a slider switch would be quicker.  A
> slider gives a "graphical"
> indication of selection.  A "lighted" push button can give
> you an indication of the
> selection at a glance.  Much better than having to read the
> numbers.

I actually like the concept of pulling in the filter edges of
the filter as you see it on the panadapter. The latest SVN is
really heading in the right direction in this regard. In my
opinion the more stuff you can directly act upon inside the
panadapter window the better.

> (BTW  ALL of this mouse interface is not unlike the old
> comment about using a mouse
> in a paint program is like using a BRICK to paint in oil.)

My main contention is that *if* you do design a UI to be
mouse driven that you only create screen objects that are
mouse friendly, i.e. just say no to simulated rotary knobs
completely. Mouse movements are fine for linear motion click
and drag or hover and click, they are not very good for
making circular motions for example.

> Ergonomics and aesthetics are not mutually exclusive, but
> are very subjective.
> Separating the console from the radio allows a lot of
> options to please everyone.

Bingo.

> In some ways, keyboard shortcuts are an admission that the
> interface is not as
> good as it could be -- or an admission that a mouse-derived
> interface is not as efficient as it could be.

Or they could simply mean that some people just prefer
keystrokes. I wouldn't necessarily read "mouse" failure into
it.

> Ultimately the interface should allow you to run the radio
> in a very intuitive
> fashion --whether you are a newcomer or a long-time SDR
> user.

When I had the chance to sit down in front of IC-7800 at the
local dealer I was first struck by its unnecessary
complexity. I'm sure that the FTDX-9000 is as bad or worse.
So many knobs and buttons; and so many of them with multiple
uses. YUK. On the other hand the first time I fired up the
PowerSDR console I could very easily make it do anything that
I wanted it to, (and which it was capable of). And most
everything that I saw on the screen simply made sense. While
I didn't necessarily agree with many of the details about how
it worked, or that it wasn't at all optimal for some of my
operating activities, I still found to be very intuitive.
Even so I knew that the things I wanted were entirely
possible in the future. The 7800 and 9000, well no, what you
see is what you get and it ain't gonna change much, if any.

> An SDR console should allow anyone to sit down and run the
> radio without a
> lot of tutorial required.  And it should allow an
> experienced contester to be
> as efficient (or even more efficient) than with an analog
> radio.  And with skins
> it will be easier to do this.  With an SDR-based station
> with guest ops it is
> very important than anyone can sit down and run the radio
> very efficiently with little study required.

I'm not that sure skins per se would make a software radio UI
any easier to operate. However I do agree about the
importance being able to sit down and just make it work. The
only fly in the ointment for achieving this goal though is
the disparity between the person who has never run a
traditional radio before in their life and those who have.
The first time radio user will likely find many of the more
"unconventional" (by knobs and buttons standards) UI
approaches and designs easier to learn and become effective
with than a long time radio person who has deeply ingrained
notions about how to drive radio would. Software UI's by
their very nature are somewhat incongruous with touchy-feely
knobs and buttons. I will once again assert that the software
UI's design must take advantage of what monitor screens and
mice (or other specific controller) truly have to offer
ergonomically vs. trying to emulate traditional panels done
with knobs and buttons on a screen.
 
> I like techno-geek as much as the next guy.  There is a lot
> of skill required
> to know what to put on the console and what not to put on
> the console --
> as well as how to make operation as efficient as possible.

For the same reasons I dislike traditional radio panels with
tons of knobs and buttons (80% of which I will rarely use) I
dislike a software UI that tries to put every possible
control and function on the screen. There's always just too
much 

Re: [Flexradio] Console Graphics

[Frank Brickle]

Jim Lux wrote:

> And when will those specs be published?  RSN?

As soon as you've finished them, Jim.

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

[Martin Hirsch]

Jeff, I agree with you 100%. I personally like PowerSDR as it is: clear and 
easy to handle. Having the choice would make (nearly) everybody happy but 
needs a lot of programming-work and there are so many things for the 
FlexRadio programmers left to do in the technical section (spurs etc.) that 
have higher priority, I think(hope). But as PowerSDR is free source 
everybody who is lucky to know programming software may implement all those 
dream-transceiver-designs or retro transceivers (nice idea Jim!).

Martin DL5YEJ

- Original Message - 
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; 
Sent: Monday, August 21, 2006 8:24 PM
Subject: Re: [Flexradio] Console Graphics


>
> Slow down!  Not so fast!
>
> The skins do look great, but if I want to operate a radio that looks like
> my
> FT 1000, I'll turn off my SDR-1000 and turn on the black box.
>
> I'm tired of the old paradigm.  The SDR is new, fresh and  unconventional.
> Don't make it like all the others.
>
> For those that want the skins, OK..  But I don't want to go back to  the
> conventional.
>
> Bob
> K8MLM
> Happy Flex user since MAY 05
>
> In a message dated 8/21/2006 11:17:30 A.M. Eastern Daylight Time,
> [EMAIL PROTECTED] writes:
>
> Dear  Beppe--
>
>
> I LOVE the look of your front panel art for the SDR  projects.  I sure
> hope
> that
> someone incorporates the concepts into the  console software for both the
> FlexRadio and the  SoftRock.
>
> http://www.radioamatore.it/sdr1000/mypowersdr.html
>
> Here  is a link to a friend of mine who has a calculator program with a
> similar
> appearance.  You can go to the VIEW and then SKINS and make  changes in
> the appearance of the calculator.  It would be very nice to  have skins to
> allow
> the colors and general appearance to be easily  changed.  I can see the
> need for BRIGHT colors to help keep you awake  late at night, especially
> at
> the end of a contest.  On the other hand  there is a lot to be said for
> soothing colors for general  operation.
>
> http://www.dreamcalc.com/
>
> This software was written  by a British friend of mine in about 8 THOUSAND
> hours of effort.  So I  have some idea of the work involved in some of
> these
> projects.
>
> Just  thought you might like to look at it as an idea of where to take
> the
> console's appearance.  Not only does it do scientific calculations  and
> business calculations, it does a lot of very nice graphics  presentations
> of the data in an appearance of your  choice.
>
>
> 73--John   W0UN
>
>
> ___
> 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/20060821/0efa5271/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


___
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

[Jim Lux]

At 01:50 PM 8/21/2006, W0UN -- John Brosnahan wrote:
>At 02:33 PM 8/21/2006, you wrote:
>
>
> >>Slow down!  Not so fast!
> >>
> >>The skins do look great, but if I want to operate a radio that looks 
> like my
> >>FT 1000, I'll turn off my SDR-1000 and turn on the black box.
> >>
> >>I'm tired of the old paradigm.  The SDR is new, fresh and  unconventional.
> >>Don't make it like all the others.
> >>
> >>For those that want the skins, OK..  But I don't want to go back to  the
> >>conventional.
> >
>eg, a pull down menu with bandwidth selections is not as efficient
>(in my book, not as
>elegant) as a series of push buttons (or other single-step
>selection).  Pull downs require
>two actions, pulling down the menu and then selecting the
>value.  Either separate push
>buttons for each BW or a slider switch would be quicker.  A slider
>gives a "graphical"
>indication of selection.  A "lighted" push button can give you an
>indication of the
>selection at a glance.  Much better than having to read the numbers.
>
>(BTW  ALL of this mouse interface is not unlike the old comment about
>using a mouse
>in a paint program is like using a BRICK to paint in oil.)



Which is why I like tablets...  I'm used to writing with a pen/pencil, 
ticking boxes, etc.

I've just started to fool with trying to see if any of a host of 
logging/control programs will work with the handwriting recognition on my 
tablet.

The primary problem with most applications is that they rely too much on 
mouse specific things that are plain old unnatural with a pen.  Worse, they 
rely on a combination of mouse and keyboard at the same time. (Ctrl-Click, 
for instance, isn't doable with a tablet, unless you have the keyboard 
deployed)

Of course, my tablet PC is never going to have the crunch to run the DSP, 
which is why I really, really am waiting for the radio/UI bifurcation to 
occur.  (I have tried doing some things using the tablet as a remote 
console, using Timbuktu, but you keep running into places where you need a 
keyboard)

I'd like to sit in a comfortable chair, with a BT headset (or not), and a 
footswitch(or not), and operate the radio with my tablet in my lap, without 
needing wires going this way and that.

By the way, if anyone knows of a Bluetooth footswitch or PTT, I'd like to 
hear about it.  All the BT products seem to be phone oriented.  Maybe a 
unusual use of a BT serial port?  I'll have to do some experiments with 
something like hooking a switch to one of the modem control lines.


>Ergonomics and aesthetics are not mutually exclusive, but are very
>subjective.
>Separating the console from the radio allows a lot of options to
>please everyone.
>
>In some ways, keyboard shortcuts are an admission that the interface is not as
>good as it could be -- or an admission that a mouse-derived interface is 
>not as
>efficient as it could be.

Exactly...







___
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

[Jim Lux]

At 01:45 PM 8/21/2006, Tim Ellison wrote:
>I agree with the whole new paradigm aspect, but we also have an
>opportunity to do something really cool in the retro sense.
>
>I have never owned a Collins S-line or a pair of Gold Dust Twins, but if
>I wanted to operate some vintage hardware, just slap on a skin and you
>are off to the races.  There is not reason not to do both.


Hey, and with a SDR, you can also implement all the defects of the radios 
of a bygone era.. drifting LOs, noisy front ends, all manner of transmit 
and receive distortions and intermods.

One can even duplicate the signals and sounds of the days of King Spark.




>I suspect on the specs are published, skins will start coming out of the
>woodwork.  I can't wait for the day!

And when will those specs be published?  RSN?

Jim 



___
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

[W0UN -- John Brosnahan]

At 02:33 PM 8/21/2006, you wrote:


>>Slow down!  Not so fast!
>>
>>The skins do look great, but if I want to operate a radio that looks like my
>>FT 1000, I'll turn off my SDR-1000 and turn on the black box.
>>
>>I'm tired of the old paradigm.  The SDR is new, fresh and  unconventional.
>>Don't make it like all the others.
>>
>>For those that want the skins, OK..  But I don't want to go back to  the
>>conventional.
>
>Bob,
>
>You are 100 percent correct here !
>
>A lot of people may not realize that the SDR Console GUI is related 
>most closely to a well established professional programming field, 
>software you see on a myriad of systems, everything from factory 
>floor automation controllers, to controllers for SMPTE driven 
>professional entertainment stage lighting systems, and everything in 
>between, and many many other jobs and tasks out there in the real 
>industrial world.  Yes, the SDR is a Ham radio, but the purpose of 
>the GUI is user control of a remoted system (the SDR black 
>box).  Writing user control interfaces whose intent is to meld the 
>human operator with the "remote -machine" is an art, but it is also 
>a well understood technical endeavor with many previous example of 
>how it is best done. Skins aren't one of them.
>I detect that there has been a very vocal element that has spoken up 
>early on and raved  to Flex about various example screen design 
>proto typing that has been done by some. I think it might be time 
>for some of us "silent onlookers" to have our say heard as well, and 
>balance out this issue.
>
>73  -Dan K6KDK



Dan, Bob --

I couldn't DISAGREE more with what you are saying!;-) Well, I 
guess I could,
because I do understand your side of the issue, but I think there is 
room for a
lot of improvement here.

The console does two things -- provides a human interface to the 
controls and gives a
sense of "feel" (comfort) to the operator.

I am certainly NOT wanting a RETRO panel from a Heath DX100, but rather a
human interface panel that is the most functional possible.  This is especially
important in contesting where every second counts.  But I also think it needs
to be aesthetically pleasing to maximize the comfort factor.

There is a certain "gee-whiz" look to the current crop of panels 
(read, techno-geek)
but they may not be the most efficient and/or intuitive.  BTW  I 
don't like the hassle
of MODERN (analog) radios that require you to drill down through the menus to
make some changes either.

eg, a pull down menu with bandwidth selections is not as efficient 
(in my book, not as
elegant) as a series of push buttons (or other single-step 
selection).  Pull downs require
two actions, pulling down the menu and then selecting the 
value.  Either separate push
buttons for each BW or a slider switch would be quicker.  A slider 
gives a "graphical"
indication of selection.  A "lighted" push button can give you an 
indication of the
selection at a glance.  Much better than having to read the numbers.

(BTW  ALL of this mouse interface is not unlike the old comment about 
using a mouse
in a paint program is like using a BRICK to paint in oil.)

Ergonomics and aesthetics are not mutually exclusive, but are very 
subjective.
Separating the console from the radio allows a lot of options to 
please everyone.

In some ways, keyboard shortcuts are an admission that the interface is not as
good as it could be -- or an admission that a mouse-derived interface is not as
efficient as it could be.

Ultimately the interface should allow you to run the radio in a very intuitive
fashion --whether you are a newcomer or a long-time SDR user.  In my contest
station I have three IC-781s because I love their performance (for their era)
but I also have an FT-1000D (as well as an MP).  The IC-781s are borderline
USER-HOSTILE compared to the FT-1000D.   And what I mean is that with
the 1000D almost anyone can sit down and use the radio pretty well the
very first time he plays with it.  With the IC-781 there is a much 
steeper learning
curve.

An SDR console should allow anyone to sit down and run the radio without a
lot of tutorial required.  And it should allow an experienced contester to be
as efficient (or even more efficient) than with an analog radio.  And 
with skins
it will be easier to do this.  With an SDR-based station with guest ops it is
very important than anyone can sit down and run the radio very efficiently
with little study required.

I like techno-geek as much as the next guy.  There is a lot of skill required
to know what to put on the console and what not to put on the console --
as well as how to make operation as efficient as possible.

My interest in Beppe's panel ideas is that they have an appeal to me
from my OWN personal techno-geek perspective as well as being artistically
"pretty" by their 3D feel.

Balancing the gee-whiz appearance with the artistic appearance while
maintaining the most efficient and intuitive interface is going to be a lot
easier wi

Re: [Flexradio] Console Graphics

[Tim Ellison]

"I personally liked the idea of a Flex supported console and a different
K6JCA version.  I'd prefer there being as many different console options
as there are people who want to maintain them.  The more the merrier."

..and hence the BEAUTY of software defined radios!


-Tim
---
Integrated Technical Services 

"Lately it occurs to me, what a long strange trip it's been."
-Robert Hunter

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of KA5MIR
Sent: Monday, August 21, 2006 4:38 PM
To: flexradio@flex-radio.biz
Subject: Re: [Flexradio] Console Graphics

  I frequently see on this list where someone posts a suggestion or a
new idea and others say "No, I don't like that.  Don't do it." or
something to that effect.
  I don't understand why it has to be this way or that way.  Why not
both?  
Why not many different ways?  If a person or group wants to make a
different console upside down or backwards, more power to them.  I might
not use it but it doesn't bother me if it's just an option.

  I personally liked the idea of a Flex supported console and a
different K6JCA version.  I'd prefer there being as many different
console options as there are people who want to maintain them.  The more
the merrier.

Jeff/KA5MIR

___
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

Re: [Flexradio] Console Graphics

[Tim Ellison]

I agree with the whole new paradigm aspect, but we also have an
opportunity to do something really cool in the retro sense.

I have never owned a Collins S-line or a pair of Gold Dust Twins, but if
I wanted to operate some vintage hardware, just slap on a skin and you
are off to the races.  There is not reason not to do both.

I suspect on the specs are published, skins will start coming out of the
woodwork.  I can't wait for the day! 


-Tim
---
Integrated Technical Services 

"Lately it occurs to me, what a long strange trip it's been."
-Robert Hunter

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jim, W4ATK
Sent: Monday, August 21, 2006 4:09 PM
To: Flex-radio Reflector
Subject: Re: [Flexradio] Console Graphics

Bob wrote:

"Slow down!  Not so fast!

The skins do look great, but if I want to operate a radio that looks
like my FT 1000, I'll turn off my SDR-1000 and turn on the black box.

I'm tired of the old paradigm.  The SDR is new, fresh and
unconventional.
Don't make it like all the others.

For those that want the skins, OK..  But I don't want to go back to  the
conventional."

TO WHICH I ADD A HEARTY AMEN!!!

Jim, W4ATK


___
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

Re: [Flexradio] Console Graphics

[KA5MIR]

  I frequently see on this list where someone posts a suggestion or a new 
idea and others say "No, I don't like that.  Don't do it." or something to 
that effect.
  I don't understand why it has to be this way or that way.  Why not both?  
Why not many different ways?  If a person or group wants to make a different 
console upside down or backwards, more power to them.  I might not use it 
but it doesn't bother me if it's just an option.

  I personally liked the idea of a Flex supported console and a different 
K6JCA version.  I'd prefer there being as many different console options as 
there are people who want to maintain them.  The more the merrier.

Jeff/KA5MIR

___
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

[Jim, W4ATK]

Bob wrote:

"Slow down!  Not so fast!

The skins do look great, but if I want to operate a radio that looks like
my
FT 1000, I'll turn off my SDR-1000 and turn on the black box.

I'm tired of the old paradigm.  The SDR is new, fresh and  unconventional.
Don't make it like all the others.

For those that want the skins, OK..  But I don't want to go back to  the
conventional."

TO WHICH I ADD A HEARTY AMEN!!!

Jim, W4ATK


___
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

[k6kdk]

> Slow down!  Not so fast!
>
> The skins do look great, but if I want to operate a radio that looks like 
> my
> FT 1000, I'll turn off my SDR-1000 and turn on the black box.
>
> I'm tired of the old paradigm.  The SDR is new, fresh and  unconventional.
> Don't make it like all the others.
>
> For those that want the skins, OK..  But I don't want to go back to  the
> conventional.
>

Bob,

You are 100 percent correct here !

A lot of people may not realize that the SDR Console GUI is related most 
closely to a well established professional programming field, software you 
see on a myriad of systems, everything from factory floor automation 
controllers, to controllers for SMPTE driven professional entertainment 
stage lighting systems, and everything in between, and many many other jobs 
and tasks out there in the real industrial world.  Yes, the SDR is a Ham 
radio, but the purpose of the GUI is user control of a remoted system (the 
SDR black box).  Writing user control interfaces whose intent is to meld the 
human operator with the "remote -machine" is an art, but it is also a well 
understood technical endeavor with many previous example of how it is best 
done. Skins aren't one of them.

This field (system control user interface design) is so well researched, so 
well understood, there are dozens of tools available to the programmer that 
is doing this kind of job, and many examples if how it is done in industry 
already, that Flex would do well to look long and hard at these existing 
examples, and THINK long and hard about how these interfaces are generally 
designed.

I can assure you that if you go into the control room of  a (you pick it 
here..) maybe Cummins Diesel engine assembly test area, and look at the 
dozens of screens in use, you will not see one that looks like a "retro 
skin" of the cab of a  1940s Kenworth.

Flex has a Golden Opportunity here to forge new ground for Ham Radio user 
interfaces. My advice is DON'T BLOW IT!Don't fall for the nonsense, no 
matter how "cutesy" it looks !

I wrote Flex a three page "white paper" on just this issue. At Flexs request 
it is not available for public posting,  but anyone specifically interested 
in this subject can private email and I will send you a copy.

I detect that there has been a very vocal element that has spoken up early 
on and raved  to Flex about various example screen design proto typing that 
has been done by some. I think it might be time for some of us "silent 
onlookers" to have our say heard as well, and balance out this issue.

73  -Dan K6KDK





___
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

[Radio Station W5AMI]

On 8/21/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Slow down!  Not so fast!
>
> The skins do look great, but if I want to operate a radio that looks like
> my
> FT 1000, I'll turn off my SDR-1000 and turn on the black box.
>
> I'm tired of the old paradigm.  The SDR is new, fresh and  unconventional.
> Don't make it like all the others.
>
> For those that want the skins, OK..  But I don't want to go back to  the
> conventional.
>
I love my SDR-1000 too, and that hasn't a thing to do with this idea
Beppe has come up with.  A "skin" is just that.  A skin allows you to
have whatever look you want.  I know there are a lot of other
"Flexers" out there that do miss the 3D look of a real radio.  I
promise you that I do, as I am a "vintage rig person".  Everything I
have except the Flex was built from 1937 to 1956.  The ONLY modern rig
I have is the Flex SDR-1000.  I bought it because I knew, after a lot
of reading that it was the BEST rig for the money, and I wanted a
modern rig to serve that need I had.  Maybe some of us don't have an
FT-1000 as you do...  I don't know why I would have one myself if I
had an SDR-1000 anyway. ;)

There is nothing wrong with having a console that can be changed with
skins.  That's what the new fad is all about isn't it?  Software
Defined Radio?

I honestly don't think that anyone needs to "slow down" with SDRadios.
 If that were the case, we would still be operating some of the old
vintage rigs I have here.

73
Brian

___
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

[K8MLM]

 
Slow down!  Not so fast!  
 
The skins do look great, but if I want to operate a radio that looks like  my 
FT 1000, I'll turn off my SDR-1000 and turn on the black box.
 
I'm tired of the old paradigm.  The SDR is new, fresh and  unconventional.  
Don't make it like all the others.
 
For those that want the skins, OK..  But I don't want to go back to  the 
conventional.
 
Bob
K8MLM
Happy Flex user since MAY 05
 
In a message dated 8/21/2006 11:17:30 A.M. Eastern Daylight Time,  
[EMAIL PROTECTED] writes:

Dear  Beppe--


I LOVE the look of your front panel art for the SDR  projects.  I sure hope 
that
someone incorporates the concepts into the  console software for both the
FlexRadio and the  SoftRock.

http://www.radioamatore.it/sdr1000/mypowersdr.html

Here  is a link to a friend of mine who has a calculator program with a  
similar
appearance.  You can go to the VIEW and then SKINS and make  changes in
the appearance of the calculator.  It would be very nice to  have skins to 
allow
the colors and general appearance to be easily  changed.  I can see the
need for BRIGHT colors to help keep you awake  late at night, especially at
the end of a contest.  On the other hand  there is a lot to be said for
soothing colors for general  operation.

http://www.dreamcalc.com/

This software was written  by a British friend of mine in about 8 THOUSAND
hours of effort.  So I  have some idea of the work involved in some of these
projects.

Just  thought you might like to look at it as an idea of where to take  the
console's appearance.  Not only does it do scientific calculations  and
business calculations, it does a lot of very nice graphics  presentations
of the data in an appearance of your  choice.


73--John   W0UN


___
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/20060821/0efa5271/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

[Radio Station W5AMI]

On 8/21/06, W0UN -- John Brosnahan <[EMAIL PROTECTED]> wrote:
> Dear Beppe--
>
>
> I LOVE the look of your front panel art for the SDR projects.  I sure hope
> that
> someone incorporates the concepts into the console software for both the
> FlexRadio and the SoftRock.
>
> http://www.radioamatore.it/sdr1000/mypowersdr.html

Whoa!!!  Now that is NICE!  I love the darker colors as they are much
easier on my eyes over time.  Is it possible we could have a "skin"
such as this soon?  Good work Beppe!

Brian/w5ami

___
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] Console Graphics

[W0UN -- John Brosnahan]

Dear Beppe--


I LOVE the look of your front panel art for the SDR projects.  I sure hope that
someone incorporates the concepts into the console software for both the
FlexRadio and the SoftRock.

http://www.radioamatore.it/sdr1000/mypowersdr.html

Here is a link to a friend of mine who has a calculator program with a similar
appearance.  You can go to the VIEW and then SKINS and make changes in
the appearance of the calculator.  It would be very nice to have skins to allow
the colors and general appearance to be easily changed.  I can see the
need for BRIGHT colors to help keep you awake late at night, especially at
the end of a contest.  On the other hand there is a lot to be said for
soothing colors for general operation.

http://www.dreamcalc.com/

This software was written by a British friend of mine in about 8 THOUSAND
hours of effort.  So I have some idea of the work involved in some of these
projects.

Just thought you might like to look at it as an idea of where to take the
console's appearance.  Not only does it do scientific calculations and
business calculations, it does a lot of very nice graphics presentations
of the data in an appearance of your choice.


73--John  W0UN


___
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

[José Dumoulin]

An HTML attachment was scrubbed...
URL: 
http://mail.flex-radio.biz/pipermail/flexradio_flex-radio.biz/attachments/20060425/655440c4/attachment.htm

[Flexradio] console

[Bob W5RG]

Where do I go to get the download for the console? Bob

W5RG
SDR-1000
-- next part --
An HTML attachment was scrubbed...
URL: http://mail.flex-radio.biz/pipermail/flexradio_flex-radio.biz/attachme=
nts/20060425/ef499cb2/attachment.htm

RE: [Flexradio] Console running out of room?

[Bill Guyger]

>>> "ecellison" <[EMAIL PROTECTED]> 06/26/05 07:36AM >>>
Frank

 we already have discussed many of these ideas before, so you end up reading the
same basic idea over again, and again.

It needs a fairly simple framework for individual customizations.

Thanks
Eric

First of all, I'm probably whipping a dead horse, and this has probably been 
said in so many words in one of the many posts on this subject

Secondly, I agree that there has to be a basic or standard console as a 
starting reference, but
Since no one console can or will be "ideal" for everyone. Might it be possible 
for you coding wizards to create several versions of each area of the console 
that could be drag and dropped onto the work surface in whatever arrangment 
that an individual user might desire?  Each 'button" or "slider" would then map 
to the proper line in code automatically.

I say this as a hardware type who is painfully ignorant of the inner workings 
of C# or any of the C languages and apologize in advance if this is a blatent 
parading of my stupidity in public.

Tnx es 73's 

Bill AD5OL

RE: [Flexradio] Console running out of room?

[ecellison]

Frank

Well, our message said it more politely! Just sort of frustrating, when we
already have discussed many of these ideas before, so you end up reading the
same basic idea over again, and again.

It needs a fairly simple framework for individual customizations.

Thanks
Eric


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Frank Brickle
Sent: Saturday, June 25, 2005 10:08 AM
To: FlexRadio@flex-radio.biz
Subject: Re: [Flexradio] Console running out of room?

ecellison wrote:

> Well, I was overstating on the 'banning' discussion, sort of to make a
> point...

It's not a bad idea to modulate discussion on this subject, 
because most everybody (yours truly!) has strong feelings on 
the subject, and it's an easy subject to have opinions about.

The task is to make it easy to convert those opinions into 
individual consoles :-)

To that end, these links

<http://wiki.wxpython.org/index.cgi/UsingXmlResources>
<http://wxglade.sourceforge.net/>

and these

<http://xmlrpc-c.sourceforge.net/xmlrpc-howto/xmlrpc-howto.html>
<http://www.onlamp.com/pub/a/python/2001/01/17/xmlrpcserver.html>

might be suggestive.

73
Frank
AB2KT


___
FlexRadio mailing list
FlexRadio@flex-radio.biz
http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz

Re: [Flexradio] Console running out of room?

[Frank Brickle]

ecellison wrote:


Well, I was overstating on the 'banning' discussion, sort of to make a
point...


It's not a bad idea to modulate discussion on this subject, 
because most everybody (yours truly!) has strong feelings on 
the subject, and it's an easy subject to have opinions about.


The task is to make it easy to convert those opinions into 
individual consoles :-)


To that end, these links




and these




might be suggestive.

73
Frank
AB2KT

RE: [Flexradio] Console running out of room?

[Duane - N9DG]

Ooops, I hate it when I leave key bridge words out

... The behavior reminds me a lot of multiple monitors under
Windows except that you *CAN'T* move applications from screen
to screen.

N9DG



--- Duane - N9DG <[EMAIL PROTECTED]> wrote:

> 
> Here's another neat little app that allows you to have the
> mouse and keyboard span multiple PC's. You just move the
> pointer across the multiple screens. Wherever the pointer
> is
> the PC that has the keyboard and mouse focus. The behavior
> reminds me a lot of multiple monitors under Windows except
> that you move applications from screen to screen. The PC's
> are entirely separate. This could be useful for multi PC
> configurations where the monitors are all right beside each
> other. It's a little like VNC without the video. 
> 
> http://synergy2.sourceforge.net/ 
> 
> Duane
> N9DG
> 
> --- ecellison <[EMAIL PROTECTED]> wrote:
> 
> > I think you can even drag them on to separate digital
> > monitors.
> > 
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of
> > Philip Covington
> > Sent: Friday, June 24, 2005 10:45 PM
> > To: FlexRadio@flex-radio.biz
> > Subject: Re: [Flexradio] Console running out of room?
> > 
> > On 6/24/05, Frank Brickle <[EMAIL PROTECTED]> wrote:
> > 
> > > Does Windows make it easy to use multiple desktops?
> > > 
> > > 73
> > > Frank
> > > AB2KT
> > 
> > Microsoft has a download from the XP Power Toys that will
> > give you
> > multiple virtual desktops.
> > 
> >
>
http://download.microsoft.com/download/whistler/Install/2/WXP/EN-US/DeskmanP
> > owertoySetup.exe
> > 
> > It allows up to 4. Kinda clunky but it does work...
> > 
> > 73 de Phil N8VB




__ 
Discover Yahoo! 
Find restaurants, movies, travel and more fun for the weekend. Check it out! 
http://discover.yahoo.com/weekend.html 

RE: [Flexradio] Console running out of room?

[ecellison]

Larry

Well, I was overstating on the 'banning' discussion, sort of to make a
point. We all have delete keys (smile). Everyone's idea for console
modification is great. As you can see, I posted your white paper later in my
reading of the discussions, that is where I think the master programmers and
software architecture folks should be putting their effort, and you have
largely mentioned below.

Somehow Ken seems to have moved your complete paper on his website, along
with the "Teamspeak Quickstart Guide". Could you repost your paper? Your
client/server model is the tool which will allow all of this and more.

Eric






-Original Message-
From: Larry Loen [mailto:[EMAIL PROTECTED] 
Sent: Saturday, June 25, 2005 9:11 AM
To: ecellison; FlexRadio@flex-radio.biz
Subject: Re: [Flexradio] Console running out of room?

ecellison wrote:

>Frank
>
>
>(snip)
>***
>Second point. "Running out of real estate" is a poor excuse 
>for starting to restrict what people can bring out to the 
>front easily. This is a software radio, for heaven's sake. 
>If you're running out of real estate, *the design is wrong*. 
>It shows that the monolithic console has outlived its 
>usefulness.
>
>In any case nobody else should be making policy decisions 
>for me about what's easy to get to and what isn't. It should 
>be up to me whether I get to see the CWL/CWU switch all the 
>time or not, and your prerogative contrariwise.
>**
>Truer words were never spoken.
>
>I think we should have a ban on discussing console changes. Generates
>hundereds of messages, and accomplishes nothing, since everyone has their
>own preferences. Hundereds of hours were spent on "Beppe's Console" and
>design discussions. Still monolithic!
>  
>
You?  Banning discussion?

Relax, my friend.  It may look like nothing is going on, but I think 
something is.

This is a classic "Cathedral versus the Bazzar" kind of discussion.  The 
Bazzar types will roll their own.

This will eventually include me.  For a bazzar to flourish, it needs a 
lot of discussion, much of it which ultimately goes nowhere.  So, I 
relish the discussion -- I'm looking for new ideas and for people to 
take potshots at mine.

However, there will be other that will have neither the capability or 
interest in producing their own.  These will want a "monolithic" 
console.  One that is blessed, if you will, by someone.  That someone is 
probably preferentially K5SDR.

Meanwhile, we're already diverging, a bit.  At present, my console of 
choice is the 1.3.5 _as modified_ by KD5TFD and N8VB.  There's the 
"Sharp console" even though I haven't been able to run it yet.  There's 
stuff going on in Python and Linux.  Just because I'm not running those 
doesn't mean it won't eventually affect me.  Or, the official console.

Frank has mentioned to me a technology that may make it a bit easier for 
the "roll your own" types.  The COMx and/or TCP/IP is another pathway, 
running the CAT interfaces, especially if we can all get our hands on 
the digitized buffers going back and forth.  That will allow coders to 
write little "applet" like things that demo specific interface ideas 
without having to master either C# or the current codebase.  Maybe 
Frank's technology will do the same as I don't thoroughly understand it 
yet.  And, two pathways wouldn't hurt, here.

All that will come.  And when it does, experiments will flourish.  

Console discussions may appear fruitless today because we have some 
technology limits and coding limits.  When the console has a few more 
holes drilled in it, and becomes more of an API platform than it now is 
(one way or the other), we'll see a lot more experiments.

The best will eventually make their way into the monolithic console.

This is a unique situaiton which, I think, we may as well celebrate, 
because there's no alternative anyway.  I've never seen a case where it 
is possible and even likely to have both a cathedral and a bazaar 
approach coexist.  It would be a uniqueness that would go beyond having 
a software defined radio.  It would be a melding of what so far has 
never been held together anywhere -- cathedral customers and bazzar 
customers.

In the meantime, I think we do need to encourage discussion and 
experimentation.  I have repeatedly stated that in a year, we may well 
not recognize this beast.  Look how far it has already come.  I haven't 
given up on Beepe's approaches either, by the way.  If I can master some 
of the simpler pathways, I'm likely to try some things out.  The winners 
(mine or, perhaps more likely, the experiments of others) could be take

RE: [Flexradio] Console running out of room?

[Duane - N9DG]

Here's another neat little app that allows you to have the
mouse and keyboard span multiple PC's. You just move the
pointer across the multiple screens. Wherever the pointer is
the PC that has the keyboard and mouse focus. The behavior
reminds me a lot of multiple monitors under Windows except
that you move applications from screen to screen. The PC's
are entirely separate. This could be useful for multi PC
configurations where the monitors are all right beside each
other. It's a little like VNC without the video. 

http://synergy2.sourceforge.net/ 

Duane
N9DG

--- ecellison <[EMAIL PROTECTED]> wrote:

> I think you can even drag them on to separate digital
> monitors.
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Philip Covington
> Sent: Friday, June 24, 2005 10:45 PM
> To: FlexRadio@flex-radio.biz
> Subject: Re: [Flexradio] Console running out of room?
> 
> On 6/24/05, Frank Brickle <[EMAIL PROTECTED]> wrote:
> 
> > Does Windows make it easy to use multiple desktops?
> > 
> > 73
> > Frank
> > AB2KT
> 
> Microsoft has a download from the XP Power Toys that will
> give you
> multiple virtual desktops.
> 
>
http://download.microsoft.com/download/whistler/Install/2/WXP/EN-US/DeskmanP
> owertoySetup.exe
> 
> It allows up to 4. Kinda clunky but it does work...
> 
> 73 de Phil N8VB


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Flexradio] Console running out of room?

[Larry Loen]

ecellison wrote:


Frank


(snip)
***
Second point. "Running out of real estate" is a poor excuse 
for starting to restrict what people can bring out to the 
front easily. This is a software radio, for heaven's sake. 
If you're running out of real estate, *the design is wrong*. 
It shows that the monolithic console has outlived its 
usefulness.


In any case nobody else should be making policy decisions 
for me about what's easy to get to and what isn't. It should 
be up to me whether I get to see the CWL/CWU switch all the 
time or not, and your prerogative contrariwise.

**
Truer words were never spoken.

I think we should have a ban on discussing console changes. Generates
hundereds of messages, and accomplishes nothing, since everyone has their
own preferences. Hundereds of hours were spent on "Beppe's Console" and
design discussions. Still monolithic!
 


You?  Banning discussion?

Relax, my friend.  It may look like nothing is going on, but I think 
something is.


This is a classic "Cathedral versus the Bazzar" kind of discussion.  The 
Bazzar types will roll their own.


This will eventually include me.  For a bazzar to flourish, it needs a 
lot of discussion, much of it which ultimately goes nowhere.  So, I 
relish the discussion -- I'm looking for new ideas and for people to 
take potshots at mine.


However, there will be other that will have neither the capability or 
interest in producing their own.  These will want a "monolithic" 
console.  One that is blessed, if you will, by someone.  That someone is 
probably preferentially K5SDR.


Meanwhile, we're already diverging, a bit.  At present, my console of 
choice is the 1.3.5 _as modified_ by KD5TFD and N8VB.  There's the 
"Sharp console" even though I haven't been able to run it yet.  There's 
stuff going on in Python and Linux.  Just because I'm not running those 
doesn't mean it won't eventually affect me.  Or, the official console.


Frank has mentioned to me a technology that may make it a bit easier for 
the "roll your own" types.  The COMx and/or TCP/IP is another pathway, 
running the CAT interfaces, especially if we can all get our hands on 
the digitized buffers going back and forth.  That will allow coders to 
write little "applet" like things that demo specific interface ideas 
without having to master either C# or the current codebase.  Maybe 
Frank's technology will do the same as I don't thoroughly understand it 
yet.  And, two pathways wouldn't hurt, here.


All that will come.  And when it does, experiments will flourish.  

Console discussions may appear fruitless today because we have some 
technology limits and coding limits.  When the console has a few more 
holes drilled in it, and becomes more of an API platform than it now is 
(one way or the other), we'll see a lot more experiments.


The best will eventually make their way into the monolithic console.

This is a unique situaiton which, I think, we may as well celebrate, 
because there's no alternative anyway.  I've never seen a case where it 
is possible and even likely to have both a cathedral and a bazaar 
approach coexist.  It would be a uniqueness that would go beyond having 
a software defined radio.  It would be a melding of what so far has 
never been held together anywhere -- cathedral customers and bazzar 
customers.


In the meantime, I think we do need to encourage discussion and 
experimentation.  I have repeatedly stated that in a year, we may well 
not recognize this beast.  Look how far it has already come.  I haven't 
given up on Beepe's approaches either, by the way.  If I can master some 
of the simpler pathways, I'm likely to try some things out.  The winners 
(mine or, perhaps more likely, the experiments of others) could be taken 
Beppe's way for the final, new "cathedral" design betimes.  And, when I 
finally get around to coding some of this stuff, I may just go back and 
"mine" his threads for ideas.  Indeed, I wish more of this was taking 
place on the forum where it might not be so easily lost, but that's 
another argument for another day.


When I first started daydreaming about this SDR potential 10 years ago, 
I thought I would have to do everything.  Besides not being Gerald, it 
was one reason it stayed a daydream.  This GPL-based approach is 
_already_ far better than I had imagined back then.  I have Frank and 
Bob to do the DSP, which I have no real competence at, and I couldn't 
hire their kind of talent.  So, maybe I can concetrate on areas that 
either interest me or in which my expertise figures more strongly.  We 
can all work together or, even, separately.  For instance, it's kind of 
a cathedral thing, but I'm interested in adding a logging interface. 
Bob thinks I should simply "integrate" via the existing loggers and 
CAT.  And, I'm sure many will do so.  But, eventually, I suspect some 
will want a "blessed" logge

RE: [Flexradio] Console running out of room?

[ecellison]

I think you can even drag them on to separate digital monitors.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Philip Covington
Sent: Friday, June 24, 2005 10:45 PM
To: FlexRadio@flex-radio.biz
Subject: Re: [Flexradio] Console running out of room?

On 6/24/05, Frank Brickle <[EMAIL PROTECTED]> wrote:

> Does Windows make it easy to use multiple desktops?
> 
> 73
> Frank
> AB2KT

Microsoft has a download from the XP Power Toys that will give you
multiple virtual desktops.

http://download.microsoft.com/download/whistler/Install/2/WXP/EN-US/DeskmanP
owertoySetup.exe

It allows up to 4. Kinda clunky but it does work...

73 de Phil N8VB

___
FlexRadio mailing list
FlexRadio@flex-radio.biz
http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz

RE: [Flexradio] Console running out of room?

[ecellison]

Phil

(snip)
*
For those of us who can make changes to the code we basically can have
anything we care to code.  But there still needs to be some kind of
standard console (as Larry mentioned) as a common point of reference
for all users.

73 de Phil N8VB
*

I agree.

Since your original posts and your console suggested a 'training' approach,
how about a webinar on Teamspeak and TightVNC for those of us who would like
to play with the foreground stuff? Skins and the like.

A couple of hours 1 time per week would probably bring another order of
magnitude of programmers out of the woodwork who could focus on custom
consoles, if the underlying control code design was modular.

Thanks for all your work!

Eric - AA4SW

RE: [Flexradio] Console running out of room?

[ecellison]

Frank


(snip)
***
Second point. "Running out of real estate" is a poor excuse 
for starting to restrict what people can bring out to the 
front easily. This is a software radio, for heaven's sake. 
If you're running out of real estate, *the design is wrong*. 
It shows that the monolithic console has outlived its 
usefulness.

In any case nobody else should be making policy decisions 
for me about what's easy to get to and what isn't. It should 
be up to me whether I get to see the CWL/CWU switch all the 
time or not, and your prerogative contrariwise.
**
Truer words were never spoken.

I think we should have a ban on discussing console changes. Generates
hundereds of messages, and accomplishes nothing, since everyone has their
own preferences. Hundereds of hours were spent on "Beppe's Console" and
design discussions. Still monolithic!

With software there are an infinite number of 'solutions'.

I think the only resolution to the conundrum is a 'roll your own' approach
where 'non-programmers' can play with simple design tools to genereate their
own preferences.

I could go on forever about the monolithic console, but you said it ALL in 2
paragraphs!

Eric - AA4SW

RE: [Flexradio] Console running out of room?

[ecellison]

Folks

I welcome any 'movement' towards making the console more efficient. I agree
with Larry though. Dropdown boxes, tabbed areas, Tabs at bottom which bring
up huge amounts of mode specific area on current console foreground. "When
in CW, do as the CW'ers do!", only in the foreground ON the console. 

Hundereds of messages have been written on the forum about it. 

Nice job Phil.

Eric


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Friday, June 24, 2005 2:22 PM
To: Philip Covington
Cc: Flexradio Reflector
Subject: Re: [Flexradio] Console running out of room?

> Hi All,
>
> I posted a couple of screenshots of a modification that I quickly made
> to the console to try to get some more real estate...  It is no big
> deal... just playing around...
>
> see notes June 24, 2005 on http://www.philcovington.com/SDR.html  if
> you are bored sometime.  Comments?
>

As an experiment, it is just fine.  As as a direction, it is probably not
what we want.

I have already complained about the overlap (at 1280x1024) between the
existing form and the CW form.  I have even proposed multiple, "shorted"
CW forms as one way to deal with it.  And, that's the existing form.

Ultimately, I think we're going to end up with either tear offs or else
some sort of clickable control that temporarily moves not-so-often used
controls (e.g. PWR perhaps) over the top of the panadapter area and have
them invisible the rest of the time.

This will be required to keep the real estate reasonable and to keep the
new user from being overwhelmed as we add stuff.


___
FlexRadio mailing list
FlexRadio@flex-radio.biz
http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz

RE: [Flexradio] Console running out of room?

[Duane - N9DG]

--- Bill Tracey <[EMAIL PROTECTED]> wrote:

> Do we need to handle all situations in the mainline
> console.  With the CAT 
> commands maturing we now have the ability to drive the
> console with any 
> number of purpose oriented radio control progs.   Perhaps
> that 
> would  fulfill the special requirements of a contest or DX
> operation?
> 
> Regards,
> 
> Bill

No I don't think we should even try to handle all situations
in the mainline console. To do so represents too many
compromises to all users. Attempting to accommodate all types
of users and their operating styles in a single user
interface is precisely what has caused the emergence of the
ergonomic abominations that so many of the big 3 radios
manufacturers now produce. They try so hard to accommodate
everyone's operating style in a single panel design. But by
doing so they force *everyone* to compromise more than they
should have to for what they really want to do. We can now
truly break free of that thought and design pattern with the
SDR-1000 if we really want to.

George K5TR's comment about the panadapter "being in the way"
is quite likely quite true in high density, high run rate HF
contesting and/or his style of operating. I however wouldn't
even go into a VHF contest anymore without one, or even for
chasing VHF DX for that matter. So to pick just one or the
other in a UI design means that one of us is compromising,
with the SDR-1000 and software we no longer need to make
those kinds of compromise decisions. There will still be
design compromises to be sure but they will be more benign to
the end user.

Duane
N9DG




 
Yahoo! Sports 
Rekindle the Rivalries. Sign up for Fantasy Football 
http://football.fantasysports.yahoo.com

RE: [Flexradio] Console running out of room?

[Bill Tracey]

Do we need to handle all situations in the mainline console.  With the CAT 
commands maturing we now have the ability to drive the console with any 
number of purpose oriented radio control progs.   Perhaps that 
would  fulfill the special requirements of a contest or DX operation?


Regards,

Bill

At 09:40 PM 6/24/2005, Gary Schmidt W5ZL wrote:

I don't exactly know what multiple desktops are, but there is always the
possibility of opening and closing what I think you're calling tear-offs to
do specific things - a la N1MM as a contest logger which allows you to
display as many special purpose "windows" as you want or have surface area
to display.

When Gerald and I met with George Fremin K5TR several months ago - he's a
world class contester and also a veteran of several high profile DXpeditions
- he commented that he'd like to see a very stripped-down console and
several functions moved off-screen to physical knobs and/or buttons. That
was before the discovery of the ShuttlePro. He even commented that as sexy
as the panadapter was, it would frequently just be in his way. Think how
much we could shrink the console in those times when we were using the SDR
as a run station.

I intend to use my little laptop pretty extensively for SDR operation, first
as part of a three-radio rover in the Texas QSO Party coming up in September
and hopefully in our all-SDR DXpedition to V31 for CQWW SSB in late October.
Since I'll be logging on the same computer, and given the extremely small
(bid wide) screen, cutting down the span of the console could be very
beneficial.

Gary

-Original Message-
From: Frank Brickle [mailto:[EMAIL PROTECTED]
Sent: Friday, June 24, 2005 9:30 PM
To: [EMAIL PROTECTED]
Cc: FlexRadio@flex-radio.biz
Subject: Re: [Flexradio] Console running out of room?

Gary --

> I personally would choose to display a smaller set of buttons for
> features I use all the time, like CW controls and one-button memory
> dumps to CW or voice (or digital), or just fewer buttons altogether if,
> because of my limited operating skill set and interests, they're
> controlling functions I don't use.

Isn't this just the kind of thing Duane N9DG was talking
about? Tailor the interface to the kind of operating you
need to do? Certainly doesn't speak to limitations, just
convenience and efficiency.

Not to speak for Eric KE5DTO, but I think there's been a
general feeling on his part for awhile now that the console
code needs a basic restructuring. From this thread it's
pretty clear that a fundamental piece of the revised
architecture should be selectable groups and positions of
controls, probably in tear-off panels.

Does Windows make it easy to use multiple desktops?

73
Frank
AB2KT







___
FlexRadio mailing list
FlexRadio@flex-radio.biz
http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz

Re: [Flexradio] Console running out of room? - Short term perspective

[Duane - N9DG]

--- Philip Covington <[EMAIL PROTECTED]> wrote:

> Hi all,
> 
> I didn't really want to start a big argument on all of
> this... I
> mainly was interested in seeing if we can do something in
> the *short*
> term to get a little more room in the console without
> increasing the
> size of the console form.  I am not suggesting anything
> here for the long term...



> 73 de Phil N8VB


My comments here are only in the context of keeping this
discussion thread in line with Phil's original goal of it
being only for short term tweak(s) of this *existing* UI. 

First I'll state that I do like this change to the filter
area. The only additional thing that would be neat to
implement is an ability to be able to write your
'masterpiece' filter setting(s) configuration to any of the
various fixed filter button positions for later recall.

Additionally I would like to then see a similar treatment of
the controls for the PWR, AF, SQL, MIC, AGC and Preamp. These
too are good candidates for being made into sliders where
appropriate (these would be more natural if made vertical).
Then there would be two tabs, one for TX items and other for
RX items.

Duane
N9DG



 
Yahoo! Sports 
Rekindle the Rivalries. Sign up for Fantasy Football 
http://football.fantasysports.yahoo.com

Re: [Flexradio] Console running out of room?

[Frank Brickle]

Phil --

All right, that's great. It's not a real or a permanent 
solution, but having multi desktops might be one way to ease 
the pain of expanding to a full-screen console.


Also, under Linux, I have several small sticky windows -- 
things like the jack controls -- that stay in place even 
when you switch desktops. Having sticky tearoffs might be a 
way to keep an eye on the SDR even when switched to another 
desktop where logging is going on, etc. It would be nice if 
Windows had that capability too.


Thanks
Frank
AB2KT

Philip Covington wrote:


Microsoft has a download from the XP Power Toys that will give you
multiple virtual desktops.

http://download.microsoft.com/download/whistler/Install/2/WXP/EN-US/DeskmanPowertoySetup.exe

It allows up to 4. Kinda clunky but it does work...

Re: [Flexradio] Console running out of room?

[Philip Covington]

On 6/24/05, Frank Brickle <[EMAIL PROTECTED]> wrote:

> Does Windows make it easy to use multiple desktops?
> 
> 73
> Frank
> AB2KT

Microsoft has a download from the XP Power Toys that will give you
multiple virtual desktops.

http://download.microsoft.com/download/whistler/Install/2/WXP/EN-US/DeskmanPowertoySetup.exe

It allows up to 4. Kinda clunky but it does work...

73 de Phil N8VB

RE: [Flexradio] Console running out of room?

[Gary Schmidt W5ZL]

I don't exactly know what multiple desktops are, but there is always the
possibility of opening and closing what I think you're calling tear-offs to
do specific things - a la N1MM as a contest logger which allows you to
display as many special purpose "windows" as you want or have surface area
to display. 

When Gerald and I met with George Fremin K5TR several months ago - he's a
world class contester and also a veteran of several high profile DXpeditions
- he commented that he'd like to see a very stripped-down console and
several functions moved off-screen to physical knobs and/or buttons. That
was before the discovery of the ShuttlePro. He even commented that as sexy
as the panadapter was, it would frequently just be in his way. Think how
much we could shrink the console in those times when we were using the SDR
as a run station.

I intend to use my little laptop pretty extensively for SDR operation, first
as part of a three-radio rover in the Texas QSO Party coming up in September
and hopefully in our all-SDR DXpedition to V31 for CQWW SSB in late October.
Since I'll be logging on the same computer, and given the extremely small
(bid wide) screen, cutting down the span of the console could be very
beneficial.

Gary

-Original Message-
From: Frank Brickle [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 24, 2005 9:30 PM
To: [EMAIL PROTECTED]
Cc: FlexRadio@flex-radio.biz
Subject: Re: [Flexradio] Console running out of room?

Gary --

> I personally would choose to display a smaller set of buttons for 
> features I use all the time, like CW controls and one-button memory 
> dumps to CW or voice (or digital), or just fewer buttons altogether if, 
> because of my limited operating skill set and interests, they're 
> controlling functions I don't use.  

Isn't this just the kind of thing Duane N9DG was talking 
about? Tailor the interface to the kind of operating you 
need to do? Certainly doesn't speak to limitations, just 
convenience and efficiency.

Not to speak for Eric KE5DTO, but I think there's been a 
general feeling on his part for awhile now that the console 
code needs a basic restructuring. From this thread it's 
pretty clear that a fundamental piece of the revised 
architecture should be selectable groups and positions of 
controls, probably in tear-off panels.

Does Windows make it easy to use multiple desktops?

73
Frank
AB2KT

Re: [Flexradio] Console running out of room?

[Frank Brickle]

Gary --

I personally would choose to display a smaller set of buttons for 
features I use all the time, like CW controls and one-button memory 
dumps to CW or voice (or digital), or just fewer buttons altogether if, 
because of my limited operating skill set and interests, they’re 
controlling functions I don’t use.  


Isn't this just the kind of thing Duane N9DG was talking 
about? Tailor the interface to the kind of operating you 
need to do? Certainly doesn't speak to limitations, just 
convenience and efficiency.


Not to speak for Eric KE5DTO, but I think there's been a 
general feeling on his part for awhile now that the console 
code needs a basic restructuring. From this thread it's 
pretty clear that a fundamental piece of the revised 
architecture should be selectable groups and positions of 
controls, probably in tear-off panels.


Does Windows make it easy to use multiple desktops?

73
Frank
AB2KT

Re: [Flexradio] Console running out of room?

[Larry Loen]

Bill Tracey wrote:

Console out of room: what screen resolutions are folks typically 
running?   One of the reasons we're running out of space is a desire 
to maintain the ability to run on an 800x600 display.   Would making 
the console larger be a viable approach in the short term?


Regards,

Bill (kd5tfd)


I think the current limit is a very good goal.  I'm running 1280x1024, 
but the base console plus CW display, as I noted, overlap on the display.


So, there's more to think about than just the 800x600.  Not to mention 
those of us trying to run Ham Radio Deluxe et. al.  Smaller (as long as 
legible/sensible) is better.  Larger would be an operational headache 
for me, even though my display nominally has room for larger.  In fact, 
I think I've run experimentals that are larger, but this isn't something 
we should easily yield on.  If nothing else, it's a hint we're getting 
too complicated (at least on the default screens).



Larry  WO0Z

RE: [Flexradio] Console running out of room?

[Gary Schmidt W5ZL]

At the risk of tossing another log on the fire . . . 

 

While there are undoubtedly weirdos and geeks like
Frank (just kidding Frank, put down that gun) that do cross-band/mode operation
and who like to have all those extraneous buttons displayed to impress their
friends, I was merely suggesting there be a simplified “default”
console that would meet the needs of the masses and provide a less cluttered
GUI. It was never my intent to suggest that those functions be deleted for super
ops like Frank, but more to suggest that we mere mortals have the option to
uncheck them in the setup and make them disappear from the console since we are
apparently not bright enough to know that we need them. Heck, maybe the whole
GUI should be drag and drop – undoubtedly mere minutes for coding gods
like Eric to knock out.

 

I personally would choose to display a smaller set of
buttons for features I use all the time, like CW controls and one-button memory
dumps to CW or voice (or digital), or just fewer buttons altogether if, because
of my limited operating skill set and interests, they’re controlling
functions I don’t use.  

 

With tongue firmly in cheek (my own), I remain,

 

W5ZL

 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bill Tracey
Sent: Friday, June 24, 2005 8:15 PM
To: FlexRadio@flex-radio.biz
Subject: Re: [Flexradio] Console running out of room?

 

Console out of room: what screen resolutions are folks
typically 

running?   One of the reasons we're running
out of space is a desire to 

maintain the ability to run on an 800x600
display.   Would making the 

console larger be a viable approach in the short term?

 

Regards,

 

Bill (kd5tfd)

RE: [Flexradio] Console running out of room?

[Bob Tracy]

Yes, I'm running the same - 1280 x 1024 on my workstation, 1024 x 768 on my
laptop.

Bob K5KDN

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Philip Covington
Sent: Friday, June 24, 2005 8:31 PM
To: FlexRadio@flex-radio.biz
Subject: Re: [Flexradio] Console running out of room?


running 1280 x 1024 here...  my laptop is at 1024 x 768...

Is anyone running less than 1024 x 768???

73 de Phil N8VB

On 6/24/05, Bill Tracey <[EMAIL PROTECTED]> wrote:
> Console out of room: what screen resolutions are folks typically
> running?   One of the reasons we're running out of space is a desire to
> maintain the ability to run on an 800x600 display.   Would making the
> console larger be a viable approach in the short term?
>
> Regards,
>
> Bill (kd5tfd)
>
>
>
> ___
> FlexRadio mailing list
> FlexRadio@flex-radio.biz
> http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
>


--
Philip A Covington
vHMI Automation, Inc.
http://www.vhmiautomation.com
http://www.philcovington.com

___
FlexRadio mailing list
FlexRadio@flex-radio.biz
http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz

Re: [Flexradio] Console running out of room?

[Philip Covington]

running 1280 x 1024 here...  my laptop is at 1024 x 768...

Is anyone running less than 1024 x 768???

73 de Phil N8VB

On 6/24/05, Bill Tracey <[EMAIL PROTECTED]> wrote:
> Console out of room: what screen resolutions are folks typically
> running?   One of the reasons we're running out of space is a desire to
> maintain the ability to run on an 800x600 display.   Would making the
> console larger be a viable approach in the short term?
> 
> Regards,
> 
> Bill (kd5tfd)
> 
> 
> 
> ___
> FlexRadio mailing list
> FlexRadio@flex-radio.biz
> http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
> 


-- 
Philip A Covington
vHMI Automation, Inc.
http://www.vhmiautomation.com
http://www.philcovington.com

Re: [Flexradio] Console running out of room?

[Bill Tracey]

Console out of room: what screen resolutions are folks typically 
running?   One of the reasons we're running out of space is a desire to 
maintain the ability to run on an 800x600 display.   Would making the 
console larger be a viable approach in the short term?


Regards,

Bill (kd5tfd)

Re: [Flexradio] Console running out of room?

[Philip Covington]

Hi all,

I didn't really want to start a big argument on all of this... I
mainly was interested in seeing if we can do something in the *short*
term to get a little more room in the console without increasing the
size of the console form.  I am not suggesting anything here for the
long term...

For those of us who can make changes to the code we basically can have
anything we care to code.  But there still needs to be some kind of
standard console (as Larry mentioned) as a common point of reference
for all users.

I hope everyone has a nice weekend.

73 de Phil N8VB

On 6/24/05, Larry Loen <[EMAIL PROTECTED]> wrote:
> Frank Brickle wrote:
> 
> > Couple of items.
> >
> > I switch between CWL and CWU all the time. The nice thing about LSB
> > injection is that the pitch of a CW signal goes *up* as you tune *up*.
> > That seems nice and intuitive to me. However, I also do a fair amount
> > of cross-mode operation (HF and VHF both) and you need to be able to
> > switch easily in that situation.
> >
> > Second point. "Running out of real estate" is a poor excuse for
> > starting to restrict what people can bring out to the front easily.
> > This is a software radio, for heaven's sake. If you're running out of
> > real estate, *the design is wrong*. It shows that the monolithic
> > console has outlived its usefulness.
> 
> Try stuggling with the current console and the CW display and see if you
> still agree that "running out of real estate" is a design issue.  To me,
> it's not a debate about best practices, it's a daily issue!  And, yet,
> that part, at least, could be fixed as long as :1) the current
> console experiences no net height or width increase,   2) some of my
> ideas for multiple CW displays would be adopted, so each would be
> smaller.  Within those boundaries, if they existed, I would not care how
> the thing is laid out as long as it is usable.  What "gets" me today is
> the simple and humble problem that they overlap at all.
> 
> "The design is wrong" is a nice global statement.  Maybe I'll come to
> agree with it.  I confess I have sometimes suspected it, given creeping
> featureitis.  Indeed, if you stack all my statements together, I may
> have been on both sides of this argument over time.
> 
> But, in the end, I'm still convinced that whatever we all do, however
> many skins we have, there probably will always be a place for a
> "standard" console that is (inevitably) badly overloaded functionally so
> that we all have a common frame of reference and users who aren't coders
> can still (eventually) do what they want.  Such an overloaded console
> will have to make some practical choices of what to show and what to
> hide, at least when it first comes up.
> 
> >
> > In any case nobody else should be making policy decisions for me about
> > what's easy to get to and what isn't. It should be up to me whether I
> > get to see the CWL/CWU switch all the time or not, and your
> > prerogative contrariwise.
> >
> > 73
> >
> 
> Well, as long as things are as they are today, there is a de facto
> policy with the current code.  And, I suspect, some people are going to
> want to have such a default (which is also de facto), even if you and
> maybe I and certainly Phil run off in other directions with varying
> degrees of success.
> 
> Heck, some of what I may try, I'm not sure I care if anyone follows.
>  This could get to be a little like radio kit building for some of us
> where it is a quantity one exercise, except in software not hardware.
>  But, that's all the more reason for a kind of "reference platform" that
> everyone uses.
> 
> If nothing else, I think Gerald needs a "standard" console for his
> business,  as does W0VB et. al. for presentations, even if there are
> (say) three or four popular alternatives with varying degrees of
> departure from the base.  Standards are always a set of compromises
> (maybe particularly ugly ones here), but they have their own power.
> 
> 
> 
> Larry   WO0Z
> 
> 
> 
> 
> ___
> FlexRadio mailing list
> FlexRadio@flex-radio.biz
> http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
>

Re: [Flexradio] Console running out of room?

[Larry Loen]

Frank Brickle wrote:


Couple of items.

I switch between CWL and CWU all the time. The nice thing about LSB 
injection is that the pitch of a CW signal goes *up* as you tune *up*. 
That seems nice and intuitive to me. However, I also do a fair amount 
of cross-mode operation (HF and VHF both) and you need to be able to 
switch easily in that situation.


Second point. "Running out of real estate" is a poor excuse for 
starting to restrict what people can bring out to the front easily. 
This is a software radio, for heaven's sake. If you're running out of 
real estate, *the design is wrong*. It shows that the monolithic 
console has outlived its usefulness.


Try stuggling with the current console and the CW display and see if you 
still agree that "running out of real estate" is a design issue.  To me, 
it's not a debate about best practices, it's a daily issue!  And, yet, 
that part, at least, could be fixed as long as :1) the current 
console experiences no net height or width increase,   2) some of my 
ideas for multiple CW displays would be adopted, so each would be 
smaller.  Within those boundaries, if they existed, I would not care how 
the thing is laid out as long as it is usable.  What "gets" me today is 
the simple and humble problem that they overlap at all.


"The design is wrong" is a nice global statement.  Maybe I'll come to 
agree with it.  I confess I have sometimes suspected it, given creeping 
featureitis.  Indeed, if you stack all my statements together, I may 
have been on both sides of this argument over time.


But, in the end, I'm still convinced that whatever we all do, however 
many skins we have, there probably will always be a place for a 
"standard" console that is (inevitably) badly overloaded functionally so 
that we all have a common frame of reference and users who aren't coders 
can still (eventually) do what they want.  Such an overloaded console 
will have to make some practical choices of what to show and what to 
hide, at least when it first comes up.




In any case nobody else should be making policy decisions for me about 
what's easy to get to and what isn't. It should be up to me whether I 
get to see the CWL/CWU switch all the time or not, and your 
prerogative contrariwise.


73



Well, as long as things are as they are today, there is a de facto 
policy with the current code.  And, I suspect, some people are going to 
want to have such a default (which is also de facto), even if you and 
maybe I and certainly Phil run off in other directions with varying 
degrees of success.


Heck, some of what I may try, I'm not sure I care if anyone follows. 
This could get to be a little like radio kit building for some of us 
where it is a quantity one exercise, except in software not hardware. 
But, that's all the more reason for a kind of "reference platform" that 
everyone uses.


If nothing else, I think Gerald needs a "standard" console for his 
business,  as does W0VB et. al. for presentations, even if there are 
(say) three or four popular alternatives with varying degrees of 
departure from the base.  Standards are always a set of compromises 
(maybe particularly ugly ones here), but they have their own power.




Larry   WO0Z