Web based SSDR

Walt - KZ1F

Symlink to conversation in progress regarding OS agnostic control surface for SmartSDR

Walt - KZ1F

I opened up this conversation under a slightly different name, SmartSDR for Linux. While I am a Linux user and much prefer Linux to Windows on so many fronts, I did not necessarily imply writing or using a SmartSDR compiled in GNU C using Linux libraries. To quite the contrary I proposed HTML5 and/or JavaFX2 for the UI of it, JavaFX2 also can do web widgets. The point was, not requiring Windows. My last post under https://community.flexradio.com/flexradio/topics/smartsdr_for_linux , refers to a company who's business model is renting (or leasing) time on very impressive Amateur Radio sites. This is not what I propose for FRS to get in the business of but they have a web based UI as an option that I believe, even at my skill level, I could out do, Panadaptors would simply be other tabs or other instances of the browser so that solves the real estate issues. Nor does it necessarily have to be web based, but web based is the most easily OS agnostic platform. And I just want to resurrect the conversation. The premise I took as a subtheme was not to second guess a decision FRS made 3 years ago but merely point out all software has a shelf life and now there are other, perhaps better, options for a control surface.  Much like those fortunate enough to attend Dayton got to vote with their hands on ideas for the next most wanted thing, perhaps in that vein, we Flexers in general, could vote on whether an OS agnostic control surface might be, if not the next most sought after feature, a highly sought after feature for FRS's customers. So I encourage all readers to look at the above linked idea and view their tutorial YouTube and, not think in therms of the look and feel of the current SSDR rather than RHR's UI but one that doesn't require either Windows or iPad to work.

Thanks and 73,

Walt - kz1f

Stu Phillips - K6TU

Walt,

Thanks for restarting the conversation and the link to the remote ham stuff which I just watched (it reminds my why I'd rather see a prepped presentation that have to suffer through 30 minutes of video but that's personal preference!).

I was surprised at the late 20th century nature of the UI.  I can understand why they went down this path given the constraints of the browser including the specification of a single browser (Chrome).  In my day job I work with startup and larger companies in the tech space - so I am VERY familiar with the implementation issues - regardless of whether you use HTML5, Javascript/frameworks or JAVA, the browser environment is write once, port everywhere - unless you keep to a very limited sub-selection of what is available.

I haven't looked but I suspect even a low resolution pan adaptor/waterfall would be ugly to implement with the graphic support in the browser...

So, a question...

How basic a user interface would be acceptable?

What beyond the limited UI shown in the demo would be needed?  For example, would single band, 2 slice operation and perhaps no pan adaptor be acceptable?  Perhaps even hiding the second slice as VFO B (yikes!) and making the 6000 series look like a boat anchor from a UI perspective?

Curious to get your thoughts - all things are possible - its just SMOP (simple matter of programming) and resources (time/money etc).

Would you pay extra for this and if so how much?  Writing good quality software and supporting it is NOT free and while Hams are notoriously cheap (cheap as in cheap illegitimate person - NOT frugal) we have to realize that we will get the software we pay for... (free is like software written by an infinite number of primates bashing keyboards at random - you might get something useful but likely not!).

Stu K6TU

PS: I am the author of the K6TU Control iPad app - I'm intimately familiar with what it takes to use the (well thought through) native API to the radio... 

Jon_KF2E

I'm not sure what the use case for such an app would be? If your need is remote operation, that functionality is already on the way. If you just have a bad taste in your mouth for Window's, it's not going to motivate a tremendous number of users. You would probably make way more users happy with an OSX port of SmartSDR.

Personally, I'm a Mac convert from Windows. That said, the computer I run in my shack runs Window's. Not just for SmartSDR, but because most amateur related software is Window's based. I could run a Mac and use VMware or Parallels but why bother. Once the remote functionality is native to SmartSDR I'll use VMware on my Macbook to access my radio remotely when needed.

As for a crippled, browser based access to the radio or a limited functionality app...I'm not sure what I would do with it.

Jon...kf2e

Walt - KZ1F

I guess I really have to respond to this directly. ;-) crippled browser based access? Really Jon, tell us what you really think.  No, what I envision is not at all crippled. Thanks to Ajax, browser based applications are no longer especially thin clients. Being the server could be right on the box it's TCP  and UDP connections would be using the loopback path so no router delay. There is no widget or control one can write for a graphical user interface that doesn't have a conterpart in a web browser. In fact, JSF supports user defined widgets much as Groovy allows for. Consequently one could have a medium weight (as opposed to thin or heavy) client in the browser so for those that don't want a lockin to Apple either they can work. The UI will work from an Android, phone or tablet, Apple phone, tablet, Mac, Linux phone, tablet laptop etc, and yeah, even Windows. So the 'Use Case" is portability, freedom of choice, big with Open Source proponents, and flexibility. And, "I'll just use VMWare"....Why if you can eliminate faking an OS or running one in a virtual environment.
   Jon, I've been a Principal Software Developer for over 20 years, with over 40 in the field. I am not just guessing at this stuff. I wrote some ampr.org software in the late 80's and 90's and have some of my code in the Amateur Radio packages for Linux.

73,

Walt - kz1f

Stu Phillips - K6TU

Walt,

Before we go leaping off into virtual implementation, let's try and stick to the requirements.

What functionality is desired and how much would folks be prepared to pay for it?

The horse belongs in front of the cart...
Stu K6TU

Walt - KZ1F

"I was surprised at the late 20th century nature of the UI.  I can understand why they went down this path given the constraints of the browser including the specification of a single browser (Chrome)."

Mee too Stu! That why I was saying one should not concentrate on their UI specifically rather the audio / point and click and the fact it is browser based, OK so it is limited to Chrome (not sure why) Chrome is also OS agnostic so that is less a factor but, as you said, why???

Low quality Panadapters....well clearly this is a risk but consider YouTube videos, more busy than a Panadaptor and runs in a browser. In the HTML5 spec there is a control for that. In JSF one can make a control for that. One just points it to the opened input stream and off it goes. I haven't used that but I've seen it in the Rich/Prime Faces versions of JSF controls. Further the new version of JavaFX2 has some very high quality media controls. I mean, it's not rocket science, Microsoft figured it out, I am other non-Microsoft people have equally good solutions, i.e. Fldigi's waterfall. 

Other options for display... I am glad you responded and are engaged. Even if this crashes and burns it is worth people fluent in the technology to weigh in on it.

For non desktop displays I am not sure I'd even go with the current SSDR display which divides each panadapter to a shrinking portion of the monitor's real estate. I recommend they make each a child of the desktop such that the user can at least move that Panadaptor to its own monitor or certainly it's own detached window.
But to your question, yes, I'd look at the rolodex model for flipping through panadapters, in that way they are all equally sized. If one opens up their horizon to non-Windows options maybe there are better choices for other display form factors

"How basic a user interface would be acceptable?"

Excellent question. Honestly I think it depends. Personally, I think the waterfall is a tad irrelevant. Yes, I understand it being missing people would scream as PSDR had it. Does it convey any information? No, not really, it is interesting depicting sig level with different colors ... oh that one is white hot compared to blue or yellow or red. But the same can be gleaned from the height of the spectrum window. The spectrum window, that is a very desirable control. As I said, I would not do PA 2-4 or 2-8 as chidren of the main window, I'd make them children of desktop. In a Rich/Prime Faces control I'd make them selectable so one could finger through them but have dedicated real estate for them and perhaps, make them drag and drop such as if there were a drag operation it would make it a child of the desktop instead such that it could be moved to another piece of real estate or monitor altogether. I believe I briefly saw a single shot of your initial POC, not that basic.

"Would you pay extra for this and if so how much?  Writing good quality software and supporting it is NOT free and while".

$1MM question. Me, maybe nothing. I'd consider it as a part of the cost of maintenance. You didn't see my comments on OSNOS and PMNOS, oh, that was on QRZ. I did that before, not sure I want to do it again, especially for the love of it. I paid for HRD 6, once I got it successfully working with SSDR and that was only begrudgingly. They put an awful lot of work into it.  For that matter so did the folks at FRS and they did a fantastic job, given what they had to work with at the time. This is why it makes way more sense for them to do this not me, not you. Whatever you or I might do will live if they support it, it would whither and die if they don't. Frankly, I got tired of supporting PMNOS for free. It worked 'good enough' for me and I made the source avaiable. I did help....a guy in Atlanta do an OS/2 device driver for  a 56kb comm card. His name is on the tip of my tongue and so is the card name. But doing it for free, dealing with potential FCC accusations of for money usage. I'd have to incorporate or restart my LLC to get my name away from it. I could certainly do the POC and, ideally, Steve would say, "cool, we'll take it from here".

The other thing I suspect, SSDR isn't designed with portability in mind. Even in the SSDK (I can say this as I haven't been 'read in' yet). Writing portable code isn't easy either. I was also architect of XPErtware a multiplatform communications API set from a company no longer in business (it was bought). XPE was cross platform environment. I would write the control logic and let the manifestation of the control float such that if it came from a Windows HWDR or from a EJB or otherwise message driven bean, the logic wouldn't care. At any rate, you've got to separate out the business logic from the view, be it Microsoft's whatever that is, or managing bean or whatever. But without that and without a braindump and look at the existing UI code whatever either of us did would be a from scratch effort. I think, get Wireshark and figure out the traffic is more effort than I want to put into it.  I vacillate on that one though. As I told FRS, I'll sign whatever they want.  I am not a Mac user nor do I have an iPad but I totally applaud what you did Stu. I'd applaud even louder if I could convince you to share. :-)

Stu, I see you put another post in...I'll end this and respond directly to that post.

73,

Walt - KZ1F

Walt - KZ1F

We weren't designing it, there was no horse, no cart.

OK, yes, if I were designing this...actually the 'proper' way is with use cases or 'stories' if we are to be agile (that's the latest fad in software development for those unfamiliar with the terms usage here). Aside from the name, every control needs a reason to exist.

Jon, I disagree. Way more people use Linux than OSX and, at its base, OSX is Linux.

I'll fire SDR up now.

As a Ham Radio Operator (hence HRO) I want to know how much RF I am pushing to the antenna and how much of it is returning to the rig in order to know if I am being efficient with my radiated signal.

As an HRO I want to chose the control surface I use for my radio such that I can match the device to the environment I will be using it in.

As a computer user I want to control the Operating System I chose to use, not have my software dictate that decision such that I can control the technology I use in my home, in my car, on the road, and at the office, or the hotel room.

As an HRO I want a visual feedback on my audio and compression level in order to know if I am clipping or otherwise distorting.

As an HRO I want visual feedback and control over frequency of a slice receiver so I can see and change what frequency I am listening to or transmitting on.

As an HRO I want visual feedback and control over my  antenna input such that I can control where my RF goes to and comes from.

As an HRO I want visual feedback and control over receier's  bandwidth in order to tune out adjacent QRM and QRN.

As an HRO I want visual representation and contol over my receiver and transmit incremental tuming such that I can adjust for qso partners who might be off frequency (esp at band edges).

As an HRO I want visual representation and control of noise reduction, noise blanking and notch filtering so as to use scalpel-like precision in controlling QRM and QRN.

As an HRO I want a visual representation of the audio equalization available to match my voice, my mic, and the propogation noise for optimum audio at the receiver's end, including the ability to equalize my qso's audio for my taste.

As an HRO I want the ability to quickly view other band conditions so I know when it is advantageous to switch bands and capture emerging propogation windows.

As an HRO I want the ability to pre amplify the signal coming off an antenna in the even I am working an extremely weak signal.

OK, As an HRO I want a rolling display of what signals are where on the band such that I can review historic signal characteristics.

As an HRO I want the ability to do text to and from CW.

As an HRO I want the ability to visually see and control the speed and spacing of my CW.

As an HRO I want the ability to do text to and from PSK.

As an HRO I want the ability to visually see and control the width of my PSK.

As an HRO I want the ability to do text to and from RTTY.

As an HRO I want the ability to visually see and control the width of my RTTY.

As an HRO I want the ability to like to 3rd party logging software.

As an HRO I want the ability to link to 3rd party DC Cluster software.

As an HRO I want the ability to visually see and control a maximum SWR limiter such that exceeding that would terminate the transmitter logic so I wouldn't inadvertantly transmit wildly bad RF and/or damage my rig or other electronics.

As an HRO I want the ability to provide access to other 3rd party software in order to couple other software efforts to my rig in a loosely coupled manner.

As an HRO I want the ability to visually see and control speaker and headphone volume.

As an HR tranceiver owner I want the ability to control who has access to and authority on my radio such that I can finely control access to my transmitter which I am responsible for legally.

As a HR transceiver owner I want to provide a SOA interface to my radio such that I can exercise a fine control over who has access to and data / process abstraction from how to accomplish that function behind the interface. So there is a firewall between certain functions and the outside world.

I think that does it. I am sure others have their own ideas. For the sake of others unfamiliar with agile, the way these requests are they don't (or shouldn't address how) they should address what it is you want and why it is you want it. From this the developer adds those tasks required to accomplish it and the Product Owner, prioritizes the order and the team implementing the story would sign up for how many they could, amongst themselves, accomplish in a given sprint or iteration. This way here it eliminates the potpourri of requests arriving in the middle of development. Also, every request must have an owner, who uses this function and why. Often times all of these function owners are the same person, in this case. However, by identifying the owner you can essentially identify the control surface. Not everything has to be in one monolithic program, Swiss knife syndrome.


73,

Walt - kz1f

Stu Phillips - K6TU

Walt,

Thanks for the comments.  

I'm looking for the requirements not the implementation choices or for that matter, who were to implement a different client.  Regardless of who does it, it won't be free and I for one wouldn't expect FlexRadio to bundle this in maintenance - paid or otherwise.

The only requirement I could extract from your message was of a spectrum display without a waterfall.  So noted.

The Objective C interface for the Ethernet API I developed is available - ask FlexRadio and once you have signed their developer agreement, you can get github access to the source code - that piece of the my application I gave back to FlexRadio as a courtesy and keep it current.  Its not complicated code and has been used by MacLoggerDX to interface to the 6000 series (a $95 paid piece of excellent software).

For the rest of the application, I have no intention of "sharing" - not sure what you mean but its not available.  This is for the same reason that I charge for the application - to make the point that software is NOT free.  I developed the application because I knew if I didn't, I wouldn't get it!

Even when folks are prepared to pay, they will have to accept what is considered as the sweet spot of the market - ie the most revenue income for developer resources expended.

I suspect most hams spend more on their magazines/newspapers and beverage consumption (coffee or otherwise) in a week than they spend on ham radio software in a year.

'Nuff said - its dark in this troll cave and I'm headed out into the sunlight!
Stu K6TU

Walt - KZ1F

Stu, you misunderstood. I am not paying you to do this. As I said, I suspect there is a legality issue. This is, I suspect, why the authors of Fl*** give their software away. HamRadioDeluxe LLC is the entity making HRD. So the authors are not directly receiving compensation. Would the FCC be successful, maybe not but I don't want to be the test case. I gave away PMNOS and OSNOS. But, to your point, if I were to write this, and again check my cred, I would want to charge for it also. But, since I already paid for this radio I sought of expect the software to be what they advertised.

And I agree with your comment software is not free. I've actually made a pretty good living at it these last 40+ years. As for paying for it, I did that when I bought the rig and the $200/yr for the maintenance of the software. If FRS is warm to revisiting their 3 yr old decision, I could see my way clear to provide essentially what you did, that also, btw, would run on your iPad.

Walt - kz1f

Stu Phillips - K6TU

Walt,

Part 97.113 is the only restrictions re compensation - and that specifically relates to TRANSMISSIONS. 

Thanks for the subsequent message that pretty much summarizes SSDR today with exceptions of:
- cross platform support
- roles & capability control for users

The SSDR roadmap has a significant number of the other things you captured.

I'll leave the thread at this point.
Stu K6TU

Walt - KZ1F

Again, HamRadioDeluxe LLC is a separate legal entity, the authors of Fl* give away their software, and Open Source, pretty much means free.

And your observation is correct except for the portability and one or two other things, the stories are what they already do on a single platform or have committed to doing, again, on a single platform.

Since 90%+ of the code is already written it would be silly not to go the 10% more to make everything you have portable.

I don't have a tablet yet but I can see uses for it. I don't want to have to get a Windows one just because the powers that be at FRS force their customers to adapt Microsoft products. There is another forum on Yahoo filled with a ton of people with their collective knickers in a twist because Microsoft dropped support for Windows XP and they don't like or want to go to Windows 7 or 8 (esp in the case of a tablet). So basically FRS is kissing these potential paying customers goodbye because they won't follow FRS into another Windows release. So, looking at the window (NPI) as half full, I am presenting an opportunity for FRS to gain a healthy amount of new business. That is the use case and that is the profit motive.

As I said earlier, I applaud what you did but it will fail. You aren't a software developer, they aren't paying you to implement their road map, you will bore and whatever you wrote will come off the rails. But if you're having fun at it for now, go for it. 

Stu Phillips - K6TU

Ah I was right!  This IS a TROLL CAVE and you are the troll. LOL!

You really should check your facts - not a software developer? - pah!  

Bye bye.
Stu K6TU

George KF2T

In the 2-cents department -

Stu's iPad application feature set (and elegant UI), with some kind of low-latency audio and keying capability, would make a very, very excellent portable client. Open a new tab per slice, don't worry about panadapters or waterfalls except maybe a low-bandwidth "bandscope" - would be pretty cool.

I look at it this way - such a client would likely be used away from the main station, for limited operating periods, so should support the operations most necessary to just have a good time on the radio. Plus a security layer to allow only an authorized operator to connect.

Digimode support - no, as much as I like them. Practical interfacing to 3rd party apps would probably be best, and would avoid bloat. Hooks to enable connections would be nice. Maybe even a limited CAT feature to allow a DXCluster app to change frequencies, too. But let's not go overboard.

For big-time serious operating, having a full version of SSDR running on a client computer would always be best. I like Macs, and dream of a beautiful OS X version of SSDR someday, but am not keen to debate OS's, and am doing just fine without it right now.

Cost - I happily spent $ for MacLogger for iPad. A similar sum (perhaps even more) would be entirely within reason for such a thing.

It would get a lot of use!

I'm not a programmer, but appreciate the work and sheer brainpower that goes into creating quality work. It's great watching this discussion.

Walt - KZ1F

UM, Stu, I wasn't attacking you. if software development is something you sort of hack around at in your space time between doing due diligence on emerging software companies that doesn't make you a professional software developer. Not that that is any more a badge of honor than being a VC. The software folk at FRS are paid to implement the road map, they do that for a livelihood. I have a woodworking shop in the basement. I've built a bunch of stuff, not professional grade but stuff I enjoyed building and the recipients of it enjoy using. However, I had very specific design goals with the desk viewable from my QRZ page. I hired a professional furniture maker to do it. It had to survive, it had to be, well, perfect. That is what he did for a living, not me, I write and design software. This desk is professional grade. The software I write is professional grade. The woodworking projects I do likely don't stand up to the 'professional grade' level.
When I wrote the NOS's it was fun and I enjoyed doing it, right up until I stopped enjoying enhancing it and fitting in changes to the Debian Amateur Radio base. What I had worked for me. That others got utility out of it was rewarding but, primarily, it worked for me. It wasn't a life goal, it was a solution to a problem.
Yes, I have spoke to Steve on this subject. I've discussed the whole ownership thing with Steve and told him the only way it would be practical for me to do this is if it lived on beyond my direct involvement. If the software is written in an MVC fashion that going to another platform is straight-forward. Since I, and I gather you, don't have their source code there is NO code resuse. There is no incremental improvement. What you did is from scratch and similarly whatever I would do would be equally from scratch. And I do this for a living and I don't like re-inventing something already invented.

When I first talked with Greg at FRS was at Boxboro two summers ago. Boxboro is the NE equivalent of Dayton. Not to that extent but I did have to park about 1.5 miles from the convention center. I can not quote how the progression of FlexRadios was presented to me but that it was to the effect of the radio would be self contained in the box such that it would be independent of any given OS. The reality is that goal wasn't met. Yes Tim did parse it such the 'radio' was software agnostic. No, the 'radio' includes the control interface (knobs and dials)  to it which is still Windows.  Frankly I fail to see the, on the surface, difference between PSDR and SSDR. My 1500 requires PSDR run on my laptop and my 6500 requires SSDR running on my laptop. So, from a user view what's the difference. Yeah, down to the nuts and bolts yes there is a difference but from a user requirements perspective NONE. What I am proposing, and frankly the only way it would fly, is something portable the same quality the same fit and finish of SSDR now, except portable. As with the furniture maker, he makes furniture for a living, you do not write software for a living. So given a requirements list for what I am looking for, no, I was never looking for you to hold out your hand to say "what's it worth to you". From the perspect I initially understood you to mean, what do you think it would be worth to an anonymous ham operator...good question. My take is I already paid for it. If they need someone to prove it is commercially viable, OK I can do that. I didn't need you to vet my concept. I thought people were on here, not to snipe but to kind of say, yes I could see that, maybe they'd like SSDR on Android or Linux or....whatever. The people in Al's poll that said they'd really like a Linux control surface I am certain wouldn't mind if that same surface ran on iPad or OSx or Windows..they want something that runs on Linux. If Al had asked the question differently as far as 'would you like the choice of what platform it could run on, more people would say yes.

But, I am perplexed why you thought this conversation was about you and you cashing in  off of it, no, sorry, it wasn't. That you compounded that with "Ah ha...you are a troll" well, I will let everyone who read that come to their own conclusion on your maturity.

Ba Bye, works for me Stu.

W9OY

I find the waterfall to be as informative if not more informative as the panadapter. It is very sensitive to coherence, being able to sense signals at the noise. It is also far easier to accurately click tune 73. W9OY

Richard G7EIX

I have to agree, and the WebSDR Java implementation of the waterfall is very easy to use and allows for a large chunk of the band to be seen.   

http://websdr.org/

Of course I have not see the code behind it, but it was created well before HTML5 became more mainstream, so I suspect it would be easy enough to implement in an HTML5 based web client.

Walt - KZ1F

Hi Lee, would you elaborate on that? I think, in the case of PSKnn or perhaps RTTY, it is invaluable but for that I use the waterfalls in HRD and Fldigi. While I did say I didn't see much value in it I didn't mean to imply thee was none. With the potential exception of the bandscope, which I view as a must have, and the waterfall, which I don't view as a must have, the rest of the SSDR interface is pretty easily replicated. I don't mean it is simplistic but relative to the aforementioned controls it is way easier. Both would require AJAX which provides asynchronous communications to the server so it is not relegated to when the user hits enter or F5. I am 'highly' confident they are doable in a very professional looking web control. In a sense it is the same thing as what YouTube does, you are watching the video in a browser control widget. Both controls have dynamic input as opposed to static as a button usually has.  Also, you used the term 'coherence' would you elaborate.

73,

Walt - kz1f

W9OY

http://sdr-w9oy.blogspot.com/2014/06/waterfall.html

Walt - KZ1F

Thank you, that is so cool. I didn't realize that site even existed. Hopefully others didn't realize that site existed either. I say that by way of if there is a ground swell of OMG, look at that FRS, what I am advocating for may see fruition. My opening comment on this thread was "oh wow, look at RemoteHamRadio". I agreed with Stu it was very, um, dated controls. Again, thanks for the link, they are impressive and encouraging.

Walt - kz1f

Richard G7EIX

I've been pushing that site to people for about 5 years now, I am always surprised at the responses when people see it - I was sure it was a well known quantity in the SDR arena!   

It was actually viewing that site that pushed me to buy a Flex 3000.

Walt - KZ1F

Well, better late than never. TU. While I never have done that 'busy' of a browser control I, intellectually, knew/had strong reason to believe, it was way doable. Again, one just needs to view a YouTube video to see the browser, any browser could handle it. There is a HTML5 control that takes an input stream, like opening a file and creating an input stream from the file object and that gets passed to the control which just displays the content as it is read.

I very much appreciate you pointing this out, so there is the POC. So if others, equally unware of that site see that and respond "FRS, do that" then nobody loses anything functionality and users are open to chose the form factor and host OS they most prefer. As Jim Whitehurst CEO of Red Hat is fond of saying, "It's about choice and not being locked in" and "no vendor lockin".

Thanks and 73,

Walt - kz1f

Al_NN4ZZ

Lee,
Same here on CW, I've spotted weak signals that I would otherwise have missed.

Regards, Al / NN4ZZ  
al (at) nn4zz (dot) com

Walt - KZ1F

I see your point Lee. I agree and stand corrected on the issue of relevance of the waterfall. Generally, if they don't show up above the noise by a visible amount even if I can hear them they won't here me. (Al, that's why I am toying with the 5 ele 17m mono). I may soften my position on a modest PA help, say 600 watts for 300 up the coax. 

KY6LA_Howard

Waterfall is absolutely essential if ur trying to work weak signals. But to make sure they hear me, I run lotsa power into a large antenna. I get a lot of kudos from the small station weak ones as they really have a hard time makinging Q's.

Walt - KZ1F

I can see that now (weak signal work necessity). I was really torn when configuring this station. Especially because of the multiple PanAdapters I wanted to be able to simultaneously be tuned on multiple bands so I opted to lose a little gain in favor of 17, 15, 12, and 10. While, at least, they allow towers here, there is a height limitation and a limit on 1 antenna. It's better than no antenna or dipole at 10' between the trees and hope nobody complains antenna. Given those restrictions I tried to go with the best I could that would exploit the 6000 series. I've survived over 30 years as a ham without an amplifier. I am now warming up to one. Even barefoot though, the 6000 does really well with an LP working into a pileup. There are a couple I've had no luck with but generally do well. Another 4 or 5 db wouldn't hurt.

Beppe IK3VIG

Hi,

this is a simple example of an SDR receiver used in Firefox or other browser. ELAD FDM line receivers with their SW-.2 software can be remote tuned/listen, simply on a webpage.



73 Beppe
ik3vig