Pages: 1 2 3 4 [5] 6 7 8   Go Down

Author Topic: Sherwood Engineering Receiver Test Data  (Read 2263 times)

W6RZ

  • Member
  • Posts: 449
Re: Sherwood Engineering Receiver Test Data
« Reply #60 on: March 26, 2021, 12:20:51 PM »

You make no sense whatsoever. It's about a comparative list showing trends and relative performance, not a single report by itself.

Stop being a drama queen. You're the one not making any sense. DC4KU is providing some of the very same data as Sherwood. It's pretty easy to fit that data into the Sherwood list manually. The 84 dB 3rd order intermodulation figure puts the Airspy HF+ Discovery just above the FTdx-3000 on the Sherwood list.

Logged

KF5LJW

  • Posts: 577
    • HomeURL
Re: Sherwood Engineering Receiver Test Data
« Reply #61 on: March 26, 2021, 01:51:27 PM »

On Sherwood's list, I have done was has been suggested a few times, ie copied it into an excel sheet and sorted it the way I want to.  That's because some operating conditions are quite different than close-spaced CW contesting situations, and having the other test conditions (wide-spaced interferers, for example) in the database is useful information too.

73, Ed
No offense but I have heard this many times put many different ways. Sherwood's list is biased by a sort filter.
Logged

K6BRN

  • Member
  • Posts: 2231
Re: Sherwood Engineering Receiver Test Data
« Reply #62 on: March 26, 2021, 04:12:32 PM »

You make no sense whatsoever. It's about a comparative list showing trends and relative performance, not a single report by itself.

Stop being a drama queen. You're the one not making any sense. DC4KU is providing some of the very same data as Sherwood. It's pretty easy to fit that data into the Sherwood list manually. The 84 dB 3rd order intermodulation figure puts the Airspy HF+ Discovery just above the FTdx-3000 on the Sherwood list.

Hi Ron:

Here you go again, fixated on the AirSpy (only) and avoiding any real work whatsoever.

We were discussing the need for a low-cost SDR cost/performance list to inform the community of the capability spectrum, drive makers to improve their products and THEN compare to Sherwood's list for any convergence trends (YOU claim convergence right now).

Two separate lists.  And lists, plural, not ONE review of ONE item you're obsessing on.  The need and benefits are obvious.

Brian - K6BRN
Logged

N2DTS

  • Member
  • Posts: 1368
Re: Sherwood Engineering Receiver Test Data
« Reply #63 on: March 26, 2021, 05:56:04 PM »

Just using in a casual way, I think its the best (by far) of the under $200.00 sdr receivers.
Much better the the Hermes lite 2 which had a lot of overload.
I wish you could run powersdr with it though.
Logged

W6RZ

  • Member
  • Posts: 449
Re: Sherwood Engineering Receiver Test Data
« Reply #64 on: March 26, 2021, 06:03:45 PM »

Blah, blah, blah.

You're just making my point. If DC4KU's data isn't good enough to compare to the Sherwood list, why would anyone else's data be good enough?

Also stop implying that I haven't done any work. I've contributed heavily to the SDR community as a member of the GNU Radio team for the last 8 years. 164 separate contributions and over 200,000 lines of code. All for free. GNU Radio is used by many many folks including government, military and research organizations.

In 2017, my DVB-T2 code was selected as the basis for the Rohde and Schwarz Engineering Competition. Over 1200 students combed over the code looking for improvements. In the end, only five improvements were upstreamed to GNU Radio (of which only two were significant). Here's the link to the winners video.

https://www.youtube.com/watch?v=Kj6hGD2wCy4

And quit the sanctimonious "maker" references. They're radios just like any other radio.
« Last Edit: March 26, 2021, 06:09:14 PM by W6RZ »
Logged

K6BRN

  • Member
  • Posts: 2231
Re: Sherwood Engineering Receiver Test Data
« Reply #65 on: March 26, 2021, 09:20:20 PM »

Ron:

You're avoiding the topic of creating an SDR/DSP list by any means possible.  All you really have to do is say "OK, fine.  Let somebody else do it."  End of story.

Regarding "maker" references, I'm using it with a SMALL "m".  Vendor, provider, maker, firm, etc.  I don't really care who produces the equipment or what they call themselves.  Yaesu is a "maker".  However YOU associated yourself with the "Maker" community (which I know little about) many threads ago.  That's on your watch.

But it would be quite useful to have a tabulated list comparing all of the offerings to show trends, provide comparisons and promote improvement.

Glad to hear you contributed to a student competition.  But I'm a little confused.  As far as I know, you're well over 50, not a student and this looks like a competition between schools and students.  So....?

Also, you avoid any actual product production, test or analysis like the plague.  Software (NOT VHDL/Verilog firmware design) coding appears to be your wheelhouse.  Not architectural design, not hardware design/test not algorithm design/simulation/test, not product design... 

And that's fine.  Skillful software coding is good, needed and requires a great deal of talent, hard work, debugging and verification.  The software TEAM (and I stress "Team"), whether that team implements DSP algorithms (generally designed by a different team) or control has a critical, essential task to perform.  No way to get around that - though I do think Agile tends to be a little over-blown.

But the purely software design of DSP systems is pretty limited in bandwidth/capability, even when using CPUs optimized for that task, which you do not seem to be familiar with, preferring what are essentially microcontrollers for that task.  Sounds like what you are really doing is data compression, formatting and ECC coding, or relatively low rate ECC decoding.  I.e. baseband functions.

Modern DSP systems require massively parallel processing to develop significant benefit over significant bandwidth, which is why, even in mainstream, relatively narrowband HF receivers, front end processing is still either analog (Yaesu, Kenwood) or performed in a massively parallel FPGA (Icom, Flex).  Even the majority of "SDR" dongles use analog front ends with (Yech!) I/Q sampling (rather than real sampling) to reduce the data rate (and hence bandwidth) into their software driven back ends.

That's really where the world is today.  As processing technology improves, SISO and even MIMO CPUs are able to do more.  Check out the evolution of the venerable TI DSP CPUs.  But then, expectations in DSP processing performance and application bandwidth tends to expand with that capability.  And ASICs and FPGAs simply offer much more throughput and power efficiency, hence, performance.

Regarding being in the "SDR community", I've been designing, building, delivering installing, training engineers and leaders in DSP systems - all in what you mistakenly call the "SDR" world for going on four decades.  Commercial, civil, national...  tight schedules, contractually guaranteed performance.  Delivery and performance bonuses and penalties.

I don't think you play in that world - if you did, we'd probably have crossed paths.  It's NOT a big community.

Or perhaps you work on systems with X kHz of bandwidth and mine usually involve Y GHz of processed bandwidth - a real possibility.  Different skills and solutions for different needs.  One is loaded with custom components and design, the other able to use standard components and lots of design compromises - finesse counts for a lot.

Flex Radio is a case in point regarding truly fine DSP design (firmware and software) that impacts every other aspect of their product.  I've been inside their products.  They're not perfect, none are.  But they are marvels of physical/electrical/mechanical simplicity with very good architecture and algorithm design.  Right now, the Flex-6600 is a perfect example of their maturity in this field - surprise!  Almost nothing inside that big box.  And it works great!  Bravo!  Other companies have noticed and drawn up lucrative contracts with them leveraging their IP base and existing products.  That's a real mark of success.  I hope they keep it up.

Regardless, my point remains the same.  A comparative list of cost vs. performance for low cost "SDRs" would be a benefit to the entire ham community, no matter who produced it, as long as it was done consistently and credibly.

Given your obsessive assertion that the AirSpy design meets or surpasses much more expensive mainstream receivers (found in both stand alone receivers and tranceivers), I'd think that this would be welcome - it SHOULD show a convergence TREND between the two philosophies.

Right now, we have one (or two) people making major claims for the ascendancy of inexpensive SDR radios the vast majority of evaluators and users seems to be ignoring as ...  cranks.  A list with credible, tabulated performance data showing an evolution TREND and convergence between the two approaches, even if that convergence is tomorrow rather than today, is REALLY hard to ignore.  It provides a platform and voice to you and others who believe this convergence is happening.

If making this happen is not worth the effort to you, when it's so clearly useful to your cause and the community, you've answered your own question regarding what YOU really believe is reality and the confidence you have in your own claims.  Personally, I'd like you to be correct.  More for less is always attractive and we all win.

Do we really have to pursue this any further?  I think the topic has been beaten to death.

Brian - K6BRN



 
Logged

W6RZ

  • Member
  • Posts: 449
Re: Sherwood Engineering Receiver Test Data
« Reply #66 on: March 27, 2021, 12:08:40 AM »

What exactly is your specialty besides being a engineering manager (what Billy Walsh in "Entourage" calls a "suit")?

Do you know how to code FPGA's? I don't think so.

Do you know how to write software? I don't think so.

Do you know how to design PCB's? I don't think so.

Do you know how to write schedules and pester the members of the team. Yeah, that's the ticket.
Logged

AC7CW

  • Member
  • Posts: 1789
Re: Sherwood Engineering Receiver Test Data
« Reply #67 on: March 27, 2021, 11:16:38 AM »

Sherwood's list bothers people. I don't get that. I posted about how it was possible to import it into excel and sort by any of the parameters and I got replies telling me not to use the list to buy a rig and saying that's what I said. I said it's interesting, and sortable once imported to excel, nothing more. It's not produced to go straight into excel, once imported some extraneous stuff has to be deleted to abet sorting but it's not at all difficult. I sorted by sensitivity or something like it and wound up with a list of the most venerated old timey rigs near the top for example...
Logged
Novice 1958, 20WPM Extra now... (and get off my lawn)

K6BRN

  • Member
  • Posts: 2231
Re: Sherwood Engineering Receiver Test Data
« Reply #68 on: March 27, 2021, 11:48:32 AM »

Hi Ron:

I see you want to continue this.

To answer your questions, I've done all of that and much more.  And because of that, when I do lead a team, they succeed in product delivery, every time.  Which makes it very hard to retire, because its a small industry (people wise) and success breeds popularity.

I tried retirement in 2013.  It didn't take - too many organizations I'd built relationships showing up at the door and calling in favors.  So I went back for some light consulting, training a cadre of new technologists in subsystems engineering, radiation effects, DSP architectures for signal processing and feedback control loops, etc.  Then, two years later, several demands for new systems emerged, and here I was sitting in the middle of a new team of talent ready to go.  Two and a half years after that, three different prototype systems designed, delivered, and installed with customers very pleased with the results, awards and monetary incentives distributed to my teams and these teams ready to tackle new systems on their own.  And this happened right through the worst of a pandemic.  Not too shabby  But also exhausting.

Pays well, too.  And so did the benefits from earlier worldwide patents that established product lines that are now built into many 3rd parties equipment.  And yes, this work included cost and schedule - I always worked directly with customers and THEIR customers at every level and this is what they required.  And I did it MY way, with requirements and feasibility simulations and advanced POC brass-boards done up front, before production design work began.  But I also spent many hours, every day, in labs and design centers working through issues has they came up and anticipating others before they did - the benefit of doing almost every job myself at one time or another, in a supporting or lead role.  40 years is a long time and I put this time to use.  Yep, some of my exact knowledge of the lastest rev. of a Synopsys, Labview, etc. tool is out of date.  But I know how it works and what it can do.  The people who are now much more current and better than be do that work.  With my support.  It's called "delegation" and "leadership".

You should appreciate THIS metric.  All of the systems I helped develop or lead the development of contained ASICs or FPGAs or CPUs or a mix of the above.  The industry average for first pass ASIC success is about 50%.  My teams averaged 98%, which means we did a LOT of ASICs and they were done well.  1st article delivery time for DSP processors ranged from 2-4 years, generally with massive late penalties.  It required good engineering to hit these marks, and knowing what had to happen in what order to avoid many expensive re-dos later on.

In reality, this is very modest success compared to many engineers/entrepreneurs I've met and worked with (like Harold Rosen, Tom Hudspeth and many others), but it did allow me to ensure the security of my family for the foreseeable future, retiree early and live well, though I didn't count on the magnitude of demand following me out the door.  And it lead to similar success for many others as well, which I also find satisfaction in.

BTW, I ran across quite a few "gadflys" in building/leading teams.  Seemingly intelligent people who ultimately contributed nothing but criticism to others, blew a lot of smoke to no benefit, pretended knowledge well beyond  their capability and soon found themselves on the road to a better place.  Their main features were:  1. the need for constant attention, and 2.  Obsession with some trivial or imaginary point of design they could never get past.  Easy to spot after a while.  Sound familiar?

Conversely, I was blessed to find and work with non-degreed and degreed engineers who were simply brilliant, and special needs persons (ex-Asperger's) who performed miracles reducing the complexity of nearly intractable control systems.  If they had the skills and were better than me I pushed them up as high as I could, knowing we and the project would all benefit in the end.

One memorable year, after working straight through the holidays and Christmas, I was very happy to hand out many millions of dollars of bonus checks to team members myself, sitting down with each one, telling war stories and thanking them for their hard work.  The bonuses were flowed directly down from a delighted customer, were NOT contractually required and are the best vote of a contract well executed that I can think of.  Then it happened again.  And again. 

So, yes, I do lead teams, do cost and schedule, architecture, analysis and even sit with engineers and technicians as the equipment is going through temperature cycling, writing requirements and procedures, training via 1-on-1 sessions and by example and jumping in wherever I can help.  Including bringing in coffee, lunch and whatever else the team needs, personally.  I expect a LOT.  And I give a LOT.  That's what leadership is all about.

All of this consistently required very, very long work weeks and personal sacrifice.  Which is why I'm TRYING to retire a 2nd time and doing my best to politely deflect the numerous phone calls that still come in every week.  2020 was a brutal year in every respect.  I'm "Pooped".  And STILL have open contracts, if I wish to go back, again.  (XYL says "NO!")

So.  Any other questions or bets?  Because this is now WAY off topic and is turning into a personal showcase.

Brian - K6BRN
Logged

K6BRN

  • Member
  • Posts: 2231
Re: Sherwood Engineering Receiver Test Data
« Reply #69 on: March 27, 2021, 12:00:07 PM »

Sherwood's list bothers people. I don't get that. I posted about how it was possible to import it into excel and sort by any of the parameters and I got replies telling me not to use the list to buy a rig and saying that's what I said. I said it's interesting, and sortable once imported to excel, nothing more. It's not produced to go straight into excel, once imported some extraneous stuff has to be deleted to abet sorting but it's not at all difficult. I sorted by sensitivity or something like it and wound up with a list of the most venerated old timey rigs near the top for example...

Ron (N6YWU):

Sherwood's list is VERY useful and kudos to Sherwood for providing this service to the community.

The problem is that many believe that the list is the be-all and end-all definition of a good radio.  It's not.  It's an indication of relative performance and performance treands in several key categories and as such points out where makers (ummmm... companies/providers) can improve their products.  In response, they do.

Sherwood has to provide SOME metric for ranking, by itself a clever move to highlight key performance capabilities, but this exact metric by itself is only a fragment of the story and does not indicate the BEST receiver.

Others hate the tendency to of people to take the list as a definitive ranking from BEST to WORST overall, which it's NOT.

Reviewing Sherwood's list and comparing prospective radios to reviews based on actual user experiences provides a much more complete picture and is what every shopper should do.  Eham user reviews are one of the defining benefits of this site and provide many perspectives on the benefits and satisfaction each bit of equipment provides to its users.

In my running rant with (the other Ron, above), my point is that a similar system of lists plus reviews would benefit the low-cost DSP/SDR segment.  Right now the combination of user satisfaction (user reviews) played against objective key performance metrics is a hodgepode of data here and there, hardly ever complete.  this makes it hard to make a good purchase decision and does not help makers drive improvements into their products.

Brian - K6BRN

Logged

N6YWU

  • Posts: 362
    • HomeURL
Re: Sherwood Engineering Receiver Test Data
« Reply #70 on: March 27, 2021, 12:24:24 PM »

But the purely software design of DSP systems is pretty limited in bandwidth/capability, even when using CPUs optimized for that task, which you do not seem to be familiar with, preferring what are essentially microcontrollers for that task.

Limited?  I hope you're not too far behind the times.  Maybe you used Cray YMP's at 333 Mflops peak?  Or special purpose ECL DSPs that could do a Gigaflop?  The tiny "microcontroller" CPU in your grandkid's iPhone 12 beats that, capable of sustaining several Gigaflops of processing performance running filters, demodulators, FFTs, and other DSP code.
Logged

K6BRN

  • Member
  • Posts: 2231
Re: Sherwood Engineering Receiver Test Data
« Reply #71 on: March 27, 2021, 01:12:31 PM »

But the purely software design of DSP systems is pretty limited in bandwidth/capability, even when using CPUs optimized for that task, which you do not seem to be familiar with, preferring what are essentially microcontrollers for that task.

Limited?  I hope you're not too far behind the times.  Maybe you used Cray YMP's at 333 Mflops peak?  Or special purpose ECL DSPs that could do a Gigaflop?  The tiny "microcontroller" CPU in your grandkid's iPhone 12 beats that, capable of sustaining several Gigaflops of processing performance running filters, demodulators, FFTs, and other DSP code.

No, I'm not behind the times.  Capable broadband DSP requires many, many teraflops of computing horsepower that drives a "dataflow" architecture where the data literally flows through many more or less fixed (reconfigurable but not usually programmable in a SW sense) execution units and all the processing is done in parallel in an assembly line fashion.

That's what an FPGA is all about and why their capability is usually measured in LUTs and DSPs available on-chip to the "firmware" designer, who uses an "HDL" (Hardware Description Language) to logically configure and interconnect the functional blocks.  Which than all work in parallel.

Various array processors (arrays of SISO or MIMO CPUS interconnected by switches) have been tried over the years and have proven to be way too power intensive, too hard to program and have too many bottlenecks in their pre-determined routing paths.

I just finished up delivery of new DSP hardware software and firmware in late December.  So unless the world has radically changed since then, I'm still current.

Brian - K6BRN
Logged

N2DTS

  • Member
  • Posts: 1368
Re: Sherwood Engineering Receiver Test Data
« Reply #72 on: March 27, 2021, 01:14:40 PM »

I would guess dynamic range narrow spaced is the hardest thing to do of all the things listed on the chart.
Low phase noise seems to be somewhat easy to do these days, so what other thing would anyone want a receiver to be ranked by?
Most seem sensitive enough given the typical noise floor people have in most locations.....

He should include a listing for how easy they are to use which is much more important to me then many other things.
If a radio is on the first two pages, its good enough for most hams...

Logged

N6YWU

  • Posts: 362
    • HomeURL
Re: Sherwood Engineering Receiver Test Data
« Reply #73 on: March 27, 2021, 03:07:53 PM »

No, I'm not behind the times.  Capable broadband DSP requires many, many teraflops of computing horsepower that drives a "dataflow" architecture where the data literally flows through many more or less fixed (reconfigurable but not usually programmable in a SW sense) execution units and all the processing is done in parallel in an assembly line fashion.

That's what an FPGA is all about and why their capability is usually measured in LUTs and DSPs available on-chip to the "firmware" designer, who uses an "HDL" (Hardware Description Language) to logically configure and interconnect the functional blocks.  Which than all work in parallel.

Various array processors (arrays of SISO or MIMO CPUS interconnected by switches) have been tried over the years and have proven to be way too power intensive, too hard to program and have too many bottlenecks in their pre-determined routing paths.

I just finished up delivery of new DSP hardware software and firmware in late December.  So unless the world has radically changed since then, I'm still current.

Brian - K6BRN

Very impressive.  But my guess is that the sweet spot in the amateur radio HF market probably requires engineering designs several orders of magnitude more unit-cost-effective and power efficient than government contract installations.  The entire sum of all amateur frequency allocations below UHF can likely be processed in a single low-cost FPGA, plus some multi-core "toy" microprocessors of the kind that can be found inside an Apple Watch.  (And, yes, I have benchmarked real-time DSP code on an Apple Watch.  I'm also named on some FPGA related patents, so I'm familiar with the capabilities of that technology as well.)

So, except for specialized niches that require physically large and well spaced apart components, I wouldn't count out small affordable tech for a vast portion of the potential amateur radio market.
Logged

K6BRN

  • Member
  • Posts: 2231
Re: Sherwood Engineering Receiver Test Data
« Reply #74 on: March 27, 2021, 03:40:24 PM »

Hi Ron (N6YWU):

"The entire sum of all amateur frequency allocations below UHF can likely be processed in a single low-cost FPGA, plus some multi-core "toy" microprocessors of the kind that can be found inside an Apple Watch"

To a degree, you're describing FlexRadio (see below -and Icom), whom everyone's already familiar with.  And there, ADC linearlty and dynamic range are more the limiting factors, because they have plenty of more powerful FPGAs to call on - at higher cost.  And... there really are no FPGA toys.  All require skill to develop - well.  But you know this already, right?

And the other Ron was talking about the AirSpy device, which is fundamentally different in execution and cost.

BTW, a very low voltage Apple watch CPU is probably not the best choice for an HF receiver DSP.  For many reasons.  But if you'd like to prove me wrong, feel free to actually develop, demonstrate, sell and deliver a cost effective HF to VHF radio that uses one for its DSP.  I predict this would be a voyage of discovery for you.

As I've said several times before....

Quote
Flex Radio is a case in point regarding truly fine DSP design (firmware and software) that impacts every other aspect of their product.  I've been inside their products.  They're not perfect, none are.  But they are marvels of physical/electrical/mechanical simplicity with very good architecture and algorithm design.  Right now, the Flex-6600 is a perfect example of their maturity in this field - surprise!  Almost nothing inside that big box.  And it works great!  Bravo!  Other companies have noticed and drawn up lucrative contracts with them leveraging their IP base and existing products.  That's a real mark of success.  I hope they keep it up.

Cheers!

Brian - K6BRN
Logged
Pages: 1 2 3 4 [5] 6 7 8   Go Up