开云体育

Well I am stumped, I use digital modes a lot, J8Call, VARAHF, FT4 & 8 so I know I have the right sound card settings in windows 11 to my IC-7300. Youtube has some videos, ok... But I can not get a wefax to come in. I have found the signal mostly out of New Orleans, on 4317.9 USB and a pulsing S5 to7. I can hear it on my headset but Nothing shows on FLdigi waterfall. the green receiving line is around 60 and moves with the s-meter. I have tried B/W and the color option, but they're blank. I've run it for 24 hours for possible propagation differences, but nothing is received. Thoughts, suggestions? yes the antenna is connected.. lol

Dave, Here is a curiosity question: I am running the current alpha code (4.2.06.15) now, but have seen this multiple line blurring effect going back a ways in previous versions. If I run fldigi on this Win 11 or my old Win 10 i7 boxen for a while, The display goes like: and the copy become erratic. If I close fldigi and immediately restart the display goes back to normal and copy is nominal: This appears to happen in all digital modes I commonly use (most often Thor, Olivia, FSQ - but also others). It also impacts all visible signals on the waterfall together. I notice it on the 7300 because it is my primary "digital" radio, but also have seen it on the 705 and 7610. At first I thought it was a propagation artifact, until I restarted the program and immediately the blurring was gone. Restarting the program always clears things up. Any clues what this might be? Something with the fourier algorithm associated with WF and decode? I am sure my cat did not walk on the keyboard... :) Note, those two birdies seem to be generated away from the QTH - they are periodic and don't bother me when there. They were convenient to show what happens to all signals. -- Jack Spitznagel KD4IZ FM19oo Pakton, MD

THOR 25 TEST RESULTS A test of the new mode THOR25 was achieved on the PANBEMS net (Sunday 0730 hr EST on 3583 kHz VFO) The new alpha version of Fldigi: 4.2.06.15 did work with TxID/RxID and THOR25 codes. Copy with THOR25 was excellent and prop on 80m at 0800 hr was very stable with strong signals from PA/NJ/NY/ and New England Here is the AUDIO spectrum of THOR25 on 3583 kHz (vfo) caught on my HF SSB receiver and sound card (Icom 7610)

Posted at http://www.w1hkj.com/alpha/fldigi fldigi-4.2.06.15.tar.gz fldigi-4.2.06.15_SO.dmg fldigi-4.2.06.15_setup.exe fldigi-dark-scheme.png readme.dmg.txt readme.txt Most recent three changes to the program: commit ad817413f9d517a88b9156d48cc28f3a0b53c92c Author: dave-w1hkj <w1hkj@...> Date: Mon Dec 9 15:05:42 2024 -0600 MFSK afc * Increase AFC low pass filter range to 500. commit 68e700918a9517b6825c94365037ae07fbb57fd3 Author: dave-w1hkj <w1hkj@...> Date: Thu Dec 12 09:23:27 2024 -0600 THOR-25 * add new THOR modem with following characteristics . symlen = 320 . samplerate = 8000 . flushlength = 20 . bandwidth = 460 . IEEE coefficients for viterbi encode/decode algorithms THOR_K15 15 K15_POLY1 044735 K15_POLY2 063057 . objective to provide highest baud within 500 Hertz bandwidth for European amateurs * assigned secondary RsID code 691 to THOR-25 * increased flush length for all THOR baud rates * added configurable start and end of signal shaping to these modem types: . dominoEX . psk . mfsk . rtty . thor . selectable on configuration tab Modem/General commit 8aa6a3ea07596d0c61e57462c8ffe1bae939339b Author: dave-w1hkj <w1hkj@...> Date: Wed Nov 27 15:49:26 2024 -0600 MFSK afc * add configuration item allowing user to adjust the decay averaging of the AFC tracking. 73, David W1HKJ

THOR 25 Here is the RF Spectrum of the new (alpha) mode THOR25 sent on 441.525 simplex FM with no PL tone Rig: Icom 2820 (set to 1200 baud) and Masters Communications DRA SR sound card Deviation set to about 2.2 kHz (since amplitude of pair of first sidebands = carrier amplitude) Recorded on RSP duo hardware and RSP Spectrum Analyzer software Let's test this new (alpha) mode soon on the HF SSB nets (Pa NBEMS and MidAtlantic NBEMS) and on local county FM 2m/70cm source: w1hkj.com/alpha Dec 12 2024 de k3eui

THOR25 is a new (alpha) mode in FLDIGI THOR I am using version: 4.2.06.15 Here is an AUDIO SPECTRUM of THOR25 as I was sending a FLMSG on 80m NBEMS net. Note the sharp sides down to a BW of about 800 Hz @ 30dB below the peak Hope to try this new speed on the 80m and 40m NBEMS nets in the Pa region: PaNBEMS: Sunday 0730 hr EST on 3583.0 kHz (vfo) Mid-Atlantic NBEMS: Sunday 1000 hr EST on 7068.0 kHz (vfo) de k3eui Barry Philly =============================

I downloaded FLdigi v4.2.06 and configured it to work with my Apache Labs 7000DLE MKII rig. When I make a short xmission 'PSK31' say about 5 to 15 seconds all is OK. The problem is if I send a file , brag, etc, that is longer than 20 sec or so, I lose the HAMLIB CAT connection in my 7000DLE MKII rig. I can see this happen real time while monitoring the 'TCPIP CAT server' in the rig. The client connection goes from ONE to ZERO, and I know the conn is lost. What this does in the rig is, once the FLdigi brag file finishes the rig stays in XMIT mode, the MOX button does not turn off. I can manually hit MOX and the rig goes back into receive. To restore the TCPIP cat connection, in FLdigi I unchk HAMLIB then rechk and initialize. The 7000DLE MKII TCPIP connection is now back to ONE. As I said a short xmission works fine, the rig returns to rec once the file has finished transmitting. I have not posted this issue on the Apache Labs site yet. Thanks, Dave k4em

I have the very same problem described here: winfldigi@groups.io | Double-clicking setup.exe does nothing but I can’t seem to post there. I’m running Win 10 pro 64-bit. When I click on setup.exe, I get the Windows user account control warning about running an app from an unknown publisher, I say Yes to it, and nothing happens. This happens on another Win 10 Pro 64-bit unit as well. It is not a zip file either. I right-click it and there is no ‘extract all’ option. Even if I select ‘run as administrator’, I get that UAC warning, click on Yes, and nothing happens. The file I’m using is fldigi_4.2.06_setup.exe from http://www.w1hkj.com/files/fldigi/ -- Bob N7PTM “Number 7 Pegs The Meter”

Mick N3OJP I have never encountered a “run time error” so have no advice, other than to keep asking folks more familiar with operating systems. I will copy your concern to folks who are pretty solid with FLDIGI. I would not complain if a Win 7 machine fails. Update! But my three Win10 computers (two desktops, one laptop) have never encountered a RUN TIME ERROR. Keep us in the loop. I would delete the PREFS file first, and start all over with FLDIGI. Barry Why am I getting a runtime error? Runtime errors can occur if you are running two software programs that are not compatible, if your computer has memory problems, or if the computer has been infected with malicious software. Therefore, I suggest you to check if there are any latest updates available for the program from the manufacturer's site.Aug 30, 2011 Barry On Dec 10, 2024, at 6:05 PM, MICHAEL PYZOHA <pyzoham@...> wrote: ? Hi Barry I need some guidance from you as VARA on my Win 10 machine using Winlink or VacAC is giving me Run Time Error and used to work just fine. I use a Win 7 machine and I have no trouble with VARA, Winlink or VarAC. I have deleted from the Win 10 machine Winlink, VarAC and VARA and reinstalled same problem. The Run Time Error appeared out of no where and if I can resolve that I may have luck with the Win 10 machine. I did check the VarAC forums and VARA support and I find nothing on the Run Time Error so must be a Win 10 computer issue and VARA. I have done research on the Run Time Error, tried some suggestions and no change. There is also a Com Port issue with VarAC. This Win 10 laptop used to work with VarAC and Winlink and something changed and I do not have a restore point. Any advise is appreciated Barry and don't spend much time as I think I will deinstall the programs and start fresh again. BTW Fldigi works ok on this Win 10 machine and I will download the version that uses THOR 25 as I read your groups.io postings. I like to use the Win 10 machine in my travels to Western NY home with 71' wire and EFHW. I have attached 3 screenshots showing the problems I see. See what you think Barry....thanks Mick Pyzoha N3OJP Using Winlink I always get this error on the Win 10 machine when VARA opens. If I click on ok VARA closes and does not restart. I have to close Winlink, start up Winlink, VARA starts up and I get the error. When using VarAC in Settings the Com port number will not save. I can enter Com 3 which is correct, PTT ON test works, Save and Exit and reopen VarAC Setting and Port is blank. The Com port will not save. VARA does not open automatically in VarAC even though in Settings in the VARA tab I have the correct path. I open VARA manually and get the Run Time Error.

Hi all, I'm EA3FH just joined the group while trying to fix an issue with FLRIG which I'm experiencing since my last setup change. I've been using FLRIG with an emulated K3 from Remotehams since years ago. With my old setup I used to have one remote computer and one local dedicated computer for radio related, but finally I will just keep the remote computer and my needs now are not to use Remotehams for now. So, I configured FLRIG and I am able to connect my 706MK2G wihout issues; I was able also to use keyers, wsjt-x, ptt... all ok. The issue comes now that the SPLIT button that it's suposed to be in the FLRIG Application is not there. In the FLRIG help webpage it states that button should be there: But in my case, this is how I see it, without the Split button. How can this be fixed? FLRIG version used is 2.0.05 Thank you! Julio EA3FH

http://www.w1hkj.com/alpha/fldigi/ fldigi-4.2.06.14.tar.gz fldigi-4.2.06.14_SO.dmg fldigi-4.2.06.14_setup.exe Most recent change: commit 0169172527f33938496aa6672adf7b0947922def Author: dave-w1hkj <w1hkj@...> Date: Sun Dec 8 17:20:08 2024 -0600 THOR25 * add new thor modem with following characteristics . symlen = 320 . samplerate = 8000 . flushlength = 20 . bandwidth = 460 . IEEE coefficients for viterbi encode/decode algorithms THOR_K15 15 K15_POLY1 044735 K15_POLY2 063057 * increased flush length for all baud rates * added configurable start of signal shaping to these modem types: . psk . mfsk . rtty . thor * removed end of signal shaping * assigned secondary RsID code 691 Thor-25 signal showing RsID and 200 msec rise time at start of data stream. 73, David W1HKJ

http://w1hkj.com/alpha/fldigi/readme.txt suggestion - let’s try thor25 for traffic over next few weeks on PA NBEMS (3583 kHz at 0730 hr EST) and MidAtlantic nbems net (7068 kHz at 1000 hr est) on Sunday mornings Barry k3eui readme Text Document · 895 KB

RF SPECTRA of the THOR speeds on HF SSB There is a new (alpha) THOR mode with the designation THOR 25 We tried THOR25 after the PA NBEMS net (Sunday 0730 hr on 3583.0 kHz) and it worked well as a traffic mode, compared to THOR32 which we have been using (as well as MFSK32). I wanted to compare the RF SPECTUM of each of the THOR speeds, so I used a SDR (RSP play hardware) and RSP Spectrum Analyzer (software) and set it on 3585.5 kHz center frequency with a very high resolution bandwidth. Transmitter was an Icom 7610 (built in sound card) with VFO set to 3585.0 kHz Here are the results, showing the "peak" bandwidth of the THOR speeds, as well as the BW at 30dB below the peak. I think the present definition of "bandwidth" is that width at -26dB below the peak, so -30dB is close to that standard and easy to see. I think the other definition of BW is that signal containing 99% (or was it 99.9%) of the energy. THOR25 is still in testing (alpha) and does not yet have an assigned TXID/RXID identifier. But you can manually go to OP MODE on top menu and select THOR25. The goal of the 80m and 40m NBEMS nets is to use one mode for taking check-ins (usually THOR22) and to send the call sign twice, then the name, location (county if in Pa) and traffic/no traffic or QTC/QRU, and many send a S/N of the net control. THOR vs. MFSK THOR modes are far easier to tune in on SSB compared to MFSK modes. I find if I mistune a MFSK32 signal by about 15 Hz then I lose all copy. THOR can be badly mistuned and still get full print. THOR also uses the "difference in pitch" from one tone to the next tone as the character, not the absolute pitch. There are other reasons I prefer THOR on HF NBEMS nets. So take a look at the RF spectra (not the audio spectra) and see for yourself the pros/cons of each speed. As FLDIGI develops the THOR 25 mode, we will have more data to report back to W1HKJ. de k3eui Barry Kennett Square PA (near Phila) Dec 08 2024

Tobias, Please test both MFSK and THOR (especially new modem type THOR-25) added to 06.12 test version at http://www.w1hkj.com/alpha/fldigi/ commit db6798876a79e5087a69017c2a6c5c32712c05b6 Author: dave-w1hkj <w1hkj@...> Date: Wed Dec 4 06:31:43 2024 -0600 THOR25 * add new thor modem with following characteristics . symlen = 320 . samplerate = 8000 . flushlength = 40 . bandwidth = 460 Also increased the flush length on all THOR modem types. David On 12/1/24 09:22, T? via groups.io wrote: Hello David, I found the respective information mentioned in my last e-mail, that the bandwidth is restricted to 500 Hz: it's in the IARU Region 1 Bandplan (attached) for the 80 m DigiMode frequencies between 3580 and 3600 kHz, denominated 'Narrow band modes'. While wider modes are accepted above 3600 kHz, these parts of the band are usually full of SSB communication and thus not used (and suited) for DigiMode traffic, except the area around 3733 kHz, which is frequently used for short SSTV (analog and digital) image QSOs here in Europe. Similar 500 Hz bandwidth restrictions apply in many other HF bands. - - - - - - If I may ask, is there a technical necessity to define the THOR32 mode a bit wider (vs. the MFSK32 definition) than the above-mentioned 500 Hz limit? In other words, would it be possible to define a THOR32-500 mode. e.g. by reducing the tone spacing to the 31.25 Hz used in MFSK32, which Hams could then use within the 500 Hz limits of the bandplan? I am aware that not all signals on the air do comply with the requirements, and some Hams actually use wider modes in these bands (against the rules), but at least all members of the German DARC club are required to adhere to the official bandplan definitions, and they do risk losing their membership, I was told, if they don't. So there's no practical way to replace MFSK32 with THOR32 for the DL0BS QTC and the QSL traffic, as I had recently described. - - - - - - By the way, based on your recent feedback about THOR32, I got curious and made a first comparative PathSim evaluation between MFSK32 and THOR32 with signals directly created in fldigi ver4.2.06.11, using an old (yet typical) DL0BS intro text, dating back to the Ol4/500 times and Wednesday schedule (today, it's every Monday evening at 2100 CET = 2000z in MFSK32 on 3590.75 kHz). - FLdigi @ 1500 Hz: TX generate MFSK32 and then THOR32 -> 2 separate WAV files. - Level normalized to 5% amplitude (both files) and 1 second pauses (leading and trailing) were added, this helps runs the simulations correctly. - PathSim set to 'Mid-Latitude Disturbed NVIS' with path 1 (1 Hz frequency spread), path 2 (1 Hz frequency spread, delay 7 ms), plus AWGN noise set for 0 dB SNR. - FLdigi Audio Playback (both files), again set to 1500 Hz (no center offset). - Rx text (both files) separately copied into the prepared spreadsheet. - The spreadsheet compares each line vs. the original TX Text, auto-highlighting all deviating text lines in yellow. The plain result is, that MFSK32 produced 2 errors (one of which was the missing SOT sign), and THOR32 produced 18 errors (one of which was the missing SOT sign, too). I don't know what has caused this unexpected difference, but it is clearly too significant to be just a random effect. There may be other signal conditions where THOR32 is more stable than MFSK32 (certainly in case of RX mistuning), but I have intentionally chosen a test case known to be borderline, where MFSK32 started producing first errors in a simulation run back in 2023, in the wake of the intended Ol4/500 to MFSK32 transition (Olivia did a lot worse by the way). While THOR32 has decoded parts of the text perfectly fine, others deviate considerably. Could this be an effect of the built-in wide frequency range compatibility (a bit similar to the discussed AFC issues in MFSK32 - AFC was OFF here!), so that instead of keeping the theoretically best signal (staying put @ 1500 Hz audio in this case), when the signal blurs in weak conditions, it starts going astray 'sideways' temporarily, and thus decodes worse than what is is ideally capable of