[Flexradio] Acorn-sdr
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
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 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 btr...@anvilcom.com 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 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
Re: [Flexradio] Can anyone help?
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 b...@g3ukb.co.uk 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 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] Can anyone help?
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
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
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
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
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 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
Re: [Flexradio] A proposal
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 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
Re: [Flexradio] A proposal
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 flexRadio@flex-radio.biz 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 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
Re: [Flexradio] A proposal
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 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
Re: [Flexradio] A proposal
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 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
Re: [Flexradio] G3UKB new API demo filter GUI
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 flexradio@flex-radio.biz 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
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/
[Flexradio] What do users really really want...
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
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
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
Re: [Flexradio] Q for software team (Was: PowerSDR Open Source Fan)
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)
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. 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
Re: [Flexradio] Q for software team (Was: PowerSDR Open Source Fan)
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)
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] Erlang, my second steps (was my first steps)
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 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
Re: [Flexradio] Erlang, my first steps
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-radio.biz/ FlexRadio Homepage:
Re: [Flexradio] Erlang, my first steps
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 that I and others can question things and get reasoned answers. I think this and the previous thread I had with Frank has increased my knowledge 100% and I feel much more comfortable
Re: [Flexradio] Erlang, my first steps
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
Re: [Flexradio] Erlang, my first steps
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 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
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?
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? http://sourceforge.net/projects/pyerlbridge/
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?
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?
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 towards having the nodes local or remote. 3 Ok. Please
Re: [Flexradio] Console Graphics - maybe mode-specific?
On Sun, 2006-08-27 at 13:33 -0400, Frank Brickle wrote: On Sun, 2006-08-27 at 16:13 +0100, Bob Cowdery wrote: 2 I don't know if this is a real difference in topology or not. I didn't envisage a central service but more a peer-to-peer network where the VR is just a node even if that node is 'hidden' in the sense that all commands from other nodes route to the VR node by default. There is certainly a difference of expression if not conception here. In the scenario I'm imagining, the only thing visible to any of the nodes except the kernel, is the kernel. However the kernel sees all nodes (at this level of abstraction). Furthermore the only node directly visible to the user is the UI node. I think it's only a difference in expression, the semantics are the same. There may be a difference in implementation terms but I'm not sure what it is. ...One of the VR's responsibilities is definitely to understand what needs to be done (in terms of what messages need to be sent to other nodes) to complete a request... To put it a little more emphatically: the kernel is the interface between the front end (the UI) and the back end (the DSP and hardware). It's the kernel's job to implement vocabularies that the front end can use and the back end can understand. The mapping between front end and back end vocabularies is complex and potentially many-to-one in either direction. 2 I've looked at the ports tutorial and as far as I can tell the underlying interface is pipes which talk to external processes via stdin/stdout... That is the simplest form. On the other hand, several languages including C, Python, and Java (I think) have libraries which let them behave as if they were native Erlang nodes. I've done a bit more digging. There seems to be three options for integration: 1. The arms length pipes (I think this can be TCP/IP as well and possibly some others (according to some papers I read)). Pipes only work for *nix so it means an extra sockets hop under Windows on the same machine. 2. Port Drivers which are effectively shared libraries .so or .dll for *nix and Windows. This seems to be limited to languages that can create proper shared libraries, predominantly aimed at C. 3. C Nodes which are definitely C only and receive native Erlang messages. There is mention of the Erl_Interface for C and Java. I think these are C Node implementations, not sure how Java is done. I haven't seen anything for Python apart from the ports tutorial that uses pipes. All in all and no surprise it's harder on Windows. To take this a bit further, ports don't define a protocol or a data format. So both these issues are still open... It depends on whether you are relying on the simple or the native realization. There are also native Erlang libraries which let Erlang masquerade as XML-RPC, which would be my personal favorite as a syntactic wrapper. Its another possibility. The interface consists of two asychronous paths. An outgoing event path when the user perform some interaction and an incoming update path. The GUI has absolutely zero intelligence it just does what it's told... 2 I think this is a significant difference in what we see in the VR... a) The CAT node is a separate node on the network, it listens for both external (virtual or real serial port) and internal messages on the network. b) An external message arrives to change freq ency. It packages and dispatches this message over the network. c) The message is received by the VR node and unpacked. The message is in fact very similar to that which the GUI would generate. The event name would be different to distinguish the different actions required of GUI and CAT commands. d) The VR decides if this event has an associated action in its current state. If not a warning message is returned. Otherwise the action is called. e) The action will send messages to the DSP and Controller nodes and also form an update message to send to the GUI. f) The DSP and Controller do the necessary. The GUI updates its e.g. current frequency display because that's what the command told it to do. OK, I think I see where there's an impedance mismatch between our concepts. What you're calling the GUI, I'm thinking of as a node in a whole subgraph which I call the UI. That subgraph has only one bidirectional edge to the kernel, so for convenience I blur the internals and call it a single node. If I understand right, for you, the GUI is really only the collection of widgets, and the VR encompasses the data structures that the GUI manipulates, but which reside in a separate node. If we can agree that everything in the User Interface arena has in the end only one path into and out of the message-handling kernel (irrespective of what we think the exact protocol would be), then we're in substantial agreement. This is I think the crux of the issue. Yes the VR contains the complete model
Re: [Flexradio] Console Graphics - maybe mode-specific?
On Sun, 2006-08-27 at 16:01 -0400, Frank Brickle wrote: On Sun, 2006-08-27 at 20:38 +0100, Bob Cowdery wrote: I've done a bit more digging. There seems to be three options for integration: 1. The arms length pipes (I think this can be TCP/IP as well and possibly some others (according to some papers I read)). Pipes only work for *nix so it means an extra sockets hop under Windows on the same machine. The situation is expanded considerably if the messaging transpires among distributed Erlang nodes, which communicate only locally with clients in other languages. I think this was the generally-understood model. Distribution is transparent so I don't see that it make a difference if the nodes are distributed or not. Yes I was only considering the language integration to be local. Logically its a single node although the bulk of the work is being done outside of Erlang. The point was simply that under Windows you have to go through a socket connection albeit on the same machine to achieve that integration. It's advantageous secondarily in that the distributed Erlang nodes are much more versatile in their error handling and propagation capabilities than the local C or C# or Python nodes would be. I was only considering Erlang as the nodes with integration to another language where necessary within a node. I don't much like the idea of implementing an Erlang node in a different language as that seems to completely defeat the object to me. 2. Port Drivers which are effectively shared libraries .so or .dll for *nix and Windows. This seems to be limited to languages that can create proper shared libraries, predominantly aimed at C. It certainly brings Python, C#, Ruby, and PHP into the fold. It's not pretty though. These are exactly the integration issues I was trying to get away from. 3. C Nodes which are definitely C only and receive native Erlang messages. Once again, wrapping up the C interfaces for other environments like Python and C# is straightforward. I believe I have the Python version living on this machine somewhere. It might be, but I want single language nodes or a clean way to integrate any language with the messaging infrastructure. ...Yes the VR contains the complete model of the whole system, so yes it contains all the data that the UI displays, it has static data, it has dynamic data and it has configuration data and it persists and restores that data. Here we part company. In my view the VR is simply the syntax and vocabulary of the messages acceptable to the radio kernel. In this sense, then, the radio kernel corresponds neatly with a microkernel, in that it's responsible for very little more than message passing and protocol handling, and maintaining just enough state to economize on the former and enable the latter. Ok. But something in this system has to be *the* application. If it's not the radio kernel (we seem to have introduced another term here, is this different from the VR?) and it's not the UI because that puts me back to square one where we have multiple UI's with screeds of code in them, then it's simply another node. Lets call it the Application Node for want of a better term. All the VR does for me then is slightly reduce the complexity of my Application Node. However I now need the ability for the Application Node to talk to the UI WITHOUT going through the VR which I think you would disallow from previous discussion. In fact most nodes like CAT for example would now want to talk to the Application Node and only the Application Node would talk to the VR. I don't think this is what you have in mind at all! This data is required in various quantities by all nodes of the system, not just the UI. On this I could not agree less. The goal is to minimize the visibility of the nodes among one another. That's proportional to minimizing the bandwidth requirements for controlling the nodes. I can't see how you move that back to the UI without having duplicate data and a lot of issues. You talk about this as if it were a bad thing. Duplication of data is to be desired, especially in a distributed system, as long as there's some mechanism for assuring consistency. What we have a lot of is memory. What's potentially in short supply is bandwidth. The more we hold on to locally, the less we have to send around as data, if we've made up an adequately rich shorthand vocabulary. Jst as with the VFO example, the UI's notion of a VFO has very little in common with the DSP's and the hardware's, except a single number. The UI wants to remember that number. The DSP and the hardware don't need to remember it, they just need to obey the commands that effect it. I am unclear what advantage there is in any other arrangement. Sorry, but I'm really unmovable on having a model. It's the central underpinning of the application and I certainly don't want to deal with data synchronisation issues. Quite
Re: [Flexradio] Console Graphics - maybe mode-specific?
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?
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?
On Fri, 2006-08-25 at 23:29 -0400, Robert McGwier wrote: Frank Brickle wrote: On Wed, 2006-08-23 at 08:37 +0100, Bob Cowdery wrote: On Tue, 2006-08-22 at 22:54 -0700, Jim Lux wrote: I've been waiting for the long anticipated UI/backend split with a well defined interface, as announced, gosh, several times over the past couple years... Am I the only one that doesn't understand this. As far as I can see there *is* a good split between the DSP and the rest of the radio. *I* thought so too ;-) I avoid saying UI because there is a heck of a lot of code which is neither DSP nor UI. This not inconsiderable wadge of code is what I am incorporating into a middle tier with a defined interface to the UI. Just to be explicit, this wadge of code is exactly the radio kernel we've been talking about. Bob (this Bob!) has done quite a bit of work in the area already, very illuminating work one might add. There has been another experimental version of this, done up in python, for over a year now, as an item -- a virtual radio -- to contemplate and meditate over, for merits and defects. I have not found a pitfall yet. It has taken me time to get my old write iterative C/C++ code out of my brain and shifted into recursive, functional list processing but it has been worth every single hard step. This code is VERY compact. I really do hope we do not run into any serious performance issues but so far, on Linux, Windows, and Mac OS/X, erlc writes good code and the foreign language interface/ interop to C/C++ is quite functional. Very very few people will need to write erlang. It will be switching station for messages essentially between distributed things where the core is required to learn and preserve state while parsing/passing commands. Bob This interface will be defined in terms of JSON (www.json.org). Whether anybody else is interested in this approach is academic. I just wanted to point out I don't follow the line of thought. FWIW, the DttSP radio kernel is being developed and implemented in erlang. Barring unforeseen potholes, erlang will be the platform for the virtual radio. Can I explore this a little because languages and distributed systems fascinate me and I want to understand more about whats good and whats bad for this application. I have an onion skin model of what I want to do and at that level I think its the same type of onion. I should draw a picture but lets make do with words. At the centre is good old sockets, next up is the messaging layer, then potentially but not necessarily language bindings. I say not necessarily because I have two options, a common messaging layer, say in 'C' with binding for each language I might want to interop with or language specific libraries (which is my current preferred route). The application layer then contains DSP, HW Control, GUI, Virtual Radio/ Middle Tier and Management. Each of those pieces will be a separate process interacting only through the messaging layer. There can of course be multiples of each and each can be in virtually any language as they are separated by process boundaries. I've done a lot of this several times before but I've used the capabilities of a specific language such as Pyro with Python and Opera with Squeak. That has required me to have the same language on both sides and therefore language bindings if I wanted the 'other' side to be in a different language. This is an extra hop with marshalling which adds complexity and impacts performance and in a lot of cases might not be possible at all. What I am aiming for now is an efficient language neutral messaging layer where each end can have its own language specific library. At the moment my favourite for this is JSON as being somewhat more efficient than XML and very straight forward to implement. This brings me to Erlang. I can see its a excellent concurrent distributed language. If everything in the system was implemented in Erlang or a minimal language mix I'm sure it would work great. However, if I want to say write my middle tier in Ruby and my front end as a Java web application with my process control layer (manager) in Python and the backend still being in 'C'. A bit of an extreme example maybe but it's a viable mix, I don't want to have to deal with a lot of language integration issues. I am drawing a big distinction here between the messaging layer and what's being called the virtual radio. I see these as completely separate things. The VR *is* the application and the messaging layer is the communications infrastructure which the VR and other processes use. A nice side-effect of this is the relative simplicity of talking to the kernel in any old language you choose. Another nice side-effect is the way erlang makes it possible to demonstrate (if not prove formally) the correctness of the kernel. I have
Re: [Flexradio] Console Graphics - maybe mode-specific?
On Tue, 2006-08-22 at 22:54 -0700, Jim Lux wrote: I've been waiting for the long anticipated UI/backend split with a well defined interface, as announced, gosh, several times over the past couple years. That way, I can do what *I* want to do, without having to insert it into the middle of PowerSDR, with all that entails. I'm not the only one asking for the ability to have some well defined interface for plug-ins, so, you'll excuse my admittedly snide RSN comment (http://en.wikipedia.org/wiki/Real_soon_now) Am I the only one that doesn't understand this. As far as I can see there *is* a good split between the DSP and the rest of the radio. I avoid saying UI because there is a heck of a lot of code which is neither DSP nor UI. This not inconsiderable wadge of code is what I am incorporating into a middle tier with a defined interface to the UI. This interface will be defined in terms of JSON (www.json.org). Whether anybody else is interested in this approach is academic. I just wanted to point out I don't follow the line of thought. Incidentally I agree with the mode separation. The state machine I am using in the middle tier is largely based on mode state, separately in RX and TX. This gives the ability to finely control what happens in different modes. However I do believe the request has more to do with the ability to have control over the DSP configuration, to re-sequence blocks and insert user defined blocks aka GNURadio style than it is to do with separating DSP and UI. If I'm way off track tell me. de Bob ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ FlexRadio Homepage: http://www.flex-radio.com ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ FlexRadio Homepage: http://www.flex-radio.com
Re: [Flexradio] Console Graphics - maybe mode-specific?
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
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
___ 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
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] Test
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] Strange hardware behaviour
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] SDR-Breadboard
As it nears the next release I have posted some preview information at http://myweb.tiscali.co.uk/g3ukb/preview.htm 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] How do you VAC?
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
A new version is up on Squeak map and http://myweb.tiscali.co.uk/g3ukb/ 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
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
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
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/ 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?
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?
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?
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?
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.
Re: [Flexradio] Howcum?
[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 to notify the sender by reply email.
[Flexradio] Questions on the Windows code
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
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 AB, CD 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 else.In such case, you should
Re: [Flexradio] FW: A bit of light entertainment
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.
Re: [Flexradio] A bit of light entertainment
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] FW: A bit of light entertainment
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] 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/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
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 Bob
Re: [Flexradio] [SPAM] Musings
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.
Re: [Flexradio] Synthedit like interface as a basis for experimen tal SDR?
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
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
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.
Re: [Flexradio] My SDR-1000 webpage
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.
[Flexradio] cygwin-X
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] Linux, pyhw(2) broken
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] mailto:[EMAIL PROTECTED] *To:* FlexRadio@flex-radio.biz mailto: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.
[Flexradio] Linux - mode selection
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 - mode selection
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.
RE: [Flexradio] Linux, pyhw(2) broken
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.
[Flexradio] RE: Linux
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
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.
[Flexradio] Linux/Windows hybrid
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
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.
[Flexradio] Which way now!
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.
