please one more digit in the field "center frequency of reception"

[DD0CW]

it would be nice to have one more digit for the RX QRG. On Satellite QO100 we have RX QRGs like 10491.500 Mhz ( Beacon ) and we use LNBs with LOs of around 9.xxx Ghz. The field "Transverter Delta Frequency" in Hz is long enough for that. But the RX QRG field is a bit too short.

[f4exb]

This is a long story.... and to make it short I will not implement this.

The longer explanation: adding one more digit to the dial is not the real issue but as a consequence this extra digit (the two most significant digits so here "10" will be reported in the frequency scale of the spectrum and thus take some extra space reducing the number of ticks which is detrimental to the usefulness of this scale. Here this is not even the case where the frequency span would cross a GHz border and even though you may not need it still.

During years when using transceivers people were used to mentally integrate the frequency shift of the transceiver. Have we become so dumb? This is not even the case to translate 10368 MHz to 144 or 432 MHz here the full lower digits are significant so that for example 10495 MHz is read as 495 MHz.

If you think a little these two digits are useless it will always be 10xxx.xxx MHz so why would I care this is just cosmetic and does not bring any value and is even detrimental. If this is just to parade and say: "hey look! I am working at 10 GHz!" you can forget about it. This is serious business here.

You probably know already the deal. You will use the transverter delta feature so that with a 9.75 GHz LO to tune to the beacon at 10491.5 MHz you don't have to dial 741,5 MHz (the actrual value) but 491.5 MHz (subtracting 250 MHz by setting the transverter delta to -250 MHz) which is indeed more comfortable and comfortable enough.

So sorry no... this will not be implemented,

Note: the 10's GHz digit will be implemented the day and for devices that actually tune to these frequencies by themselves.

[f4exb]

Actually this latest point is the most definite since you could always fiddle with the transverter delta to get the display of your choice.

But... not everyone will use their SDR this way and thus it makes sense that its frequency dial matches its range capability else that extra digit is a distraction and can just be an annoyance. To put it to the extremes what if you use a Perseus in the 28-30 MHz range with a 10 GHz capable setup in front?

[DD0CW]

It's ok. I have accepted that you do not want it. Although Simon Brown did this "gimmick" in his SDR-console program too. Just get on with your serious business. tnx & 73 de DDØCW

[f4exb]

SDR console has a different less modular approach which is totally fine by me but when you are "serious" you should also be serious about and confident in your model. SDRangel has a modular approach to SDR hardware support thus a device plugin should stick to the device capabilities (I have to check out for this btw). It is not in my plan and wishes to just imitate SDR console.

[srcejon]

But... not everyone will use their SDR this way and thus it makes sense that its frequency dial matches its range capability else that extra digit is a distraction and can just be an annoyance. To put it to the extremes what if you use a Perseus in the 28-30 MHz range with a 10 GHz capable setup in front?

Yep, I agree with that, however, the number of digits doesn't need to be fixed. We could only display the extra digits when the transverter option is enabled. Most of the device GUIs seem to have enough spare space.

Here this is not even the case where the frequency span would cross a GHz border and even though you may not need it still.

That's true for QO100, but there is some interest in other frequencies. For example, people are monitoring StarLink, from 10.7GHz to 12.7GHz: https://forum.amsat-dl.org/index.php?thread/3981-receiving-starlink-satellite-beacons/.

the two most significant digits so here "10" will be reported in the frequency scale of the spectrum and thus take some extra space reducing the number of ticks which is detrimental to the usefulness of this scale.

Omitting these digits makes some sense if you are only within the 10GHz band, but less so, in my opinion, once you get to 11GHz.

This pic is the narrowest width that displays 10 grids, but there's still just enough space to fit the leading 1 in. Even if you wanted to maintain the spacing between numbers, for readability, that minimum width wouldn't have to increase by much to fit the leading ones in. It's probably only 40 pixels extra, and the spectrum would still be less than 550 pixels wide, which isn't much on a modern display, so I don't see it being that problematic. I would favour having the actual RF frequency displayed, but that is subjective, and I know you like a minimalist display. However, this is software, so differing tastes can be catered for :)

One other point I would add though, is that it in some cases it is useful for SDRangel to know the exact RF frequency, not just the device frequency. For example:

• in the spectrum measurements, calculation of the harmonic frequencies may not be off, as it doesn't know the actual fundamental frequency (In practice, that's not going to change the result unless you are looking at the first ~20MHz of the 10GHz spectrum, as the harmonics will still be out of band).
• You may need to have multiple sets of annotation markers, to avoid frequencies overlapping.

Both minor points, but those are just a couple of things that came to mind without much thought. There may be more as we add new functionality in the future.

Note: the 10's GHz digit will be implemented the day and for devices that actually tune to these frequencies by themselves.

I had a 26GHz Keysight Spectrum Analyzer on my desk a while back :) I wrote a VISA sample source plugin to read data from it in to SDRangel, but unfortunately couldn't stream data continuously in real time. So not quite yet...

[f4exb]

And what if your transverter is for 250 GHz? OK... 9 digits (in kHz) everyone!

[f4exb]

Et voilà!

[f4exb]

BTW the width of tick numbers does make a difference on the number of displayable ticks. Compare vs

[DD0CW]

many thanks, that's real ham spirit . vy 73. 🙂

[f4exb]

I haven't found an article so far of an amateur radio setup that would run above 1 THz with frequency conversion. If you find me one I'll be more than happy to add the THz digit.

[srcejon]

As I said previously, I do agree that sometimes a simplified scale makes sense - but also other times not. I was trying to suggest we might want to support different ways of displaying the scale.

We sort of have the same problem even when not using the transverter. For example, when looking at a narrow spectrum > 1GHz

We could make a similar argument here, about the leading 1.00000. It's not instantly obvious (to me at least) what those numbers are, without counting the digits.

But there are two separate things to consider - one is whether SDRangel knows the actual RF frequency (for things like measurements and potentially use in features) - and the other is how to display it, in different places. E.g:

• In the device GUI
• In the Info bar in the spectrum
• In the spectrum scale
• On markers
• In the peak table

I would say that for the reasons mentioned previously, SDRangel should know the actual RF frequency, regardless of what is displayed. For display:

• In the device GUI, it does make sense to display the device frequency, but as some users seem to want it, perhaps the RF frequency could be displayed additionally (maybe in the tooltip or another label when the transverter is enabled).
• In the info bar in the spectrum, the actual RF frequency should be displayed (always helpful when looking at screenshots later in time)
• In the peak table, the full actual RF frequencies should be displayed
• For the spectrum scale, in some cases we might want the actual RF frequency - in others, perhaps all we want to display is the least significant digits of the frequency and sometimes an offset (E.g. +/- from the center frequency) is most useful. I imagine this would be user selectable, so you can choose the best for whatever you're trying to do.

[srcejon]

I haven't found an article so far of an amateur radio setup that would run above 1 THz with frequency conversion. If you find me one I'll be more than happy to add the THz digit.

SDPangel?

(P for photonics)

:)

[f4exb]

sure :) while poking around I found this interesting video at 30 THz: https://www.youtube.com/watch?v=6gJtzMLR6T0&ab_channel=VK3CV_WQ1SAndrew

About the frequency scale this is the only item concerned by a way of displaying frequency other than in full so at first sight this should be handled in the ScaleEngine component. Since it knows the absolute values and the range it could be possibly done in a smart way so that the exact portion of the frequency to display does not need to be specified.

[f4exb]

Example knowing the start and end frequency of the scale and thus its width Start: 10,496,750,000 Hz End: 10,499,750,000 Hz => Width 3,000,000 Hz

So I should display at least up to the 10⁶ digit. Now I will move through the upper digits and "drop" the lower digits until start and end matches. Here it is very quick since at the next on (10⁷ ) we have 10,490,000,000. So just subtract this value and you obtain a displayable range of 6,750,000 to 9,750,000.

If there was any boundary crossed at an upper digit the start and end would not match and you will have to take at least up to that digit. Other example Start 10,499,500,000 Hz End: 10,500,500,000 Hz => Width: 1,000,000 Hz

So the algorithm starts at 10⁶ and the first matching start/end is at 10⁹ so you know you have to subtract 10,000,000,000 and thus end up with a display scale between 499,500,000 and 500,500,000 to which the usual formatting algorithm would apply. You could add a leading tick (') to mark that the upper digits have been dropped (similar to what is done in the BATC wideband monitor).

Of course this works only if the start and end have the same int(log10(x)). But if this is not the case then this algorithm simply does not apply and numbers have to be considered in full.