开云体育

OK, I got it. The tuning is really difficult. Leigh L. Klotz Jr wrote:

Dave, I could not copy Olivia 16/500 on 40m just now, but could with your most recent gmfsk. The SNR reported from GMFSK was 32. Leigh/WA5ZNU

There's something a little different about the fldigi waterfall, not just in the recent 0.941b. It seems less distinct when compared to the gmfsk waterfall and the Windows programs. Is there a

Dave, Have you seen the Visual CQ for PSK that I did? I think Patrick did a mode indicator for Olivia and I believe MixW has something similar, showing you the mode as an "image" in the power

Joe, KD8ATU, and I were able to confirm the correct operation of MFSK-8 this evening on 40 meters. He was running MultiPsk at his club station when I heard him call CQ on PSK-31. He must have thought

The MFSK fixes discovered during the fldigi developement have been retrofitted to gMFSK. MFSK-8 now works correctly with IZ8BLY's */Stream/*. The AFC implementation now works ... it really never did

Leigh L Klotz, Jr. wrote:

Maybe just show them when the mouse is over the waterfall? The enter and exit events should be cheap. People will learn...

Dave, Why don't you just make a modem library and share it between the two? I want to write another psk TCP/IP server anyway, as I did that in gmfsk because it had the cleanest modem code, as you

Still had some repairs to make in the RTTY & DominoEX modems re the CR/LF problem. It would be so simple if everything was Unix or Windows or Apple compliant. But MSDOS/WINDOWS apps send CR/LF pairs,

Yes I did skip a few minor revs. But I think that a sigificant change requires a significant notification. You may have been aware that the MFSK-8 modem code in all revisions of gmfsk, both the

w1hkj wrote: Overall CPU usage is way down on the old 600 MHz Mandrake 10.1 machine I test with here at work. Color waterfall and normal speed is about 45% total, and B&W waterfall and slow speed is

w1hkj wrote: I hadn't thought about automating the acquisition to handle the tuning errors. I think you are right. This might be a superior solution. I've tried DominoEX, and agree about it's

I considered and tried implementing something similar to what you have suggested Rick. It seems like such a trivial thing to implement, but drove the waterfall processing over the top. Perhaps it has

Leigh, WA5ZNU, reported having problems with cpu% usage, so I took another hard look at the waterfall code. Incremental changes, but I have managed to cut the cpu usage down. You will not see much

I was tuning some weak MFSK16 signals last night on 40 and have a request about tuning markers. I really like the way there are no vertical markers in the waterfall on fldigi now as compared to gMFSK,

Leigh L. Klotz, Jr. wrote: For what it's worth, I am not seeing the 100% CPU usage here on either the old and slow 600 MHz Mandrake 10.1 machine )50-65% depending on waterfall speed and color or B/W)

I'm seeing 100% on the previous release too...I haven't isolated it yet. Leigh L. Klotz, Jr. wrote:

I get 100% CPU utilization on this version. When I naively run it under GDB, type ^C, and where, it's always in innards(). I don't remember how to select the other threads. The previous version showed

w1hkj wrote: I cannot compile the FLTK, line 1022 is looking for stdlib.h and it is in /usr/include. Root has read/write, groups and user have read permissions. I have no idea how to set the path if