DAX IQ bandwidth only 170kHz when set to 192kHz

  • 1
  • Question
  • Updated 4 months ago
  • (Edited)
I currently use DAX IQ to stream 20m to my WebSDR server. Unfortunately when set to 192kHz sample rate, the visible bandwidth is only 170kHz because DAX IQ rolls off prematurely. In contrast, the streams for 160, 80 & 40m obtained from three (relatively cheap) SDR's from Cross Country Wireless via 3 x 24-bit 192kHz USB ADC's are flat accross the full 192kHz.

Over several months streaming 24/7
I have found DAX IQ to be very stable in all other respects. It would be a pity if the full bandwidth cannot be exploited.

I may be overlooking something - is there a currently a way to improve this? If not, will this limitation be improved in future versions

Many thanks, Paul
Photo of Paul

Paul

  • 477 Posts
  • 144 Reply Likes

Posted 4 months ago

  • 1
Photo of Neal - K3NC

Neal - K3NC, Elmer

  • 443 Posts
  • 134 Reply Likes
Paul

What is the frequency range of your panadapter when you are noticing it?
Photo of Paul

Paul

  • 477 Posts
  • 144 Reply Likes
Hi Neal. The visible bandwidth (on the WebSDR) is constant regardless of panadaptor range. I can zoom in or out fully in SSDR and there is no effect on the bandwidth being streamed by DAX IQ. This is what I would expect, since DAX IQ stream bandwidth ought to be equal to the sampling rate and be centred on the panadaptor from which it is being streamed. Thanks for your suggestion but I don't think that is the problem.

73, Paul
Photo of Neal - K3NC

Neal - K3NC, Elmer

  • 443 Posts
  • 134 Reply Likes
Does it roll off evenly at the  top and bottom or on one end of the spectrum?
Photo of Paul

Paul

  • 477 Posts
  • 144 Reply Likes
The roll off is equal at both ends of the spectrum. I am losing approximately 11kHz bandwidth at each end. It's as though there is a filter limiting the bandwidth. In other words, it rolls off gradually rather than there being a 'brick wall' cut off. By the way, I have looked closely at the antenna bandwidth and it's not the source of the problem.
Photo of Steve - N5AC

Steve - N5AC, VP Engineering / CTO

  • 1031 Posts
  • 1002 Reply Likes
There is a trade off between computational complexity and available bandwidth inside a filter at a given sampling rate. There MUST be a transition band in order to prevent folding of frequencies outside the sampling bandwidth. 11kHz is actually quite good. I’m interested how far signals outside your 192kHz are visible and how they fold with your other devices. So what does an S9+60 signal 97kHz above or below your center-frequency affect the flat response you see?
Photo of Paul

Paul

  • 477 Posts
  • 144 Reply Likes
Thanks for your comments Steve. Each band uses it's own separate (sound-card type) SDR hardware to generate analogue I and Q signals. Each pair of these is digitised by a USB ADC to feed the server. I guess it's equivalent to having a three SCU Flex but with MUCH less bandwidth. My 6500 simply provides a fourth band (without so many wires thanks to DAX IQ :)

The WebSDR server only delivers a 192kHz slice per band. Nothing is visible outside that bandwidth  so unfortunately it is not possible tell what the response does outside that range. I presume this does relax the complexity of the computation required by the server. It must be said though, that it works extremely well within that bandwidth.

Regarding foldover; yes there is a point above which a strong out of band signal appears within the 192 kHz bandwidth but the level needs to be extremely strong (as you suggest). In tests, I have transmitted into a dummy load and increased the power to the point where this occurs. The signal needs to be 'end-stopping' so unfortunately I can't put a figure on it. There is no detectable affect on the displayed response though, it stays as flat as it is without the transmission.

I hope this is helpful, although from your comments it sounds as though this limitation might be too deeply rooted in the Flex architecture to be easily modified.

EDIT: FWIW I just tested the other sampling rates to see what the actual (approx) visible bandwidths are in each case....

192k gives 170k visible, 96k gives 90k visible, 48k gives 45k visible and 24k gives 22k visible

Doesn't the "transition band" for 192 k sampling seem disproportionately wide (at 11%) when compared to the others (at 6-8%) ?
(Edited)
Photo of Steve - N5AC

Steve - N5AC, VP Engineering / CTO

  • 1031 Posts
  • 1002 Reply Likes
I think you may be missing the point. If a strong out of band signal appears in-band the receiver is “lying” to you. This is the point of having the filter — to prevent out of band signals from appearing as if they are on another frequency or from allowing them to interfere with in-band signals. The sharper the filter is, the less transition band you see and the more latency there will be from the antenna to the received audio. This is not FlexRadio architecture, it’s physics and mathematics.

There are two likely scenarios with your other device/service: 1) they are using an extremely sharp filter, with significant delay, so the you cannot see the transition band (I think this is less likely, but possible), 2) their filter STARTS to show insertion loss (stopband loss) just outside the 192kHz rather than being n-dB down where n prevents a signal of certain size from interfering. In this case, it looks like you get 192kHz, but some of the edges are not interference free — your receiver can “lie” to you pretty easily and you can only tell if you inject a signal into the receiver just outside the pass and and see if it shows up inside the pass band. An unlikely scenario is that one could spread signals in the no-IL band across the sampling spectrum for display and lie about frequency precision instead. This is an unlikely scenario because it’s not “dumb” (as choice 2 is) but is more deceitful. In other words, you could do #2 out of ignorance, but this last choice requires knowledge of the problem and a desire to hide it in defiance of the truth.

In short, there is no free lunch in physics: you have to pick from the available trade offs. In our case, we have a number of customers that would very much not appreciate the “lie” of allowing interference from an out of band signal so this heavily influenced our choices. All of the panadapter and waterfall data is built this way in a FLEX-6000. The intent is that it is as close to what-you-see-is-the-way-it-is as we could get.
Photo of Paul

Paul

  • 472 Posts
  • 141 Reply Likes
As you say Steve: "The sharper the filter is, the less transition band you see and the more latency there will be..."

Why not have a number of user selectable options for this as you do for the standard receive filters? In that way your users could select which trade-offs suit their given application.

On my WebSDR, the question most asked by listeners is;
"why is your 20m coverage narrower than the other bands?"
As things stand, it seems the answer has to be; "because Flex have engineered it that way" .... and refer them to this thread.
(Edited)
Photo of Steve - N5AC

Steve - N5AC, VP Engineering / CTO

  • 1031 Posts
  • 1002 Reply Likes
There are two reasons we do not offer options for this filter: 1) A change in this filter would affect other radio functions including slice receiver and panadapter performance, and 2) the filter is implemented in HDL and the option hardly seems with the effort of partial reconfiguration (technical term for reloading only part of an FPGAs configuration memory).
Photo of Paul

Paul

  • 472 Posts
  • 141 Reply Likes
Understood Steve. Not so FLEXible in that area then ;)
Many thanks for the interesting discussion anyway. 73, Paul
Photo of Paul

Paul

  • 477 Posts
  • 144 Reply Likes
Thanks for the overview Steve. I understand the underlying principles but am a died-in-the -wool hardware engineer with some experience, but no expertise, in software. The whole exercise is a learning curve for me. The server, however, was written by an expert; PA3FWM, likwise the html/javascript for the client (which I have modified). Clearly there is a compromise and the different approaches taken by Pieter vs Yourselves has resulted in differing output. Considering difference in cost, I am more than content with the results obtained with the cheap SDR's. On the other hand, the simpicity of DAXIQ has it's benefits.

In the light of our discussion, I notice that the DAX IQ bandwidth is incorrectly quoted as 24-192kHz in the 6500/6700 data/spec sheets. Also, in contrast, I could find no corresponding bandwidth figures quoted in the 6400/6600 data/spec sheet. Interesting ;)

I appreciate you having spent the time to discuss this Steve. 73, Paul.
(Edited)
Photo of Steve - N5AC

Steve - N5AC, VP Engineering / CTO

  • 1031 Posts
  • 1002 Reply Likes
Generally, bandwidth quotations in the RF sampling world quote ideal sampling bandwidth rather than bandwidth less the transition band. It's mostly a simplicity in marketing communications thing. If we listed the width of the passband, we'd probably want to list the in-band insertion loss as well (so many kHz at s no forced air system nor impeller responsible for the change in speed!)
Photo of Paul

Paul

  • 477 Posts
  • 144 Reply Likes
That may be so, but it would be helpful if it were labelled as such. I fully expected to be able to stream a usable 192 kHz using DAX IQ based on the figures in your data sheet. I believe your "marketing communications" could have been made clearer by using the term "sampling rate per channel" (or sampling bandwidth) as opposed to "bandwidth per channel" - since the two are clearly different. Perhaps this is why it is not quoted in the data for the new models. Happily there were other reasons why I was attracted to my used 6500 so this discrepancy is a relatively minor disappointment.
Photo of Steve - N5AC

Steve - N5AC, VP Engineering / CTO

  • 1031 Posts
  • 1002 Reply Likes
It is identical in the 6500, FYI
Photo of WA2SQQ

WA2SQQ

  • 421 Posts
  • 87 Reply Likes

A most interesting discussion – I learned a few things about a subject that has always been somewhat confusing to me. It's also very reassuring to see FRS engage in such direct and honest discussions. I doubt you'd see this from "the big three".  In my job I am often presented with similar situations where the compatibility of our product, with a 3rd party product, is not always what the customer wishes it was. While such situations are regrettable I always try to explain that the specific design characteristics that were used were selected to provide a specific level of performance for our product. If third party products are somewhat compatible, that’s great – but no implied compatibility was ever stated.

Photo of Paul

Paul

  • 477 Posts
  • 144 Reply Likes
Agreed, interesting & enlightening. Although the items are in fact compatible. It turns out that the issue is more about the transparency (or otherwise) of published specifications. On that note I rest my case. Many thanks for the discussion everyone.