[Flexradio] Acorn-sdr

[Bob Cowdery]

Hi all,

I've put up a new project at http://code.google.com/p/acorn-sdr. It is
the start of an evolution of both erlink-sr http://www.g3ukb.co.uk and
pylink-sr http://code.google.com/p/pylink-sr. This is a software bus
with a reference implementation of a set of nodes. I will be moving this
forward as time allows with some heavyweight nodes. As always I hope
someone finds something of interest there. The info is minimal at the
moment but hopefully sufficient.

73
Bob
G3UKB


___
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.flex-radio.com/  Homepage: http://www.flex-radio.com/

Re: [Flexradio] New architecture questions

[Bob Cowdery]

Interesting stuff and certainly a world away from the current
implementation. I did ask about graphic displays in a browser as I
wanted to try that myself and was rather hoping Bob had done some of the
leg work! I'm not sure that's the real intention though. It's perfectly
possible and even preferable these days to have a rich client over HTTP.

Bob
G3UKB

On Wed, 2009-01-07 at 15:58 +0100, Frank Goenninger wrote:
> All,
> 
> thanks for providing this wealth of information! Sure very interesting  
> reading!
> 
> @Bob: Thanks a lot, Bob, for sharing your experience and for keeping  
> us up-to-date on your progress. I wasn't aware you're not working for  
> FRS so thanks for making this clear. Having read all the info now I am  
> excited to see how people will do the Panadpter of PowerSDR within a  
> web browser ... ;-)
> 
> 73,
> Frank DG1SBG
> 
> Am 07.01.2009 um 01:03 schrieb Tim Ellison:
> 
> > The Overview and Basic Structure components of Frank's readme file  
> > on the vrk architecture are available in the KC for review.  The  
> > "programmer" details have been omitted.
> > http://kc.flex-radio.com/KnowledgebaseArticle50395.aspx
> >
> >
> > Thanks Frank for permission to publish the content.
> >
> >
> > -Tim
> >
> > -Original Message-
> > From: flexradio-boun...@flex-radio.biz 
> > [mailto:flexradio-boun...@flex-radio.biz 
> > ] On Behalf Of Lux, James P
> > Sent: Tuesday, January 06, 2009 6:46 PM
> > To: Roland Etienne; Bob Cowdery
> > Cc: Reflector Flex-Radio
> > Subject: Re: [Flexradio] New architecture questions
> >
> >
> >> -Original Message-
> >> From: flexradio-boun...@flex-radio.biz
> >> [mailto:flexradio-boun...@flex-radio.biz] On Behalf Of Roland Etienne
> >> Sent: Tuesday, January 06, 2009 12:31 PM
> >> To: Bob Cowdery
> >> Cc: Reflector Flex-Radio
> >> Subject: Re: [Flexradio] New architecture questions
> >>
> >> Frank, AB2KT, gives interesting informations about the
> >> Virtual Radio Kernel, in a readme file located at
> >> <https://www.cgran.org/cgran/projects/dttsp/branches/ab2kt>
> >>
> >>
> > One should note that the URL is a SVN server, NOT a webserver.   
> > You'll need to do a SVN checkout to get stuff (or use a SVN browser).
> >
> > Jim
> >
> > ___
> > 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.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://kc.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://kc.flex-radio.com/  Homepage: http://www.flex-radio.com/

Re: [Flexradio] New architecture questions

[Bob Cowdery]

Bob

I wonder if you have done any experiments with graphical interfaces with
JS. I think I probably have something roughly equivalent in function but
on a completely different architecture but have stopped short of trying
to do a graphical display because I have to severely limit the time I
spend on hobbies at the moment. I have just used plain old JS and Ajax
and get a reasonable scroll rate with frequency but I'm not sure what
refresh rate could be achieved with a graphical display and whether it
would be very different on different browsers. If you plan to do
anything in that area I would be very interested in how you get on.

Bob
G3UKB

On Tue, 2009-01-06 at 13:28 -0600, Bob Tracy wrote:
> Frank,
> 
> First, let me clarify my position with respect to the new architecture:  I
> do not work for FlexRadio, I am a volunteer developer.  My concept of how
> the new software will be structured may or may not be the way it happens, I
> can only suggest ways to implement it.
> 
> No, there are no diagrams currently available for publication, it is simply
> too early in the process.  I understand there will be a formal presentation
> at Dayton this year, at which time I'm sure more details will be published.
> 
> In general terms, your "requirements/wishes" are included in my
> understanding of the overall design goals for the new software, you are not
> off-track.
> 
> I am absolutely incompetent to discuss the audio chain, you will need to
> talk to one of the resident wizards about that.
> 
> My current experiment in command and control looks like this:
> 
> A simple GUI built with GWT containing a few buttons to simulate band, mode,
> and frequency selection.
> A button press is translated into an HTTP POST with a URL like
> http://servername:port/device/service_area/command.
> A YAWS application receives the HTTP request and directs the command to the
> application module (appmod) in charge of the device/service_area  
> requested.
> The appmod spawns as many processes as needed to perform the specific task.
> Some tasks may be accomplished by the initial appmod itself,
>   others (like band swtiching) may need to spawn many concurrent processes
> (change band, save/recall bandstack, etc).
> At present, a simple TCP/IP server connects the VR kernel request to the
> radio interface.
> 
> As stated above, this is the first-cut implementation and is subject to
> change from minute to minute.  Wish I had more to offer.
> 
> 73,
> 
> Bob K5KDN
> 
> 
> 
> -Original Message-
> From: Frank Goenninger [mailto:f...@me.com]
> Sent: Tuesday, January 06, 2009 10:23 AM
> To: Lux, James P; Bob Tracy
> Cc: Reflector Flex-Radio
> Subject: Re: [Flexradio] New architecture questions
> 
> 
> With all those bits and pieces of information on the new architecture
> I am wondering what it actually looks like... Anywhere any info
> available? Some early diagrams?
> 
> I would assume it meets the following "requirements" / wishes:
> 
> * Separate "radio driver" process, connectable from several "clients"
> * Interface connectable via sockets for maximum flexibility
> * Clients could be: PowerSDR, NetJack for audio distribution, VAC ...
> * Separate "channels" for audio RX1, RX2, command & control, I/Q, ...
> 
> Or am I completely off track here?
> 
> ... being really curious ;-)
> 
> Thanks for info!
> 
> 73, Frank DG1SBG
> 
> Am 06.01.2009 um 05:19 schrieb Lux, James P:
> 
> >
> >
> >
> > On 1/5/09 7:00 PM, "Bob Tracy"  wrote:
> >
> >> Jim,
> >>
> >> I am using Eclipse with the Erlang (ErlIDE) and Google Web Tools
> >> (GWT)
> >> plug-ins to develop an experimental GUI.  I have an Erlang VR
> >> kernel (not as
> >> sophisticated as Frank's, but functional) that I use to test
> >> communications
> >> between the GUI and the radio.  I am also using several of the open
> >> source
> >> third-party GWT libraries and the Google GWT incubator library.
> >>
> >> I have found Eclipse to be an excellent IDE and I had no problems
> >> switching
> >> from VS to Eclipse.
> >
> > Likewise..I'm using Eclipse at work now.
> >
> >>
> >> I think the current consensus among the developers is that Eclipse
> >> will be
> >> the IDE, the GUI tool will probably be GWT but that is still
> >> subject to more
> >> testing.
> >
> > OK.. And I guess the next question is whether the "new PowerSDR"
> > would run
> > as a Windows native app, or in some sort of emulation or VM.  All
> > sorts of
> > issues with either approach when it comes to audio and video devices
> > under
> > Vista (as I thrash about with Ekiga)
> >
> >
> > ___
> > 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.flex-radio.com/  Homepage:
> http://www.flex-radio.com/
> 
> 
> 
> 
> ___
> FlexRadio Systems M

Re: [Flexradio] Can anyone help?

[Bob Cowdery]

Jim, thanks for the comments, there are always different ways to look at
things which is what makes life interesting!

On Wed, 2008-12-31 at 07:34 -0800, Lux, James P wrote:
> 
> 
> On 12/31/08 1:38 AM, "Bob Cowdery"  wrote:
> 
> > Rob, Frank
> >
> > Thanks for the input. SOAP, usually over HTTP, is as you say very
> > lethargic and entirely unsuited to this type of system. It's also a
> > pretty low level of abstraction.
> SOAP can be at whatever level of abstraction you want. HTTP is just the
> transport mechanism, and I've seen some very fast implementations within a
> single processor (after all, how much does it take to do a "GET").  Where it
> gets clunky is when there's a mismatch between server and client, or where
> there's a lot of "late binding" (i.e. Lots of back and forth to establish
> the vocabulary of the conversation, then once both sides have agreed on what
> they're going to send, actually sending the data.)  A lot of implementations
> use a very "interpreter-like" front end to do the lexical analysis and
> parsing from a not particularly efficient data structure.  Sort of like
> saying "Here's a BASIC program to tell the server what the client needs" and
> then having the server parse the BASIC program.
> 
I've used it to an extent in commercial system where I wanted to
orchestrate across enterprise boundaries using UDDI as a location
service - for that its good but I don't like it much for distributing
the components of a single application.
> 
> 
> >CORBA I believe is pretty much dead
> > except for a bunch of niche users.
> 
> One of those niches, is, oddly enough, software defined radios.  OMGs
> Software Communications Architecture (SCA) uses CORBA for middleware (google
> CORBA SCA for lots of stuff).  So does the DoD Joint Tactical Radio System
> (JTRS)..
> 
> Both of these are fairly big efforts (multi billion dollar), and one can
> find much to gripe about with both, but, as far as installed base, they're
> pretty dominant in the SDR world.
> 
Yes I agree they are major users, in fact most users are now in the
technical arena. I think once you buy into the technology in a big way
its hard to back out or even switch vendor as interoperability was never
that great between vendors.
> 
> 
> There are some good alternative
> > commercial offerings but I'm looking for open source as all my stuff is
> > open source. I have a test bed in pylink-sr and as Ice has Python
> > bindings this would be a low-cost way to get a comparison. At the moment
> > I am using net-jack for audio distribution and Pyro for control
> > distribution. Moving both of those over to Ice would give me a good
> > side-by-side comparison of performance and relative code complexity. It
> > will be interesting if nothing else.
> >
> > 73
> > Bob
> > G3UKB
> >
> > On Tue, 2008-12-30 at 16:07 +0100, Frank Goenninger wrote:
> >> Hi Bob, hi Rob,
> >>
> >> Web Services based on SOAP (or HTML, which means the same, normally)
> >> is all over the place these days. If you require real performance I'd
> >> strongly recommend to stay away from anything XML or CORBA. XML is way
> >> to inefficient in its gross/net information ratio. CORBA requires
> >> significant amounts of processing power to handle all the proxy and
> >> interface finding stuff.
> >>
> 
> Kind of depends on where you need the performance.. If it's something like
> tuning a radio every second, no big deal.  If it's running a FIR filter,
> probably not.
> 
One of the things I want is a proper event service and that's hard to do
with HTTP. I'm prepared to give Ice a shot at being a better CORBA, if
it doesn't get there I've just lost a little time, but either way I get
to add something to the armoury or write something off.
> 


___
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.flex-radio.com/  Homepage: http://www.flex-radio.com/

Re: [Flexradio] Can anyone help?

[Bob Cowdery]

Rob, Frank

Thanks for the input. SOAP, usually over HTTP, is as you say very
lethargic and entirely unsuited to this type of system. It's also a
pretty low level of abstraction. CORBA I believe is pretty much dead
except for a bunch of niche users. There are some good alternative
commercial offerings but I'm looking for open source as all my stuff is
open source. I have a test bed in pylink-sr and as Ice has Python
bindings this would be a low-cost way to get a comparison. At the moment
I am using net-jack for audio distribution and Pyro for control
distribution. Moving both of those over to Ice would give me a good
side-by-side comparison of performance and relative code complexity. It
will be interesting if nothing else.

73
Bob
G3UKB

On Tue, 2008-12-30 at 16:07 +0100, Frank Goenninger wrote:
> Hi Bob, hi Rob,
> 
> Web Services based on SOAP (or HTML, which means the same, normally)  
> is all over the place these days. If you require real performance I'd  
> strongly recommend to stay away from anything XML or CORBA. XML is way  
> to inefficient in its gross/net information ratio. CORBA requires  
> significant amounts of processing power to handle all the proxy and  
> interface finding stuff.
> 
> That's why there are alternatives such as ICE. When I was with Hewlett- 
> Packard we used ICE for transferring large amounts of CAD data between  
> nodes. It is still a pain to use because it's just providing a C++  
> interface on HP-UX but, hey, that's the price we had to pay. Nowadays  
> I am using TIBCO Rendezvous Services as the infrastructure for  
> distributed communication and application deployment. Raw C interface,  
> no big API, just the basics and blazingly fast.
> 
> One other note concerning the GPL: Be careful. Anything that uses the  
> GPL stuff gets a GPL thing itself. So: Your piece of software will  
> inherit the GPL. This may or may not be what you want... and makes me  
> stay away from GPL stuff as much as I can...
> 
> Whishing you best of luck and success!
> 
> 73, Frank DG1SBG
> 
> 
> Am 30.12.2008 um 15:34 schrieb ab...@juno.com:
> 
> > Hi Bob,
> >
> > Back in my working days we used CORBA a bunch.
> >
> > Now the guys tell me they use the latest version of HTML to do what  
> > CORBA tried to do.  Don't know the details but do know they are  
> > wildly successful!
> >
> > Best regards,
> > Rob
> > AB7CF
> >
> > -- Bob Cowdery  wrote:
> >
> > To all you software guys out there.
> >
> > Has anyone tried, played with or preferably used in anger, Ice from
> > ZeroC - http://www.zeroc.com/. It's a comms backbone which takes its
> > roots from CORBA and DCOM but claims to be the working  
> > implementation of
> > everything they got wrong! If it does what it says on the tin it could
> > make a very nice bus for the software equivalent of HPSDR. Attractive
> > features are highly performant (their words), cross platform and
> > language bindings to C++, C#, Java, Python, Ruby, VB and a few others,
> > and its GPL otherwise I wouldn't bother to mention it.
> >
> > I did quite a lot with CORBA in the early days and liked having  
> > services
> > defined by interfaces. Ice retains that feel and has code generators
> > that create the boiler plate from the IDL. It feels quite familiar  
> > to me
> > but I think the real advantage would be language interop in a
> > distributed environment without having to map through some other
> > language to get there. Yes, there are all sorts of caveats around how
> > types are marshaled and the real world may be just as complex as doing
> > it some other way. The examples are quite succinct but the user  
> > guide is
> > long! That's why I want to know if anyone has experience before I  
> > waste
> > time.
> >
> > Thanks for any replies. Opinions welcome if you have a few minutes to
> > scan over the site.
> >
> > 73
> > Bob
> > G3UKB
> >
> >
> > ___
> > 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.flex-radio.com/  Homepage: 
> > http://www.flex-radio.com/
> >
> >
> >
> > 
> > Save $15 on Flowers and Gifts from FTD!
> > Shop now at http://offers.juno.com/TGL1141/?u=http://www.ftd.com/17007
> >
> > __

[Flexradio] Can anyone help?

[Bob Cowdery]

To all you software guys out there.

Has anyone tried, played with or preferably used in anger, Ice from
ZeroC - http://www.zeroc.com/. It's a comms backbone which takes its
roots from CORBA and DCOM but claims to be the working implementation of
everything they got wrong! If it does what it says on the tin it could
make a very nice bus for the software equivalent of HPSDR. Attractive
features are highly performant (their words), cross platform and
language bindings to C++, C#, Java, Python, Ruby, VB and a few others,
and its GPL otherwise I wouldn't bother to mention it.

I did quite a lot with CORBA in the early days and liked having services
defined by interfaces. Ice retains that feel and has code generators
that create the boiler plate from the IDL. It feels quite familiar to me
but I think the real advantage would be language interop in a
distributed environment without having to map through some other
language to get there. Yes, there are all sorts of caveats around how
types are marshaled and the real world may be just as complex as doing
it some other way. The examples are quite succinct but the user guide is
long! That's why I want to know if anyone has experience before I waste
time.  

Thanks for any replies. Opinions welcome if you have a few minutes to
scan over the site.

73
Bob
G3UKB


___
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.flex-radio.com/  Homepage: http://www.flex-radio.com/

[Flexradio] pylink-sr

[Bob Cowdery]

Some minor updates for more flexibility and a new browser based UI to
look at, see http://code.google.com/p/pylink-sr/ .

73 and a Happy Christmas

Bob
G3UKB


___
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.flex-radio.com/  Homepage: http://www.flex-radio.com/

[Flexradio] Pylink-SR

[Bob Cowdery]

Hi all,

For anyone interested there is a new version of pylink-sr posted at
http://code.google.com/p/pylink-sr/. I'm listening to 40m right now with
the console running in a VM (I'm typing this in another VM on the same
machine) and the business end up in the shack about 30m away running on
a 2GHz single core. 

73 de Bob
G3UKB


___
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.flex-radio.com/  Homepage: http://www.flex-radio.com/

[Flexradio] JunkBox SDR

[Bob Cowdery]

Long time no say much. Lots been happening but not on the radio front
until recently. Job change, contracting now. Doing a surveying course so
permanent job change in the next 6 months or so. Lots of house
renovation projects. Son got married... Unfortunately ErLink-SR really
hasn't had a look-in for 8 months.

Strictly speaking this has not a lot to do with this forum but there
might be some lurkers that fancy a small Linux challenge.

I can't face serious radio work right now so I had some fun with my
other favourite language. The results are up on Google Code at
http://code.google.com/p/pylink-sr/. Any interest let me know. You might
spot the relevance to JunkBox SDR.

73 de Bob
G3UKB  



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

[Bob Cowdery]

Rob

If it goes ahead I expect a lot of different levels of experience so its
not a problem to have people pick and choose what they want to hear. As
for Erlang, it's very far from C. In C it is definitely very easy to
write rubbish that compiles and then trashes your program. It's equally
easy to do it in C++ as well. Erlang runs under a Virtual Machine so
it's environment is much more caring and it's much less painful to
develop and test your program. I don't say that Erlang will catch as
many potential errors at compile time as PASCAL because it won't but
those errors won't trash your program they will give you reasonable
error messages.

Hope that helps.

Bob
 
On Wed, 2008-01-16 at 12:44 -0800, Robert Dennison wrote:
> Hi Bob,
> 
> I was fiddling with MIMD processors and programing languages back when
> microprocessing was just taking off.   Functional languages were just
> beginning to dominate.  Then microprocessors took off..  Now the wheel is
> turning the full circle and here are functional languages again.  
> 
> I'd be interested in starting out again.  However, I do have a concern. I
> consider C & C++ too error prone for anyone but a serious full time
> professional.  For that reason I've done most of my work in PASCAL and
> such.  If Erlang is C like, I'd be interested in the introduction
> portions but probably drop out later on.  If it is a bit higher level,
> I'd probably try to hang in all the way!
> 
> vy 73
> Rob
> AB7CF
> 
>  
> On Thu, 17 Jan 2008 01:06:13 + Bob Cowdery <[EMAIL PROTECTED]> writes:
> > Kirk
> > 
> > Thanks for the interest. This area is really just in its infancy. 
> > With
> > hardware becoming more challenging to source components and build I
> > think more people that like to roll their own will be turning to
> > software. As with all languages reading is much easier than writing 
> > so
> > having something you can read in an application area that is 
> > familiar
> > should help quite a bit. Functional programming is a different mind 
> > set
> > but once you get over that hurdle you start to realise the power.
> > 
> > Bob
> > 
> > On Wed, 2008-01-16 at 12:51 -0600, Kirk wrote:
> > > Bob,
> > > 
> > > I think this is a great idea.  About a week ago I purchased a book 
> > on Erlang
> > > programming which I'm currently reading.  When I did the review on 
> > Erlang I
> > > had the same thought as you.  This language is tailored for Flex 
> > SDR.  I'm
> > > not currently a Flex user (by midyear I will be), however, I do 
> > own a Orion
> > > II. One of the things that interests me in SDR is the ability to 
> > design and
> > > build your own applications.  
> > > I am very interested in your proposal.  I have some programming 
> > experience
> > > using other venues ie C++, SQL, VB and others.  Certainly not an 
> > expert in
> > > any of them but I can get around.  
> > > 
> > > Regards,
> > > 
> > > Kirk, K6KAR
> > > Niceville, FL
> > > 
> > > -Original Message-
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED] On Behalf Of Bob 
> > Cowdery
> > > Sent: Wednesday, January 16, 2008 4:43 PM
> > > To: Reflector Flex-Radio
> > > Subject: [Flexradio] A proposal
> > > 
> > > Hi all
> > > 
> > > If you are not in the slightest interested in delving into some of 
> > the
> > > software engineering behind all the wonderful SDR hardware 
> > available
> > > then please disregard this message.
> > > 
> > > The purpose of this message is to gauge interest in learning how 
> > to
> > > apply Erlang to SDR implementations. Anybody who has been 
> > following
> > > along with the messages on the various forums must be aware that 
> > Erlang
> > > is an integral part of some future architectures. I happen to 
> > believe in
> > > its capabilities and therefore want to promote its use. I am not
> > > implying that what I am doing is in any way the actual 
> > implementation of
> > > that future, just that it's a good base from which to start 
> > learning.
> > > 
> > > My proposal would be along the following lines. A set of tutorial 
> > based
> > > sessions with supporting software and text. These would be 
> > delivered
> > > over Skype or some other similar forum. The sessions would build 
> > up to a
> > > working radio using

Re: [Flexradio] A proposal

[Bob Cowdery]

Hi Bob

Very please to hear you are doing that. I haven't posted source yet
because it's still a work in progress in terms of being fully
functional. However I have no problem in supplying source code to
individuals. Interfacing CAT to the system should be a breeze and would
be a nice addition. If you contact me off-list we can sort out the
details.

Bob

On Wed, 2008-01-16 at 14:26 -0600, Bob Tracy wrote:
> Hi Bob,
> 
> I am currently porting the CAT code over to Erlang, mostly as a learning
> experience.  I've found in the past that the best way for me to learn a new
> language is to port a project I'm very familiar with into the new language.
> The transition to FP has been a little mind-bending but I think I'm over the
> hump.
> 
> Is any of your source code available?  The last time I looked (which was
> some time ago) only the beam files were posted.  I'd like to see if we can
> make my CAT interface with your radio.
> 
> 73,
> 
> Bob, K5KDN
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Bob Cowdery
> Sent: Wednesday, January 16, 2008 4:43 PM
> To: Reflector Flex-Radio
> Subject: [Flexradio] A proposal
> 
> 
> Hi all
> 
> If you are not in the slightest interested in delving into some of the
> software engineering behind all the wonderful SDR hardware available
> then please disregard this message.
> 
> The purpose of this message is to gauge interest in learning how to
> apply Erlang to SDR implementations. Anybody who has been following
> along with the messages on the various forums must be aware that Erlang
> is an integral part of some future architectures. I happen to believe in
> its capabilities and therefore want to promote its use. I am not
> implying that what I am doing is in any way the actual implementation of
> that future, just that it's a good base from which to start learning.
> 
> My proposal would be along the following lines. A set of tutorial based
> sessions with supporting software and text. These would be delivered
> over Skype or some other similar forum. The sessions would build up to a
> working radio using the building blocks that I have developed. Each
> component (primarily the Erlang parts) of the architecture would
> therefore be explained in detail and thus the Erlang language would be
> taught by example after perhaps a primer session. The intention would be
> not just to explain what is there but to enable experimentation by
> building new parts to plug into the architecture and explore ways to
> improve and enhance the design.
> 
> I would expect to cover the following topics.
> 
> 1. Why Erlang? Installation of Erlang, dev tools and a language primer.
> 2. Context, how the Erlink-SR architecture fits together. How messages
> are routed.
> 3. The message routing component explained with a test harness to
> experiment with.
> 4. Linking to C code. How do linked-in drivers work. How is data
> marshaled between the Erlang and C sides. An explanation of the Erlang
> 'C' helper library. Supported with simple examples to play with.
> 5. The main data handing components explained and the use of shared
> memory. All these use linked-in-drivers to acquire, process and output
> sample data. Simple test harnesses will be used to exercise these
> components.
> 6. The Mnesia database explained and the radio database API with a test
> harness to exercise the database.
> 7. The Erlang bindings to wxWidgets explained with some simple
> stand-alone UI examples. The integration of wxErlang with Erlink-SR with
> a walk-through of the pattern for creating new widgets and how they
> interact with the system.
> 8. Driving the hardware, a walk through the hardware component and a
> test harness to exercise it.
> 9. Putting it all together. The OTP (Open Telecomms Platform). The FSM
> (the OTP FSM behaviour, not to be confused with anything else going by
> that name) at the centre of the system, what it does and how it does it.
> The system startup and shutdown.
> 10. Running the radio. What's missing and discussions of how to address
> the missing parts and build out new capability.
> 11. A quick look at the Java integration using erlink-j.
> 
> You should come out of this knowing a lot about Erlang and have an SDR
> system you understand sufficiently to be able to experiment with and
> contribute to. A couple of provisos. The system is not finished yet but
> there is enough there to run the sessions and to run a receiver (SDR1000
> only at the moment) under Windows. The C code is not ported to Linux yet
> so if you have only Linux you won't be able to run everything. You will
> need to have had some programming experience to 

Re: [Flexradio] A proposal

[Bob Cowdery]

Hi Jim

I'm not that far off retirement myself. I am away from Friday for 10
days. I hope there will be enough interest stacked up by the time I
return to make it a goer. Building things is good therapy so keep coding
away.

Bob

On Wed, 2008-01-16 at 13:20 -0600, Jim Rogers, W4ATK wrote:
> Bob I am a retired senior systems analyst and would be most interested in 
> taking part in such an activity. I have programmed in assembler, basic, 
> pascal, C, Visual Basic and of course that dinasaur COBOL (ugh!). Currently 
> I have been exploring OS X and Xcode. Old programmers never die, they just 
> code away. Please keep me posted.
> 
> 73s Jim, W4ATK
> [EMAIL PROTECTED]
> http://web.mac.com/jimrogers_w4atk
> 
> ----- Original Message - 
> From: "Bob Cowdery" <[EMAIL PROTECTED]>
> To: "Reflector Flex-Radio" 
> Sent: Wednesday, January 16, 2008 4:43 PM
> Subject: [Flexradio] A proposal
> 
> 
> > Hi all
> >
> > If you are not in the slightest interested in delving into some of the
> > software engineering behind all the wonderful SDR hardware available
> > then please disregard this message.
> >
> > The purpose of this message is to gauge interest in learning how to
> > apply Erlang to SDR implementations. Anybody who has been following
> > along with the messages on the various forums must be aware that Erlang
> > is an integral part of some future architectures. I happen to believe in
> > its capabilities and therefore want to promote its use. I am not
> > implying that what I am doing is in any way the actual implementation of
> > that future, just that it's a good base from which to start learning.
> >
> > My proposal would be along the following lines. A set of tutorial based
> > sessions with supporting software and text. These would be delivered
> > over Skype or some other similar forum. The sessions would build up to a
> > working radio using the building blocks that I have developed. Each
> > component (primarily the Erlang parts) of the architecture would
> > therefore be explained in detail and thus the Erlang language would be
> > taught by example after perhaps a primer session. The intention would be
> > not just to explain what is there but to enable experimentation by
> > building new parts to plug into the architecture and explore ways to
> > improve and enhance the design.
> >
> > I would expect to cover the following topics.
> >
> > 1. Why Erlang? Installation of Erlang, dev tools and a language primer.
> > 2. Context, how the Erlink-SR architecture fits together. How messages
> > are routed.
> > 3. The message routing component explained with a test harness to
> > experiment with.
> > 4. Linking to C code. How do linked-in drivers work. How is data
> > marshaled between the Erlang and C sides. An explanation of the Erlang
> > 'C' helper library. Supported with simple examples to play with.
> > 5. The main data handing components explained and the use of shared
> > memory. All these use linked-in-drivers to acquire, process and output
> > sample data. Simple test harnesses will be used to exercise these
> > components.
> > 6. The Mnesia database explained and the radio database API with a test
> > harness to exercise the database.
> > 7. The Erlang bindings to wxWidgets explained with some simple
> > stand-alone UI examples. The integration of wxErlang with Erlink-SR with
> > a walk-through of the pattern for creating new widgets and how they
> > interact with the system.
> > 8. Driving the hardware, a walk through the hardware component and a
> > test harness to exercise it.
> > 9. Putting it all together. The OTP (Open Telecomms Platform). The FSM
> > (the OTP FSM behaviour, not to be confused with anything else going by
> > that name) at the centre of the system, what it does and how it does it.
> > The system startup and shutdown.
> > 10. Running the radio. What's missing and discussions of how to address
> > the missing parts and build out new capability.
> > 11. A quick look at the Java integration using erlink-j.
> >
> > You should come out of this knowing a lot about Erlang and have an SDR
> > system you understand sufficiently to be able to experiment with and
> > contribute to. A couple of provisos. The system is not finished yet but
> > there is enough there to run the sessions and to run a receiver (SDR1000
> > only at the moment) under Windows. The C code is not ported to Linux yet
> > so if you have only Linux you won't be able to run everything. You will
> > need to have had some programming experien

Re: [Flexradio] A proposal

[Bob Cowdery]

Hi Jeff

You are right, there is always another language. However, I'm firmly on
the bandwagon with FP. Functional programming is being recognised
(again), and concurrency is key to future systems. So whether its
Erlang, F# or something else it's not a bad thing to start learning. If
this goes ahead I would ensure each component as it is put forward for
scrutiny is fully and properly commented. I think I do that anyway but I
know, when I look back at code it's not always the case!

Bob  

On Wed, 2008-01-16 at 11:01 -0800, Jeff Anderson wrote:
> Sounds like a worthwhile endeavor, Bob (although I'm not sure I want to 
> learn yet *another* language).
> 
> But what I'm really wondering about this new effort (especially with an 
> uncommon language like Erlang) is...will the code be commented?
> 
> Thanks!
> 
> - Jeff, K6JCA
> 
> Bob Cowdery wrote:
> > Hi all
> >
> > If you are not in the slightest interested in delving into some of the
> > software engineering behind all the wonderful SDR hardware available
> > then please disregard this message.
> >
> > The purpose of this message is to gauge interest in learning how to
> > apply Erlang to SDR implementations. Anybody who has been following
> > along with the messages on the various forums must be aware that Erlang
> > is an integral part of some future architectures. I happen to believe in
> > its capabilities and therefore want to promote its use. I am not
> > implying that what I am doing is in any way the actual implementation of
> > that future, just that it's a good base from which to start learning.
> >
> > My proposal would be along the following lines. A set of tutorial based
> > sessions with supporting software and text. These would be delivered
> > over Skype or some other similar forum. The sessions would build up to a
> > working radio using the building blocks that I have developed. Each
> > component (primarily the Erlang parts) of the architecture would
> > therefore be explained in detail and thus the Erlang language would be
> > taught by example after perhaps a primer session. The intention would be
> > not just to explain what is there but to enable experimentation by
> > building new parts to plug into the architecture and explore ways to
> > improve and enhance the design.
> >
> > I would expect to cover the following topics.
> >
> > 1. Why Erlang? Installation of Erlang, dev tools and a language primer.
> > 2. Context, how the Erlink-SR architecture fits together. How messages
> > are routed.
> > 3. The message routing component explained with a test harness to
> > experiment with.
> > 4. Linking to C code. How do linked-in drivers work. How is data
> > marshaled between the Erlang and C sides. An explanation of the Erlang
> > 'C' helper library. Supported with simple examples to play with.
> > 5. The main data handing components explained and the use of shared
> > memory. All these use linked-in-drivers to acquire, process and output
> > sample data. Simple test harnesses will be used to exercise these
> > components.
> > 6. The Mnesia database explained and the radio database API with a test
> > harness to exercise the database.
> > 7. The Erlang bindings to wxWidgets explained with some simple
> > stand-alone UI examples. The integration of wxErlang with Erlink-SR with
> > a walk-through of the pattern for creating new widgets and how they
> > interact with the system.
> > 8. Driving the hardware, a walk through the hardware component and a
> > test harness to exercise it.
> > 9. Putting it all together. The OTP (Open Telecomms Platform). The FSM
> > (the OTP FSM behaviour, not to be confused with anything else going by
> > that name) at the centre of the system, what it does and how it does it.
> > The system startup and shutdown.
> > 10. Running the radio. What's missing and discussions of how to address
> > the missing parts and build out new capability.
> > 11. A quick look at the Java integration using erlink-j.
> >
> > You should come out of this knowing a lot about Erlang and have an SDR
> > system you understand sufficiently to be able to experiment with and
> > contribute to. A couple of provisos. The system is not finished yet but
> > there is enough there to run the sessions and to run a receiver (SDR1000
> > only at the moment) under Windows. The C code is not ported to Linux yet
> > so if you have only Linux you won't be able to run everything. You will
> > need to have had some programming experience to get full benefit but you
> > should be able to follow along 

Re: [Flexradio] A proposal

[Bob Cowdery]

Kirk

Thanks for the interest. This area is really just in its infancy. With
hardware becoming more challenging to source components and build I
think more people that like to roll their own will be turning to
software. As with all languages reading is much easier than writing so
having something you can read in an application area that is familiar
should help quite a bit. Functional programming is a different mind set
but once you get over that hurdle you start to realise the power.

Bob

On Wed, 2008-01-16 at 12:51 -0600, Kirk wrote:
> Bob,
> 
> I think this is a great idea.  About a week ago I purchased a book on Erlang
> programming which I'm currently reading.  When I did the review on Erlang I
> had the same thought as you.  This language is tailored for Flex SDR.  I'm
> not currently a Flex user (by midyear I will be), however, I do own a Orion
> II. One of the things that interests me in SDR is the ability to design and
> build your own applications.  
> I am very interested in your proposal.  I have some programming experience
> using other venues ie C++, SQL, VB and others.  Certainly not an expert in
> any of them but I can get around.  
> 
> Regards,
> 
> Kirk, K6KAR
> Niceville, FL
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Bob Cowdery
> Sent: Wednesday, January 16, 2008 4:43 PM
> To: Reflector Flex-Radio
> Subject: [Flexradio] A proposal
> 
> Hi all
> 
> If you are not in the slightest interested in delving into some of the
> software engineering behind all the wonderful SDR hardware available
> then please disregard this message.
> 
> The purpose of this message is to gauge interest in learning how to
> apply Erlang to SDR implementations. Anybody who has been following
> along with the messages on the various forums must be aware that Erlang
> is an integral part of some future architectures. I happen to believe in
> its capabilities and therefore want to promote its use. I am not
> implying that what I am doing is in any way the actual implementation of
> that future, just that it's a good base from which to start learning.
> 
> My proposal would be along the following lines. A set of tutorial based
> sessions with supporting software and text. These would be delivered
> over Skype or some other similar forum. The sessions would build up to a
> working radio using the building blocks that I have developed. Each
> component (primarily the Erlang parts) of the architecture would
> therefore be explained in detail and thus the Erlang language would be
> taught by example after perhaps a primer session. The intention would be
> not just to explain what is there but to enable experimentation by
> building new parts to plug into the architecture and explore ways to
> improve and enhance the design.
> 
> I would expect to cover the following topics.
> 
> 1. Why Erlang? Installation of Erlang, dev tools and a language primer.
> 2. Context, how the Erlink-SR architecture fits together. How messages
> are routed.
> 3. The message routing component explained with a test harness to
> experiment with.
> 4. Linking to C code. How do linked-in drivers work. How is data
> marshaled between the Erlang and C sides. An explanation of the Erlang
> 'C' helper library. Supported with simple examples to play with.
> 5. The main data handing components explained and the use of shared
> memory. All these use linked-in-drivers to acquire, process and output
> sample data. Simple test harnesses will be used to exercise these
> components.
> 6. The Mnesia database explained and the radio database API with a test
> harness to exercise the database.
> 7. The Erlang bindings to wxWidgets explained with some simple
> stand-alone UI examples. The integration of wxErlang with Erlink-SR with
> a walk-through of the pattern for creating new widgets and how they
> interact with the system.
> 8. Driving the hardware, a walk through the hardware component and a
> test harness to exercise it.
> 9. Putting it all together. The OTP (Open Telecomms Platform). The FSM
> (the OTP FSM behaviour, not to be confused with anything else going by
> that name) at the centre of the system, what it does and how it does it.
> The system startup and shutdown.
> 10. Running the radio. What's missing and discussions of how to address
> the missing parts and build out new capability.
> 11. A quick look at the Java integration using erlink-j.
> 
> You should come out of this knowing a lot about Erlang and have an SDR
> system you understand sufficiently to be able to experiment with and
> contribute to. A couple of provisos. The system is not finished yet but
> there is enough there to run the sessions and to run a rec

[Flexradio] A proposal

[Bob Cowdery]

Hi all

If you are not in the slightest interested in delving into some of the
software engineering behind all the wonderful SDR hardware available
then please disregard this message.

The purpose of this message is to gauge interest in learning how to
apply Erlang to SDR implementations. Anybody who has been following
along with the messages on the various forums must be aware that Erlang
is an integral part of some future architectures. I happen to believe in
its capabilities and therefore want to promote its use. I am not
implying that what I am doing is in any way the actual implementation of
that future, just that it's a good base from which to start learning.

My proposal would be along the following lines. A set of tutorial based
sessions with supporting software and text. These would be delivered
over Skype or some other similar forum. The sessions would build up to a
working radio using the building blocks that I have developed. Each
component (primarily the Erlang parts) of the architecture would
therefore be explained in detail and thus the Erlang language would be
taught by example after perhaps a primer session. The intention would be
not just to explain what is there but to enable experimentation by
building new parts to plug into the architecture and explore ways to
improve and enhance the design.

I would expect to cover the following topics.

1. Why Erlang? Installation of Erlang, dev tools and a language primer.
2. Context, how the Erlink-SR architecture fits together. How messages
are routed.
3. The message routing component explained with a test harness to
experiment with.
4. Linking to C code. How do linked-in drivers work. How is data
marshaled between the Erlang and C sides. An explanation of the Erlang
'C' helper library. Supported with simple examples to play with.
5. The main data handing components explained and the use of shared
memory. All these use linked-in-drivers to acquire, process and output
sample data. Simple test harnesses will be used to exercise these
components.
6. The Mnesia database explained and the radio database API with a test
harness to exercise the database.
7. The Erlang bindings to wxWidgets explained with some simple
stand-alone UI examples. The integration of wxErlang with Erlink-SR with
a walk-through of the pattern for creating new widgets and how they
interact with the system.
8. Driving the hardware, a walk through the hardware component and a
test harness to exercise it.
9. Putting it all together. The OTP (Open Telecomms Platform). The FSM
(the OTP FSM behaviour, not to be confused with anything else going by
that name) at the centre of the system, what it does and how it does it.
The system startup and shutdown.
10. Running the radio. What's missing and discussions of how to address
the missing parts and build out new capability.
11. A quick look at the Java integration using erlink-j.

You should come out of this knowing a lot about Erlang and have an SDR
system you understand sufficiently to be able to experiment with and
contribute to. A couple of provisos. The system is not finished yet but
there is enough there to run the sessions and to run a receiver (SDR1000
only at the moment) under Windows. The C code is not ported to Linux yet
so if you have only Linux you won't be able to run everything. You will
need to have had some programming experience to get full benefit but you
should be able to follow along and try the built examples without any
previous experience.
   
Now for the crunch. Obviously, this would involve me in a lot of effort
and I would be looking to cover some of my time by charging a nominal
fee per session. I would want to keep that very low, maybe something
like $10 a session. If there are enough people interested to make it
viable I will make it happen.

A final plea. I don't want to start any discussions about technologies,
operating systems etc. Please don't use this message as a bouncing
board. 

73
Bob
G3UKB
http://www.g3ukb.co.uk  (there is a problem with my ISP at the moment so
the web site is unavailable, but hopefully fixed soon).



___
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] G3UKB new API demo filter GUI

[Bob Cowdery]

Thank you for the kind words. It does kind of have a mind of its own now
and one thing seems to follow on naturally from another. One day it
might get published if there is enough interest. If I had a dedicated
month I could really push it forward but it takes me about a year for a
months work! Right now I'm getting pulled in the direction of turning
the guts of my UI into a library of components that sits on top of the
API to raise the level of UI building. Then again I want to complete
jDSP and then again I want to do the porting work for Linux, Mac and
then again put in support for the 5000, HPSDR. 

73 de Bob
   
On Mon, 2007-08-20 at 19:58 -0400, Joe - AB1DO wrote:
> I too have been following Bob's progression from time to time and I think it 
> is absolutely spectacular what he is doing (and I only understand a fraction 
> of it!). As far as I can see Bob is and has been continously pushing the 
> envelope in creating a tremendously versatile and flexible software 
> environment for SDRs. I just don't know how you find the time to do it all 
> Bob.
> 
> 73 de Joe - AB1DO
> 
> - Original Message - 
> From: "Ken N9VV" <[EMAIL PROTECTED]>
> To: "Flex-radio Reflector" 
> Sent: Monday, August 20, 2007 19:19
> Subject: [Flexradio] G3UKB new API demo filter GUI
> 
> 
> > Bob G3UKB has created a little demo of how to make a simple filter
> > selection window using the new API that he has created for his ER-Link
> > project:  http://www.g3ukb.co.uk/api.html
> >
> > good work Bob,
> > de ken n9vv
> >
> >
> > ___
> > 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 Knowledge Base: http://kb.flex-radio.com/
> > 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 Knowledge Base: http://kb.flex-radio.com/
> 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 Knowledge Base: http://kb.flex-radio.com/
FlexRadio Homepage: http://www.flex-radio.com/

[Flexradio] ERLINK-SR

[Bob Cowdery]

This project is still running and I hope to complete it to a reasonable
level of functionality this year. The direction is pretty much set in
stone now so it's very unlikely there will be any radical changes of
direction. I post updates on my web site (http://www.g3ukb.co.uk)
roughly every 2-4 weeks depending on what other commitments I have.
Generally speaking I don't announce updates but today I thought I would
be different!

73 de 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/

FlexRadio Knowledge Base: http://kb.flex-radio.com/

Re: [Flexradio] What do users really really want...

[Bob Cowdery]

Hi Sam

It's not a straight forward answer. You can participate in the alpha
program and that's a useful thing to do, look at the instructions on the
Flex download site. This is more about individual efforts though. When
announcements are made, and they usually make it to this list as well as
others, go look, try it out if there is something offered you think you
can manage, and comment. The comment bit is important. Looking at the
fringe efforts and having an opinion will influence what Flex do in
their next generation architecture.

Bob 

On Wed, 2007-01-03 at 11:25 -0500, Samuel W. Cartinhour wrote:
> Hi,
> 
> I was interested in your recent post to the Flex list, specifically
> 
> > I would ask all the users out there, get involved, look at what's being
> > done. Make the effort to try things out and provide feedback, shape the
> > future because sure as hell it won't shape itself or if it does you
> > can't complain it wasn't what you thought it should be.
> 
> I'd like to participate but I'm not sure how one goes about obtaining the
> latest versions that are being actively discussed such as "V1.9.0 (803)".
> I'm a very new Flex user however and I may have simply missed the obvious.
> 
> Sincerely,
> 
> Sam Cartinhour W2SNX
> 
> 
> 


___
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 Knowledge Base: http://kb.flex-radio.com/

[Flexradio] What do users really really want...

[Bob Cowdery]

The Linux/Windows/WHY threads have been an interesting read.
Degeneration has now set in so how about a round up.

At the risk of stating the blindingly obvious:

- Users like Windows and would be very disgruntled if forced to move.
- Users hate Windows and want everyone to move to Linux.
- Users use both and get the best of what they have to offer.
- Users want an open SDR that runs on everything the same so they can
play.
- Users want the best implementation that runs on their favourite OS.
- Users want an appliance and don't give a stuff what OS is underneath.
- Users want the backend an appliance but want the front end on their
favourite OS.
- Users want a web front-end.
- Users want to run one radio type.
- Users want to run all SDR hardware out there and not out there yet.

- Developers like Linux for it's elegance and architecture and promote
it as a much better platform for the SDR.
- Developers like Windows for Visual Studio.
- Developers want the best SDR on their favourite OS.
- Developers want a cross-platform SDR.
- Developers want an embedded SDR.
- Developers want to support a specific SDR hardware.
- Developers want an architecture to support all SDR hardware. 
etc etc.

We have a diverse mix of users and a diverse mix of software and
hardware. We have a diverse mix of developers who have personal agendas,
community agendas or a mix of both. As Frank put it there are lots of
crumbs out there, possibly enough crumbs to make a cake if they were put
together.

Here's the conundrum. Although users seem to want a lot of the crumbs
being developed there is almost zero interaction between developers and
users and while that continues the fragmentation will stay. In the end
maybe these fragments will deliver some fully functional
implementations, or maybe those developers that are less self motivated
will give up through lack of interest. 

I would ask all the users out there, get involved, look at what's being
done. Make the effort to try things out and provide feedback, shape the
future because sure as hell it won't shape itself or if it does you
can't complain it wasn't what you thought it should be.

73 de 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

[Flexradio] ERLINK-SR

[Bob Cowdery]

Hope everyone had a Happy Christmas.

For those who don't monitor the HPSDR list this is a quick note to say
that a major update is available at http://www.g3ukb.co.uk for the
erlink-sr project. 

73 de 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] An Important Announcement from FlexRadio Systems

[Bob Cowdery]

Congratulations Ken! You are one of the good guys who seems to make time
for everyone and everything. As we all know time is the most valuable
commodity we have to give. I am sure you will be a great asset to Flex.

Bob

On Fri, 2006-12-15 at 14:16 -0600, John Basilotto wrote:
> We are pleased to announce that Ken Hopper, N9VV, has joined the FlexRadio
> Systems staff as a support associate.  Ken has been a strong supporter of
> software defined radio.  Many will recognize Ken as one of the leaders of
> Team Speak and an active participant of the HPSDR group. Ken will be our
> front line contact for support matters. Ken will be a great asset to our
> customers as our business continues to increase and the prospect that 2007
> will be even a busier year.  Please give Ken a warm welcome as a member of
> the FRS team.
> 
> Our phones have been realigned to accommodate the staffing changes.
> 
> Sales (512) 535-5266
> Support (512) 250-8595
> Shipping/Receiving (512) 535-4713
> Repairs  (512) 535-4713
> 
> 
> 
> 
> 
> John P. Basilotto
> W5GI
> Marketing and Product Manager
> FlexRadio Systems
> 7
> 
> 
> 
> ___
> 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] ERLINK-SR

[Bob Cowdery]

The ERLINK-SR software is now posted at
http://myweb.tiscali.co.uk/g3ukb/ . The site is also updated with more
information. I stress this is early alpha. From previous experience I
know there will be a number of deployment issues and a fair bit of
required knowledge that I probably have omitted from the site. The only
way this gets fixed is of course from feedback.

I am about to move my ISP as the service I am getting is dreadful. That
means email and web addresses will change in the near future and the
site will probably be off-line for a while.

73
de
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] Q for software team (Was: PowerSDR Open Source Fan)

[Bob Cowdery]

On Thu, 2006-10-19 at 09:52 -0400, Robert McGwier wrote:
> Bob Cowdery wrote:
> > On Wed, 2006-10-18 at 19:20 -0500, KE5EUP wrote:
> >
> >   
> >>>> I'd like to have:
> >>>>
> >>>> 1. A platform independent GUI.
> >>>> 2. An IDE that makes GUI development "nice" (i.e. NOT VC6 style).
> >>>>
> >>>> 
> > I think one should consider in all this the push into distribution with
> > Erlang which frees up each node to be in the appropriate language for
> > the appropriate platform. One size fits all is no longer a limiting
> > factor. The GUI layer 'should' be thin and easily redeveloped in
> > multiple guises.
> >
> > 73 de Bob
> >   
> Amen.
> 

This was a somewhat throw-away remark at the time which I didn't
substantiate and no one challenged. I know people have been interested
in the past in easier ways of getting involved and in general that means
high level dynamic languages which are interactive and hide away that
edit/compile/run cycle. This is a back-to-the-future moment where I can
leverage what went before into the erlink-sr system. If you missed it or
thought the earlier post irrelevant there is an intro at
http://myweb.tiscali.co.uk/g3ukb/ . 

I effectively have a UI API which I can package up quite easily into a
library that can be used from Squeak and Python. I do believe in using
the best language for the job and... 

- Erlang is wonderful for the infrastructure. 
- C is undoubtedly the best for DSP and arguable HW Control.
- C with GTK+ is good for a high performance GUI.
- Python is good for those quick automated processes and pieces of GUI
in GTK+ or wxWindows.
- Squeak Smalltalk is a great scripting environment and general
playground.

In effect Python and Squeak will be able to connect and play as erlang
nodes against an API that will be exposed in their own language. For
those who played with Squeak before there is 3.9 out which is a huge
improvement in look and feel, less like a toy shop and more like a
professional piece of work.

I plan to work over the next few weeks on some shortcomings in the
framework and on the Squeak plug-in adaptor (Python will come later).

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] erlink-sr (was Erlang, my second steps)

[Bob Cowdery]

The builds are now sorted and tested on both XP and Ubuntu. I have put
some preliminary information up on my web site
( http://myweb.tiscali.co.uk/g3ukb ). I am having real trouble with my
ISP at the moment and can't even view the site properly but I trust it's
all up there! There is a pretty non-technical overview as well as some
techi stuff.

73
Bob
G3UKB 

On Tue, 2006-10-17 at 21:56 +0100, Bob Cowdery wrote:
> Just a quick update. Things are not moving along as fast as I would like
> but the day job is getting really busy right now. I kind of have a local
> SVN repository in the right shape and now have a build on Windows as
> well as Linux. I spent a long time agonising over what build process to
> use. In the end the Windows build is all under Visual C++ Express and
> for Erlang I am using Eclipse with the Erlang plug-in which works pretty
> well. On Linux I am using Anjuta for the C++ and again Eclipse for
> Erlang.
> 
> Right now I am running the thin UI on my XP laptop and the back-end
> which is everything else on my main Ubuntu box as that has the sound
> card. When I say everything else that includes the Erlang hub, my state
> machine and the dsp and control. I'm please to say it's just as
> responsive across two machines as on the same machine.
> 
> I have a deal of consolidation to do to clean up the two builds and SVN
> and then rejig my website before I get back to stuffing more function
> in.
> 
> 73
> Bob
> G3UKB
> 
> On Sun, 2006-10-01 at 09:55 +0100, Bob Cowdery wrote:
> > On Sat, 2006-09-30 at 19:55 -0400, Frank Brickle wrote: 
> > > Sigh. Once again, G3UKB laps the field.
> > > 
> > > Is it getting a little lonely out there, being so far ahead of pack?
> > > 
> > > :-)
> > > 
> > > Very fine work, Bob.
> > > 
> > I don't feel ahead of the pack in most respects. Hopefully, everything
> > that goes into the mix like the stunning HPSDR work moves the game
> > forward a little and evolution takes over.
> >  
> > On Sun, 2006-10-01 at 11:29 +0800, Phil Harman wrote: 
> > > Hi Bob,
> > > 
> > > Thanks for your post. I'm a hardware guy, but I'm excited because your 
> > > excited. I only understand 1% of what you write on the subject - but I'm 
> > > still excited!
> > > 
> > > Some day I'd really like to write up your work in my RadCom SDR column. 
> > > But 
> > > first I have to understand it so I can explain it to others.
> > > 
> > The forward plan is to get all my source properly organised under SVN,
> > probably locally for now. I want to be able to build for Windows and
> > Linux. Re-jig my web site so it reflects what I am doing, a few pictures
> > will help a lot to show what goes on. Then a few bugs to fix and a few
> > enhancements such that everything I have on the screen actually works
> > (like my pan sliders and offset frequency controls for the sub-receivers
> > don't work yet). Then I will publish the code either as a package or
> > make the SVN public. It should be straight forward to install and run.
> > If you can run it up that's obviously the best way to understand how
> > it's put together. Good work on the column, I always read it and it's
> > always informative.
> > 
> > > Again, very exciting, and I hope the penny drops here real soon!
> > > 
> > > 73's Phil...VK6APH
> > 
> > On Sun, 2006-10-01 at 00:15 -0700, Paul Shaffer wrote: 
> > > There is a project at http://jungerl.sourceforge.net/ called otp.net. 
> > > It's a port of the
> > > jinterface java code to c#. I tried it out, and there were several bugs 
> > > and at least 
> > > one unfinished method. I updated it for the latest version of erlang and 
> > > sent the
> > > new code to the project owner. He checked my changes into cvs. So if you 
> > > want
> > > a c# node you could start with that, even if it's just for a piece of the 
> > > UI for windows.
> > > I don't think anyone uses Erlang with .net.
> > > 
> > This is the beauty of course, you can write plug-ins in your favourite
> > language. Essentially any language that can talk to C can be done so you
> > can either roll your own or use one someone made earlier. I would tend
> > to use my C code that interfaces to Erlang and just wrap that with a C#
> > interface so I only have one codeline to support. I will certainly have
> > a look at this stuff though. I'm glad to see you are getting into this.
> > I think there is huge mileage in it.

Re: [Flexradio] Q for software team (Was: PowerSDR Open Source Fan)

[Bob Cowdery]

On Wed, 2006-10-18 at 19:20 -0500, KE5EUP wrote:

> >> I'd like to have:
> >>
> >> 1. A platform independent GUI.
> >> 2. An IDE that makes GUI development "nice" (i.e. NOT VC6 style).
> >>
I think one should consider in all this the push into distribution with
Erlang which frees up each node to be in the appropriate language for
the appropriate platform. One size fits all is no longer a limiting
factor. The GUI layer 'should' be thin and easily redeveloped in
multiple guises.

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
> >
> >
> >   
> 
> ___
> 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] Q for software team (Was: PowerSDR Open Source Fan)

[Bob Cowdery]

On Wed, 2006-10-18 at 16:02 -0500, Eric Wachsmann wrote:
> Not necessarily.  I would prefer to have a cross platform solution.  I have
> not evaluated Eclipse yet, but it sounds like it could be an alternative.
> 
A cross-platform solution does not necessarily need a cross-platform IDE
although of course that would be nice if there was such a thing. Eclipse
is very good for Java which was its original target being Java itself.
It's a little lack-luster on everything else. I've settled for just
doing different builds on each platform with the best IDE for the
platform. VS is very good at staying completely out the way by letting
you put all the files exactly where you want so not polluting the source
tree, others are not so good at that or I haven't found how yet.

Bob
> 
> Eric Wachsmann
> FlexRadio Systems
> 
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > radio.biz] On Behalf Of Philip Covington
> > Sent: Wednesday, October 18, 2006 3:44 PM
> > To: [EMAIL PROTECTED]
> > Cc: FlexList
> > Subject: Re: [Flexradio] Q for software team (Was: PowerSDR Open Source
> > Fan)
> > 
> ...Sounds like the plan is the Console will stay in C#
> > though, using WinForms and .NET 2.
> 

___
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] Q for software team (Was: PowerSDR Open Source Fan)

[Bob Cowdery]

On Wed, 2006-10-18 at 13:20 -0400, Philip Covington wrote:
> On 10/18/06, James Courtier-Dutton <[EMAIL PROTECTED]> wrote:
> > > Eric wrote on 10/10/06
> > >
> > > "We ARE NOT planning on using the same tools for the future versions of
> > > the software.  Rather, we will use FREE TOOLS.  We have not settled 100%
> > > on what those free tools will be, but right Visual Studio 2005 Express
> > > versions are looking to be the best pick for the windows GUI.  Obviously
> > > we'd like to have a cross platform GUI, but have yet to find a set of
> > > libraries/tools that rival the ease-of-use and efficiency of Visual
> > > Studio's tools."
> > >
> > >
> >
> > Which tools were looked at?
> > It would be nice if the PowerSDR gui could be built in eclipse.
> > One could then look at running the PowerSDR gui on Linux.
> > I believe the PowerSDR gui is written in C#.
> > Linux can run C# programs in something called "mono".
> > dttsp already works in Linux. What else is needed to get PowerSDR gui
> > working in both Windows and Linux?
> >
> > James
> 
> System.Windows.Forms in Mono is still pretty much crap.  It would be
> better to use GTK# on both Windows and Linux in Mono.  If you don't
> want to stay in C#, then of course there is wxWindows, Qt, etc...
> etc... though there may be development still going on in wx.NET.
> 
I've settled for using GTK+ on both Windows and Linux. Glade is a really
nice GUI builder and the only one I've found where it's effortless to
create resizable everythings and the only builder where I have been able
to cut and paste whole chunks of interface between containers and
windows without it throwing up it's hands in horror. It's also very
cross platform. I compile it with Express on Windows without trouble.

73 de Bob 

> 73 de Phil N8VB
> 
> ___
> 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] Erlang, my second steps (was my first steps)

[Bob Cowdery]

Just a quick update. Things are not moving along as fast as I would like
but the day job is getting really busy right now. I kind of have a local
SVN repository in the right shape and now have a build on Windows as
well as Linux. I spent a long time agonising over what build process to
use. In the end the Windows build is all under Visual C++ Express and
for Erlang I am using Eclipse with the Erlang plug-in which works pretty
well. On Linux I am using Anjuta for the C++ and again Eclipse for
Erlang.

Right now I am running the thin UI on my XP laptop and the back-end
which is everything else on my main Ubuntu box as that has the sound
card. When I say everything else that includes the Erlang hub, my state
machine and the dsp and control. I'm please to say it's just as
responsive across two machines as on the same machine.

I have a deal of consolidation to do to clean up the two builds and SVN
and then rejig my website before I get back to stuffing more function
in.

73
Bob
G3UKB

On Sun, 2006-10-01 at 09:55 +0100, Bob Cowdery wrote:
> On Sat, 2006-09-30 at 19:55 -0400, Frank Brickle wrote: 
> > Sigh. Once again, G3UKB laps the field.
> > 
> > Is it getting a little lonely out there, being so far ahead of pack?
> > 
> > :-)
> > 
> > Very fine work, Bob.
> > 
> I don't feel ahead of the pack in most respects. Hopefully, everything
> that goes into the mix like the stunning HPSDR work moves the game
> forward a little and evolution takes over.
>  
> On Sun, 2006-10-01 at 11:29 +0800, Phil Harman wrote: 
> > Hi Bob,
> > 
> > Thanks for your post. I'm a hardware guy, but I'm excited because your 
> > excited. I only understand 1% of what you write on the subject - but I'm 
> > still excited!
> > 
> > Some day I'd really like to write up your work in my RadCom SDR column. But 
> > first I have to understand it so I can explain it to others.
> > 
> The forward plan is to get all my source properly organised under SVN,
> probably locally for now. I want to be able to build for Windows and
> Linux. Re-jig my web site so it reflects what I am doing, a few pictures
> will help a lot to show what goes on. Then a few bugs to fix and a few
> enhancements such that everything I have on the screen actually works
> (like my pan sliders and offset frequency controls for the sub-receivers
> don't work yet). Then I will publish the code either as a package or
> make the SVN public. It should be straight forward to install and run.
> If you can run it up that's obviously the best way to understand how
> it's put together. Good work on the column, I always read it and it's
> always informative.
> 
> > Again, very exciting, and I hope the penny drops here real soon!
> > 
> > 73's Phil...VK6APH
> 
> On Sun, 2006-10-01 at 00:15 -0700, Paul Shaffer wrote: 
> > There is a project at http://jungerl.sourceforge.net/ called otp.net. It's 
> > a port of the
> > jinterface java code to c#. I tried it out, and there were several bugs and 
> > at least 
> > one unfinished method. I updated it for the latest version of erlang and 
> > sent the
> > new code to the project owner. He checked my changes into cvs. So if you 
> > want
> > a c# node you could start with that, even if it's just for a piece of the 
> > UI for windows.
> > I don't think anyone uses Erlang with .net.
> > 
> This is the beauty of course, you can write plug-ins in your favourite
> language. Essentially any language that can talk to C can be done so you
> can either roll your own or use one someone made earlier. I would tend
> to use my C code that interfaces to Erlang and just wrap that with a C#
> interface so I only have one codeline to support. I will certainly have
> a look at this stuff though. I'm glad to see you are getting into this.
> I think there is huge mileage in it.
> > 
> > Erlang seemed so obtuse for a quick learn that I had to get back to my real 
> > work. I would like to see some Erlang code that actually did anything 
> > interesting
> > for a radio. 
> > 
> When I publish the code you will see first attempts at this language. I
> will do a simple scripting node as well which should be more informative
> than the switcher. I will probably look back on this code in a while and
> wonder what I was on! The one thing I found quite difficult and fell
> over the same issue several time was immutable variables. I couldn't
> figure how to hold the state of variables that were changing like
> dictionaries and lists that I was modifying. I found the Erlang list
> very helpful for these things.
>  
> > I think the concept of nodes i

Re: [Flexradio] Erlang, my first steps

[Bob Cowdery]

On Sat, 2006-09-30 at 19:55 -0400, Frank Brickle wrote: 
> Sigh. Once again, G3UKB laps the field.
> 
> Is it getting a little lonely out there, being so far ahead of pack?
> 
> :-)
> 
> Very fine work, Bob.
> 
I don't feel ahead of the pack in most respects. Hopefully, everything
that goes into the mix like the stunning HPSDR work moves the game
forward a little and evolution takes over.
 
On Sun, 2006-10-01 at 11:29 +0800, Phil Harman wrote: 
> Hi Bob,
> 
> Thanks for your post. I'm a hardware guy, but I'm excited because your 
> excited. I only understand 1% of what you write on the subject - but I'm 
> still excited!
> 
> Some day I'd really like to write up your work in my RadCom SDR column. But 
> first I have to understand it so I can explain it to others.
> 
The forward plan is to get all my source properly organised under SVN,
probably locally for now. I want to be able to build for Windows and
Linux. Re-jig my web site so it reflects what I am doing, a few pictures
will help a lot to show what goes on. Then a few bugs to fix and a few
enhancements such that everything I have on the screen actually works
(like my pan sliders and offset frequency controls for the sub-receivers
don't work yet). Then I will publish the code either as a package or
make the SVN public. It should be straight forward to install and run.
If you can run it up that's obviously the best way to understand how
it's put together. Good work on the column, I always read it and it's
always informative.

> Again, very exciting, and I hope the penny drops here real soon!
> 
> 73's Phil...VK6APH

On Sun, 2006-10-01 at 00:15 -0700, Paul Shaffer wrote: 
> There is a project at http://jungerl.sourceforge.net/ called otp.net. It's a 
> port of the
> jinterface java code to c#. I tried it out, and there were several bugs and 
> at least 
> one unfinished method. I updated it for the latest version of erlang and sent 
> the
> new code to the project owner. He checked my changes into cvs. So if you want
> a c# node you could start with that, even if it's just for a piece of the UI 
> for windows.
> I don't think anyone uses Erlang with .net.
> 
This is the beauty of course, you can write plug-ins in your favourite
language. Essentially any language that can talk to C can be done so you
can either roll your own or use one someone made earlier. I would tend
to use my C code that interfaces to Erlang and just wrap that with a C#
interface so I only have one codeline to support. I will certainly have
a look at this stuff though. I'm glad to see you are getting into this.
I think there is huge mileage in it.
> 
> Erlang seemed so obtuse for a quick learn that I had to get back to my real 
> work. I would like to see some Erlang code that actually did anything 
> interesting
> for a radio. 
> 
When I publish the code you will see first attempts at this language. I
will do a simple scripting node as well which should be more informative
than the switcher. I will probably look back on this code in a while and
wonder what I was on! The one thing I found quite difficult and fell
over the same issue several time was immutable variables. I couldn't
figure how to hold the state of variables that were changing like
dictionaries and lists that I was modifying. I found the Erlang list
very helpful for these things.
 
> I think the concept of nodes is excellent. I suppose it's been around 
> forever, but if
> you are stuck with the com+, web services, service oriented architecture, 
> interop
> (and so forth) blinders on, it's like a breath of fresh air. The clarity of 
> the nodes idea seems 
> inversely proportional to the readability of Erlang itself. Erlang code could 
> use 
> descriptive variable names, lots of comments, but it seems to be used by real 
> programmers who like it tough looking. I think some of the recommended coding
> conventions for c# deserve consideration.
> 
Yes, the idea's been around a long time. Some 20 years ago I was
involved in a large message switch for BT. It was a totally resilient,
self-healing system that internally used a monitor to startup the system
and restart failed processes. Processes registered with a central
registry and communicated by messages. This of course was completely in
C but the ideas stuck and I've reused the pattern several times. 

I think you will always get some very bright people writing things which
are barely recognisable as language X or Y. I try to write my code
simple and straight forward whatever the language. If I don't, I will
struggle to read it in a month or a years time.

> [How do you keep your lines wrapped on this mailing list? i can't even figure 
> that
> out.]
If you are using Outlook then I didn't figure it either. I use Linux for
my mail now. 

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

Re: [Flexradio] Erlang, my first steps

[Bob Cowdery]

Well it's been a while but - now I'm having fun - although the last
month has been a roller-coaster ride. Many times, sometimes more than
once in the same day giving up seemed a really good option, then a small
breakthrough would spur me on a little further. I don't know how much
time I have spent on this because I do have a day job but I suspect more
time than I should have.

I'm not going to make this technical. I will do a writeup later and post
it on my web site. Suffice it to say I am sitting here listening to my
Erlang distributed radio. It's not quite the architecture I envisaged at
the start but I like it... rather a lot. It's running in 3 nodes, two
are pure C using the Erlang ei library and the other is native Erlang.
Node 1 is a thin GTK+ UI. Node 2 is the application implemented with a
state machine and Node 3, the Erlang node, I have called the switcher.
Node 1 is completely dumb, it sends events and receives updates, it
absolutely never does anything of it's own accord. Node 2 knows what to
do to implement an event. Node 3 knows how to route messages and is the
message switching hub. 

I didn't want a hub topology as I had peer-to-peer in mind but in the
end after failing on my initial design it looked the best way forward.
Having done it I think it separates out the 'what to do' (Node 2) and
the 'where to get it done' (Node 3) quite nicely. My real fear was
performance, longer message path and potential bottleneck. The
performance has literally astounded me. My acid test is running the
pointer over the tuning digits which grow when the cursor is over the
digit. I can't beat the system it's absolutely as responsive as it was
when it was all C in the same executable. All running on my 2.4GHz m/c
DSP takes 2% and the rest is not measurable. If I scroll frequency up
and down fast or run over the digits I can get the UI to take 2%. I'm
not sending display data right now and that will be the teller but
indications are it shouldn't be a problem.

Erlang is very stable, very fast and very concise. I'm well impressed.
My Erlang switcher is just over 50 lines of code. It's a start-up
monitor, a registry and a store and forward switch. It will cope with an
arbitrary number of nodes. In my books that's impressive in 50 lines.
Ok, it needs to grow up a bit, well, quite a lot but it does the job.

The thing that kept me going was the possibilities that kept popping
into my head that this would open up.

1. Obviously the hardware controller and DSP can be placed at C nodes.
Currently these are directly attached to the state machine. You can of
course have multiple of these as the switcher only need resolve who the
messages are for.
2. The UI can be distributed. There is no need for the UI to all run as
the same piece of code. Heck, the pieces don't even need to be the same
language or run on the same machine. There would be no overhead at all
in splitting the UI up.
3. A ready made plug-in architecture. A bit of boiler-plate code and
pieces of UI can be made as separate nodes (or anything else for that
matter). How about a scanner, a memory bank, a special display or tuning
control.
4. A prime candidate for a node is CAT. If the CAT sends change
frequency to the switcher, messages end up at the UI to update the
frequency and the controller to set the frequency because that's what
the state machine does when it gets that event.
5. Another prime candidate is a scripting node. This would let you write
small programs preferably in Erlang to run the radio for special
purposes. The infrastructure is there, the API is there because it's
that same set of events the state machine can respond to.
6. Easy to distribute across machines (of course). This is the next
thing I want to do.
7. Everything is potentially cross-platform. Next but one thing to try.
8. Can be expanded to spoke and hub topology to spread the switching
load should it become too high.

I do believe I'm going to stop playing infrastructure now and work on
function (no - really, this time). I've only scratched the surface of
Erlang so I'm looking forward to learning what it can really do. It is
still first steps but I'm walking a little faster. Thanks to Frank and
Bob for pointing things in this direction. I was sceptical, and to be
honest remained sceptical virtually until I had it working, always
expecting that stopper than would render everything useless. Happily
nearly all the problems were self-inflicted.

73
Bob
G3UKB

On Sat, 2006-09-02 at 16:18 -0400, Robert McGwier wrote:
> Bob Cowdery wrote:
> > On Sat, 2006-09-02 at 14:55 -0400, Robert McGwier wrote:
> >   
> >
> >> 
> > Unfortunately my work is much more mundane and radio is just a hobby. I
> > think a lot of the work you and Frank do is well beyond my understanding
> > but it is important 

Re: [Flexradio] Erlang, my first steps

[Bob Cowdery]

On Sat, 2006-09-02 at 14:55 -0400, Robert McGwier wrote:
> Bob Cowdery wrote:

> > I think there is a very strong clue here. The architecture is aimed at
> > supporting a radio factory. The major motivation to my mind therefore
> > comes from the idea of a virtual radio or radio kernel architecture to
> > support 10's or 100's of real and virtual radios. I have to question how
> > relevant this is to most people. Most of us have one radio and are
> > unlikely to have more.
> >   
> So this argument would seem to imply we should do the wrong thing for 2 
> radios just because most people have 1?  As soon as I got to two,  I saw 
> I need a better mousetrap.  The first time I started down the path of 
> building ONE virtual radio from several distributed pieces,  I needed a 
> better mousetrap.  The gist of the argument appears to be  "I do not 
> need XYZ to do the subset of the problem I am focusing at this time so I 
> will not attempt to find a globally best solution by applying a greedy 
> algorithm to decision making". However, let's take your  relevance 
> remark as primarily rhetorical (given what is written below) and say 
> this.  Erlang will cost us nothing in terms of performance on the one 
> radio set up.  The computational complexity of what is to be done here 
> in the switching station/application manager is not even worth 
> mentioning compared to painting the power spectrum on the GUI and is 
> much less than the DSP which is also less than painting the power 
> spectrum on the GUI.
I was merely pointing out that the motivation came from the need to run
potentially hundreds of radios. I am not saying you would have made a
different decision for one radio but that requirement clinched the deal.

> > Erlang is a good language, as a language; probably excellent as a
> > switching station and a composer of real hardware into virtual radios.
> > That part of the system is obviously going to be written in Erlang.
> >
>
> Correct.
> > However, is Erland a good language for DSP. I would say it's probably
> > too slow having tried to do DSP in Python. I am not talking from
> > definite experience here but my guess is DSP will stay in C although it
> > could have some orchestration from Erlang in the same way that GNU Radio
> > is orchestrated by Python.
> >   
> Correct.  It will be EXTREMELY hard to beat the basic performance of 
> DttSP in a high level language.  There are some hotspots that I know 
> require work (such as the agc code and all of the nonlinear functions in 
> it) but until somebody decides the GUI code needs serious replacement,  
> worrying about the agc code is nibbling at the edges and a waste of time.
> > Is Erlang a good language for a UI. From what I can glean, probably not.
> > It has no native toolkit and its bindings to C toolkits seem to be in
> > disrepair. My guess therefore is that people won't be writing UI's in
> > Erlang, they will continue to be in a variety of other languages. A
> > client library will have to be provided for UI's to connect to the
> > Erlang system. The library will need bindings to various languages. Some
> > such libraries already exist and might provide starting points.
> >   
> I do not want to touch a GUI until it is written.  Since I won't be 
> writing it but Eric,  John,  Edson, et. al. will be,  they can write it 
> in machine language  for all I care.
Some of us do care.

> > Is it a good language for HW control. It's probably as good as any
> > other. The task is not processor intensive and has been done in at least
> > C, C#, Python and Squeak. My guess however is that it will stay in C as
> > the main implementation.
> >
> >   
> I have no intention at this time on replacing the C/C++ code for 
> hardware control.  I need to FINISH the hardware control for the Linux 
> world so they can transmit!
> 
> > The net result is that there is at worst one native Erlang node which is
> > the virtual radio (that function itself could of course be distributed,
> > but essentially one node). Only that node can take full advantage of
> > Erlang the language, the rest are just using it as a transport.
> >   
> Correct.
> > I think the world according to most people is GUI and DSP although I
> > still maintain the Console is really a number of functions, only one of
> > which is the GUI. These other functions e.g application logic, model,
> > CAT are potential candidates for being native Erlang nodes. That does
> > require that the vast majority of what's in the PowerSDR Console is
> > rewritten in Erlang. I've not heard anybody say th

Re: [Flexradio] Erlang, my first steps

[Bob Cowdery]

This thread has got broken into so many fragments I can't find a
suitable message to reply to so I'm going to try and recompose my
thoughts here.

I don't feel my fundamental issues got answered so I have drawn my own
conclusions. I'm pleased it provoked some discussion. My intention is
simply to understand the motivation and where it's come from.


> Lightweight threads aka processes. I don't think we are running
massive
> numbers of threads and threads are not particularly difficult in most
> modern languages.

Frank Brickle wrote:
Not so. We are talking about hundreds and potentially thousands of
threads. Remember that we're talking about an environment that can
support 2^N simultaneous radios on one processor, where is easily 6 or
7. This is not speculation. It's happening right now with DttSP,
although not on an SDR-1000.


I think there is a very strong clue here. The architecture is aimed at
supporting a radio factory. The major motivation to my mind therefore
comes from the idea of a virtual radio or radio kernel architecture to
support 10's or 100's of real and virtual radios. I have to question how
relevant this is to most people. Most of us have one radio and are
unlikely to have more.

Erlang is a good language, as a language; probably excellent as a
switching station and a composer of real hardware into virtual radios.
That part of the system is obviously going to be written in Erlang.

However, is Erland a good language for DSP. I would say it's probably
too slow having tried to do DSP in Python. I am not talking from
definite experience here but my guess is DSP will stay in C although it
could have some orchestration from Erlang in the same way that GNU Radio
is orchestrated by Python.

Is Erlang a good language for a UI. From what I can glean, probably not.
It has no native toolkit and its bindings to C toolkits seem to be in
disrepair. My guess therefore is that people won't be writing UI's in
Erlang, they will continue to be in a variety of other languages. A
client library will have to be provided for UI's to connect to the
Erlang system. The library will need bindings to various languages. Some
such libraries already exist and might provide starting points.

Is it a good language for HW control. It's probably as good as any
other. The task is not processor intensive and has been done in at least
C, C#, Python and Squeak. My guess however is that it will stay in C as
the main implementation.

The net result is that there is at worst one native Erlang node which is
the virtual radio (that function itself could of course be distributed,
but essentially one node). Only that node can take full advantage of
Erlang the language, the rest are just using it as a transport.

I think the world according to most people is GUI and DSP although I
still maintain the Console is really a number of functions, only one of
which is the GUI. These other functions e.g application logic, model,
CAT are potential candidates for being native Erlang nodes. That does
require that the vast majority of what's in the PowerSDR Console is
rewritten in Erlang. I've not heard anybody say that is part of the
plan.

Conclusions
---
You might think that I will come out strongly against Erlang. In fact I
am now fairly convinced it is an appropriate route, but I had to come to
that conclusion myself rather than accept the arguments I was given,
none of which I found very convincing. Maybe I misheard, didn't want to
hear or just got lost in the mathematical purity and jargon of the
solution. These are my reasons, please feel free to add/subtract
according to taste.

1. Erlang is a very mature language and should be low risk in terms of
robustness. Yes, it will break if you hit it hard enough, everything has
its breaking point.
2. It makes concurrency and communication trivial to implement and it
does it with style. I have to caveat this by saying that's only really
true if you stay in the language so part of the plan must be to do as
much as possible in the language and build robust easy to use bridges to
those parts that cannot be in Erlang.
3. Part of my plan long term would be to build everything possible from
the GUI layer as Erlang native nodes and just leave the thinest possible
UI with a multi-language binding to a client library into Erlang.
4. The Virtual Radio concept is to me much more about abstracting the
radio (DSP, HW and potentially other control elements of a radio) to a
common interface irrespective of platform or distribution than it is to
providing a switching centre for multiple radios. It brings a common
interface to all platforms which is something I have long wanted. The
language choice probably makes it no simpler or harder for one radio but
if talking 100's then it's a good choice. The VR for one radio is not
complex so I will probably roll my own.
5. I leave performance as an outstanding issue. Nodes are separate
execution environments, operating system processes if you like.
Communication b

Re: [Flexradio] Erlang, my first steps

[Bob Cowdery]

Let me play devils advocate for a moment. I have to say I am still
pondering Erlang as a platform. What I am wondering is what features of
Erlang are desirable or necessary for the task in hand. Several things
strike me. 

Its a functional programming language, which is a style that takes a
little getting used to. I don't think my brain really works well with
it. I'm not good with XSLT which people might not think of as a
functional language but actually is. You can do functional styles in
other languages, Python has all the pieces for example but isn't so
elegant and doesn't force that style. I don't know what advantage is
gained from an FP language (in this environment). Unless large portions
are going to be rewritten in Erlang, just using it to connect processes
in other languages seems a waste and actually not very straight forward.
Could there be plans to dissect the DSP and run it as multiple
concurrent processes, now that could make sense. 

Lightweight threads aka processes. I don't think we are running massive
numbers of threads and threads are not particularly difficult in most
modern languages.

Message passing. It's one way for processes to talk but may not be
appropriate in all cases. It's easy in Erlang and because it's an FP
language (no side effects) the threads are isolated, so Erlang calls
them processes. A messaging layer is not difficult to add and most
modern languages already have one or more messaging options.

Distribution, well lots of ways to do it. Sockets of course underlie
them all. Python has Pyro which is very simple to use and I've done
massive transfers for long periods of time so I know its robust.

My options at the moment are Erlang, Python, Ruby - all of which require
some glue code at each non native node (and I recon at the moment that's
all of them) and my original plan of plain sockets and JSON which
requires no glue code as everybody can do sockets and everybody can
encode/decode JSON. I think they are all a similar amount of work
strangely enough.

73
Bob
G3UKB

On Fri, 2006-09-01 at 16:37 -0400, Frank Brickle wrote:
> It works just fine here.
> 
> You have to start up 2 instances of erlang. Here's how I do it under
> cygwin.
> 
> (1) Start up 1 instance like this:
>   werl -sname pong
> then compile the tutorial
> c(tut17).
> and run it
> tut17:start_pong().
> (2) Start up the other instance:
> werl -sname ping
> and then run
> tut17([EMAIL PROTECTED]).
> where 'ab2kt' is the hostname of my Windows machine. [You can find that
> out by running
> node().
> on the machine in question.]
> 
> It runs perfectly on an HP laptop using XP SP2.
> 
> What's the issue?
> 
> 73
> Frank
> AB2KT
> 
> On Fri, 2006-09-01 at 19:47 +0100, Bob Cowdery wrote:
> > Thanks for that. I will certainly check it out before I dive into the
> > real thing. I would have thought that the guys would have checked that
> > out pretty early on...but then no one has popped up to say it does work,
> > so maybe not. There really shouldn't be an issue but then this is
> > software, anything can happen.
> > 
> > Bob
> > 
> > On Fri, 2006-09-01 at 07:18 -0500, Cecilio Bayona wrote:
> > > Paul Shaffer wrote:
> > > >> Were you having problems with getting a program that works with Linux 
> > > >> Erlang to work in Windows?
> > > > 
> > > > =
> > > > It's all just for fun of course.
> > > > I was just going through the distributed erlang samples getting each 
> > > > one to work. Then I hit a brick wall with distributed nodes. Nodes
> > > > will not communicate on my Windows system. This appears to 
> > > > be a problem others have had, and there's no solution so far. A couple
> > > > of erlang people have tried to help, but they don't run Windows so their
> > > > help can only go so far. Try to open 2 nodes on an XP system for 
> > > > example and try to ping one from the console of the other. Should
> > > > be a piece of cake. I've checked everything I could think of: firewall, 
> > > > cookies, etc.
> > > > 
> > > > 
> > > SNIP
> > > > 
> > > Ah, did you notice if the bricks had a slice of lemon on them? Sorry, 
> > > too early, I couldn't help myself.
> > > 
> > > In "theory" it should all work the same, it uses IP sockets to 
> > > communicate between processes, so it should work with one PC, multiple 
> > > PC's, or multiple OS's. In theory that is. Theory says that theory and 
> > > practice s

Re: [Flexradio] Erlang, my first steps

[Bob Cowdery]

Thanks for that. I will certainly check it out before I dive into the
real thing. I would have thought that the guys would have checked that
out pretty early on...but then no one has popped up to say it does work,
so maybe not. There really shouldn't be an issue but then this is
software, anything can happen.

Bob

On Fri, 2006-09-01 at 07:18 -0500, Cecilio Bayona wrote:
> Paul Shaffer wrote:
> >> Were you having problems with getting a program that works with Linux 
> >> Erlang to work in Windows?
> > 
> > =
> > It's all just for fun of course.
> > I was just going through the distributed erlang samples getting each 
> > one to work. Then I hit a brick wall with distributed nodes. Nodes
> > will not communicate on my Windows system. This appears to 
> > be a problem others have had, and there's no solution so far. A couple
> > of erlang people have tried to help, but they don't run Windows so their
> > help can only go so far. Try to open 2 nodes on an XP system for 
> > example and try to ping one from the console of the other. Should
> > be a piece of cake. I've checked everything I could think of: firewall, 
> > cookies, etc.
> > 
> > 
> SNIP
> > 
> Ah, did you notice if the bricks had a slice of lemon on them? Sorry, 
> too early, I couldn't help myself.
> 
> In "theory" it should all work the same, it uses IP sockets to 
> communicate between processes, so it should work with one PC, multiple 
> PC's, or multiple OS's. In theory that is. Theory says that theory and 
> practice should be the same, practice however tells you otherwise.
> 
> I'm hoping to get to try out some of the sample programs this long 
> weekend, but I have a lot of stuff on my plate.
> 
> I'm surprised that they are not looking at Lisp as the glue to the 
> pieces, well maybe they are and haven't told us. It's so incredibly 
> capable, and not just in concurrent process.
> 

___
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] Erlang, my first steps

[Bob Cowdery]

I don't know who is playing with Erlang but in case there are any hints
or tips on how to play here's what I plan. It's taken me a while to feel
comfortable enough to commit something to code. 

My current toys consist of a GTK+ thin front end loosely coupled to a
state machine that executes all the application logic. The state machine
calls out to a Python script that manages the Linux environment, DSP and
Controller as well as back to the front end to execute updates. I plan
to split this into two builds. The first will be the front end and this
will be built as an Erlang C Node. It will support two threads for
outgoing and incoming messages. Outgoing are simple events from the GUI,
incoming are update messages for the GUI. The second build, which at the
moment is everything else will be built on the back of an Erlang port
driver. This will have at least two Erlang processes in correspondence
with the front end.

This is by way of a test bed. It's as simple as I can think of making it
and supports the fact that the GUI is an executable process and the rest
can be built as a shared library. If it works good, and I suspect it
will, the next steps will be a lot easier. I expect this first step to
be quite challenging.

Let the fun begin...

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

[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

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
> 
> <http://www.erlang.org/user.html>

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 hard

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

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?

[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 dea

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?

[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

[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

[Flexradio] Testing again

[Bob Cowdery]

___
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] Strange hardware behaviour

[Bob Cowdery]

Well, it's been an interesting day. We had a blockage in the bathroom
which involved dismantling a fair bit to get at the pipe run. It was hot
today as its been for several weeks, hitting 30 plus so maybe it was the
heat but while doing this boring mucky task I decided to dual boot my
main machine with Ubuntu to make sure the problem was a software one as
it was looking increasingly like hardware...

I knew it would break stuff but I hit the buttons anyway and sure enough
my dual boot machine turned out to be a half boot machine. It would half
boot Windows and then reboot ad-infinitum. Oh , I just knew it had
trashed my RAID array and only written to one of the discs. I pulled the
power from one disc and sure enough I had a dual boot machine on one
disc. Not sure I'm brave enough to try and rebuild the other half just
yet.

Having got the new Ubuntu up to scratch and installed my software it
works fine. I guess my parallel port on my other box is not up to the
job.

Bob

 
On Fri, 2006-07-21 at 09:18 -0700, Jim Lux wrote:
> At 07:35 AM 7/21/2006, FlexRadio - Eric wrote:
> >This is characteristic of the DDS dropping out.
> 
> And, what Eric forgot to mention, often from the DDS overheating...
> 
> 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

[Flexradio] Strange hardware behaviour

[Bob Cowdery]

Does anyone know what initial conditions set on the SDR1000 hardware
would cause a pulsating noise (around 2 seconds cycle) associated with a
current drop from the normal 1 amp to something much less. I have seen
this occasionally on XP but starting things up again always seemed to
fix it. I now have it solidly on some Linux stuff i am doing in spite of
using the exact same controller code (bar the driver). This even
persists if I pull out the parallel connector. No relays click during
the power drop. I just have the 3 board stack by the way.

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

[Flexradio] Test

[Bob Cowdery]

Please ignore.

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

[Bob . Cowdery]

As it nears the next release I have posted some preview information at
http://myweb.tiscali.co.uk/g3ukb/preview.htm
 .

 

Enjoy.

 

73 de Bob


*** Confidentiality Notice *** Proprietary/Confidential
Information belonging to CGI Group Inc. and its affiliates
may be contained in this message. If you are not a recipient
indicated or intended in this message (or responsible for
delivery of this message to such person), or you think for
any reason that this message may have been addressed to you
in error, you may not use or copy or deliver this message
to anyone else.  In such case, you should destroy this
message and are asked to notify the sender by reply email.
-- next part --
An HTML attachment was scrubbed...
URL: 
/pipermail/flexradio_flex-radio.biz/attachments/20060601/2577b24f/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] FW: SDR-Breadboard

[Bob . Cowdery]

The points Mark raises may be useful to others with the same feeling that
they just bounced off the surface because the assumed knowledge was too
high.

73 de Bob (G3UKB)

-- 


Bob,

No, I don't mind at all - I just didn't feel qualified to judge if it was
appropriate for the list.

I'll definitely take another, deeper look.  

Incidentally, I used to develop software; mostly COBOL and FORTRAN in the
70's and 80's, machine/assembly language and later C.  I moved on to
information security before I could get into more "object oriented"
environments. 

Thanks for the detailed reply - I'll be out of the country for a week or so
but I'll take another look at some point and provide additional feedback.  I
appreciate the effort and I'm looking forward to learning more.  I know how
hard it is to teach something that one knows very well - I forget what it
was like to be a beginner in my areas of expertise and tend to assume much
more knowledge in my audience than is reasonable to expect.

Mark

-Original Message-
From: Cowdery, Bob [UK] [mailto:[EMAIL PROTECTED] 
Sent: Friday, May 12, 2006 9:10 AM
To: Mark Amos
Subject: RE: [Flexradio] SDR-Breadboard

Hi Mark

Firstly, thanks for the feedback. It's easy to assume a level of
knowledge so this kind of feedback is really useful. 

Secondly, do you mind if this is sent to the reflector as well because
others may be thinking the same thing but simply dismissed the whole
thing rather than shout. 

>> Ok - here's some feedback. Not much, but I got stuck pretty early
on...

>> In the first line of the installation instructions you say "start
with a
>> clean 3.8 image."  This is the only place on the page where the words
"3.8
>> image" occur, and from the context I guessed that it was something to
do
>> with a development or operating platform, but I really have
absolutely no
>> idea what a "3.8 image" is...

I have sorted out the first page a bit into three pages and added a
small section on the environment. Let me know if this is enough or what
you think is missing that would be helpful. The 3.8 version is the
current version although 3.9 is close. I have not tried any of the 3.9
pre-releases.

>> Of course, I've never seen Smalltalk, so perhaps I'm just jumping in
the
>> deep end and don't have enough context for the words to make sense
(clearly
>> written Queens English, but pretty much meaning-free for me.) 

I don't know what your background is Mark but I got one person right
through installing and running the previous version and we had to
remotely debug problems as I was putting in auto-search for audio cards
and he had different cards and also an RFE and PA which I don't have.
The current version is in part the result of that exercise and that guy
wasn't on his own admission a computer techi. 
 

>> The website seems to assume some level of knowledge about something
but, a.)
>> I don't know what that something is; b.) the website doesn't describe
the
>> level of knowledge that is assumed (or perhaps I just missed it in my
>> cursory look); c.) doesn't provide enough background or context
information
>> for someone that isn't already familiar with the subject about which
you're talking.

I absolutely agree and there is a lot more info that should go in but
it's hard to know exactly what. What works well is someone, like
yourself just trying to follow what is there and just asking every time
you get stuck. Every question then adds some information to the site and
eventually when enough people go through that process the site has the
right level of information for most of the people most of the time.

>> In any case I was completely at sea without some kind of high-level
>> overview.  Maybe some links to elementary or remedial web pages about
the
>> environment you're using for people like me would be useful.

The Squeak web site (squeak.org) is a good place to start. Download the
software, its very easy to install, and simply play, lots of tutorials
on the web also if you Google for 'squeak tutorials'. Don't be put off
by the fact a lot of it looks like a toy shop, it's used extensively in
education.
 

>> I'm probably just the wrong audience!

Not at all, to get the radio working should be a completely
non-technical process once you have mastered your way around the menus
and know how to install stuff.


"People seem not to see that their opinion of the world is also a
confession
of their character." - Ralph Waldo Emerson 


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Cowdery, Bob [UK]
Sent: Thursday, May 11, 2006 5:13 PM
To: FlexRadio@flex-radio.biz
Subject: [Flexradio] SDR-Breadboard

Folks

 

Version 4.0 is now released and on the SqueakMap. The web site
http://myweb.tiscali.co.uk/g3ukb/ is up to date and contains a fair bit
more info. I have even joined hamsdr.com so the link is there as well.
This version has a lot of improvements and is much easier to manage. If
all this means absolut

[Flexradio] How do you VAC?

[Bob . Cowdery]

Is there anybody out there who has been through audio.cs and has managed to
work out what the philosophy is for using VAC. Like how the three PortAudio
callback routines interact, how /why the ring buffer is used. It's a pretty
rambling module and a leg-up would be appreciated. I don't need detail just
a high level description of what it's trying to do.

 

Thanks

Bob


*** Confidentiality Notice *** Proprietary/Confidential
Information belonging to CGI Group Inc. and its affiliates
may be contained in this message. If you are not a recipient
indicated or intended in this message (or responsible for
delivery of this message to such person), or you think for
any reason that this message may have been addressed to you
in error, you may not use or copy or deliver this message
to anyone else.  In such case, you should destroy this
message and are asked to notify the sender by reply email.

[Flexradio] SDR-Breadboard

[Bob . Cowdery]

A new version is up on Squeak map and http://myweb.tiscali.co.uk/g3ukb/
  has been updated with more information
and a high level design in UML. This is probably the first 'usable' version
for RX (depends on your definition of usable of course!). The install
includes a new project with a dual-watch configuration that should work
right out the box on Windows.

 

73

Bob (G3UKB)


*** Confidentiality Notice *** Proprietary/Confidential
Information belonging to CGI Group Inc. and its affiliates
may be contained in this message. If you are not a recipient
indicated or intended in this message (or responsible for
delivery of this message to such person), or you think for
any reason that this message may have been addressed to you
in error, you may not use or copy or deliver this message
to anyone else.  In such case, you should destroy this
message and are asked to notify the sender by reply email.

Re: [Flexradio] Free documenting tools

[Bob . Cowdery]

Hi Cecil

> I never ceases to amaze me the tools that are available for free on 
> the Internet.

> Several weeks back there was a discussion on the use of ULM to 
> document software, I was not paying too much attention and deleted 
> the emails, I guess my next stop will be the archives. This afternoon 
> it popped into my head and I started nosing around to find out what 
> it is. I found a lot of information, much of it worthless, if you are 
> going to be a professor at a University, they should insist that you 
> take several courses in how to communicate with other human beings. 
> Nevertheless there were some useful articles and I was able to get 
> some tools for documenting processes, such as the one below.

> < http://www.visual-paradigm.com/product/vpuml/productinfovpumlce.jsp >

> I ended purchasing some software on eBay that does the following;

> VS Studio Project --> ULM diagrams in Visio

> It seems like a good thing,  I'm also expecting a copy of Visual 
> Studio 2003 ($217) from eBay also, they need each other so I'll find 
> out soon enough how they work together.

UML is a useful tool if correctly applied. I use Poseidon, which is not free
but it's pretty cheap when compared to the big boys. I've never found UML
that useful for reverse engineering. It's easy for it to sort out class
hierarchy but associations are a different matter. I've started using UML to
track the design of my console. That's where I find it most useful to kind
of tag along with the design and make it more obvious if something is not
quite right. It's on the web if you want to take a gander at
http://myweb.tiscali.co.uk/g3ukb/UML.htm . 

Let me know if made a good job of reverse engineering, maybe things have
moved on a bit since I last tried.

Bob(G3UKB)--

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

*** Confidentiality Notice *** Proprietary/Confidential
Information belonging to CGI Group Inc. and its affiliates
may be contained in this message. If you are not a recipient
indicated or intended in this message (or responsible for
delivery of this message to such person), or you think for
any reason that this message may have been addressed to you
in error, you may not use or copy or deliver this message
to anyone else.  In such case, you should destroy this
message and are asked to notify the sender by reply email.

Re: [Flexradio] A little more light entertainment

[Bob . Cowdery]

Ken

You are one of life's ambassadors. I thank you for the comments cunningly
concealed. Of course, now I know you speak ST I will be expecting the 'N9VV'
component to pop up!

Bob

-Original Message-
From: Ken N9VV [mailto:[EMAIL PROTECTED] 
Sent: 25 February 2006 00:39
To: Cowdery, Bob [UK]
Subject: Re: [Flexradio] A little more light entertainment

SuperClass variableSubclass: #bob-s-a-genius
 instanceVariableNames: 'amazing'
 classVariableNames: 'beyond-human-thought'
 poolDictionaries: 'a-triumph'
 category: 'must-be-seen-to-be-believed'.

beautiful Bob!
ken


[EMAIL PROTECTED] wrote:
> The Smalltalk based SDR-Breadboard radio is coming along. This release is
> primarily aimed at Windows although the Linux functionality is still
intact.

*** Confidentiality Notice *** Proprietary/Confidential
Information belonging to CGI Group Inc. and its affiliates
may be contained in this message. If you are not a recipient
indicated or intended in this message (or responsible for
delivery of this message to such person), or you think for
any reason that this message may have been addressed to you
in error, you may not use or copy or deliver this message
to anyone else.  In such case, you should destroy this
message and are asked to notify the sender by reply email.

[Flexradio] A little more light entertainment

[Bob . Cowdery]

The Smalltalk based SDR-Breadboard radio is coming along. This release is
primarily aimed at Windows although the Linux functionality is still intact.
Have a look on http://myweb.tiscali.co.uk/g3ukb/
  for an update. Even if you have no
intension of trying it you might find the approach interesting.

 

Best 73

Bob (G3UKB) 


*** Confidentiality Notice *** Proprietary/Confidential
Information belonging to CGI Group Inc. and its affiliates
may be contained in this message. If you are not a recipient
indicated or intended in this message (or responsible for
delivery of this message to such person), or you think for
any reason that this message may have been addressed to you
in error, you may not use or copy or deliver this message
to anyone else.  In such case, you should destroy this
message and are asked to notify the sender by reply email.

[Flexradio] A unified architecture?

[Bob . Cowdery]

I have a question on the game plan for Windows, Linux and WHY architectures,
not individually, but as a whole. I have been following all the discussions
but they have not helped me resolve this issue so I guess the only way to
find out is to ask.

 

Having dabbled with both implementations there is something that has now
moved high on my wish list. I have my Smalltalk radio talking to both the
Windows and the Linux jsdr implementations. However, the way it does so is
quite different. For Windows it's a plugin dll and for Linux it talks
through named pipes. For Windows I had to move audio processing back in and
make a number of other changes to achieve the integration. 

 

I would love a single code line for jsdr that had the same interface and the
same functionality on all platforms. The key things I would really like are.

 

1. A unified messaging interface that is not targeted, so that different
external interfaces could be mapped on top to expose jsdr to C#, Java,
Python, Lisp, Smalltalk or as a web service, raw socket service or WHY in a
way that is the most natural for the language/environment. I don't care
particularly what the messaging format is as long as it is expressive enough
to cope with complex data formats. What I would hate is a completely
separate Windows and Linux jsdr that did exactly what each environment
required with a hard coded external interface.

 

2. For audio processing to be part of jsdr on all platforms and use
PortAudio on all, rather than PortAudio on Windows and Jack on Linux. This
means all management of sound cards, dual cards, VAC and Jack (I assume Jack
would be used under PortAudio for routing) would be common.

 

Is anything like this on the roadmap? Is it a load of rubbish and are there
reasons why it will never be like this? My worst nightmare at the moment is
that I will keep putting effort into redoing my changes to jsdr every time I
want to take a new cut. If it is moving in this direction then I am sure I
could help in some way.

 

Best 73

Bob (G3UKB)


*** Confidentiality Notice *** Proprietary/Confidential
Information belonging to CGI Group Inc. and its affiliates
may be contained in this message. If you are not a recipient
indicated or intended in this message (or responsible for
delivery of this message to such person), or you think for
any reason that this message may have been addressed to you
in error, you may not use or copy or deliver this message
to anyone else.  In such case, you should destroy this
message and are asked to notify the sender by reply email.

Re: [Flexradio] Howcum?

[Bob . Cowdery]

Simon Brown wrote:
>I am currently running 4 operating systems from a single Windows server, 
>VMware is the finest development tool out there.

VMWare is good for a lot of things. I have used it to an extent but I
believe sound support is very limited and system calls can be slow.

Bob

*** Confidentiality Notice *** Proprietary/Confidential
Information belonging to CGI Group Inc. and its affiliates
may be contained in this message. If you are not a recipient
indicated or intended in this message (or responsible for
delivery of this message to such person), or you think for
any reason that this message may have been addressed to you
in error, you may not use or copy or deliver this message
to anyone else.  In such case, you should destroy this
message and are asked to notify the sender by reply email.

Re: [Flexradio] Howcum?

[Bob . Cowdery]

Frank, I can feel a good deal of synergy coming on here. I have picked out
what for me are pretty important points.

>What I'm pushing here is the idea that "Eric's console" should and will 
>be a very different beast from "Jose's console" and even less 
>recognizable in "Duane's console." Short form: the Linux SDR "console" 
>will be more like a desktop environment than an application, more like 
>KDE or Gnome than xemacs or the gimp.

I don't think the console should be fixed form either. I'm not just talking
skinnable which is much more about what it looks like than how it behaves
but consisting of many communicating parts, each independent but
collaborating in defined ways. Each individual can then purpose the console
to their exact needs and build additional parts as required.

>Far as I know, all the current efforts can be 
>distributed across networked machines. That's as it should be. It 
>determines a lot about how components have to be organized and
>interconnect.

Absolutely essential to have transparent distribution. For my purpose I
would say this must span the three dominant platforms which means all parts
must run bit identical on all platforms. There will of course be necessary
platform variants of parts. 

>For myself, I am convinced that an SDR is properly embodied in an OODL.

I am completely sold on OODLs. There are many reasons I won't go into here.

>exposed and available via SWIG 
>in a completely different programming environment. Lisp, if you must 
>know

I routinely use Java, C, C#, VB, Python, Ruby and Smalltalk. I went through
a Lisp tutorial when wxPython ran out of puff and I was back searching
again. Very impressive language and I was seriously considering it.

There is a lot of common ground here, certainly enough to plunge a few
stakes into! 

I think at this level there are two issues that stand out. The first is
Linux or cross-platform. I definitely want cross-platform because I don't
want to be locked out from using the best platform for a given task. I think
most others in this thread just want a Linux console. The second is the
language issue and not really even the language itself except OODL is pretty
much a given. It's the library support, the IDE's available, a decent ORB
and object persistence, integration with C (most important) and near the top
of my list, the GUI and Web builder environments available.

73
Bob --



*** Confidentiality Notice *** Proprietary/Confidential
Information belonging to CGI Group Inc. and its affiliates
may be contained in this message. If you are not a recipient
indicated or intended in this message (or responsible for
delivery of this message to such person), or you think for
any reason that this message may have been addressed to you
in error, you may not use or copy or deliver this message
to anyone else.  In such case, you should destroy this
message and are asked to notify the sender by reply email.

Re: [Flexradio] Howcum?

[Bob . Cowdery]

[EMAIL PROTECTED] wrote:
> ...It's a huge effort to
> produce something that has equivalent functionality to the Windows console
> on an OS and audio subsystem that is really quite different...

Frank Brickle wrote:
>All right. Let me try to give an honest (rather than glib) answer to 
>Eric2's original question.

>First, there isn't a finished, well-rounded Linux console yet because 
>there isn't a strong enough demand for it. The experts who have been 
>building their own GUIs (Bob, John, Edson) have been seeing to their own 
>needs.

>This is possible because the design of the underlying DSP code has been 
>decoupled and modular from the very beginning. It was built from day one 
>on the idea of making separate and/or remote control as *simple* as 
>possible.

>People who are interested in an 
>"I-don't-care-just-give-me-a-working-console-with-the-features-I-want" 
>interface already *have* the Windows version. It's hard to argue for 
>duplicating that. (My own opinion is that Mac OSX is probably a better 
>platform for that, but never mind.)

>Empirically the people who want a Linux version want something *else*.

>Personally, I have been privately detesting the monolithic Windows 
>console since the VB days. I've been calling it the "horseless carriage 
>SDR" since the beginning. It's like the original automobiles that were 
>styled to look like a horse-drawn vehicle that just happened to be 
>missing a horse. Making a long rant short, I believe that hobbling an 
>SDR with a glass front panel that's hard to work is a way to hold SDR 
>development back in a crippling way, in the medium and long terms.

>The clearest illustration of this is the matter of multiple receivers. 
>The DSP software has been capable of providing multiple independent RX 
>channels in the passband for many months. It isn't there in PowerSDR 
>because the interface won't support it. That's because the 
>glass-front-panel model, in any manifestation, just sucks eggs. Putting 
>on skins is like rearranging deck chairs on the etc.

>This is not a prejudice that came out of nowhere. I have been intensely 
>involved in using computers for processing music sound since 1970, when 
>we used to have to drive to Bell Labs in Murray Hill to get D/A 
>conversion of our digital tapes. These interface issues have been 
>thrashed over time and time again in the computer music world for thirty 
>years. The lesson is always the same. Highly proficient users want and 
>need different things than beginners when it comes to complex 
>interfaces. Windows and mice are hopelessly inadequate to capture the 
>repertoire and gestural vocabulary of expert users. It's kind of like 
>when electronic keyboards went polyphonic. Adding a second tone 
>generation section isn't a 2X improvement, it's an improvement by 1/88.

>Binding your interface to a visual model based on physical resemblance 
>is a *terrible* idea in the long run. The GUI needs to fit the *mental 
>model of a the community of experts*. At present the experts are still 
>learning.

>The Linux console is ultimately going to be a coalescence of the lessons 
>learned from the great work by Bob, John, Edson, and others. It's a good 
>bet the result won't look much like PowerSDR.

I started to formulate a reply to Larry and then binned it. You have put far
more elegantly than I could have done why things are where they are. We are
a selfish lot, switching strategy, swapping language seemingly at a whim.
It's all part of the learning process though and if nothing else we know a
lot of what not to do. The collateral is not in the lines of code in the
different consoles, it's in the knowledge gained. 

The jsdr is a stunning piece of code and makes it possible for people to get
involved that would never have gotten off the ground otherwise, me included.
It does not suffer the same kind of uncertainty as the console because it
has a specialized job to do and it does it extremely well within a very nice
structure. Whilst we might play with the interface there is little need to
dig any deeper.

The biggest challenge now is getting a quorum to agree on the right route.
Enough critical mass to start building the ultimate beast!

Bob (G3UKB)
___
FlexRadio mailing list
FlexRadio@flex-radio.biz
http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Archive Link: http://mail.flex-radio.biz/pipermail/flexradio_flex-radio.biz/
FlexRadio Homepage: http://www.flex-radio.com

*** Confidentiality Notice *** Proprietary/Confidential
Information belonging to CGI Group Inc. and its affiliates
may be contained in this message. If you are not a recipient
indicated or intended in this message (or responsible for
delivery of this message to such person), or you think for
any reason that this message may have been addressed to you
in error, you may not use or copy or deliver this message
to anyone else.  In such case, you should destroy this
message and are asked 

Re: [Flexradio] Howcum?

[Bob . Cowdery]

This simple question is actually pretty complex. It's a huge effort to
produce something that has equivalent functionality to the Windows console
on an OS and audio subsystem that is really quite different. It's not just a
case of GUI programming, in fact that's the least of the work. It's actually
pretty simple to make something that provides elementary control and
configuration of the radio. Several people have done that, me included. But
why should anyone use such a console when it's a million miles away from the
Windows version AND not 'officially' supported and no guarantee it's going
to live or be enhanced. 

The only way to have done this would have been to start out with a
cross-platform architecture and toolkit. Given where we are the only options
are a completely separate Linux version (choose your starting point for
this, Java, Python, C with GTK or WHY), a mono port of the C# console (not
sure how practical this is) or a completely new design which from the ground
up is cross-platform.

My own stance is that if I want to use this radio seriously on the air I
will use the official console (for the foreseeable at any rate). If I want
to experiment I will roll my own. I am building a fully cross-platform
environment in Smalltalk that can run on one machine or distributed across
mixed Windows/Linux machines. I don't know how long it will take it to
achieve a fully usable level of functionality but I enjoy doing it and it's
getting there a lot quicker than I expected. I have no real expectation of
anyone else using or contributing to this - but if anyone else does find
synergy with what I am doing I am willing to share. If on the other hand you
want a turnkey fully functional, supported Linux console which tracks the
Windows console then that is probably an unrealistic expectation. Unless of
course someone else knows different...

Just my pennyworth.

73
de Bob --

John g0orx/n6lyt wrote: 

> Sounds like I should give up on the Java code ;-)


Frank Brickle wrote On 02/14/06 02:47,:
> Quick answer: talent. Neither Bob nor I has even a quark of aptitude at 
> GUI programming. The legacy of growing up with punch cards and paper tape.
> 
> Edson's console is *beautiful*. It works wonderfully. It's the vehicle 
> of choice. Not sure, but I think the only obstacle to polishing it off 
> is manual labor, and a little help from the DSP programmers.
> 
> 73
> Frank
> AB2KT
> 
> Eric Ellison wrote:
> 
>>Folks
>>
>> 
>>
>>Howcum we don't have a running version of Linux SDR-1000 console?
>>
>> 
>>
>>It is the 'natural platform' for SDR-1000. 
>>
>> 
>>
>>WHAT IS THE FRIGGIN'  LIMITING FACTOR?
>>
>> 
>>
>>Dan?
>>
>> 
>>
>>Eric2
>>
>> 
>>
>>___
>>FlexRadio mailing list
>>FlexRadio@flex-radio.biz
>>http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
>>Archive Link:
http://mail.flex-radio.biz/pipermail/flexradio_flex-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://mail.flex-radio.biz/pipermail/flexradio_flex-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://mail.flex-radio.biz/pipermail/flexradio_flex-radio.biz/
FlexRadio Homepage: http://www.flex-radio.com

*** Confidentiality Notice *** Proprietary/Confidential
Information belonging to CGI Group Inc. and its affiliates
may be contained in this message. If you are not a recipient
indicated or intended in this message (or responsible for
delivery of this message to such person), or you think for
any reason that this message may have been addressed to you
in error, you may not use or copy or deliver this message
to anyone else.  In such case, you should destroy this
message and are asked to notify the sender by reply email.

[Flexradio] Questions on the Windows code

[Bob . Cowdery]

WARNING - technical stuff.

 

I don't know exactly who to address these to so
if Eric/Frank/Bob want to take them off-line please do so. 

 

I am building a Squeak plugin from the DttSp Windows
code-line. I have put the audio processing on the 'C' side of the
fence and made necessary changes to the interfaces. Fundamentally it works in
that the right calls get made and everything starts up and runs. Can't
actually get any audio out of it yet but at the moment I am trying to
understand the code. I probably have not understood correctly how things work,
hopefully someone can put me straight. A couple of things which have got me
puzzled.

 


 In audio.cs there is some code to start the
 process_samples_thread which is in the DttSp winmain.c. However, in setup_threading
 in winmain.c there is also code to start the process_samples_thread. I did
 have code in my audio.c to start it until I realized it was starting twice.
 When I first tried to run things all the threads
 were getting hung. I tracked this down to everything waiting on top.sync.upd.sem.
 I had to comment out the wait on that S4 in process_samples_thread to get
 things moving. Clearly I shouldn't need to do this. Looking through
 the code as I understand it an initialise like sem_init(&top.sync.upd.sem,
 0, 0); will initialise in a locked state. I can't find anywhere in
 the code where this S4 is posted which does not have a preceding wait.
 Obviously the code works so what am I missing?


 

73

Bob --




*** Confidentiality Notice *** 
Proprietary/ConfidentialInformation belonging to CGI Group Inc. and its 
affiliatesmay be contained in this message. If you are not a 
recipientindicated or intended in this message (or responsible 
fordelivery of this message to such person), or you think forany reason 
that this message may have been addressed to youin error, you may not use or 
copy or deliver this messageto anyone else.  In such case, you should 
destroy thismessage and are asked to notify the sender by reply 
email.

Re: [Flexradio] A bit of light entertainment

[Bob . Cowdery]

Michael

 

Pleased to know you are joining the Squeakers.

 


> I downloaded
squeak and have started playing with it. Way cool!
> I spent 7 years
programming java, but got tired of it, but squeak looks
> like where I want
to spend my time.



It is
refreshingly different and a lot of fun. I am a great believer in horses for
courses and this horse is right for what I have in mind. I am involved in two
projects at work at the moment and for the first Python has worked really well,
for the other which is much larger Java is the only choice for the backend
tiers but I am using Ruby on Rails for the Web Application. In both cases I
think I have the right horses but it's always a difficult choice.


> My goals:

> 1. I would like to
run the sdr1000 on my mac. I've had it about 6 months 
> and just can't go
back to windows. You might say that I have a severe case
> of Windows Post
Traumatic Stress Syndrome (WPDST) :-)
> Besides, my
stepson absconded with my Intel box that was dual boot
>  linux/windows.




It would
be nice to see at least the GUI on a Mac, and that should be pretty straight
forward. Linux is a good host for the DSP and my preferred mode is to have the
DSP on it's own machine as I can then mess about on the machine running
the GUI and run lots of stuff without any danger of causing a hiccup.


> 2. I'd like to
contribute what I can to a aqueak port of sdr code.



That
would be great if you could. As each component is very loose coupled, it should
be easy to write new components without in most cases touching anything else
save maybe adding an entry to a map and implementing any new methods in the
components you link to. I haven't really stopped to think about how
things should link together yet. I think the basic philosophy is going to be
each component deals with its own responsibilities. So for example the DSP
client and server components know the state of the DSP and should reflect this in
software LED's. etc. But things like how to arbitrate between all the
frequency displays that you could throw on a screen, do A<>B, C<>D
etc, IRT/ITT and IF shift, multiple receivers (jsdr supports 4) etc etc is
still up for grabs. At the moment I am thinking about a persistency addition to
the framework using the Magma package which I have started playing with. As
with the connection management I want it to be completely transparent to
component writers.


> 3. And finally, I
am interested in 3d sound. The idea, for cw, is that if youto
> can move the sound
3 dimensionally to improve cw copy. I've tried this 
> (by moving
speakers) and when I get it just right (above the plane of my
> head and about a
foot in front) for me the code just seems to make letters appear
> automatically.



That
sounds more like DSP work. I do hope that eventually the DSP can be implemented
as components that can be wired up in the same way as the rest of the
application. There is a PortAudio port going on at the moment which will open
up those possibilities. As you say, lets see what can happen.


> Look forward to
seeing what can happen. 



73

Bob

 



On 12/29/05, Cowdery, Bob [UK] <[EMAIL PROTECTED]>
wrote: 



Perfectly feasible in
that squeak runs on Mac OSX. I can't speak for how it runs as I don't have a
Mac. The SDR1000 controller would have to be changed to use the Mac way of
getting to the parallel port which I guess is the same as nix. More importantly
the jsdr implementation would have to run and I don't think that has been
ported, but I could be wrong.

 

Bob



 

-Original Message-
From: Michael Doherty [mailto:[EMAIL PROTECTED]]

Sent: 29 December
 2005 12:35
To: Cowdery, Bob [UK]
Subject: Re: [Flexradio] A bit of
light entertainment

 

Is it feasible to
run this on mac (OSX)?

73's, Michael kd5wby



On 12/29/05, Cowdery, Bob [UK] <
[EMAIL PROTECTED] > wrote:

> You're too modest, Bob. This is exactly what I
(personally, from a 
very
> jaundiced point of view) want an SDR to be.

I never blow my trumpet too hard Frank incase it falls apart! I hope
this effort will have a longer life span and I think maybe it will.

I made a few small updates to my web page so text wraps, had to cut the 
pic in half (must be a better way). Added the installation info.

73
Bob

-Original Message-
From: Frank Brickle [mailto:[EMAIL PROTECTED]]
Sent: 29 December 2005 10:26 
To: Cowdery, Bob [UK]
Cc: FlexRadio@flex-radio.biz
Subject: Re: [Flexradio] A bit of light entertainment

[EMAIL PROTECTED]
wrote:
> Ok guys. I think a bit of real information is called for here.


73
Frank
AB2KT
*** Confidentiality Notice *** Proprietary/Confidential
Information belonging to CGI Group Inc. and its affiliates 
may be contained in this message. If you are not a recipient
indicated or intended in this message (or responsible for
delivery of this message to such person), or you think for
any reason that this message may have been addressed to you 
in error, you may not use or copy or deliver this message
to anyone els

Re: [Flexradio] FW: A bit of light entertainment

[Bob . Cowdery]

Several tens of messages and a few bottles
of wine later I have no idea what's going on but everyone have a happy
new year and I might even dig out my Atari from the loft. If I can find the
loft that is! 

 

Bob

 

-Original Message-
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: 30 December 2005 16:36
To: Flex Radio
Subject: Re: [Flexradio] FW: A bit
of light entertainment

 

I hooked it up to my
Televideo 950 terminal, 10 meg HD, and the twin Pertec 1.2 Meg drives and it
booted right away, I said my goodbye and took it all to the dump, hardware,
software, books. In absolute mint condition, that use to be my baby until 1984.
I have regretted it, not just for the money but the memories of the fun I had
with that computer. Different days, with very efficient software, the OS would
boot in less than .5 seconds once the HD spins up.

At 08:58 AM 12/30/2005, you wrote:



AND YOU SOLD IT OR LOST
IT?

You shall pay a hefty fine of 25 geek points and serve a sentence of 42 years
of regret and you just slid off the geekdar.

Bob


That said,  we have drifted (yes, with my help) hopelessly off topic and I
suspect we are boring a lot of Flex Radio types.



KD5NWA wrote:




That might be worth a lot
of money to a museum, I know a friend that sold a Altair for $40,000. I could
kick myself, I owned Altair #19, personally delivered and signed inside by Ed
Roberts, I use to know him well. Funny thing his dad use to look just like
Jimmy Carter the President.

Young people can be quite dense, I got to know him, and often I would give him
rides or pick him up from the Miami airport when he was flying to Albuquerque,
It took me a while to figure out that he was the President of MITS he never
mentioned it. One time I complained that my kit for the Altair had not arrived,
when he came back from New Mexico he carried Altair #19 with him and gave it to
me, he told me he knew a couple of people at Altair. Being dumb as a stump when
it came to personal matters, I still didn't get it, until one day I noticed a
stack of mail at his office addressed to Ed Roberts president of MITS, duh, the
light bulb finally lit up.

My Altair was in mint condition, with every board they ever made, and fully
functional, my wife nagged until I threw it away, four month later, my friend
called me and wanted to know about my Altair, a Museum in Japan was interested.
When I found how much my friend got for his (which wasn't functional) I very
calmly told her how much making a little extra room in the garage had cost, she
was unusually quiet for several days.



-- 
AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats,
NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman
Laziness is the number one inspiration for ingenuity.  Guilty as charged!


Cecil Bayona
KD5NWA
www.qrpradio.com

I fail to see why doing the same thing over and over and getting the same
results every time is insanity: I've almost proved it isn't; only a few more
tests now and I'm sure results will differ this time ... 




*** Confidentiality Notice *** 
Proprietary/ConfidentialInformation belonging to CGI Group Inc. and its 
affiliatesmay be contained in this message. If you are not a 
recipientindicated or intended in this message (or responsible 
fordelivery of this message to such person), or you think forany reason 
that this message may have been addressed to youin error, you may not use or 
copy or deliver this messageto anyone else.  In such case, you should 
destroy thismessage and are asked to notify the sender by reply 
email.

[Flexradio] FW: A bit of light entertainment

[Bob . Cowdery]

Title: FW: [Flexradio] A bit of light entertainment





Sami wrote:


> Smalltalk? Now, what we need is an SDR project in Lisp.


I fully appreciate your viewpoint but there is method in my madness. When it comes down to it, from a programming point of view all languages are much more similar than they are different. However, from a functional point of view there are certain things you can only do in dynamic late-bound languages. 

I did try every dynamic language including Lisp and Ruby after admitting to myself that the wxPython GUI was never going to be what I wanted and the cross platform compatibility (or lack of) was a real pain. But the thing that really swung it to Squeak wasn't actually Smalltalk but the Morphic system for building interfaces which is pretty much spot-on for what I wanted to build. Yes, you could do this in other languages but it wouldn't be as good and would probably take an order of magnitude more time. 

I think the solid engineering principals and mainstream language applied to the official console is absolutely right and for the vast majority this is the road to follow, the rest should just be peripheral noise which can be tuned out. For those that want to play in their own space there is more opportunity with this radio than any other on the planet. In my book you can't have too many projects going on, be they hardware, software or a mix like the FPGA project, which I think is great if only I had more time I would jump in on it.

73
Bob




*** Confidentiality Notice *** 
Proprietary/ConfidentialInformation belonging to CGI Group Inc. and its 
affiliatesmay be contained in this message. If you are not a 
recipientindicated or intended in this message (or responsible 
fordelivery of this message to such person), or you think forany reason 
that this message may have been addressed to youin error, you may not use or 
copy or deliver this messageto anyone else.  In such case, you should 
destroy thismessage and are asked to notify the sender by reply 
email.

Re: [Flexradio] A bit of light entertainment

[Bob . Cowdery]

Ok guys. I think a bit of real information is called
for here. 

 

Squeak can be downloaded for windows, nix and OS X
and a lot of other platforms. I have only used it on windows and linux because
I only have those platforms. For those that have downloaded you may have found
the squeak map which lets you install a huge range of packages. I have not
published my radio yet so it won't be in that list. 

 

So that expectation are set correctly, what I have so
far is SDR1000 control through Windows (not a complete implementation yet),
although it will be fairly trivial to make that work on Linux as well. The DSP
has to be Linux using jsdr because the interface is trivial to use (unix
pipes). I will be looking at the windows implementation soon and see if that
can be packaged up in a similar way so I can use it easily from Squeak. So -
currently I run this as a distributed system with what would conventionally be
called the console on windows and the dsp on linux. This interface is not
fool-proof yet but works.

 

There are some pre-requisites for running the radio,
the first is the windows parallel port driver. This is IOST and for some reason
is not in the map, get it here http://www.smalltalking.net/Goodies/Squeak/
. The second is called Connectors which is in the Squeak map. It takes a while
to load in and gives you three grey tabs at the bottom of the screen (FSM,
Class Diagram and Connectors). Lastly you will need OperaORB-native which is
also in the map to provide distributed computing.

 

There are seven class categories that make up the
radio which I can file-out. I can also provide my workspace which gives you all
the commands you need to start things up. If anyone gets this far and wants to
give it a try please send me a personal email and I will give you the stuff. Be
aware that you may have to play to make it work on your radio hardware as I
only have the basic 3 board stack so you may have to change the initialisation
to make sure other bits of hardware are turned off etc. I am also not using the
Opera name service yet so the IP address needs to be set in the code.

 

This radio is very minimal at the moment. It's
designed to have fun with, not to be a serious operational tool (yet).

 

73

Bob (G3UKB)

 

 

 

  




*** Confidentiality Notice *** 
Proprietary/ConfidentialInformation belonging to CGI Group Inc. and its 
affiliatesmay be contained in this message. If you are not a 
recipientindicated or intended in this message (or responsible 
fordelivery of this message to such person), or you think forany reason 
that this message may have been addressed to youin error, you may not use or 
copy or deliver this messageto anyone else.  In such case, you should 
destroy thismessage and are asked to notify the sender by reply 
email.

[Flexradio] A bit of light entertainment

[Bob . Cowdery]

If you feel things are getting a little heavy in the
real SDR world the KISS principal radio is starting to do things. It must be;
because I stopped writing code and started to tune around, a sure sign that
something is working. Take a peek at http://myweb.tiscali.co.uk/g3ukb/
. I promise you there is just one picture and not very many words.

 

Trust everyone had a good Christmas and all raring to
get going on new SDR projects in the new year.

 

73

Bob (G3UKB)




*** Confidentiality Notice *** 
Proprietary/ConfidentialInformation belonging to CGI Group Inc. and its 
affiliatesmay be contained in this message. If you are not a 
recipientindicated or intended in this message (or responsible 
fordelivery of this message to such person), or you think forany reason 
that this message may have been addressed to youin error, you may not use or 
copy or deliver this messageto anyone else.  In such case, you should 
destroy thismessage and are asked to notify the sender by reply 
email.

Re: [Flexradio] Linux: was "Scope Black Out"

[Bob . Cowdery]

I have been following the Xylo posts and
it looks very interesting but time does not allow too much diversification. No,
I am still playing software. My aim is a set of visual software components that
can be dropped on a canvas and wired up 'live' into a multitude of
different configurations. I want to cover everything from GUI to DSP, Control
and Audio. So far I have 7 components that give me basic rx control over the
SDR1000 and jsdr across Windows and Linux.

 

73

Bob

 

-Original Message-
From: ecellison
[mailto:[EMAIL PROTECTED] 
Sent: 22 December 2005 00:44
To: Cowdery, Bob [UK];
FlexRadio@flex-radio.biz
Subject: RE: [Flexradio] Linux:
was "Scope Black Out"

 

Bob

 

Sounds
like you are branching out to hardware! Recently a group of Flexers and others
got together an 'offshoot' fourm based on a little FPGA project
board called the Xylo. We took it off the Flex Reflector since it is a little
off topic and there was a lot of interest and activity. At least 4 or more
folks are planning new SDR type projects or are in that 'stage'. My
hope is that the group will produce a high quality programmable audio processor,
however, all interests are welcome. I don't think your
'project' will bore anyone.

 

Eric2

 

Xylo-SDR mailing list

To post msg: [EMAIL PROTECTED]

Subscription help: http://lists.ae5k.us/listinfo.cgi/xylo-sdr-ae5k.us

Xylo-SDR web page: http://xylo-sdr.ae5k.us
Forum pages: 

http://www.hamsdr.com/hamsdrforum/

 

 

 









From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Wednesday, December 21, 2005
12:11 PM
To: FlexRadio@flex-radio.biz
Subject: Re: [Flexradio] Linux:
was "Scope Black Out"



 

Ken N9VV wrote

> Python version of the console?

> -

> I remember reading some very encouraging info
about the 

> progress that Bob G3UKB was making on his Python 

> implementation.

 

 

The Python project is mothballed at
the moment for a number of reasons. It's gone out to a lot of people and I
would hope some have found it useful. I am currently working on a much more
dynamic radio that I have high hopes will finally be the SDR breadboard that I
want for experimentation. I won't bore the list with intricate detail as I know
these kind of activities are minority interest. If enough people are curious I
might be persuaded to post a write-up somewhere...

 

73

Bob (G3UKB)

*** Confidentiality Notice ***
Proprietary/Confidential
Information belonging to CGI Group Inc. and its affiliates
may be contained in this message. If you are not a recipient
indicated or intended in this message (or responsible for
delivery of this message to such person), or you think for
any reason that this message may have been addressed to you
in error, you may not use or copy or deliver this message
to anyone else.  In such case, you should destroy this
message and are asked to notify the sender by reply email.




*** Confidentiality Notice *** 
Proprietary/ConfidentialInformation belonging to CGI Group Inc. and its 
affiliatesmay be contained in this message. If you are not a 
recipientindicated or intended in this message (or responsible 
fordelivery of this message to such person), or you think forany reason 
that this message may have been addressed to youin error, you may not use or 
copy or deliver this messageto anyone else.  In such case, you should 
destroy thismessage and are asked to notify the sender by reply 
email.

Re: [Flexradio] Linux: was "Scope Black Out"

[Bob . Cowdery]

Ken N9VV wrote

> Python version of the console?

> -

> I remember reading some very encouraging info about the 

> progress that Bob G3UKB was making on his Python 

> implementation.

 

 

The Python project is mothballed at the moment for a number
of reasons. It's gone out to a lot of people and I would hope some have
found it useful. I am currently working on a much more dynamic radio that I
have high hopes will finally be the SDR breadboard that I want for
experimentation. I won't bore the list with intricate detail as I know
these kind of activities are minority interest. If enough people are curious I
might be persuaded to post a write-up somewhere...

 

73

Bob (G3UKB)




*** Confidentiality Notice *** 
Proprietary/ConfidentialInformation belonging to CGI Group Inc. and its 
affiliatesmay be contained in this message. If you are not a 
recipientindicated or intended in this message (or responsible 
fordelivery of this message to such person), or you think forany reason 
that this message may have been addressed to youin error, you may not use or 
copy or deliver this messageto anyone else.  In such case, you should 
destroy thismessage and are asked to notify the sender by reply 
email.

Re: [Flexradio] [SPAM] Musings

[Bob . Cowdery]

 





> Thanks for the update - absolutely
fantastic and I can't wait to see the results.  I had a US visitor here in the shack today stopping over in Perth on his way to a DXperditin to Christmas Island.  He is a 160m fanatic so I showed > him my SoftRock40 that I
have modified to run on 160m together with Alex's  Rocky software. 
He begged me to sell him my SoftRock!  What Alex has done with the automatic
!/Q nulling is nothing short of fantastic - with his > > technique direct conversion will
never be the same again!





 





Thanks Phil,

 

I should have
got a SoftRock40 but I think I missed the boat. One thing I still need to add
is calibration so I might crib a look when I get round to it, sounds like an
excellent job. One of my 'down-the-road' intensions is to retrofit my own DSP stuff as another set of services with its original configurator
so I can start experimenting again.

 

    Bob






*** Confidentiality Notice *** 
Proprietary/ConfidentialInformation belonging to CGI Group Inc. and its 
affiliatesmay be contained in this message. If you are not a 
recipientindicated or intended in this message (or responsible 
fordelivery of this message to such person), or you think forany reason 
that this message may have been addressed to youin error, you may not use or 
copy or deliver this messageto anyone else.  In such case, you should 
destroy thismessage and are asked to notify the sender by reply 
email.

[Flexradio] Musings

[Bob . Cowdery]

All

 

It's been a while since I posted
anything so I though it about time I gave a brief statement of where I am in
the somewhat hectic world of SDR1000 software. 

 

I do at times feel a little
awestruck by the things Bob & Frank and the 'official team' get
up to, so I sit quietly and try to absorb. It must be very difficult at times
for people to work out how and where all the different threads of activity
converge or maybe diverge. This is one thread of activity which I hope might
become a bit clearer after reading the following (even to me - nothing
like writing down what you are doing to make you think!)

 


 Everything I am building is
 pure Python (the 'C' version, not Jython for Java, or Iron
 Python for .NET).
 There are two pieces I am
 building, a console and a radioserver controller/manager.
 The only extensions I am using
 are fully cross-platform. At present these are wxPython (a cross platform
 GUI library) and Pyro (distributed object system).
 I develop entirely under
 Windows XP.
 I am testing on Windows and Linux
 (Suse 9.3) and at some point will probably do OS X - just because I fancy
 a Mac on the desk.
 The architecture is built for
 distribution so any piece of the functionality - console, DSP, radio
 control etc could be run on a separate box. My default arrangement is the
 console on XP and my server pieces plus the jDttSP (thanks to Bob and
 Frank) pieces on Linux. However, the pieces can all be run on the same box
 with no software changes. 
 The architecture is built to
 abstract the DSP and control away from the console through a virtual radio
 API. In this way different server pieces can be fitted without any client
 side changes. For example appropriate ports of the jDttSP pieces to
 Windows could be used for a full Windows system or a different controller
 for SoftRock-40 etc.
 Distribution is achieved
 through Pyro which has proved to be fast and robust and almost trivially
 simple to implement. Other protocols could be used with appropriate
 adapters on the client and server.
 The console architecture is
 built to allow extensibility, mainly for my convenience but of course
 provides patterns to allow other to add function. This is mainly down to
 having a tree navigator and plug-in panels where the connections are
 mainly configured rather than coded. These panels currently implement all
 options, radio memory management and multi-radio functions. I expect this
 area to mature quite a lot in the future. Because this is Python user
 scripting is also possible and a python shell can be run in a plug-in panel
 with full access to all objects in the running radio. 


 

Those are the main points (I think). The reality is that this
is still a work-in-progress. I do have a single code line that works under
Windows and Linux after a certain amount of teething trouble. It looks fine
under Windows and not so great under Linux due to different screen metrics. I
am doing one piece of work at the moment which will lead to a much larger piece
of work and should finally realize the intensions I published over a year ago
and make the result truly cross-platform.

 

The first piece of work is server side. As well as the
actual radio server which is the server side behind the client virtual radio
API, I am doing a controller. The controller will start/restart/stop the server
processes and do things like make the Jack connections. This is a single click
startup of the services and works pretty well. Restart and shutdown have a
number of  problems to be resolved. There is a GUI for this, built of
course with wxPython. I am using this small program to define a build pattern
for the console. I pretty much have this sorted using OO techniques rather than
the monolith GUI builders force you into. It is built using sizers for layout,
otherwise known as layout managers. This means the GUI is resizable but more
importantly will resize automatically to take into account different
resolutions and font sizes etc. The result is it will look good on any platform
with any resolution, display metrics or font the platform substitutes. In
addition a widget factory will produce custom widgets for the entire
application to ensure ease and consistency.

 

As well as making everything truly cross-platform this also
enables one of my other aims which is that the presentation should be built
dynamically and respond to the capability of the radio services by adjusting
its presentation appropriately.

 

The really big piece of work I am about to start is to tear
apart my main console file and apply the same pattern to it. Then do the same
for all the plug-in panels. This will take some time...

 

Next up is to finally add in the missing function which of
course will never complete as desired function exceeds actual function by a
continuous margin.

 

That's all for now folks.

 

73

Re: [Flexradio] Synthedit like interface as a basis for experimen tal SDR?

[Bob . Cowdery]

Title: RE: [Flexradio] Synthedit like interface as a basis for experimental SDR?







Bob


As one that has used and built both graphical and scripted environments in the past I can understand your view and also concur with Frank's view. Graphical environments work well within the constraints of their purpose and design. I know to my cost that a new requirement out of the blue can blow the whole thing apart. The ones I have to use always run out of steam because the designer never thought you 'might want to do that' and so most allow you to extend the framework in some way to do things 'the designer forgot'. If you are not careful the whole application ends up in extensions. Scripted environments are much more powerful and controllable and I like the way GNU Radio has put theirs together.

The original Python console had some aspects of this by allowing a sequence to be built from modules. The amount of effort required to do it really well though, as well as write all the modules was going to be huge and so that aspect of it is frozen in time for the moment.

73
Bob
G3UKB



*** Confidentiality Notice *** 
Proprietary/ConfidentialInformation belonging to CGI Group Inc. and its 
affiliatesmay be contained in this message. If you are not a 
recipientindicated or intended in this message (or responsible 
fordelivery of this message to such person), or you think forany reason 
that this message may have been addressed to youin error, you may not use or 
copy or deliver this messageto anyone else.  In such case, you should 
destroy thismessage and are asked to notify the sender by reply 
email.

[Flexradio] Python Console for the Linux Radio

[Bob . Cowdery]

I have added a page here http://myweb.tiscali.co.uk/g3ukb/realisation.htm
on progress and a little info for any who are interested. The whole site needs
redoing at the moment but I will try to keep that page at least up to date. If
anyone has a good name suggestion for the console and better still an icon or
graphics that would be much appreciated.

 

73

Bob 




*** Confidentiality Notice *** 
Proprietary/ConfidentialInformation belonging to CGI Group Inc. and its 
affiliatesmay be contained in this message. If you are not a 
recipientindicated or intended in this message (or responsible 
fordelivery of this message to such person), or you think forany reason 
that this message may have been addressed to youin error, you may not use or 
copy or deliver this messageto anyone else.  In such case, you should 
destroy thismessage and are asked to notify the sender by reply 
email.

Re: [Flexradio] cygwin-X

[Bob . Cowdery]

Title: RE: [Flexradio] cygwin-X





Umm, if I knew what I was doing I could be dangerous. Yes I am running X server on cygwin as 0.0, it crashes if I try any other screen. I managed to bring up xterm by exporting my local display. I don't have ssh installed at the moment though. I tried on the Suse side exporting the display to my cygwin machine and then running the cygwin X server and typing xterm on Suse. This gives me lots of errors on cygwin:

AUDIT: Sat Jul 23 17:23:38 2005: 440 X: client 1 rejected from IP 192.168.1.102


So is looks like it's the cygwin side rejecting but I can't figure out why.


Bob


-Original Message-
From: Frank Brickle [mailto:[EMAIL PROTECTED]] 
Sent: 22 July 2005 23:26
To: [EMAIL PROTECTED]
Cc: FlexRadio@flex-radio.biz
Subject: Re: [Flexradio] cygwin-X


I assume you're running an X server on the cygwin machine. 
If you bring up a local xterm, can you ssh in it to the SuSE 
machine? If so, what happens if you ssh -X? That should let 
you run X clients on the SuSE machine with the cygwin 
machine X server as the host.


Frank


[EMAIL PROTECTED] wrote:
> Has anyone got cygwin-X to get a logon prompt from SuSE 9.3. I think I 
> have SuSE configured correctly for XDM to listen. There are no personal 
> firewalls in the way. Typing 'X -query ipaddr' at cygwin brings up an X 
> window but no logon.
> 
>  
> 
> 73
> 
> Bob
> 
>  Confidentiality Notice  Proprietary/Confidential
> Information belonging to CGI Group Inc. and its affiliates
> may be contained in this message. If you are not a recipient
> indicated or intended in this message (or responsible for
> delivery of this message to such person), or you think for
> any reason that this message may have been addressed to you
> in error, you may not use or copy or deliver this message
> to anyone else.  In such case, you should destroy this
> message and are asked to notify the sender by reply email.
> 
> 
> 
> 
> ___
> FlexRadio mailing list
> FlexRadio@flex-radio.biz
> http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz



*** Confidentiality Notice *** 
Proprietary/ConfidentialInformation belonging to CGI Group Inc. and its 
affiliatesmay be contained in this message. If you are not a 
recipientindicated or intended in this message (or responsible 
fordelivery of this message to such person), or you think forany reason 
that this message may have been addressed to youin error, you may not use or 
copy or deliver this messageto anyone else.  In such case, you should 
destroy thismessage and are asked to notify the sender by reply 
email.

[Flexradio] cygwin-X

[Bob . Cowdery]

Has anyone got cygwin-X to get a logon prompt from
SuSE 9.3. I think I have SuSE configured correctly for XDM to listen. There are
no personal firewalls in the way. Typing 'X -query ipaddr' at
cygwin brings up an X window but no logon.

 

73

Bob




*** Confidentiality Notice *** 
Proprietary/ConfidentialInformation belonging to CGI Group Inc. and its 
affiliatesmay be contained in this message. If you are not a 
recipientindicated or intended in this message (or responsible 
fordelivery of this message to such person), or you think forany reason 
that this message may have been addressed to youin error, you may not use or 
copy or deliver this messageto anyone else.  In such case, you should 
destroy thismessage and are asked to notify the sender by reply 
email.

Re: [Flexradio] My SDR-1000 webpage

[Bob . Cowdery]

Title: RE: [Flexradio] My SDR-1000 webpage





Beppe


Fantastic job, looks very professional, I'm quite jealous!


73
Bob


-Original Message-
From: Giuseppe Campana [mailto:[EMAIL PROTECTED]] 
Sent: 22 July 2005 10:35
To: flexRadio@flex-radio.biz
Subject: [Flexradio] My SDR-1000 webpage


Hi group


I have published a simple webpage with some pictures of my personal 
projects on SDR-1000 hardware.


http://www.cqdx.it/sdr1000/sdr1000box.html


Thank you for looking


Beppe
IK3VIG




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



*** Confidentiality Notice *** 
Proprietary/ConfidentialInformation belonging to CGI Group Inc. and its 
affiliatesmay be contained in this message. If you are not a 
recipientindicated or intended in this message (or responsible 
fordelivery of this message to such person), or you think forany reason 
that this message may have been addressed to youin error, you may not use or 
copy or deliver this messageto anyone else.  In such case, you should 
destroy thismessage and are asked to notify the sender by reply 
email.

RE: [Flexradio] Linux - we have control

[Bob . Cowdery]

Title: RE: [Flexradio] Linux - we have control





Frank


That will certainly make life easier, perhaps I will concentrate on hooking in Jack and ALSA mixer through Python until the DSP wrapper is available.

73
Bob


-Original Message-
From: Frank Brickle [mailto:[EMAIL PROTECTED]] 
Sent: 21 July 2005 23:24
To: [EMAIL PROTECTED]
Cc: FlexRadio@flex-radio.biz
Subject: Re: [Flexradio] Linux - we have control


Bravo!


Just to make your life a little more interesting, I've been 
extracting the DSP-command part of the virtual radio 
executive -- also Python -- and making a separate module out 
of it.


We have a little traveling to do over the next couple of 
days, but you can expect to have a Python module to command 
the DSP shortly. It should be vulnerable to PyRO-fication as 
well.


73
Frank
AB2KT


[EMAIL PROTECTED] wrote:
> I am sitting here tuning around the bands from my Python console on XP 
> remotely to my Linux box. It sounds brilliant, no dropouts, no 
> discernable latency and NO CLICKS. After the tuning clicks I suffered on 
> XP this makes such a difference. It's very early days, I have control 
> over the hardware only, no control to the DSP or mixer yet and no scope 
> but that will all come. I just love PyRO, it makes remoting a breeze.
> 
>  
> 
> Thanks for the Linux code guys, it's a great job and I'm sure it's just 
> going to keep getting better (now where did I hear that before?).
> 
>  
> 
> 73
> 
> Bob
> 
>  Confidentiality Notice  Proprietary/Confidential
> Information belonging to CGI Group Inc. and its affiliates
> may be contained in this message. If you are not a recipient
> indicated or intended in this message (or responsible for
> delivery of this message to such person), or you think for
> any reason that this message may have been addressed to you
> in error, you may not use or copy or deliver this message
> to anyone else.  In such case, you should destroy this
> message and are asked to notify the sender by reply email.
> 
> 
> 
> 
> ___
> FlexRadio mailing list
> FlexRadio@flex-radio.biz
> http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz



*** Confidentiality Notice *** 
Proprietary/ConfidentialInformation belonging to CGI Group Inc. and its 
affiliatesmay be contained in this message. If you are not a 
recipientindicated or intended in this message (or responsible 
fordelivery of this message to such person), or you think forany reason 
that this message may have been addressed to youin error, you may not use or 
copy or deliver this messageto anyone else.  In such case, you should 
destroy thismessage and are asked to notify the sender by reply 
email.

[Flexradio] Linux - we have control

[Bob . Cowdery]

I am sitting here tuning around the bands from my
Python console on XP remotely to my Linux box. It sounds brilliant, no dropouts,
no discernable latency and NO CLICKS. After the tuning clicks I suffered on XP
this makes such a difference. It's very early days, I have control over
the hardware only, no control to the DSP or mixer yet and no scope but that
will all come. I just love PyRO, it makes remoting a breeze. 

 

Thanks for the Linux code guys, it's a great
job and I'm sure it's just going to keep getting better (now where
did I hear that before?).

 

73

Bob




*** Confidentiality Notice *** 
Proprietary/ConfidentialInformation belonging to CGI Group Inc. and its 
affiliatesmay be contained in this message. If you are not a 
recipientindicated or intended in this message (or responsible 
fordelivery of this message to such person), or you think forany reason 
that this message may have been addressed to youin error, you may not use or 
copy or deliver this messageto anyone else.  In such case, you should 
destroy thismessage and are asked to notify the sender by reply 
email.

RE: [Flexradio] Linux, pyhw(2) broken

[Bob . Cowdery]

Title: RE: [Flexradio] Linux, pyhw(2) broken





Bob


This has gone a bit off topic but just to clear up how I work at the moment. I have three machines in use, none are dual boot.

A dedicated Linux box running Suse 9.3, this is a mini form-factor and sits next to the radio being not that much bigger. It will only ever run DSP and HW control. It is effectively part of the radio. Although obviously connected to my network that is just for downloading stuff and connectivity to the radio clients.

A desktop running XP which is the general family machine and was used to run all the XP SDR stuff as well. It will be one of the radio clients to run the console.

A laptop running XP which is my main machine for home and work and from which I do all my email and basically manage my life. This is where I develop software including the Python console and is the machine I am using as the radio client at the moment. Thus I need to transfer relevant stuff that comes by email or I have developed to the Linux box (I found my USB stick is an easy way to do this for the time being).

Thanks for the tips on tools. I will look into them. Although I have a monitor/keyboard/mouse on the Linux box at the moment my intension is that I will run remote sessions to that box from XP for managing it so the whole thing is remoted.

73
Bob


-Original Message-
From: Robert McGwier [mailto:[EMAIL PROTECTED]] 
Sent: 21 July 2005 01:22
Cc: FlexRadio@flex-radio.biz
Subject: Re: [Flexradio] Linux, pyhw(2) broken


My apologies Bob.  It is amazing how much we take these tools for 
granted that we use all the zip.


I completely misunderstood what was happening.  I thought you were 
working on this on a Suse 9.3 Linux install and to handle that you just to


tar jxf pyhw.tbz


and it will dump the tar-buzz right where it is.  I am very much looking 
forward to a python based console there.


On Windows,  please download Winrar, another shareware tool very similar 
to Winzip.  It will install shell helpers, but you can tell it to leave 
things alone that you want Winzip to handle when you install it.


http://www.rarlab.com/


It can easily handle tar buzzes.


On my windows machines, I would not dream of being away from my *nix 
tools.  So I install cygwin.


http://www.cygwin.com/


I am such a *nix bigot (even when I see Windows doing things in a 
preferrable way) that I thought about encouraging us compiled as a 
cygwin tool.


Bob



Philip M. Lanese wrote:


> Bob
> I tried to send this yesterday but the e-mail sys at QRL uses two 
> different addresses for receiving vs. sending e-mail so the list 
> rejected it.
>  
> If you have Win XP and Linux on the same machine, add a line to mount 
> the windows partition/folder to the Linux boot file and the 
> partition/folder will be mounted like any Linux file.  You can 
> then R/W files on the WinXP partition from Linux.  I used the 
> technique a lot when I all I had was a winmodem for my old dialup 
> telephone connection.
>  
> Phil, K3IB
>
> - Original Message -
> *From:* [EMAIL PROTECTED]
> 
> *To:* FlexRadio@flex-radio.biz 
> *Sent:* Wednesday, July 20, 2005 11:52 AM
> *Subject:* RE: [Flexradio] Linux, pyhw(2) broken
>
> Frank
>
> Thanks for the file. I was going to have a look at it but as I
> only have XP here it can't handle .tbz although I think it can a
> .tgz, so any chance of a tgz.
>
> Is pyhw2 still the correct one to use when it gets fixed or is it
> replaced by this new file?
>
> Any advice on the simplest way to get bi-directional file transfer
> between XP and Linux as my current route is not great.
>
> Thanks
> Bob
>
>
>
>
>___
>FlexRadio mailing list
>FlexRadio@flex-radio.biz
>http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
>  
>




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



*** Confidentiality Notice *** 
Proprietary/ConfidentialInformation belonging to CGI Group Inc. and its 
affiliatesmay be contained in this message. If you are not a 
recipientindicated or intended in this message (or responsible 
fordelivery of this message to such person), or you think forany reason 
that this message may have been addressed to youin error, you may not use or 
copy or deliver this messageto anyone else.  In such case, you should 
destroy thismessage and are asked to notify the sender by reply 
email.

RE: [Flexradio] Linux, pyhw(2) broken

[Bob . Cowdery]

Title: RE: [Flexradio] Linux, pyhw(2) broken





Yes I have 9.3 and it is good, so far everything works well and ALSA works fine with my Santa Cruz card.


Bob



That is *excellent* news. BTW I just upgraded to SuSE 9.3 
and it really is an improvement over its predecessors, worth 
doing if you haven't made that move yet.


Frank


[EMAIL PROTECTED] wrote:
> Fantastic, I have a working radio, if a little on the manual side at the 
> moment. I also found that SuSe is a little brighter than I thought. If I 
> just plug my USB stick in it mounts it and I can copy files across.
> 
> Thanks for the help
> 
> 73
> Bob
> 
> 
> -Original Message-
> From: Frank Brickle [mailto:[EMAIL PROTECTED]]
> Sent: 20 July 2005 17:39
> To: [EMAIL PROTECTED]
> Subject: Re: [Flexradio] Linux, pyhw(2) broken
> 
> While I still had XP on my laptop I installed cygwin and
> used ssh/scp.
> 
> Frank
> 
> 
>  > Thanks for the tar. I was just meaning file transfer, ftp, samba, usb
>  > drives etc.
> 
>  Confidentiality Notice  Proprietary/Confidential
> Information belonging to CGI Group Inc. and its affiliates
> may be contained in this message. If you are not a recipient
> indicated or intended in this message (or responsible for
> delivery of this message to such person), or you think for
> any reason that this message may have been addressed to you
> in error, you may not use or copy or deliver this message
> to anyone else.  In such case, you should destroy this
> message and are asked to notify the sender by reply email.
> 
> 
> 
> 
> ___
> FlexRadio mailing list
> FlexRadio@flex-radio.biz
> http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz



*** Confidentiality Notice *** 
Proprietary/ConfidentialInformation belonging to CGI Group Inc. and its 
affiliatesmay be contained in this message. If you are not a 
recipientindicated or intended in this message (or responsible 
fordelivery of this message to such person), or you think forany reason 
that this message may have been addressed to youin error, you may not use or 
copy or deliver this messageto anyone else.  In such case, you should 
destroy thismessage and are asked to notify the sender by reply 
email.

RE: [Flexradio] Linux - mode selection

[Bob . Cowdery]

Title: RE: [Flexradio] Linux - mode selection





Cunning, I didn't think of that one. Now I can get on with the main work in hand.


Bob


-Original Message-
From: Frank Brickle [mailto:[EMAIL PROTECTED]] 
Sent: 20 July 2005 21:38
To: [EMAIL PROTECTED]
Subject: Re: [Flexradio] Linux - mode selection


Ah. You've fallen for our chicanery. LSB, USB, CWL, and CWL 
are all actually the same mode. The difference between the 
lower and upper settings is entirely in the filter: the 
lower versions need negative settings, the upper, positive. 
So, for example, to get CWL, you would select any of the 
above, and then follow it with, say,
setFilter -1000 -500 RX
yielding a passband between -1000 and -500 Hz.


Automatic "polarity" of the filters, along with appropriate 
bandwidths, is set "above" the DSP commands with selection 
of the mode in the console, virtual radio executive, etc.


The canonical set of symbol substitutions is found in the 
enums.m4 file.


Frank


[EMAIL PROTECTED] wrote:
> I have done some more experimenting on the mode problem I reported earlier.
> 
>  
> 
> I notice from the messages that the modes are set as follows:
> 
> 0 = LSB
> 
> 1 = USB
> 
> 2 = DSB
> 
> 3 = CWL
> 
> 4 = CWU
> 
> 5 = FM
> 
> 6 = AM
> 
>  
> 
> Using 'setMode LSB' etc the above is reflected by jsdr. However, 0,1,2 
> and 3 all seem to select lower sideband, AM and FM appear to be correct. 
> If I start typing in numbers I find that 'setMode 7' selects USB.
> 
>  
> 
> 73
> 
> Bob
> 
>  
> 
>  
> 
>  Confidentiality Notice  Proprietary/Confidential
> Information belonging to CGI Group Inc. and its affiliates
> may be contained in this message. If you are not a recipient
> indicated or intended in this message (or responsible for
> delivery of this message to such person), or you think for
> any reason that this message may have been addressed to you
> in error, you may not use or copy or deliver this message
> to anyone else.  In such case, you should destroy this
> message and are asked to notify the sender by reply email.
> 
> 
> 
> 
> ___
> FlexRadio mailing list
> FlexRadio@flex-radio.biz
> http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz



*** Confidentiality Notice *** 
Proprietary/ConfidentialInformation belonging to CGI Group Inc. and its 
affiliatesmay be contained in this message. If you are not a 
recipientindicated or intended in this message (or responsible 
fordelivery of this message to such person), or you think forany reason 
that this message may have been addressed to youin error, you may not use or 
copy or deliver this messageto anyone else.  In such case, you should 
destroy thismessage and are asked to notify the sender by reply 
email.

[Flexradio] Linux - mode selection

[Bob . Cowdery]

I have done some more experimenting on the mode
problem I reported earlier.

 

I notice from the messages that the modes are set as
follows:

0 = LSB

1 = USB

2 = DSB

3 = CWL

4 = CWU

5 = FM

6 = AM

 

Using 'setMode LSB' etc the above is
reflected by jsdr. However, 0,1,2 and 3 all seem to select lower sideband, AM
and FM appear to be correct. If I start typing in numbers I find that 'setMode
7' selects USB.

 

73

Bob

 

 




*** Confidentiality Notice *** 
Proprietary/ConfidentialInformation belonging to CGI Group Inc. and its 
affiliatesmay be contained in this message. If you are not a 
recipientindicated or intended in this message (or responsible 
fordelivery of this message to such person), or you think forany reason 
that this message may have been addressed to youin error, you may not use or 
copy or deliver this messageto anyone else.  In such case, you should 
destroy thismessage and are asked to notify the sender by reply 
email.

RE: [Flexradio] Linux, pyhw(2) broken

[Bob . Cowdery]

Title: RE: [Flexradio] Linux, pyhw(2) broken





Fantastic, I have a working radio, if a little on the manual side at the moment. I also found that SuSe is a little brighter than I thought. If I just plug my USB stick in it mounts it and I can copy files across.

Thanks for the help


73
Bob



-Original Message-
From: Frank Brickle [mailto:[EMAIL PROTECTED]] 
Sent: 20 July 2005 17:39
To: [EMAIL PROTECTED]
Subject: Re: [Flexradio] Linux, pyhw(2) broken


While I still had XP on my laptop I installed cygwin and 
used ssh/scp.


Frank



> Thanks for the tar. I was just meaning file transfer, ftp, samba, usb 
> drives etc.



*** Confidentiality Notice *** 
Proprietary/ConfidentialInformation belonging to CGI Group Inc. and its 
affiliatesmay be contained in this message. If you are not a 
recipientindicated or intended in this message (or responsible 
fordelivery of this message to such person), or you think forany reason 
that this message may have been addressed to youin error, you may not use or 
copy or deliver this messageto anyone else.  In such case, you should 
destroy thismessage and are asked to notify the sender by reply 
email.

RE: [Flexradio] Linux, pyhw(2) broken

[Bob . Cowdery]

Title: RE: [Flexradio] Linux, pyhw(2) broken





Thanks for the tar. I was just meaning file transfer, ftp, samba, usb drives etc.


Bob


> Bob --


> Here it is as a pure tarfile. Not too big. Remember it needs 
> to be remade from scratch.
>
> To be honest, I'm not sure where we stand now wrt pyhw and 
> pyhw2 -- please use this one for the time being, while we 
> try to nail down the problems with pyhw2. This is a 
> reversion to the earlier code. The newer code is necessary 
> to handle the amplifier, but none of the current Linux users 
> has that.
>
> I'm not sure what your question about bi-directional 
> transfer is getting at -- do you mean, on an occasional 
> basis, or as a constant streaming-type connection?



*** Confidentiality Notice *** 
Proprietary/ConfidentialInformation belonging to CGI Group Inc. and its 
affiliatesmay be contained in this message. If you are not a 
recipientindicated or intended in this message (or responsible 
fordelivery of this message to such person), or you think forany reason 
that this message may have been addressed to youin error, you may not use or 
copy or deliver this messageto anyone else.  In such case, you should 
destroy thismessage and are asked to notify the sender by reply 
email.

RE: [Flexradio] Linux, pyhw(2) broken

[Bob . Cowdery]

Title: RE: [Flexradio] Linux, pyhw(2) broken





Frank


Thanks for the file. I was going to have a look at it but as I only have XP here it can't handle .tbz although I think it can a .tgz, so any chance of a tgz.

Is pyhw2 still the correct one to use when it gets fixed or is it replaced by this new file?


Any advice on the simplest way to get bi-directional file transfer between XP and Linux as my current route is not great.

Thanks
Bob 



> pyhw had undergone some changes from the way I left it.  This is my 
> fault for not testing.  I had to reimplement from the old stuff.
> I can only guarantee that this is working like a champ with my RFE 
> installed radios.  I tried to make the same changes in pyhw2 but
> to no avail, so something is different.  pyhw works with the RFE.




*** Confidentiality Notice *** 
Proprietary/ConfidentialInformation belonging to CGI Group Inc. and its 
affiliatesmay be contained in this message. If you are not a 
recipientindicated or intended in this message (or responsible 
fordelivery of this message to such person), or you think forany reason 
that this message may have been addressed to youin error, you may not use or 
copy or deliver this messageto anyone else.  In such case, you should 
destroy thismessage and are asked to notify the sender by reply 
email.

[Flexradio] RE: Linux

[Bob . Cowdery]

 

Frank Brickle wrote

 

> Bob, are you using pyhw
or pyhw2? Are other hardware 

> commands working all
right?

 

I just had a quick trawl
through the code and it looks fine. The only possibility I can see is that DDSReset()
is only called from StandBy() and nothing calls this as I just run
sdr1k-setup.py and then call methods straight from Python interactive shell.
Would this stop the DDS working? I will try calling StandBy() first when I get
home to see if it makes any difference.

 

73

Bob




*** Confidentiality Notice *** 
Proprietary/ConfidentialInformation belonging to CGI Group Inc. and its 
affiliatesmay be contained in this message. If you are not a 
recipientindicated or intended in this message (or responsible 
fordelivery of this message to such person), or you think forany reason 
that this message may have been addressed to youin error, you may not use or 
copy or deliver this messageto anyone else.  In such case, you should 
destroy thismessage and are asked to notify the sender by reply 
email.

[Flexradio] RE: Linux

[Bob . Cowdery]

Frank Brickle wrote

 

> Bob, are you using pyhw
or pyhw2? Are other hardware 

> commands working all
right?

 

I am using pyhw2 and other commands as far as I can
tell work correctly. I played with the latch delay but to no effect. If I do getDDSFreq()
it correctly reflects the value I entered. I presume this works for everyone
else?

 

73

Bob




*** Confidentiality Notice *** 
Proprietary/ConfidentialInformation belonging to CGI Group Inc. and its 
affiliatesmay be contained in this message. If you are not a 
recipientindicated or intended in this message (or responsible 
fordelivery of this message to such person), or you think forany reason 
that this message may have been addressed to youin error, you may not use or 
copy or deliver this messageto anyone else.  In such case, you should 
destroy thismessage and are asked to notify the sender by reply 
email.

[Flexradio] Linux

[Bob . Cowdery]

Things progress slowly here, mainly due to 2 weeks
hard labour on my driveway!

 

Moving up from the lashed together proof of concept
system I am now the proud owner of an iDEQ mini system with a Sempron 2800+. It
has SUSE 9.3 loaded which I eventually decided was probably the most sensible
choice. I now consider this box to be part of the radio. Pretty much everything
is stable now on the Linux box itself but I have a couple of odd problems which
I need to solve before moving back to getting the remote console going.

 


 Doing a 'setMode LSB' and 'setMode
 USB' seem to both select LSB. At least the received audio on LSB stays
 exactly where it is. Odd thing is I ventured up to 20M and could resolve
 there as well so don't quite know what's going on.
 The setDDSFreq() does not set the frequency
 although it does set the band relay. Other commands seem to work ok. I don't
 have an RFE board so changed sdr1k-setup.py to reflect that. I can set the
 frequency from the Windows Python console fine while still running the DSP
 through Linux, so again not sure what's going on.


 

I have not really investigated these which I will if
the answer is not blindingly obvious to someone.

 

73

Bob




*** Confidentiality Notice *** 
Proprietary/ConfidentialInformation belonging to CGI Group Inc. and its 
affiliatesmay be contained in this message. If you are not a 
recipientindicated or intended in this message (or responsible 
fordelivery of this message to such person), or you think forany reason 
that this message may have been addressed to youin error, you may not use or 
copy or deliver this messageto anyone else.  In such case, you should 
destroy thismessage and are asked to notify the sender by reply 
email.

RE: [Flexradio] Linux/Windows hybrid

[Bob . Cowdery]

Title: RE: [Flexradio] Linux/Windows hybrid





Great stuff Frank. I cut my teeth on Unix 25 years ago and really haven't touched it much since. It's amazing how much it's moved forward and yet stayed fundamentally the same.

If only I didn't have to work for a living!


I must admit not having looked at the dsp code yet but I did notice the named pipes for the display data, which I will need to hook into at some point. As my cat keeps saying 'so much time and so little to do' -- or should that be the other way round.

Bob


-Original Message-
From: Frank Brickle [mailto:[EMAIL PROTECTED]] 
Sent: 24 June 2005 15:01
To: [EMAIL PROTECTED]
Subject: Re: [Flexradio] Linux/Windows hybrid


Bob --


Bravo!


> This is all going to be unashamedly pythonic.


Works for me :-)


>    6. I notice a lot of traffic on the list to do with virtual comms and
>   sound interfaces. I don't know but I think we possibly have other
>   options in linux. Could we use Jack for example to route samples
>   to other applications.


That's exactly what you would do, and what it's for.


In the Linux version there's a separate pair of controllable 
audion inputs, jack ports, that mix with the other inputs. 
The aux audio channels mix with the RX stream as *late* as 
possible, with the TX stream as *early* as possible.


Over the next few days I will be adding another pair of 
ports for aux output, which will be tappable at different 
stages in the RX or TX chain. If you look at the 
scope/spectrum code, you'll see there's a long circular 
buffer of sample data which only gets processed and sent to 
a client on request, through a named pipe. This same sample 
data will be available as a continuous stream on the aux 
jack output ports.


One other little utility coming shortly is a jack client 
that does nothing but downsample audio from 48k to 8k and 
convert to ulaw, or vice-versa. Should definitely ease the 
network burden. Should be pretty easy to incorporate other 
forms of audio compression and coding on this model.


Great work, Bob.


73
Frank
AB2KT



*** Confidentiality Notice *** 
Proprietary/ConfidentialInformation belonging to CGI Group Inc. and its 
affiliatesmay be contained in this message. If you are not a 
recipientindicated or intended in this message (or responsible 
fordelivery of this message to such person), or you think forany reason 
that this message may have been addressed to youin error, you may not use or 
copy or deliver this messageto anyone else.  In such case, you should 
destroy thismessage and are asked to notify the sender by reply 
email.

[Flexradio] Linux/Windows hybrid

[Bob . Cowdery]

A quick round the houses on where things are. This is
proof of concept stuff at the moment but it's all looking quite
promising. The python console is stripped down and relieved of its dsp and
audio processing. A client API is built to hide the console behind which
provides control, dsp and mixer functions. A remote server is written to handle
the other end of the link but only hooked into the Linux HW controller at
present. Stuff starts up, relays click and things happen but not quite as we
know it at the moment! The route I am taking is very much as I described on my
web site several months ago except that running the console under Windows and
the server under Linux didn't really occur to me at that time, but being
able to use the great linux stuff that you guys have built is really going to
make this happen - will take a while, but I am very excited about the
possibilities here. I will be sticking to wxPython for the UI at present
because its there and it works, web interfaces are still way down the list.

 

This is all going to be unashamedly pythonic. In no
particular order, things I know, things I think I know and things I need to
know.

 


 All communication between clients and servers is
 over TCP/IP using Pyro (Python Remote Objects) because it works so well
 and is now proven between Linux and Windows. When it comes to streaming I
 may use a different channel although I have streamed under windows with
 this setup and it works pretty well.
 Services will be granular, that is dsp, control,
 mixer, digital modes, loggers etc will exist at that level on servers.
 Orchestration will be from the client to allow maximum flexibility in
 where things are located. The orchestration is south of the API so the
 console knows nothing about this.
 Services will be located using the Pyro NameServer,
 this gives complete transparency of location, from everything on the same box
 to distributed over arbitrary linux and windows boxes. Each service has a
 textual name which is all that needs to be known to connect to it.
 Several python modules I have located look like
 being very useful to fully automate the linux side. These are -
 
  Python-ipc http://www.xs4all.nl/~walterj/python-ipc/
  to hook into jdsp.
  Pyalsa  http://respyre.org/pyalsa.html,
  a python alsa mixer.
  Pyjack http://www.corpuselectronica.com/software,
  a python interface to Jack.
  
  All these of course are actually 'c' programs, either extensions
  or swigged to a python interface. I don't know if any of them
  actually work yet but it's better than starting from scratch. With
  a bit of glue from the Pyro server which will start as a daemon it should
  be possible to get everything up and running without human intervention.
 
 In doing the interfaces I have realised things
 have moved on a lot from when I last looked at this stuff and I don't
 understand what a lot of the methods do in the controller/dsp. At some
 point some API documentation would be very useful. I could look at the C#
 code to see what it does but I don't know if that actually uses all
 the available methods in the way the author intended although I would
 guess it probably does. Bottom line, my console has a lot of catching up
 to do.
 I notice a lot of traffic on the list to do with
 virtual comms and sound interfaces. I don't know but I think we
 possibly have other options in linux. Could we use Jack for example to
 route samples to other applications.


 

73

Bob




*** Confidentiality Notice *** 
Proprietary/ConfidentialInformation belonging to CGI Group Inc. and its 
affiliatesmay be contained in this message. If you are not a 
recipientindicated or intended in this message (or responsible 
fordelivery of this message to such person), or you think forany reason 
that this message may have been addressed to youin error, you may not use or 
copy or deliver this messageto anyone else.  In such case, you should 
destroy thismessage and are asked to notify the sender by reply 
email.

[Flexradio] Linux file missing

[Bob . Cowdery]

Hardware.h seems to be missing from the pyhw2
directory in CVS.

 

73

Bob




*** Confidentiality Notice *** 
Proprietary/ConfidentialInformation belonging to CGI Group Inc. and its 
affiliatesmay be contained in this message. If you are not a 
recipientindicated or intended in this message (or responsible 
fordelivery of this message to such person), or you think forany reason 
that this message may have been addressed to youin error, you may not use or 
copy or deliver this messageto anyone else.  In such case, you should 
destroy thismessage and are asked to notify the sender by reply 
email.

RE: [Flexradio] Which way now!

[Bob . Cowdery]

Title: RE: [Flexradio] Which way now!





Frank


Thanks for the info, when I get as far as wanting to make a connection I may quiz you a little more. Could you elaborate please on what the Virtual Radio code provides? Also what are the plans for an audio mixer? Should I use something like 'expect' over amixer for the time being.

73
Bob


-Original Message-
From: Frank Brickle [mailto:[EMAIL PROTECTED]] 
Sent: 20 June 2005 22:31
To: [EMAIL PROTECTED]
Cc: FlexRadio@flex-radio.biz
Subject: Re: [Flexradio] Which way now!


There are a myriad of ways to do it. One of them is to use 
the Python "expect" package at the client end and merely 
open a python at the host end using faucet.


Another way is to open a python on the host using faucet, 
but to have its __main__ run a loop that grabs up stdin a 
line at a time, does an eval() on the line, and prints the 
return value to stdout. The nice thing about the python 
eval(), security issues aside, is that it evaluates its 
arguments in the current lexical context, rather than at 
toplevel as in Lisp.


This is just to get started. I'm sure you will find a 
solution better suited to your purposes soon enough.


The Virtual Radio Python code will be running as a daemon, 
so both the DSP and hardware code will be accessible and 
directly executable via that socket connection.


73
Frank
AB2KT


[EMAIL PROTECTED] wrote:
> That sounds easy. I can open a socket straight from Python and stuff 
> commands down it. I know the DSP works that way. The HW control has a 
> Python wrapper but can it work from a FIFO as well?
> 
> Bob
> 
> n4hy wrote:
>  > The correct approach is to talk to the Linux animal on its port.  The
>  > Windows code will
>  > be nearly identical.  You will be able to choose between sockets and
>  > named pipes.  On
>  > Linux,  there needs to be a piece of code that is listening (however you
>  > want it to listen,
>  > sockets, etc.) and then writing instructions to the command fifo (pipe),
>  > etc.
> 
> The Linux code will probably look something like:
> 
> $ faucet 5801 --in cat - >./IPC/sdr-1000-0-commands.fifo &
> 
> and you will open port 5801 on the Linux host from someplace
> else. Whatever is written there will go right to the command
> pipe.
> 
> 
>  Confidentiality Notice  Proprietary/Confidential
> Information belonging to CGI Group Inc. and its affiliates
> may be contained in this message. If you are not a recipient
> indicated or intended in this message (or responsible for
> delivery of this message to such person), or you think for
> any reason that this message may have been addressed to you
> in error, you may not use or copy or deliver this message
> to anyone else.  In such case, you should destroy this
> message and are asked to notify the sender by reply email.
> 
> 
> 
> 
> ___
> FlexRadio mailing list
> FlexRadio@flex-radio.biz
> http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz



*** Confidentiality Notice *** 
Proprietary/ConfidentialInformation belonging to CGI Group Inc. and its 
affiliatesmay be contained in this message. If you are not a 
recipientindicated or intended in this message (or responsible 
fordelivery of this message to such person), or you think forany reason 
that this message may have been addressed to youin error, you may not use or 
copy or deliver this messageto anyone else.  In such case, you should 
destroy thismessage and are asked to notify the sender by reply 
email.

RE: [Flexradio] Which way now!

[Bob . Cowdery]

Title: RE: [Flexradio] Which way now!






nh4y wrote:
>I am really happy you are doing this.  The LV-672 price is cheaper than 
>here by $100.
>When I get ready for one I will send you the money. ;-)


That price was probably without tax, it doesn't say including VAT so probably it doesn't. That would bring the price to £176 plus various postages so the saving would probably not be that much.

Bob 



*** Confidentiality Notice *** 
Proprietary/ConfidentialInformation belonging to CGI Group Inc. and its 
affiliatesmay be contained in this message. If you are not a 
recipientindicated or intended in this message (or responsible 
fordelivery of this message to such person), or you think forany reason 
that this message may have been addressed to youin error, you may not use or 
copy or deliver this messageto anyone else.  In such case, you should 
destroy thismessage and are asked to notify the sender by reply 
email.

RE: [Flexradio] Which way now!

[Bob . Cowdery]

Title: RE: [Flexradio] Which way now!





That sounds easy. I can open a socket straight from Python and stuff commands down it. I know the DSP works that way. The HW control has a Python wrapper but can it work from a FIFO as well?

Bob


n4hy wrote:
> The correct approach is to talk to the Linux animal on its port.  The 
> Windows code will
> be nearly identical.  You will be able to choose between sockets and 
> named pipes.  On
> Linux,  there needs to be a piece of code that is listening (however you 
> want it to listen,
> sockets, etc.) and then writing instructions to the command fifo (pipe), 
> etc.


The Linux code will probably look something like:


$ faucet 5801 --in cat - >./IPC/sdr-1000-0-commands.fifo &


and you will open port 5801 on the Linux host from someplace 
else. Whatever is written there will go right to the command 
pipe.




*** Confidentiality Notice *** 
Proprietary/ConfidentialInformation belonging to CGI Group Inc. and its 
affiliatesmay be contained in this message. If you are not a 
recipientindicated or intended in this message (or responsible 
fordelivery of this message to such person), or you think forany reason 
that this message may have been addressed to youin error, you may not use or 
copy or deliver this messageto anyone else.  In such case, you should 
destroy thismessage and are asked to notify the sender by reply 
email.

RE: [Flexradio] Which way now!

[Bob . Cowdery]

Title: RE: [Flexradio] Which way now!







Nh4y wrote:
>My wife covets my Mini.  I might get the LV-672.


I will have to consider the Pentium based boards as well although more expensive could be a better investment but the VIA boards are fast enough. The LV-672 looks very good... £150 over here without processor, don't know how that stacks up.

Frank Brickle wrote:
> As a first approximation, you might want to have a look at 
> netpipes.


I will investigate that. First call is to build an interface so I can plug and play different comms and see what I like. Is there a Windows API or do I just open a socket and write to it? 

Thanks for the other comments Frank. I had never really thought about a hybrid system before but it makes a lot of sense to me now. I recon if I could get a solid week I could have it all going, trouble is that week is likely to get fragmented over several months.

73
Bob



*** Confidentiality Notice *** 
Proprietary/ConfidentialInformation belonging to CGI Group Inc. and its 
affiliatesmay be contained in this message. If you are not a 
recipientindicated or intended in this message (or responsible 
fordelivery of this message to such person), or you think forany reason 
that this message may have been addressed to youin error, you may not use or 
copy or deliver this messageto anyone else.  In such case, you should 
destroy thismessage and are asked to notify the sender by reply 
email.

[Flexradio] Which way now!

[Bob . Cowdery]

If there was only one way to do everything life would
be easy but extremely boring. I have been pondering how to fit a little bit of
radio into a hectic life. Starting to write this I don't have a clear
idea but when I finish writing I will have a much better idea, that is why I do
these ramblings - not because I think anyone might be interested - but
you never know it might strike a chord somewhere.

 

This is just my perspective although as some may
realise my mind is never made up until I arrive somewhere. I love Linux and for
me it is the right place to be doing the 'radio stuff', especially
as I want to take advantage of the latest releases of both the SDR1000 DSP and
GNU-Radio DSP blocks. 

 

However, I run XP most of the time for work and home and
like to be able to play with the radio application software when I have a few
moments. When I have Linux booted up my wife invariably wants to do something,
and doesn't understand this 'operating system thing' and at
work it's virtually impossible to have Linux running. I already have a
split system working, Linux for DSP and XP for application but it's far
from properly integrated.

 

What am I pondering, well I kind of like the idea of
separation of concerns so the radio concern is the hardware and DSP functions
and probably the control functions. What I am warming to is almost a separate
radio using a Mini-ITX form factor motherboard, possibly the VIA EPIA SP13000
running Linux (not entirely decided on the distro but it will probably be Fedora).
These are not the fastest things on earth but they are cute (and cheap) and
should be fast enough to just run DSP with a good bit of headroom. These boards
have most everything required including 1 PCI slot for the Delta 44 or whatever
but no parallel port so the USB/Parallel converter would be required.

 

First off I get the hardware up and running doing its
DSP stuff and hopefully I won't have the hassle with ALSA this time. I
then create a remote link from my Python console running under Windows using
Pyro over TCP/IP (this works well XP-XP so should work equally well XP-Linux).
This controls the DSP using a simple Python wrapper over the IPC on the Linux
side and hooks straight into GNURadio which is already pythonized. I can use
the HW control directly from XP initially and then create a similar remote
function for that on Linux. The remaining piece is the metering and display
data which can come across the same Pyro link. Full remoting can come later.
All in all this is not a massive piece of work so might even get done this side
of never! If it looks good I will have an incentive to move the console
forward.

 

Bottom line, I love Linux for its elegance and performance
and I love Python for its simplicity and power, and XP - well I have too
much investment to ditch it.

 

73

Bob




*** Confidentiality Notice *** 
Proprietary/ConfidentialInformation belonging to CGI Group Inc. and its 
affiliatesmay be contained in this message. If you are not a 
recipientindicated or intended in this message (or responsible 
fordelivery of this message to such person), or you think forany reason 
that this message may have been addressed to youin error, you may not use or 
copy or deliver this messageto anyone else.  In such case, you should 
destroy thismessage and are asked to notify the sender by reply 
email.

RE: [Flexradio] Linux and Santa Cruz

[Bob . Cowdery]

Title: RE: [Flexradio] Linux and Santa Cruz





Dan


Dan


Thanks for the hints, I did stumble across alsaconf yesterday while reading some of the ALSA threads. It finds both the built-in and the Santa Cruz (twice each for some reason). I can configure the built-in with it ok but the Santa Cruz still fails. Also the devices still don't get made unless I run snddevices. If I configure Santa Cruz first then even the built-in won't work if I run alsaconf against it until I reboot and do it first. This and the fact that alsasound seg faults does make me think there is a more fundamental installation problem or maybe even a problem with soundcore in Mandrake. I'm still a beginner in this stuff and treating it all as a learning experience at the moment. 

73 Bob


-Original Message-
From: Dan Babcock [mailto:[EMAIL PROTECTED]] 
Sent: 13 June 2005 01:51
To: FlexRadio@flex-radio.biz
Subject: Re: [Flexradio] Linux and Santa Cruz




Bob,


ALSA has a very nice utilities package
(alsa-utils)that among others contains a very useful
utility called "alsaconf."  


You can inquire if it is already installed on your OS
by typing in a terminal (as root) "which alsaconf." If
that command returns /usr/sbin/alsaconf or something
similar, alsaconf is already installed. If that is the
case then start alsaconf by typing in (as root) the
full path and file name for the executable, ie.,
/usr/sbin/alsaconf.  


The alsaconf utility will query your OS to find the
hardware configuration of the audio system.  It will
then configure ALSA to run correctly.  With the Santa
Cruz sound card, there should be a 99% certainty it
will set up ALSA correctly.


If the alsaconf utility is not found by the "which"
command, first try to finding the alsa-utils RPM for
your distribution and installing it.  If there is no
available RPM, a tarball for alsa-utils can be found
on the ALSA website http://www.alsa-project.org/


There is another utility called alsamixergui that
provides an easy to use graphical user interface to 
the alsa mixer.  It can also be found in most cases as
an RPM for a specific distro or as a tarball on the
ALSA website.


By the way the ALSA Project website has, not
trivially, a treasure trove of information about ALSA
either on the site or available via sumerous links. 
Great reading if your are interested in those sort of
things. 


73,


Dan N4XWE



--- [EMAIL PROTECTED] wrote:


> Does anyone out there in SDR1000 land have a Santa
> Cruz card working under
> Linux? I have tried everything I know and everything
> the ALSA site knows,
> but capture just refuses to capture. The card
> appears to be configured
> correctly and all the trouble shooting hints show
> everything to be dandy. I
> have followed all the recommended mixer settings and
> just about every
> combination that wasn't recommended. I have compiled
> all the latest stable
> releases to no avail. I can get lovely crosstalk but
> that's all I get. I can
> play a sound file with asound, but alas alsaplayer
> segfaults.
> 
>  
> 
> I have been using Mandrake 10.1 on a USB drive for
> all the above. I tried
> Knoppix live CD which did a great job of detecting
> my hardware and even the
> Santa Cruz. I got exactly the same problem and the
> Knoppix release was using
> OSS not ALSA. Not to be beaten I had a live CD copy
> of Suse 9.3 which
> unfortunately failed to detect any sound cards.
> 
>  
> 
> I'm not complaining mind you, it's been very
> instructional and I have learnt
> a lot about ALSA and Jack and despite everything
> they are still my friends.
> 
>  
> 
> 73
> 
> Bob
> 



        
__ 
Discover Yahoo! 
Get on-the-go sports scores, stock quotes, news and more. Check it out! 
http://discover.yahoo.com/mobile.html


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



*** Confidentiality Notice *** 
Proprietary/ConfidentialInformation belonging to CGI Group Inc. and its 
affiliatesmay be contained in this message. If you are not a 
recipientindicated or intended in this message (or responsible 
fordelivery of this message to such person), or you think forany reason 
that this message may have been addressed to youin error, you may not use or 
copy or deliver this messageto anyone else.  In such case, you should 
destroy thismessage and are asked to notify the sender by reply 
email.

[Flexradio] New Linux release

[Bob . Cowdery]

I just downloaded the new Linux release but there are
no files in the pyhw2 directory.

 

73

Bob




*** Confidentiality Notice *** 
Proprietary/ConfidentialInformation belonging to CGI Group Inc. and its 
affiliatesmay be contained in this message. If you are not a 
recipientindicated or intended in this message (or responsible 
fordelivery of this message to such person), or you think forany reason 
that this message may have been addressed to youin error, you may not use or 
copy or deliver this messageto anyone else.  In such case, you should 
destroy thismessage and are asked to notify the sender by reply 
email.