I don't remember why, I think this is due to some restriction inside the software or to synchronize OmniRig with the center frequency and not the virtual receiver frequency. I will check.

Vianney

Yes. Why would using Omnirig require “Lock to CF”?

Jeff

 

From: EladSDR@groups.io <EladSDR@groups.io> On Behalf Of Vianney Colombat
Sent: Friday, December 20, 2019 9:50 AM
To: EladSDR@groups.io
Subject: Re: [EladSDR] S2 RX1 Stuck in "Lock To CW" mode #fdm-sw2 #fdm-s2

 

[EXTERNAL]  

 

This is due to some settings. Did you enable omnirig in the Remote Ctrl tab of the Setup window ?

 

Regards,

 

Vianney

 

From: "Jeff Patterson via Groups.Io" <Jeff_patterson@...>
To: EladSDR@groups.io
Date: Fri, 20 Dec 2019 08:39:11 -0800
Subject: [EladSDR] S2 RX1 Stuck in "Lock To CW" mode #fdm-sw2 #fdm-s2

Recently bought an S2 and loaded the latest fdm-sw2 software (3.027). Impressed with both but for some reason Channel 1, Rx1 is stuck in Lock To CF mode. This is really annoying for a number of reasons.

I'm trying to determine if this a bug or if I have some hidden setting wrong. The Icon circled below is unresponsive to mouse clicks and the keyboard shortcut ("K")

Any help?

Thanks,
Jeff NG6X

Le informazioni contenute in questo messaggio di posta elettronica sono riservate e confidenziali e ne è vietata la diffusione in qualunque modo eseguita (DL 196/2003). Qualora Lei non fosse la persona a cui il presente messaggio è destinato, La invitiamo ad eliminarlo e a non leggerlo, dandone gentilmente comunicazione al mittente.

The information contained in this e-mail and any attachments is confidential and may well also be legally privileged (DL 196/2003). If you are not among the named recipients, please notify the sender immediately by reply e-mail and then delete this message from your system, do not use the contents for any purpose whatsoever nor disclose them to anyone else.

_._,_._,_

---

Le informazioni contenute in questo messaggio di posta elettronica sono riservate e confidenziali e ne è vietata la diffusione in qualunque modo eseguita (DL 196/2003). Qualora Lei non fosse la persona a cui il presente messaggio è destinato, La invitiamo ad eliminarlo e a non leggerlo, dandone gentilmente comunicazione al mittente.

The information contained in this e-mail and any attachments is confidential and may well also be legally privileged (DL 196/2003). If you are not among the named recipients, please notify the sender immediately by reply e-mail and then delete this message from your system, do not use the contents for any purpose whatsoever nor disclose them to anyone else.

Some comments:

Fan manufacturer code is correct, also that the airflow is from right to left when looking at the front of the FDM-DUO. There is a piece of thermal silicon between the heatsink and and the top cover to ensure better thermal conductivity.

The fan runs when the internal temperature reaches about 65°C (149°F) without delay time, if the temperature reaches the limit value of about 85°C (185°F), the writing HI TEMP appears on the display and the transmission is disabled. When the temperature goes below about 76°C (169°F) the transmission is re-enabled and the fan turns off when the temperature goes below about 58°C (136°F).

It is normal that the fan runs quite often if the FDM-DUO is almost always transmitting. Moreover the higher the ambient temperature, the more it will run.

Vianney

On Wed, Jan 1, 2020 at 11:46 PM, Klaus Brosche, DK3QN wrote:

Manufacturer order number MC25060V1-000U-A99   >> with re. to the fan!

Hi Group,

That fan with the cited manufacturer order number (manufacturer SUNON) is in my particular unit (FDM-DUO).
Since my unit left the factory some years ago, it would be quite interesting what kind of fan is being used by
ELAD in the more recently delivered FDM-DUO units (the fan in my unit seems to be an obsolete part by now).

Maybe Vianney is open and may comment on that.

Else: if you'll be going to open your DUO for the next firmware update: please check the fan manufacturer and
order number and report it back here.

I have opened my DUO again today in order to investigate that fan subject in more detail, including dismantling the fan from its mounting. Thus, some updated findings:
Opposite to my previous post, the fan in my unit does not blow air onto the heatsink, where the 2 final transistors
are fixed to. Instead, it sucks air from there. So, the airflow is from right to left, when looking at the front of the unit.
Which doesn't make things better, as it is a long way to go, until (hot) air may exit through the left side openings. 
Plus, there is the internal speaker sitting - for the most part - directly within that airflow passage.

Anyway, an interesting subject to deal with, especially when being faced with the DUOs quite tight internal layout.
I'll keep you updated about my further findings.

Klaus, DK3QN

Le informazioni contenute in questo messaggio di posta elettronica sono riservate e confidenziali e ne è vietata la diffusione in qualunque modo eseguita (DL 196/2003). Qualora Lei non fosse la persona a cui il presente messaggio è destinato, La invitiamo ad eliminarlo e a non leggerlo, dandone gentilmente comunicazione al mittente.

The information contained in this e-mail and any attachments is confidential and may well also be legally privileged (DL 196/2003). If you are not among the named recipients, please notify the sender immediately by reply e-mail and then delete this message from your system, do not use the contents for any purpose whatsoever nor disclose them to anyone else.

Jeroen,

I am getting some decoding but I suspect those are the very strongest signals that I am receiving.  The signal strength graph, to the left, is only at 3-5 dbm at the bottom of the scale.  What is pavucontrol?  I did not install it but where can I find it?

Thanks for your help.

73

Mark 
KK2L

Mark,

Did you install pavucontrol?
If yes, check the audio sources under all tabs. It is very likely the wrong source is selected.
If not, do so and follow the instructions above.

And I believe there was some issue about autostarting pulseaudio. Have to dig into that too...
Currently at work, so no Pi available :-)

Jeroen PF1JM

Hi Jeroen,

I got CAT working but am getting minimal audio from the Pi.  I did set up the Audio configuration as recommended in wsjt-x.  Any suggestions?

Thanks

Mark
KK2L

You can also use a CAT command to define a message and play it.  See the CM command in the manual.

Hi Craig,
Could you share your Rpi setup with me, I am still not able to get proper communication between the WSJT-x/Rpi/FDM-DUO. Off list would be fine. (qrz listing is current)

Kind Regards,
73, Dennis, W7DRW

After another 24 hours, I still see about 0.2-0.4s DT and no lagging, using that 100.002 correction factor in VAC.  I'll leave it a few more days.  Has anyone with the latency/timing problem given this a try to see if it has any effect?

I've never tried my DUO on 160m or 630/2200m, so I've been giving it a go, seeing as I want to check for latency increases anyway. In the last 48 hours, I've heard 68 DXCC entities on 160m, mostly on FT8, including 36 US states as far as Florida, Colorado, Oregon and Arizona, 20+ JAs, Philippines, Indonesia, India, loads of Caribbean islands, Costa Rica, Mexico, Ecuador, Ghana, South Africa, Brazil, Korea, Oman, Kuwait.  I'm trying it on 630m WSPR tonight.  Last time I was on 160m was in the late 1990s.  I don't remember being able to hear like this at all. Marvellous little rig in terms of fun per dollar.

Neil G4DBN

Clint, I think they are talking about the USB virtual sound card within the DUO.  The sound card in my PC isn't involved in anything connected with the DUO other than driving the loudspeakers. 

One possible full solution was explained in Alberto's post, using a control loop to adjust the clocking rate to keep the buffers from growing too large or causing under-runs.  That needs development work by Elad. 

Oidar's post in that thread suggested a way to use the clock correction in VAC to set a manual compensation rate to provide a temporary workaround until the fix was done. It looks like I did that fix back several years ago. I can't recall when.

I haven't ever noticed any lagging, so I have no idea if this might help with that, but it does seem to affect the delay when using WSJT-X, at least the DT values in FT8 anyway.

I tried a test, setting the Clock correction ratio to 99.5000 and, as expected, the DT values in FT8 started to climb toward 2 seconds.  I then set it to 100.5 and it pulled the DT value back to 0.2-0.4s over a few minutes.  With it set at 100.00200, I don't see any increase in DT value that I've noticed over a few hours, but I'll leave this on 160m overnight and see if the average DT value has risen by tomorrow night.

I didn't notice any bad effects from using a silly high value of correction ratio, I would expect to see underruns and get clicks in the audio, but nothing untoward seemed to happen. YMMV

Neil G4DBN

Here is my current VAC setting for Line 1

No guarantee it will do anything useful, but it didn't seem to do any harm.

My relevant SW2 settings are:

and WSJT-X settings:

I have seen several posts about some sound cards not causing any latency issues, but I have not seen any model numbers for the cards.  I have tested about 5 different cards and they all had latency issues.  If the fix is to install the right sound card, then it would be helpful if Elad could determine which sound cards work the best with the SW2 software and/or publish details on setting up a VAC that would resolve the issue.

 

73

Clint

W7KEC

 

From: EladSDR@groups.io [mailto:EladSDR@groups.io] On Behalf Of Neil Smith G4DBN
Sent: Friday, January 10, 2020 4:49 PM
To: EladSDR@groups.io
Subject: Re: [EladSDR] DIGITAL TIMING

 

Have a read of the thread I referred to which explored the issue around clocking. 

It is probably worth raising another support ticket to keep the issue of fractional resampling fresh in the minds of Elad developers.  See the thread for Alberto's notes https://groups.io/g/EladSDR/topic/5756057 and have a read of Oidar's post about his VAC settings at  https://groups.io/g/EladSDR/message/12350

If you are using VAC, it might be worth trying a clock correction as Oidar suggested in that post, at least until the devs implement the necessary fractional resampler. If you are 2.2 seconds in 24 hours, you would need a correction of 100*(1+(2.2/86400)) = 100.002546 (or 99.997454 if it is the other way) for that VAC. That might change if the sampling clock rate in the DUO changes.

My VAC has a correction of 100.0014, I don't notice any drift on FT8 DT after 3-4 days of operation.  I've not noticed any latency or laggy controls either.  I must have set that value a few years ago.  Whether it is doing anything of benefit, I can't tell.  Perhaps I should set it back to 100.00000 to see what happens.

Neil G4DBN

 

On 10/01/2020 22:16, chris wrote:

not sure how windows could be at fault when a restart of sw2 fixes the problem and if I use hpsdr and jtdx  and the the same vac I dont appear to get the problem

-- 

Neil

<a href="http://g4dbn.uk/"><small>g4dbn.uk</small></a>

-- 
Neil
<a href="http://g4dbn.uk/"><small>g4dbn.uk</small></a>

Have a read of the thread I referred to which explored the issue around clocking. 

It is probably worth raising another support ticket to keep the issue of fractional resampling fresh in the minds of Elad developers.  See the thread for Alberto's notes https://groups.io/g/EladSDR/topic/5756057 and have a read of Oidar's post about his VAC settings at  https://groups.io/g/EladSDR/message/12350

If you are using VAC, it might be worth trying a clock correction as Oidar suggested in that post, at least until the devs implement the necessary fractional resampler. If you are 2.2 seconds in 24 hours, you would need a correction of 100*(1+(2.2/86400)) = 100.002546 (or 99.997454 if it is the other way) for that VAC. That might change if the sampling clock rate in the DUO changes.

My VAC has a correction of 100.0014, I don't notice any drift on FT8 DT after 3-4 days of operation.  I've not noticed any latency or laggy controls either.  I must have set that value a few years ago.  Whether it is doing anything of benefit, I can't tell.  Perhaps I should set it back to 100.00000 to see what happens.

Neil G4DBN

not sure how windows could be at fault when a restart of sw2 fixes the problem and if I use hpsdr and jtdx  and the the same vac I dont appear to get the problem

-- 
Neil
<a href="http://g4dbn.uk/"><small>g4dbn.uk</small></a>

not sure how windows could be at fault when a restart of sw2 fixes the problem and if I use hpsdr and jtdx  and the the same vac I dont appear to get the problem

Mark,

16 Gig minimal. All will do well on 8 Gig also, but for the price, get 16 or 32. Get a good quality card.
It leaves you enough room to install additional packages, such as qsstv, logbook, you name it.
And it helps reduce wear on the memory chips. Each memory cell can handle a limited number of write actions before it fails. With regular use, you probably will never reach that point, though.

If you intend to use the Pi for hamradio only, start with Raspbian with desktop, not the full version with recommended software.

73, Jeroen PF1JM

Hi Jeroen,

Thank-you for the detailed explanation.  What size SD card would you recommend?  32gb?

73

Mark
KK2L