开云体育

Hi, Solar from today 22-01-2025 @ 11:00 UTC No NOAA recordings. Attached the Nancay recordings. Huub Breda The Netherlands Locator: JO21jn

OK, using Winetricks, I installed VB6, and a few missing other files. I was still getting errors about missing or misinstalled OCX files. I had to retrieve them at OCXme.com. Finally, VARA FM materialized briefly … but shut down quickly. A buzzkill. The error is something about advapi32.dll. I tried a different version, but getting the same thing. “Call from 7BDAACE8 to unimplemented function ADVAPI32.DLL. PerfEnumerateCounterSet, aborting wine …” Then it calls for debugger which didn’t run. I’m close, just not there. Any help appreciated. Going to copy this to linuxham group as well. 73, Jamie WB4YDL PS - while running Winetricks for missing files, this error box came up This may be the source of why the VARA install Pi App script would just stall. I never got this box when I ran it - only with Winetricks. Tried wineserver -k and -k9, but it never stopped these boxes. But when I clicked OK, it woul take off and continue to complete the requested fill. Again, RPi4 with 32bit Bullseye.

at http://www.w1hkj.com/alpha/linsim/ linsim-2.0.5.03.dmg linsim-2.0.5.03.tar.gz linsim-2.0.5.03_setup.exe readme.dmg.txt readme.txt EVENTS * add event log dialog * fix exit thread handler bug * add events OFFSET correction * change sign of correction * correct resampling of source wav 73, David W1HKJ

Hi. I'm sure I had all this working in the past, but not now....... Not helped by issues with my main PC preventing reliable access to it. That is fully disconnected, cold and dead for now. Fldigi 4.2.06 with Flrig 2.0.05 on LMDE 6 running on an 8 core intel based machine, a Dell XPS laptop with 8G RAM, using external USB connected sound device, and serial port DTR to key the radio, a TS870s. Using Fldigi/Flrig for "normal" working is fine, but attempting to create a macro to send a CWID and "ONLY" a CWID, and I'm failing... I'm sure this has cropped up before in the list, but attempting to create a macro to send a CWID and "ONLY" a CWID, regardless of the prevailing mode that was being used I can't make work, after some 40 minutes faffing about, so hear I am. This is the contents behind a freshly assigned "CW ID" Macro button... <TXRSID:off> <PUSH> <MODEM:CW> <TX> <CWID> <RX> <POP> <TXRSID:on> It fails miserably... Firstly it doe not always put the rig into TX! Sometimes it will for a few attempts, then it'll not bother, but sends audio each and every time. (Debugging this with the rig on low power into a load, while using the default audio device for the TX audio, so hopefully no QRM being sent.) It always sends a RSID (TXID button here is enabled by default, and is not seen to be disabled while the macro runs.) Then a burst of Olivia 8/250 (the mode that is present before invoking the macro) then does the CWID, and goes back to recieve. The indicated mode does not change in the lower left display of Fldigi either. Each individual macro function works exactly as advertised, but not it seems when combined into one file. In this case. What have I missed this time? I.e. How to force a macro to execute sequentially, as it is shown in the editor. I just want it to key the radio, send an unadulterated CWID without any TXID or burst of whatever other digimode was being used, then go back to RX restoring the mode that was in use before the macro was invoked. As earlier. "Normal" Fldigi usage is fine. As are the usual macros for calling answering sending info, logging and closing QSO's etc. Confused again and getting fed up with it. 73. Dave G0WBX. -- Created on and sent from a Unix like PC running and using open source software:

I'm running fldigi 4.2.05.24 on a RaspberryPi4 on Raspbian 10 buster. The station runs 24/7 and several times a week when I remote in to the Pi I find fldigi is no longer running. This evening I was actually looking at the display when it happened. I had entered a command, and it timed out dues to open squelch, reported that in the receive pan then immediately aborted. Anything I can look for to help troubleshot this issue?

Wonder if you would review this again Dave. Same behaviour in 4.2.06.19 (yeah I am slow...) What I didn't make clear in my OP was with "Retain tx freq lock" enabled, the operational expectation is that the RX freq would shift to meet the RSID centre, but leave the TX frequency where it is. If "Retain tx freq lock" is disabled I expect the TX and RX to shift together. (which is what it does) Note there us differing action too if the modem changes vs not. Please try a few RSID's of the same modem, then try changing the modem. Cheers Bob On 19/8/24 20:22, w1hkj wrote:

I been using fldigi for years on my Raspberry Pi station computer. It worked fine until a few months ago. Since I was having a great time on SSB DX I let it go, but I would like to be able to use it again. Symptoms: The rig interface doesn't work, it will not cause the frequency to change, and it does not follow the frequency on the transceiver. fldigi does not interface with flrig. I tried that as an alternative and nothing. flrig controls the rig fine but fldigi does not "see" flrig. There is no waterfall. It appears the audio is not getting to fldigi. As a comparison, I ran JS8Call and QSSTV (I've forgotten it's real name) and they both decode correctly. JS8Call controls the rig. fldigi is 4.1.20 flrig is 1.4.4 PiOS is Buster Pi is a 400 I have attached screenshots of the rig and audio configurations. I have run out of ideas on how to diagnose this. Suggestions please. 73, Bruce, W4BRU

I guess I cannot use fldigi on sequoia. Mac wont open it. Is there a concise step-by-step manual to load linux on my mac and then load fldigi ? I am basically computer illiterate. I miss fldigi. Thanks! John AB8O