This just goes back to what I said when the radio and initial launch date was announced. Never underestimate how difficult new software is to write, even with hired guns to code it!

I think Apache Labs will get my business now, they appear to be way ahead of the game.

Remember how this was to be a game changer? It would seem that this is all is going down the way several of us predicted. If Flex doesn't get it in gear soon, all the new Anan owners are going to start making the Flex waiting list hams real antsy! I have already seen a few say they asked for refunds.

The video shows me how far ahead the competition is. For $7499 and $200 per year shake down fee I am not impressed, in fact what I am seeing in the video is a bit silly for the cost. At this point in time it is beginning to appear for the hobbyist market the Open Source community is far better at software delivery than a small software house with its closed source and limited resources. With all the problems they appear to be having getting this out I could see bug fixes and upgrades coming out even slower than before. In addition, Flex still has the old technology legacy line to support drawing on its limited resources and unfortunately for Flex I see this bleeding them for a long time and this is one monkey their competitors will not have on their back. This line is shaping up to be a big disappointment for most of us and I at one time was very excited about it.

Software is hard, and worse is the next best thing to impossible to estimate reliably, real time software is an order of magnitude harder, realtime on a multitasking general purpose machine is harder again (And is just plain nasty to debug).

A big part of the issue is that the compute hardware out there is just so very variable, and even things like network cards (and their drivers) can be 'interesting', I have had a so called gigabit chipset start randomly dropping frames for no apparent reason, most unwelcome when trying to use UDP to move low latency audio around.

It might work here on my development box, but that is no guarantee that it will do the job on your packard bell laptop with a fan full of fluff that your mate has overclocked for you and has Norton AV hiding in the background fiddling with every system call I make, and storms of SMI exceptions trying to keep the poor thing from melting.

PCs provide a lot of cheap compute power, but low and deterministic latency is not their strong point.

Never underestimate the pain of going from a prototype to a product, especially when MS Windows is in any way involved.

What could be interesting is investigating the possibility of using a small dedicated compute board as a baseband processor for the anan/hermes radios, possibly itself with FPGA support or using CUDA or something, this would sit as a shim between the userland devices and create the the very high bandwidth I/Q data stream for the radios as well as doing the FFTs and suchlike, allowing the controls to run in a rather less time constrained environment.

I am thinking something like a TMS320C6xxx or SHARK, a Gb network port for the radios and a second network interface for the user network. The DSPs can handle the baseband processing without breaking a sweat, and can do it with negligible latency as they can work sample by sample in interrupt context rather then having to do blockwise processing like a PC does. As memory serves Hermes at least lets you select the amount of decimation in the CIC chain so it may well be practical to run at baseband bandwidths limited only by the network bandwidth to the radio.

This is essentially where the 6000 series is trying to go, but I want something hackable, including having the VHDL/Verilog be hackable, however good the supplied API may be, sooner or later you will hit something it will not let you do, and that sort of defeats the point of an SDR for me.

Oh come on Steve, jump ship and hop on the Anan boat with the rest of us!

Seriously, I do hope it all works out for you. The Anan boat is moving seemingly faster right now. What will be interesting is to see where both camps sit a year from now. Hardware wise they both appear to hold great promise so all will need to be patient!

Oh come on Steve, jump ship and hop on the Anan boat with the rest of us!

Seriously, I do hope it all works out for you. The Anan boat is moving seemingly faster right now. What will be interesting is to see where both camps sit a year from now. Hardware wise they both appear to hold great promise so all will need to be patient!

Would be really neat to do some A-B testing when both products are out.

Software is hard, and worse is the next best thing to impossible to estimate reliably, real time software is an order of magnitude harder, realtime on a multitasking general purpose machine is harder again (And is just plain nasty to debug).

You bet..

Quote

PCs provide a lot of cheap compute power, but low and deterministic latency is not their strong point.

Never underestimate the pain of going from a prototype to a product, especially when MS Windows is in any way involved.

Flex started as a sort of hacker platform. Gerald provided the basic VB core to get it working. Later, they picked up dttsp (in C) as the engine and VC# for the UI stuff. The idea was that dttsp would be a nice reliable open source signal processing core, and that the bazaar would provide enhancements both for the dsp and UI. It worked fine for what it was. But the user base grew (very quickly) and those users were not SDR hackers looking to scratch an itch. They were hams wanting an inexpensive high performance radio to compete with the multikilobuck radios. I suppose you could say it was the transition from a prototype (the hacker platform) to a product (orders of magnitude more users than coders).

That said, Windows (while a pain in some ways) didn't make it horribly harder. Had they run under Linux from day 1, they wouldn't have had the transition: it would still be a hacker platform. More importantly, Gerald would never have built the first one, because he worked in VB, and that's a Windows only product. I think it was a great thing he did. He didn't get wrapped around the axle about needing a special DSP processor, or trying to link to some fancy DSP library, or even fooling with gnuradio. To say nothing of the absolute PAIN it was trying to get audio devices to work under Linux was back in 2003. He figured, hey, my PC is fast enough to do simple DSP in VB, why not build a radio. And he did.

ANd that motivated a horde of folks to get with the program and make serious efforts in PC based SDRs. Phil Covington had an idea to build a SDR, and got convinced that it would be productive to build high performance audio interfaces to improve the performance of the SDR1k, and that got a lot of people involved in other SDRs. There were a lot of bumps in the road there, too. The SDR1K existing, or more properly, the existence of PowerSDR which was flexible enough to support other hardware prompted the development of the SoftRock, a very cheap SDR using a crystal instead of the DDS.

Quote

What could be interesting is investigating the possibility of using a small dedicated compute board as a baseband processor for the anan/hermes radios, possibly itself with FPGA support or using CUDA or something, this would sit as a shim between the userland devices and create the the very high bandwidth I/Q data stream for the radios as well as doing the FFTs and suchlike, allowing the controls to run in a rather less time constrained environment.

I am thinking something like a TMS320C6xxx or SHARK, a Gb network port for the radios and a second network interface for the user network. The DSPs can handle the baseband processing without breaking a sweat, and can do it with negligible latency as they can work sample by sample in interrupt context rather then having to do blockwise processing like a PC does. As memory serves Hermes at least lets you select the amount of decimation in the CIC chain so it may well be practical to run at baseband bandwidths limited only by the network bandwidth to the radio.

Such things have been around for a while, and never got traction. DSP-10 for instance. The problem, fundamentally, is that there are relatively few people actually interested and skilled enough to fool with the DSP side of an SDR. So the sales volume of your radio will be small, unless there is "off the shelf" software that makes it work. Today, YOU could go out and build yourself an SDR with your processor of choice (use an eval board, like Bob Larkin did for the DSP-10). But then you're constrained to work with THAT processor, and whatever you choose, it won't be as common as an x86 based PC. Pretty soon, that processor will be obsolete, you'll be running the dev tools in emulation, etc.

For a more modern, and fairly well supported, device, take a look at Matt Ettus's USRP (also available from National Instruments). It's a nice hacker platform, has an FPGA, hooks up to gnu-radio. Hundreds of them have been used by undergrads and grad students for senior projects, thesis projects, and PhD dissertations. They're also used a lot in industry, and as "cell site emulators" for a variety of purposes, some good, some evil.

Quote

This is essentially where the 6000 series is trying to go, but I want something hackable, including having the VHDL/Verilog be hackable, however good the supplied API may be, sooner or later you will hit something it will not let you do, and that sort of defeats the point of an SDR for me.

Yes.. the USRP is what you want. The F6.xK or the F5K or the F3, etc. are what the average ham SDR buyer wants: a turnkey box with easily installed software upgrades provided "by others". I'm sure others will spring up in that market. There are SUBSTANTIAL challenges: software development costs are but one (since "open source" did not provide a free (as in beer) option); there's also a host of regulatory issues. It's one thing to sell a box o'parts to a hacker in small quantities; the FCC is going to let you do whatever you do, just like if you cobbled together a rig using that surplus PTO and those 6146 tubes you got from an estate sale, with some sockets you made by drilling holes in some beer coasters.

However, start selling a "box" with a "user manual" and such, and they're going to ask questions like "how do you block reception of cellular frequencies?" and "how do you prevent out of band emissions?" and "could you demonstrate that your spurious signals meet good engineering practice"

That's the "prototype to product" transition you mentioned, in real life..

I have a 6700 on order and looking forward to it VERY much. I also took delivery of an ANAN-100 yesterday. Quick use of the RX only last night shows that this promises to be a nice rig. But it is apples and oranges when comparing to the 6700. Yes, they're both DDC SDRs but that is where the similarity ends; each with their own benefits. I'm looking forward to using them sided by side and compare the performance in crowded contest environments.

I have zero interest in a rig that I have to pay $200.00 per year for software support. But the ANAN has piqued my interest. There seem to be unanswered questions about transmitter specs, which could be a deal killer for me. I'm still leaning toward the QS1R and exciter, but am much more interested in the ANAN than the 6700 or any Flex radio. Interesting times indeed.

In spite of the limitations of the beta test software, the [Flex-6700] receiver performance was astounding.

It appeared that the radio was hearing down to -142dBm (or about S0 – 15db or almost 2 ½ S Units below S0)

BUT what was more astounding was that they introduced DSP gain into the system so that it could hear down to -149 dBm or about the phase noise levels. I am not sure how to measure down to those levels as the thermal noise in my test equipment is higher than that. (The figures are un-calibrated- we will see what Sherwood says)

Adjacent Channel rejection appeared be out of the world….you could totally block an S9+40db signal 100Hz away…..

Like Howard VE3GFW says the Sherwood numbers promise to be impressive.

I do believe that -142 dB was bogus and that the radio was not calibrated prior to setup. I would be the actual NF with the antenna connected was probably closer to -130 dB which is still not too shabby.

The QS1R was nice for use with Skimmer Server but the development was waaaay too drawn out. Planned options are xxxx and two years later they are still planned options.

In spite of the limitations of the beta test software, the [Flex-6700] receiver performance was astounding.

It appeared that the radio was hearing down to -142dBm (or about S0 – 15db or almost 2 ½ S Units below S0)

BUT what was more astounding was that they introduced DSP gain into the system so that it could hear down to -149 dBm or about the phase noise levels. I am not sure how to measure down to those levels as the thermal noise in my test equipment is higher than that. (The figures are un-calibrated- we will see what Sherwood says)

Adjacent Channel rejection appeared be out of the world….you could totally block an S9+40db signal 100Hz away…..

Like Howard VE3GFW says the Sherwood numbers promise to be impressive.

You can't hear below the ambient noise, and below 20 MHz, the ambient noise even in rural locations is more like -80 to -100 dBm at best. Rating a receiver by its sensitivity is idiotic and shows a complete lack of understanding of what numbers ARE important.

Fortunately I still own the K9IUQ "All Things Flexrradio BS Translator". So I am going to use the translator on some of these recent quotes so that all hams can understand what is going on in the Flexer World.

Note the first quote has the word Demo. This is a key word in the Flex Translator. It means "not intended for commercial release".

Remaining very keen to get my pre-order Flex-6000, when it is ready. Will be a lot of fun.K9ZW

Yep it has been really keen to give $1-2K of MY money to Flexradio for a year. Yep, I remain keen with that $$ in Flexradios pocket.Might be a while more in time but hey they already got my big deposit and I have nothing to show for it except for some really keen and exciting Demos.

Copyright 2000-2018 eHam.net, LLC
eHam.net is a community web site for amateur (ham) radio operators around the world.
Contact the site with comments or questions.
WEBMASTER@EHAM.NETSite Privacy Statement