Perseus tuning problem.
|
D R
Hi Simon, There appears to be a tuning problem with certain bandwidths on the Perseus, whereby the tuned frequency changes as the waterfall is moved from side to side, either by right-clicking or by using the slider, although the frequency display still shows the original value. It's easily audible on a CW signal, and you can also see the signal moving within the filter in the IF display. This happens when using bandwidths of 196kHz, 96 kHz and 95kHz - at other bandwidths the selected frequency stays locked on as per normal. I've noticed that there is also a 48kHz .sbs file in the program directory, but there is no 48kHz option in the bandwidth drop-down list. As there is little need for both 95 and 96kHz widths, is there a chance of replacing the 95kHz bandwidth with 48kHz (which is really useful for DGPS band recording)? One last small point: the bandwidth drop-down lists for most receivers has the narrowest at the top, except for the HF+, which has the widest at the top. It's no big deal, but worthy of a change for consistency? Regards, Dave
|
|
|
|
Dave,
Post a screenshot – this helps me immediately see what the problem is, and also whether it’s a user misunderstanding.
I think 48kHz doesn’t work well – not sure, but I removed it for a good reason 😊 .
As for the dropdowns – I’ll change the HF+, thanks for noticing this.
Simon Brown, G4ELI
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of D R via Groups.Io
Hi Simon,
There appears to be a tuning problem with certain bandwidths on the Perseus, whereby the tuned frequency changes as the waterfall is moved from side to side, either by right-clicking or by using the slider, although the frequency display still shows the original value. It's easily audible on a CW signal, and you can also see the signal moving within the filter in the IF display. This happens when using bandwidths of 196kHz, 96 kHz and 95kHz - at other bandwidths the selected frequency stays locked on as per normal.
I've noticed that there is also a 48kHz .sbs file in the program directory, but there is no 48kHz option in the bandwidth drop-down list. As there is little need for both 95 and 96kHz widths, is there a chance of replacing the 95kHz bandwidth with 48kHz (which is really useful for DGPS band recording)?
One last small point: the bandwidth drop-down lists for most receivers has the narrowest at the top, except for the HF+, which has the widest at the top. It's no big deal, but worthy of a change for consistency?
Regards, Dave
|
|
|
|
Also,
Just an idea – it could be that the 196 / 96 / 95 kHz bandwidths aren’t exact, I’ll take a look with my own Perseus.
Simon Brown, G4ELI
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of Simon Brown
Sent: 22 April 2019 15:07 To: main@SDR-Radio.groups.io Subject: Re: [SDR-Radio] Perseus tuning problem.
Dave,
Post a screenshot – this helps me immediately see what the problem is, and also whether it’s a user misunderstanding.
I think 48kHz doesn’t work well – not sure, but I removed it for a good reason 😊 .
As for the dropdowns – I’ll change the HF+, thanks for noticing this.
Simon Brown, G4ELI
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of D R via Groups.Io
Hi Simon,
There appears to be a tuning problem with certain bandwidths on the Perseus, whereby the tuned frequency changes as the waterfall is moved from side to side, either by right-clicking or by using the slider, although the frequency display still shows the original value. It's easily audible on a CW signal, and you can also see the signal moving within the filter in the IF display. This happens when using bandwidths of 196kHz, 96 kHz and 95kHz - at other bandwidths the selected frequency stays locked on as per normal.
I've noticed that there is also a 48kHz .sbs file in the program directory, but there is no 48kHz option in the bandwidth drop-down list. As there is little need for both 95 and 96kHz widths, is there a chance of replacing the 95kHz bandwidth with 48kHz (which is really useful for DGPS band recording)?
One last small point: the bandwidth drop-down lists for most receivers has the narrowest at the top, except for the HF+, which has the widest at the top. It's no big deal, but worthy of a change for consistency?
Regards, Dave
|
|
|
|
D R
Hi Simon, Five screenshots attached, showing a 10MHz sine wave fed into the Perseus at 192kHz bandwidth: 01 is the signal centred in the spectrum / waterfall, and 02 and 03 show it just after it has been moved about 90kHz to either side - both show the tuned frequency unchanged at 10MHz, but the signal has clearly moved off-centre in the IF Display (proportionate to the amount the waterfall is shifted). Pics 04 and 05 show the 10MHz signal at either side of the waterfall after it has been re-centred in the IF Display, showing a total frequency shift of almost 300Hz from one side to the other. This error occurs at all frquencies when using 192kHz, 96kHz and 95kHz bandwidths, but the tuned frequency is locked solidly in the middle of the IF Display (as it should be) when all other available bandwidths are used. I hope these pics help, but the problem is simple to verify anyway. Regards, Dave
On Monday, 22 April 2019, 15:06:57 GMT+1, Simon Brown <simon@...> wrote:
Dave,
Post a screenshot – this helps me immediately see what the problem is, and also whether it’s a user misunderstanding.
I think 48kHz doesn’t work well – not sure, but I removed it for a good reason 😊 .
As for the dropdowns – I’ll change the HF+, thanks for noticing this.
Simon Brown, G4ELI
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of D R via Groups.Io
Sent: 22 April 2019 13:24 To: SDR-Radio <sdr-radio@groups.io> Subject: [SDR-Radio] Perseus tuning problem.
Hi Simon,
There appears to be a tuning problem with certain bandwidths on the Perseus, whereby the tuned frequency changes as the waterfall is moved from side to side, either by right-clicking or by using the slider, although the frequency display still shows the original value. It's easily audible on a CW signal, and you can also see the signal moving within the filter in the IF display. This happens when using bandwidths of 196kHz, 96 kHz and 95kHz - at other bandwidths the selected frequency stays locked on as per normal.
I've noticed that there is also a 48kHz .sbs file in the program directory, but there is no 48kHz option in the bandwidth drop-down list. As there is little need for both 95 and 96kHz widths, is there a chance of replacing the 95kHz bandwidth with 48kHz (which is really useful for DGPS band recording)?
One last small point: the bandwidth drop-down lists for most receivers has the narrowest at the top, except for the HF+, which has the widest at the top. It's no big deal, but worthy of a change for consistency?
Regards, Dave
|
|
|
|
Dave,
Thanks. Looks like 192 kHz is actually ~ 192.3 kHz, this could be the reason, in fact it must be. When I’m more awake tomorrow I’ll give you some tests – we can measure the actual sample rate vs theoretical and adjust accordingly.
Simon Brown, G4ELI
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of D R via Groups.Io
Hi Simon,
Five screenshots attached, showing a 10MHz sine wave fed into the Perseus at 192kHz bandwidth: 01 is the signal centred in the spectrum / waterfall, and 02 and 03 show it just after it has been moved about 90kHz to either side - both show the tuned frequency unchanged at 10MHz, but the signal has clearly moved off-centre in the IF Display (proportionate to the amount the waterfall is shifted).
Pics 04 and 05 show the 10MHz signal at either side of the waterfall after it has been re-centred in the IF Display, showing a total frequency shift of almost 300Hz from one side to the other.
This error occurs at all frquencies when using 192kHz, 96kHz and 95kHz bandwidths, but the tuned frequency is locked solidly in the middle of the IF Display (as it should be) when all other available bandwidths are used.
I hope these pics help, but the problem is simple to verify anyway.
Regards, Dave
On Monday, 22 April 2019, 15:06:57 GMT+1, Simon Brown <simon@...> wrote:
Dave,
Post a screenshot – this helps me immediately see what the problem is, and also whether it’s a user misunderstanding.
I think 48kHz doesn’t work well – not sure, but I removed it for a good reason 😊 .
As for the dropdowns – I’ll change the HF+, thanks for noticing this.
Simon Brown, G4ELI
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of D R via Groups.Io
Hi Simon,
There appears to be a tuning problem with certain bandwidths on the Perseus, whereby the tuned frequency changes as the waterfall is moved from side to side, either by right-clicking or by using the slider, although the frequency display still shows the original value. It's easily audible on a CW signal, and you can also see the signal moving within the filter in the IF display. This happens when using bandwidths of 196kHz, 96 kHz and 95kHz - at other bandwidths the selected frequency stays locked on as per normal.
I've noticed that there is also a 48kHz .sbs file in the program directory, but there is no 48kHz option in the bandwidth drop-down list. As there is little need for both 95 and 96kHz widths, is there a chance of replacing the 95kHz bandwidth with 48kHz (which is really useful for DGPS band recording)?
One last small point: the bandwidth drop-down lists for most receivers has the narrowest at the top, except for the HF+, which has the widest at the top. It's no big deal, but worthy of a change for consistency?
Regards, Dave
|
|
|
|
D R
Cheers, Simon. Sleep well! Dave
On Monday, 22 April 2019, 22:29:27 GMT+1, Simon Brown <simon@...> wrote:
Dave,
Thanks. Looks like 192 kHz is actually ~ 192.3 kHz, this could be the reason, in fact it must be. When I’m more awake tomorrow I’ll give you some tests – we can measure the actual sample rate vs theoretical and adjust accordingly.
Simon Brown, G4ELI
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of D R via Groups.Io
Hi Simon,
Five screenshots attached, showing a 10MHz sine wave fed into the Perseus at 192kHz bandwidth: 01 is the signal centred in the spectrum / waterfall, and 02 and 03 show it just after it has been moved about 90kHz to either side - both show the tuned frequency unchanged at 10MHz, but the signal has clearly moved off-centre in the IF Display (proportionate to the amount the waterfall is shifted).
Pics 04 and 05 show the 10MHz signal at either side of the waterfall after it has been re-centred in the IF Display, showing a total frequency shift of almost 300Hz from one side to the other.
This error occurs at all frquencies when using 192kHz, 96kHz and 95kHz bandwidths, but the tuned frequency is locked solidly in the middle of the IF Display (as it should be) when all other available bandwidths are used.
I hope these pics help, but the problem is simple to verify anyway.
Regards, Dave
On Monday, 22 April 2019, 15:06:57 GMT+1, Simon Brown <simon@...> wrote:
Dave,
Post a screenshot – this helps me immediately see what the problem is, and also whether it’s a user misunderstanding.
I think 48kHz doesn’t work well – not sure, but I removed it for a good reason 😊 .
As for the dropdowns – I’ll change the HF+, thanks for noticing this.
Simon Brown, G4ELI
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of D R via Groups.Io
Hi Simon,
There appears to be a tuning problem with certain bandwidths on the Perseus, whereby the tuned frequency changes as the waterfall is moved from side to side, either by right-clicking or by using the slider, although the frequency display still shows the original value. It's easily audible on a CW signal, and you can also see the signal moving within the filter in the IF display. This happens when using bandwidths of 196kHz, 96 kHz and 95kHz - at other bandwidths the selected frequency stays locked on as per normal.
I've noticed that there is also a 48kHz .sbs file in the program directory, but there is no 48kHz option in the bandwidth drop-down list. As there is little need for both 95 and 96kHz widths, is there a chance of replacing the 95kHz bandwidth with 48kHz (which is really useful for DGPS band recording)?
One last small point: the bandwidth drop-down lists for most receivers has the narrowest at the top, except for the HF+, which has the widest at the top. It's no big deal, but worthy of a change for consistency?
Regards, Dave
|
|
|
|
Dave,
Just ran some tests with my Perseus. The sample rate at 192kHz is actually 192.300 kHz and at 1 MHz it’s 0.999932 MHz.
This explains what you are experiencing. I will add a note to the website and, when I have time, I will run longer tests at all sample rates to calibrate Nico’s filters.
So, at 192kHz the error is
Simon Brown, G4ELI
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of D R via Groups.Io
Hi Simon,
Five screenshots attached, showing a 10MHz sine wave fed into the Perseus at 192kHz bandwidth: 01 is the signal centred in the spectrum / waterfall, and 02 and 03 show it just after it has been moved about 90kHz to either side - both show the tuned frequency unchanged at 10MHz, but the signal has clearly moved off-centre in the IF Display (proportionate to the amount the waterfall is shifted).
Pics 04 and 05 show the 10MHz signal at either side of the waterfall after it has been re-centred in the IF Display, showing a total frequency shift of almost 300Hz from one side to the other.
This error occurs at all frquencies when using 192kHz, 96kHz and 95kHz bandwidths, but the tuned frequency is locked solidly in the middle of the IF Display (as it should be) when all other available bandwidths are used.
I hope these pics help, but the problem is simple to verify anyway.
Regards, Dave
On Monday, 22 April 2019, 15:06:57 GMT+1, Simon Brown <simon@...> wrote:
Dave,
Post a screenshot – this helps me immediately see what the problem is, and also whether it’s a user misunderstanding.
I think 48kHz doesn’t work well – not sure, but I removed it for a good reason 😊 .
As for the dropdowns – I’ll change the HF+, thanks for noticing this.
Simon Brown, G4ELI
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of D R via Groups.Io
Hi Simon,
There appears to be a tuning problem with certain bandwidths on the Perseus, whereby the tuned frequency changes as the waterfall is moved from side to side, either by right-clicking or by using the slider, although the frequency display still shows the original value. It's easily audible on a CW signal, and you can also see the signal moving within the filter in the IF display. This happens when using bandwidths of 196kHz, 96 kHz and 95kHz - at other bandwidths the selected frequency stays locked on as per normal.
I've noticed that there is also a 48kHz .sbs file in the program directory, but there is no 48kHz option in the bandwidth drop-down list. As there is little need for both 95 and 96kHz widths, is there a chance of replacing the 95kHz bandwidth with 48kHz (which is really useful for DGPS band recording)?
One last small point: the bandwidth drop-down lists for most receivers has the narrowest at the top, except for the HF+, which has the widest at the top. It's no big deal, but worthy of a change for consistency?
Regards, Dave
|
|
|
|
Also,
I can’t get the 48kHz rate working with a 64-bit application, sorry.
Simon Brown, G4ELI
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of Simon Brown
Sent: 23 April 2019 16:17 To: main@SDR-Radio.groups.io Subject: Re: [SDR-Radio] Perseus tuning problem.
Dave,
Just ran some tests with my Perseus. The sample rate at 192kHz is actually 192.300 kHz and at 1 MHz it’s 0.999932 MHz.
This explains what you are experiencing. I will add a note to the website and, when I have time, I will run longer tests at all sample rates to calibrate Nico’s filters.
So, at 192kHz the error is
Simon Brown, G4ELI
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of D R via Groups.Io
Hi Simon,
Five screenshots attached, showing a 10MHz sine wave fed into the Perseus at 192kHz bandwidth: 01 is the signal centred in the spectrum / waterfall, and 02 and 03 show it just after it has been moved about 90kHz to either side - both show the tuned frequency unchanged at 10MHz, but the signal has clearly moved off-centre in the IF Display (proportionate to the amount the waterfall is shifted).
Pics 04 and 05 show the 10MHz signal at either side of the waterfall after it has been re-centred in the IF Display, showing a total frequency shift of almost 300Hz from one side to the other.
This error occurs at all frquencies when using 192kHz, 96kHz and 95kHz bandwidths, but the tuned frequency is locked solidly in the middle of the IF Display (as it should be) when all other available bandwidths are used.
I hope these pics help, but the problem is simple to verify anyway.
Regards, Dave
On Monday, 22 April 2019, 15:06:57 GMT+1, Simon Brown <simon@...> wrote:
Dave,
Post a screenshot – this helps me immediately see what the problem is, and also whether it’s a user misunderstanding.
I think 48kHz doesn’t work well – not sure, but I removed it for a good reason 😊 .
As for the dropdowns – I’ll change the HF+, thanks for noticing this.
Simon Brown, G4ELI
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of D R via Groups.Io
Hi Simon,
There appears to be a tuning problem with certain bandwidths on the Perseus, whereby the tuned frequency changes as the waterfall is moved from side to side, either by right-clicking or by using the slider, although the frequency display still shows the original value. It's easily audible on a CW signal, and you can also see the signal moving within the filter in the IF display. This happens when using bandwidths of 196kHz, 96 kHz and 95kHz - at other bandwidths the selected frequency stays locked on as per normal.
I've noticed that there is also a 48kHz .sbs file in the program directory, but there is no 48kHz option in the bandwidth drop-down list. As there is little need for both 95 and 96kHz widths, is there a chance of replacing the 95kHz bandwidth with 48kHz (which is really useful for DGPS band recording)?
One last small point: the bandwidth drop-down lists for most receivers has the narrowest at the top, except for the HF+, which has the widest at the top. It's no big deal, but worthy of a change for consistency?
Regards, Dave
|
|
|
|
D R
Hi Simon, Thanks for trying with the 48kHz filter. I've had a look in the Perseus folders on my computer, and I see that in v4 of his software, Nico didn't implement 48k, 95k, 96k and 192k either, despite the files being in the installation package, and they've all been pruned from the v5 installation. Maybe he had problems with them in the past as well? It would be nice if you can eventually get 192k working, though, as it's the bandwidth I tend to use the most for NDB hunting, and it will let me have the Perseus screen looking the same as the HF+ and FDM-S2 screens. Best regards, Dave
On Tuesday, 23 April 2019, 16:41:10 GMT+1, Simon Brown <simon@...> wrote:
Also,
I can’t get the 48kHz rate working with a 64-bit application, sorry.
Simon Brown, G4ELI
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of Simon Brown
Sent: 23 April 2019 16:17 To: main@SDR-Radio.groups.io Subject: Re: [SDR-Radio] Perseus tuning problem.
Dave,
Just ran some tests with my Perseus. The sample rate at 192kHz is actually 192.300 kHz and at 1 MHz it’s 0.999932 MHz.
This explains what you are experiencing. I will add a note to the website and, when I have time, I will run longer tests at all sample rates to calibrate Nico’s filters.
So, at 192kHz the error is
Simon Brown, G4ELI
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of D R via Groups.Io
Hi Simon,
Five screenshots attached, showing a 10MHz sine wave fed into the Perseus at 192kHz bandwidth: 01 is the signal centred in the spectrum / waterfall, and 02 and 03 show it just after it has been moved about 90kHz to either side - both show the tuned frequency unchanged at 10MHz, but the signal has clearly moved off-centre in the IF Display (proportionate to the amount the waterfall is shifted).
Pics 04 and 05 show the 10MHz signal at either side of the waterfall after it has been re-centred in the IF Display, showing a total frequency shift of almost 300Hz from one side to the other.
This error occurs at all frquencies when using 192kHz, 96kHz and 95kHz bandwidths, but the tuned frequency is locked solidly in the middle of the IF Display (as it should be) when all other available bandwidths are used.
I hope these pics help, but the problem is simple to verify anyway.
Regards, Dave
On Monday, 22 April 2019, 15:06:57 GMT+1, Simon Brown <simon@...> wrote:
Dave,
Post a screenshot – this helps me immediately see what the problem is, and also whether it’s a user misunderstanding.
I think 48kHz doesn’t work well – not sure, but I removed it for a good reason 😊 .
As for the dropdowns – I’ll change the HF+, thanks for noticing this.
Simon Brown, G4ELI
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of D R via Groups.Io
Hi Simon,
There appears to be a tuning problem with certain bandwidths on the Perseus, whereby the tuned frequency changes as the waterfall is moved from side to side, either by right-clicking or by using the slider, although the frequency display still shows the original value. It's easily audible on a CW signal, and you can also see the signal moving within the filter in the IF display. This happens when using bandwidths of 196kHz, 96 kHz and 95kHz - at other bandwidths the selected frequency stays locked on as per normal.
I've noticed that there is also a 48kHz .sbs file in the program directory, but there is no 48kHz option in the bandwidth drop-down list. As there is little need for both 95 and 96kHz widths, is there a chance of replacing the 95kHz bandwidth with 48kHz (which is really useful for DGPS band recording)?
One last small point: the bandwidth drop-down lists for most receivers has the narrowest at the top, except for the HF+, which has the widest at the top. It's no big deal, but worthy of a change for consistency?
Regards, Dave
|
|
|
|
Hi Dave,
Just a calibration issue. Tomorrow I’ll explain how you can help with this.
Simon Brown, G4ELI
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of D R via Groups.Io
Hi Simon,
Thanks for trying with the 48kHz filter. I've had a look in the Perseus folders on my computer, and I see that in v4 of his software, Nico didn't implement 48k, 95k, 96k and 192k either, despite the files being in the installation package, and they've all been pruned from the v5 installation. Maybe he had problems with them in the past as well?
It would be nice if you can eventually get 192k working, though, as it's the bandwidth I tend to use the most for NDB hunting, and it will let me have the Perseus screen looking the same as the HF+ and FDM-S2 screens.
Best regards, Dave
On Tuesday, 23 April 2019, 16:41:10 GMT+1, Simon Brown <simon@...> wrote:
Also,
I can’t get the 48kHz rate working with a 64-bit application, sorry.
Simon Brown, G4ELI
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of Simon Brown
Dave,
Just ran some tests with my Perseus. The sample rate at 192kHz is actually 192.300 kHz and at 1 MHz it’s 0.999932 MHz.
This explains what you are experiencing. I will add a note to the website and, when I have time, I will run longer tests at all sample rates to calibrate Nico’s filters.
So, at 192kHz the error is
Simon Brown, G4ELI
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of D R via Groups.Io
Hi Simon,
Five screenshots attached, showing a 10MHz sine wave fed into the Perseus at 192kHz bandwidth: 01 is the signal centred in the spectrum / waterfall, and 02 and 03 show it just after it has been moved about 90kHz to either side - both show the tuned frequency unchanged at 10MHz, but the signal has clearly moved off-centre in the IF Display (proportionate to the amount the waterfall is shifted).
Pics 04 and 05 show the 10MHz signal at either side of the waterfall after it has been re-centred in the IF Display, showing a total frequency shift of almost 300Hz from one side to the other.
This error occurs at all frquencies when using 192kHz, 96kHz and 95kHz bandwidths, but the tuned frequency is locked solidly in the middle of the IF Display (as it should be) when all other available bandwidths are used.
I hope these pics help, but the problem is simple to verify anyway.
Regards, Dave
On Monday, 22 April 2019, 15:06:57 GMT+1, Simon Brown <simon@...> wrote:
Dave,
Post a screenshot – this helps me immediately see what the problem is, and also whether it’s a user misunderstanding.
I think 48kHz doesn’t work well – not sure, but I removed it for a good reason 😊 .
As for the dropdowns – I’ll change the HF+, thanks for noticing this.
Simon Brown, G4ELI
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of D R via Groups.Io
Hi Simon,
There appears to be a tuning problem with certain bandwidths on the Perseus, whereby the tuned frequency changes as the waterfall is moved from side to side, either by right-clicking or by using the slider, although the frequency display still shows the original value. It's easily audible on a CW signal, and you can also see the signal moving within the filter in the IF display. This happens when using bandwidths of 196kHz, 96 kHz and 95kHz - at other bandwidths the selected frequency stays locked on as per normal.
I've noticed that there is also a 48kHz .sbs file in the program directory, but there is no 48kHz option in the bandwidth drop-down list. As there is little need for both 95 and 96kHz widths, is there a chance of replacing the 95kHz bandwidth with 48kHz (which is really useful for DGPS band recording)?
One last small point: the bandwidth drop-down lists for most receivers has the narrowest at the top, except for the HF+, which has the widest at the top. It's no big deal, but worthy of a change for consistency?
Regards, Dave
|
|
|
|
D R
Ready and willing, Master! Dave
On Tuesday, 23 April 2019, 22:05:09 GMT+1, Simon Brown <simon@...> wrote:
Hi Dave,
Just a calibration issue. Tomorrow I’ll explain how you can help with this.
Simon Brown, G4ELI
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of D R via Groups.Io
Hi Simon,
Thanks for trying with the 48kHz filter. I've had a look in the Perseus folders on my computer, and I see that in v4 of his software, Nico didn't implement 48k, 95k, 96k and 192k either, despite the files being in the installation package, and they've all been pruned from the v5 installation. Maybe he had problems with them in the past as well?
It would be nice if you can eventually get 192k working, though, as it's the bandwidth I tend to use the most for NDB hunting, and it will let me have the Perseus screen looking the same as the HF+ and FDM-S2 screens.
Best regards, Dave
On Tuesday, 23 April 2019, 16:41:10 GMT+1, Simon Brown <simon@...> wrote:
Also,
I can’t get the 48kHz rate working with a 64-bit application, sorry.
Simon Brown, G4ELI
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of Simon Brown
Dave,
Just ran some tests with my Perseus. The sample rate at 192kHz is actually 192.300 kHz and at 1 MHz it’s 0.999932 MHz.
This explains what you are experiencing. I will add a note to the website and, when I have time, I will run longer tests at all sample rates to calibrate Nico’s filters.
So, at 192kHz the error is
Simon Brown, G4ELI
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of D R via Groups.Io
Hi Simon,
Five screenshots attached, showing a 10MHz sine wave fed into the Perseus at 192kHz bandwidth: 01 is the signal centred in the spectrum / waterfall, and 02 and 03 show it just after it has been moved about 90kHz to either side - both show the tuned frequency unchanged at 10MHz, but the signal has clearly moved off-centre in the IF Display (proportionate to the amount the waterfall is shifted).
Pics 04 and 05 show the 10MHz signal at either side of the waterfall after it has been re-centred in the IF Display, showing a total frequency shift of almost 300Hz from one side to the other.
This error occurs at all frquencies when using 192kHz, 96kHz and 95kHz bandwidths, but the tuned frequency is locked solidly in the middle of the IF Display (as it should be) when all other available bandwidths are used.
I hope these pics help, but the problem is simple to verify anyway.
Regards, Dave
On Monday, 22 April 2019, 15:06:57 GMT+1, Simon Brown <simon@...> wrote:
Dave,
Post a screenshot – this helps me immediately see what the problem is, and also whether it’s a user misunderstanding.
I think 48kHz doesn’t work well – not sure, but I removed it for a good reason 😊 .
As for the dropdowns – I’ll change the HF+, thanks for noticing this.
Simon Brown, G4ELI
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of D R via Groups.Io
Hi Simon,
There appears to be a tuning problem with certain bandwidths on the Perseus, whereby the tuned frequency changes as the waterfall is moved from side to side, either by right-clicking or by using the slider, although the frequency display still shows the original value. It's easily audible on a CW signal, and you can also see the signal moving within the filter in the IF display. This happens when using bandwidths of 196kHz, 96 kHz and 95kHz - at other bandwidths the selected frequency stays locked on as per normal.
I've noticed that there is also a 48kHz .sbs file in the program directory, but there is no 48kHz option in the bandwidth drop-down list. As there is little need for both 95 and 96kHz widths, is there a chance of replacing the 95kHz bandwidth with 48kHz (which is really useful for DGPS band recording)?
One last small point: the bandwidth drop-down lists for most receivers has the narrowest at the top, except for the HF+, which has the widest at the top. It's no big deal, but worthy of a change for consistency?
Regards, Dave
|
|
|
|
OK,
Here’s how it works. Start Perseus, look at the logfile. After a while you’ll see entries such as:
22:42:56.252: Radio Reader> Sample rate: 24027316.244275 22:43:00.425: Radio Reader> Sample rate: 24029302.648353 22:43:04.590: Radio Reader> Sample rate: 24029123.518192 22:43:08.761: Radio Reader> Sample rate: 24028052.375562 22:43:12.938: Radio Reader> Sample rate: 24025754.577374 22:43:17.102: Radio Reader> Sample rate: 24028684.660583 22:43:21.275: Radio Reader> Sample rate: 24028591.517357 22:43:25.452: Radio Reader> Sample rate: 24028722.276321 22:43:29.610: Radio Reader> Sample rate: 24030527.970270 22:43:33.781: Radio Reader> Sample rate: 24027276.841926 22:43:37.951: Radio Reader> Sample rate: 24029085.901197 22:43:42.122: Radio Reader> Sample rate: 24028274.477557
These are for the LimeSDR @ 24 MHz, but it’s the same with Perseus. I measure samples read / time so am computing the actual sample rate using my computer’s clock. You see that Lime at 24 MHz is out by quite a bit, even though it has an external reference connected and enabled!
If you do this for the Perseus at various sample rates you will see:
So, run Perseus at 1 MHz and just wait until you get 10 or more of these entries (the maximum I display is 20), the accuracy improves with time. Then run Perseus at 192, 96 and 95 kHz – it takes longer for the entries to appear at lower sample rates – maybe 30 minutes or so at 96 kHz. Save the results and send them to me.
What we’ll do is assume 1 MHz is accurate and apply correction for 192, 96 and 95 kHz. You will still select 192kHz but internally I’ll use the corrected value, I actually do this for some other radios.
I will run this test myself; our figures should agree more-or-less.
Simon Brown, G4ELI
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of D R via Groups.Io
Ready and willing, Master!
Dave
On Tuesday, 23 April 2019, 22:05:09 GMT+1, Simon Brown <simon@...> wrote:
Hi Dave,
Just a calibration issue. Tomorrow I’ll explain how you can help with this.
Simon Brown, G4ELI
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of D R via Groups.Io
Hi Simon,
Thanks for trying with the 48kHz filter. I've had a look in the Perseus folders on my computer, and I see that in v4 of his software, Nico didn't implement 48k, 95k, 96k and 192k either, despite the files being in the installation package, and they've all been pruned from the v5 installation. Maybe he had problems with them in the past as well?
It would be nice if you can eventually get 192k working, though, as it's the bandwidth I tend to use the most for NDB hunting, and it will let me have the Perseus screen looking the same as the HF+ and FDM-S2 screens.
Best regards, Dave
On Tuesday, 23 April 2019, 16:41:10 GMT+1, Simon Brown <simon@...> wrote:
Also,
I can’t get the 48kHz rate working with a 64-bit application, sorry.
Simon Brown, G4ELI
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of Simon Brown
Dave,
Just ran some tests with my Perseus. The sample rate at 192kHz is actually 192.300 kHz and at 1 MHz it’s 0.999932 MHz.
This explains what you are experiencing. I will add a note to the website and, when I have time, I will run longer tests at all sample rates to calibrate Nico’s filters.
So, at 192kHz the error is
Simon Brown, G4ELI
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of D R via Groups.Io
Hi Simon,
Five screenshots attached, showing a 10MHz sine wave fed into the Perseus at 192kHz bandwidth: 01 is the signal centred in the spectrum / waterfall, and 02 and 03 show it just after it has been moved about 90kHz to either side - both show the tuned frequency unchanged at 10MHz, but the signal has clearly moved off-centre in the IF Display (proportionate to the amount the waterfall is shifted).
Pics 04 and 05 show the 10MHz signal at either side of the waterfall after it has been re-centred in the IF Display, showing a total frequency shift of almost 300Hz from one side to the other.
This error occurs at all frquencies when using 192kHz, 96kHz and 95kHz bandwidths, but the tuned frequency is locked solidly in the middle of the IF Display (as it should be) when all other available bandwidths are used.
I hope these pics help, but the problem is simple to verify anyway.
Regards, Dave
On Monday, 22 April 2019, 15:06:57 GMT+1, Simon Brown <simon@...> wrote:
Dave,
Post a screenshot – this helps me immediately see what the problem is, and also whether it’s a user misunderstanding.
I think 48kHz doesn’t work well – not sure, but I removed it for a good reason 😊 .
As for the dropdowns – I’ll change the HF+, thanks for noticing this.
Simon Brown, G4ELI
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of D R via Groups.Io
Hi Simon,
There appears to be a tuning problem with certain bandwidths on the Perseus, whereby the tuned frequency changes as the waterfall is moved from side to side, either by right-clicking or by using the slider, although the frequency display still shows the original value. It's easily audible on a CW signal, and you can also see the signal moving within the filter in the IF display. This happens when using bandwidths of 196kHz, 96 kHz and 95kHz - at other bandwidths the selected frequency stays locked on as per normal.
I've noticed that there is also a 48kHz .sbs file in the program directory, but there is no 48kHz option in the bandwidth drop-down list. As there is little need for both 95 and 96kHz widths, is there a chance of replacing the 95kHz bandwidth with 48kHz (which is really useful for DGPS band recording)?
One last small point: the bandwidth drop-down lists for most receivers has the narrowest at the top, except for the HF+, which has the widest at the top. It's no big deal, but worthy of a change for consistency?
Regards, Dave
|
|
|
|
D R
No problem - the 1MHz run is underway. I'll collect 20 readings for each bandwidth and send them to you. Regards, Dave
On Tuesday, 23 April 2019, 22:52:08 GMT+1, Simon Brown <simon@...> wrote:
OK,
Here’s how it works. Start Perseus, look at the logfile. After a while you’ll see entries such as:
22:42:56.252: Radio Reader> Sample rate: 24027316.244275 22:43:00.425: Radio Reader> Sample rate: 24029302.648353 22:43:04.590: Radio Reader> Sample rate: 24029123.518192 22:43:08.761: Radio Reader> Sample rate: 24028052.375562 22:43:12.938: Radio Reader> Sample rate: 24025754.577374 22:43:17.102: Radio Reader> Sample rate: 24028684.660583 22:43:21.275: Radio Reader> Sample rate: 24028591.517357 22:43:25.452: Radio Reader> Sample rate: 24028722.276321 22:43:29.610: Radio Reader> Sample rate: 24030527.970270 22:43:33.781: Radio Reader> Sample rate: 24027276.841926 22:43:37.951: Radio Reader> Sample rate: 24029085.901197 22:43:42.122: Radio Reader> Sample rate: 24028274.477557
These are for the LimeSDR @ 24 MHz, but it’s the same with Perseus. I measure samples read / time so am computing the actual sample rate using my computer’s clock. You see that Lime at 24 MHz is out by quite a bit, even though it has an external reference connected and enabled!
If you do this for the Perseus at various sample rates you will see:
So, run Perseus at 1 MHz and just wait until you get 10 or more of these entries (the maximum I display is 20), the accuracy improves with time. Then run Perseus at 192, 96 and 95 kHz – it takes longer for the entries to appear at lower sample rates – maybe 30 minutes or so at 96 kHz. Save the results and send them to me.
What we’ll do is assume 1 MHz is accurate and apply correction for 192, 96 and 95 kHz. You will still select 192kHz but internally I’ll use the corrected value, I actually do this for some other radios.
I will run this test myself; our figures should agree more-or-less.
Simon Brown, G4ELI
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of D R via Groups.Io
Ready and willing, Master!
Dave
On Tuesday, 23 April 2019, 22:05:09 GMT+1, Simon Brown <simon@...> wrote:
Hi Dave,
Just a calibration issue. Tomorrow I’ll explain how you can help with this.
Simon Brown, G4ELI
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of D R via Groups.Io
Hi Simon,
Thanks for trying with the 48kHz filter. I've had a look in the Perseus folders on my computer, and I see that in v4 of his software, Nico didn't implement 48k, 95k, 96k and 192k either, despite the files being in the installation package, and they've all been pruned from the v5 installation. Maybe he had problems with them in the past as well?
It would be nice if you can eventually get 192k working, though, as it's the bandwidth I tend to use the most for NDB hunting, and it will let me have the Perseus screen looking the same as the HF+ and FDM-S2 screens.
Best regards, Dave
On Tuesday, 23 April 2019, 16:41:10 GMT+1, Simon Brown <simon@...> wrote:
Also,
I can’t get the 48kHz rate working with a 64-bit application, sorry.
Simon Brown, G4ELI
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of Simon Brown
Dave,
Just ran some tests with my Perseus. The sample rate at 192kHz is actually 192.300 kHz and at 1 MHz it’s 0.999932 MHz.
This explains what you are experiencing. I will add a note to the website and, when I have time, I will run longer tests at all sample rates to calibrate Nico’s filters.
So, at 192kHz the error is
Simon Brown, G4ELI
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of D R via Groups.Io
Hi Simon,
Five screenshots attached, showing a 10MHz sine wave fed into the Perseus at 192kHz bandwidth: 01 is the signal centred in the spectrum / waterfall, and 02 and 03 show it just after it has been moved about 90kHz to either side - both show the tuned frequency unchanged at 10MHz, but the signal has clearly moved off-centre in the IF Display (proportionate to the amount the waterfall is shifted).
Pics 04 and 05 show the 10MHz signal at either side of the waterfall after it has been re-centred in the IF Display, showing a total frequency shift of almost 300Hz from one side to the other.
This error occurs at all frquencies when using 192kHz, 96kHz and 95kHz bandwidths, but the tuned frequency is locked solidly in the middle of the IF Display (as it should be) when all other available bandwidths are used.
I hope these pics help, but the problem is simple to verify anyway.
Regards, Dave
On Monday, 22 April 2019, 15:06:57 GMT+1, Simon Brown <simon@...> wrote:
Dave,
Post a screenshot – this helps me immediately see what the problem is, and also whether it’s a user misunderstanding.
I think 48kHz doesn’t work well – not sure, but I removed it for a good reason 😊 .
As for the dropdowns – I’ll change the HF+, thanks for noticing this.
Simon Brown, G4ELI
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of D R via Groups.Io
Hi Simon,
There appears to be a tuning problem with certain bandwidths on the Perseus, whereby the tuned frequency changes as the waterfall is moved from side to side, either by right-clicking or by using the slider, although the frequency display still shows the original value. It's easily audible on a CW signal, and you can also see the signal moving within the filter in the IF display. This happens when using bandwidths of 196kHz, 96 kHz and 95kHz - at other bandwidths the selected frequency stays locked on as per normal.
I've noticed that there is also a 48kHz .sbs file in the program directory, but there is no 48kHz option in the bandwidth drop-down list. As there is little need for both 95 and 96kHz widths, is there a chance of replacing the 95kHz bandwidth with 48kHz (which is really useful for DGPS band recording)?
One last small point: the bandwidth drop-down lists for most receivers has the narrowest at the top, except for the HF+, which has the widest at the top. It's no big deal, but worthy of a change for consistency?
Regards, Dave
|
|
|
|
toggle quoted messageShow quoted text
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of D R via Groups.Io
No problem - the 1MHz run is underway. I'll collect 20 readings for each bandwidth and send them to you.
Regards, Dave
|
|
|
|
Paul NN4F
Simon, Do you need from multiple radios, I can run my Perseus also and send?
On Tue, Apr 23, 2019 at 6:32 PM Simon Brown <simon@...> wrote:
|
|
|
|
toggle quoted messageShow quoted text
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of Paul NN4F
Simon, Do you need from multiple radios, I can run my Perseus also and send?
Paul Jones - NN4F / ELAD Technical Support Work Email: Support@... Personal Email: paul@...
|
|
|
|
D R
Simon, My data file attached. Out of curiosity I also recorded the sample rates at 2M, 500k and 250k, which revealed that 250kHz is easily the most accurate, and 95k by far the least. For the sake of completeness, I'll also run 125kHz bandwidth as well, but as this will take another four and a half hours I'll send the results later tonight. The results are also tabulated in the attached Excel file for easy viewing. Regards, Dave
On Wednesday, 24 April 2019, 12:07:19 GMT+1, Simon Brown <simon@...> wrote:
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of Paul NN4F
Simon, Do you need from multiple radios, I can run my Perseus also and send?
Paul Jones - NN4F / ELAD Technical Support Work Email: Support@... Personal Email: paul@...
|
|
|
|
D R
The 125kHz data is now in the Excel file. It turned out to be the most accurate one of all - just 0.28Hz error! Regards, Dave
On Wednesday, 24 April 2019, 19:33:46 GMT+1, D R via Groups.Io <robsond90@...> wrote:
Simon, My data file attached. Out of curiosity I also recorded the sample rates at 2M, 500k and 250k, which revealed that 250kHz is easily the most accurate, and 95k by far the least. For the sake of completeness, I'll also run 125kHz bandwidth as well, but as this will take another four and a half hours I'll send the results later tonight. The results are also tabulated in the attached Excel file for easy viewing. Regards, Dave
On Wednesday, 24 April 2019, 12:07:19 GMT+1, Simon Brown <simon@...> wrote:
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of Paul NN4F
Simon, Do you need from multiple radios, I can run my Perseus also and send?
Paul Jones - NN4F / ELAD Technical Support Work Email: Support@... Personal Email: paul@...
|
|
|
|
Tony_AD0VC
If you can look at the log file numbers over time and figure out what the sample rate really is, it seems like the code could do it too...
Tony
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> on behalf of D R via Groups.Io <robsond90@...>
Sent: Wednesday, April 24, 2019 5:58 PM To: main@SDR-Radio.groups.io Subject: Re: [SDR-Radio] Perseus tuning problem. The 125kHz data is now in the Excel file. It turned out to be the most accurate one of all - just 0.28Hz error!
Regards,
Dave
On Wednesday, 24 April 2019, 19:33:46 GMT+1, D R via Groups.Io <robsond90@...> wrote:
Simon,
My data file attached.
Out of curiosity I also recorded the sample rates at 2M, 500k and 250k, which revealed that 250kHz is easily the most accurate, and 95k by far the least. For the sake of completeness, I'll also run 125kHz bandwidth as well, but as this will take another
four and a half hours I'll send the results later tonight.
The results are also tabulated in the attached Excel file for easy viewing.
Regards,
Dave
On Wednesday, 24 April 2019, 12:07:19 GMT+1, Simon Brown <simon@...> wrote:
Paul,
Yes please, should confirm Dave’s findings.
Simon Brown, G4ELI
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io>
On Behalf Of Paul NN4F
Simon, Do you need from multiple radios, I can run my Perseus also and send?
Paul Jones - NN4F / ELAD Technical Support Work Email: Support@... Personal Email: paul@...
|
|
|
|
toggle quoted messageShow quoted text
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of D R via Groups.Io
The 125kHz data is now in the Excel file. It turned out to be the most accurate one of all - just 0.28Hz error!
Regards, Dave
On Wednesday, 24 April 2019, 19:33:46 GMT+1, D R via Groups.Io <robsond90@...> wrote:
Simon,
My data file attached.
Out of curiosity I also recorded the sample rates at 2M, 500k and 250k, which revealed that 250kHz is easily the most accurate, and 95k by far the least. For the sake of completeness, I'll also run 125kHz bandwidth as well, but as this will take another four and a half hours I'll send the results later tonight.
The results are also tabulated in the attached Excel file for easy viewing.
Regards, Dave
On Wednesday, 24 April 2019, 12:07:19 GMT+1, Simon Brown <simon@...> wrote:
Paul,
Yes please, should confirm Dave’s findings.
Simon Brown, G4ELI
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of Paul NN4F
Simon, Do you need from multiple radios, I can run my Perseus also and send?
Paul Jones - NN4F / ELAD Technical Support Work Email: Support@... Personal Email: paul@...
|
|
|