Re: [digitalradio] Re: Contestia
> On Sun, 18 Apr 2010 09:06:46 +0200 (CEST), Rein Couperus > said: >> On Sat, 17 Apr 2010 21:43:54 +0100, Stelios Bounanos said: >>> On Sat, 17 Apr 2010 10:37:31 -0700, Brian Lloyd said: >>> (I forgot to reply to all.) >> (I removed one level of > characters below) >>> It is really Really *REALLY* important to understand what is going on with >>> these protocols in the presence of propagation anomalies in order to be able >>> to make decisions about which modes work best under what conditions. My own >>> recent experiments in monitoring and graphing the phase/frequency changes of >>> the WWV carrier over time (20-30 minute samples typically) have convinced me >>> that sequential testing of protocols, i.e. transmitting a message and then >>> immediately transmitting the same message using the other protocol, is not >>> likely to produce valid results unless repeated numerous times and then the >>> results averaged with outliers discarded. >> True, and I seriously doubt that anyone has bothered to do that. > The pskmail client - server communication does this all the time. It looks at > the > result of the last frames (both S/N and arq result) and decides on the mode > to use for the next frame (separately for client and server mode). > That way we always use the most effective mode for the circumstances. > We don't need modes wider than 500 Hz to be fast, and change between raw PSK, > robust PSK, MFSK and THOR modes. > This way we are gathering lots of information on this subject automatically :) > The contestia and olivia modes do not transmit the right character set so we > cannot use them. I fixed up the quoted text above so it's clearer to see who was writing what. This thread was posted to the fldigi-alpha mailing list and can be read here (start with first "Contestia" email): http://www.mail-archive.com/fldigi-al...@lists.berlios.de/index.html http://lists.berlios.de/pipermail/fldigi-alpha/2010-April/thread.html#1099 Brian was saying that non-repeated, non-averaged tests are likely to be flawed. I said I doubted that anyone tested the right way (I still do :), since on-air test reports do not mention this stuff at all. At best, the testing is said to have been done over a period of time deemed long enough, but no graphs, no averaging, no apparent effort to discard invalid data. I know you've said that pskmail collects data to decide which modes to use. But other than switching modes, and perhaps logging that data locally, it's not telling anyone anything :-) If it could collect the S/N, loss % etc. for a period of time and set of modes, and make it available, that could be very interesting! Pskmail servers might export such statistics (even to non-participants) over HTTP. > 73, > Rein PA0R -- 73, Stelios, M0GLD.
Re: [digitalradio] Re: KB1OOQ-5 back ON-LINE (Comcast comes through)
> On Fri, 26 Mar 2010 08:41:19 -0500, mikea said: >> On Fri, Mar 26, 2010 at 03:06:38AM -, aa777888athotmaildotcom wrote: >> Very unusual to have an outage, actually, especially with no weather >> in the area. In 10 years I can count them on the fingers of one hand. > So, fewer than 32, then. > "Never trust a man who can count to 1023 on his fingers." Mike, my right pinky is the LSB and I'm having trouble with numbers like 811. Bit swapping doesn't help! Do you play the guitar? :) -- 73, Stelios, M0GLD.
Re: [digitalradio] Re: Olivia web site
> On Fri, 05 Mar 2010 14:09:50 -, "g4ilo" said: > I downloaded Pawel's source code for his text mode demo application and > despite not knowing C++ managed eventually to compile and run it under > Linux. However I understand that on Windows it must run under CygWin or MinGW > which are a kind of Linux emulation. So quite a lot of work would need to be > done to make it operate in a way that it could be called from other "normal" > Windows programs. Cygwin and MinGW are not Linux emulation layers. Cygwin implements a *POSIX* compatibility layer on top of the win32 API, which requires dynamic linking to the cygwin1.dll library, but there is a compiler switch to disable this (-mno-cygwin). MinGW is a port of GCC to win32 with some headers and import libraries for the win32 API, plus better C99 support. Otherwise, it uses the MS runtime and is basically as "native" as it gets. -- 73, Stelios, M0GLD.
Re: [digitalradio] ROS carrier pattern when idle
> On Fri, 26 Feb 2010 06:29:23 -0500, KH6TY said: [snip] > It looks to me that the tone frequencies are clearly being generated > independently from the data and then the data applied to the randomly > generated frequency. There is NO pattern to ROS like there is to FSK > modes, even to 32 tone FSK (Olivia 32-1000) or to 64 tone FSK > (MT63-2000). This is a signature of FHSS. > “/If/ it walks /like a duck/, quacks /like a duck/, /looks like a duck/, > it must be a /duck/”. It sounds like US hams would run afowl of the law if they used ROS on HF, Skip. And then the FCC might waddle in and slap them all with a hefty bill. > It looks like ROS really is FHSS when you look at it on a spectrum > analyzer, and the spectrum analyzer does not lie. I guess ROS has taken a tern for the worse. And it doesn't help that it's author is now ducking the issue... :-P -- 73, Stelios, M0GLD.
Re: [digitalradio] ROS impressions so far
> On Sun, 21 Feb 2010 03:05:36 -, "obrienaj" said: > In the few ROS 16 and ROS 1 tests that I have dome so far... > ROS 16 seems similar to Olivia 8/1000 , good performance but perhaps a > not quite as good as Olivia under QRM or deep fades. > ROS 1 , not as good as JT65A in very poor conditions. > Anyone else have impressions, perhaps I am wrong... these are on-air > impressions not lab tests. I wonder if there are any test results (or even on-air impressions substantially different from Andy's) to explain what looks like the proverbial elephant in the living room from where I'm standing... i.e., the fact that ROS is > 2000 Hz while Olivia nn/1000 and JT65A are 1000 and < 200 Hz respectively. Or is it now somehow cool to do the same thing as before but with a 2x-12x larger footprint on the bands? -- 73, Stelios, M0GLD.
Re: [digitalradio] RTTY decoding
> On Tue, 16 Feb 2010 04:53:04 -0800 (PST), Rick Westerfield > said: > Download MixW 2.19. It is easy to install, free and you do not need much of a > processor. It uses your soundcard as the modem and an HF radio to gather the > signals. Your computer processor is the microcontroller, so to speak. Yeah, because MixW will really help him understand RTTY decoding after he spends a couple of terms disassembling the binaries and reverse engineering the decoder. > There are numerous sources for the engineering behind RTTY digital signal > processing. Interesting stuff and it is a good place to start for young > electrical engineers. IEEE usually covers this topic very well and their > subscription rates for students are very low. IEEE publications cover many topics really well, but someone who wants to get a grasp on DSP will have better luck reading books (some of them freely avaialble online) or university course material. There are also at least two existing, actively developed, FOSS implementations of RTTY (pocketdigi and fldigi) that anyone can study, modify, improve and share. I don't speak for the authors of the RTTY modems in these programs but I imagine that they would be happy to help someone who has already spent some time trying to understand their design. -- 73, Stelios, M0GLD.
Re: [digitalradio] Re: source of 8 pin female radio connectors?
> On Tue, 26 Jan 2010 21:43:44 -, "sszretter" > said: > I thought of digikey or mouser, but what is the generic electronic part name > for it? DIN connector? http://en.wikipedia.org/wiki/DIN_connector -- 73, Stelios, M0GLD.
Re: [digitalradio] Comparison of RTTY software sensitivity
> On Wed, 20 Jan 2010 18:01:32 -0500, Wes Cosand > said: > Recently during a QSO a ham said the software I was using was not very > sensitive. I decided I needed to collect some data to make an informed > decision about which software I should be using. I ran several of the RTTY > software packages through the AWGN function of PathSim and used RttyCompare > to calculate the percentage of errors in the resulting text. The data can > be found at > http://mysite.verizon.net/wz7i/RTTY.html Thanks for sharing your interesting experiment. It is somewhat puzzling that you convert the 8KHz audio to 11025Hz and pipe it to the programs via Virtual cable, which may involve another two conversions (e.g. to 44.1KHz and from that to whatever rate the program samples at, depending on what VAC is emulating). In the case of fldigi, the 8KHz audio file generated by pathsim can be opened directly. In fact it would be great if we could have copies of your "RTTY+noise @ 8KHz" audio files as created by pathsim, or even just the original file without the added noise. -- 73, Stelios, M0GLD.
Re: [digitalradio] Fldigi and rig control on OS X
> On Mon, 18 Jan 2010 09:44:50 -0900, Mike M said: > Hello - > I just bought a USB cat control cable for my Yaesu FT-817, and want to > use it with Fldigi to control my rig. I installed hamlib, but I don't > understand how to set it up in Fldigi (there are no radios listed in > the pull down list). Any help would be greatly appreciated! You can always try the RigCAT rig control method as Skip suggested. But hamlib is also known to work and the library is built into the executable that you can find on w1hkj.com or berlios.de; you do not need to build hamlib yourself. We've been compiling our own copy of hamlib such that it is not affected by whatever hamlib versions the user may have installed locally, but may not have applied this on the OS X build machine yet. Does the pull-down list become populated when you remove your version of hamlib? If so, I'll need to look at our OS X build again. -- 73, Stelios, M0GLD.
Re: [digitalradio] Need your help picking HF radio.
> On Fri, 25 Dec 2009 11:07:39 -0700, Alan Wilson said: > I'd have to go with the Yaesu ft-857D, it does it all with a small > footprint, reasonable price and very dependable... I have one of those and I like it for many reasons, but it's not a very good rig for digital modes. Some issues that come to mind: * DSP is at the audio stage, useless for digital. * Narrow IF filters (300 and 500 Hz) are extra. It can be frustrating to operate on HF without one of these. * TCXO is extra (but standard with the FT-897D, IIRC). * Minimum tuning step is 10Hz. * Much CAT functionality is undocumented by Yaesu, though HB9DRV and co. must have discovered all of it by now. * Reference oscillator is mounted behind the rear vent/heatsink and is therefore in the draft of air from the cooling fans. Fans always activate on transmit so you will drift, even for short transmissions and with the TCXO installed, which is most annoying on VHF/UHF. Can't blame Yaesu much about this though, it's a small rig. IMHO not worth considering for digital modes unless you _must_ have HF, 2m and 70cm in a compact radio. But then something like the IC-7000 is much better for that. And if you only want HF you have many more options. -- 73, Stelios, M0GLD.
Re: [digitalradio] Is there a convention for stereo phone plugs?
> On Fri, 27 Nov 2009 22:14:26 -, "jhaynesatalumni" > said: > I've never known if there is a standard for whether tip or > ring is left or right channel. Tip is usually left channel. > And is left or right normally used for the computer DSP radio software? Mono output always goes to the left channel from what I've seen so far. -- 73, Stelios, M0GLD.
Re: [digitalradio] DominoEX 11 is more democratic
> On Thu, 26 Nov 2009 08:19:24 -0300, Claudio said: > Only a question, what program can i used for this mode?. I work with mixw > 2.16. Fldigi is one of the programs that you can use for DominoEX. It supports DominoEX 4/5/8/11/16/22, with and without FEC: http://www.w1hkj.com/Fldigi.html More information about DominoEX: http://www.w1hkj.com/FldigiHelp/Modes/index.htm http://www.qsl.net/zl1bpu/DOMINO/Index.htm -- 73, Stelios, M0GLD.
Re: [digitalradio] Digital busy detect
> On Tue, 24 Nov 2009 22:30:21 -0500, Alan Barrow said: [snip] > OK, here's the challenge: Demonstrate it's feasibility if it's JSMOP. > Implement one that balances the right of the sending station not to be > QRM'd VS the expectation not to QRM. Publish an API & a spec (turnaround > times, etc). IE: Not a passive (hold off) detector > Make it open source so that all coders can leverage & refine it. Windows > assumption is OK, but we could probably find a lock/semaphore system > that is multiplatform. But a windows DLL & API would satisfy 90% of the > commonly used digi programs. Why make a Windows or POSIX assumption? Your busy detection API could be a chunk of DSP code that works in two modes: 1) Callback: register a callback function with the detector. Feed the detector smaller fragments of audio as you process them for decoding. The callback will be invoked whenever there is a change in the busy state. 2) Blocking: feed the detector a big chunk of audio data. It will tell you if there is a signal present in the frequency range of interest. Option (1) is probably best; the digi program will take care of threading or other concurrency issues. It is possible to implement (2) on top of (1). The detector could also supply a confidence level and other details. > Will have to codify a standard that would allow any program to grab > soundcard resources (to monitor as well as send the qrl) along with any > cat/ptt required. Or maybe you let the digi program figure out how to > send CW QRL, that would be close enough. The API should just signal the digi program. Let the latter do the PTT, audio device interfacing and sending of CW QRL or whatever -- it already knows how to do all these things. This reduces complexity. Also, the detector must be capable of being used in "advisory mode" since it cannot hope to be correct all the time. Please note that I am not talking about a generic "QRM avoidance" spec. The busy detector is enough of a SMOM-type problem as it is :) -- 73, Stelios, M0GLD.
Re: [digitalradio] Contesters and DXers should use busy detectors
> On Wed, 25 Nov 2009 09:29:13 -, "expeditionradio" > said: > All contesters and DX pileup participants > should use busy detectors! This is quite > evident since it has been proven that such > types of operation are the source of 99% of > "harmful interference" and "intentional interference" > on the HF ham bands. Manual methods of busy > detection have been proven to be devoid of merit. > Contesters and DX pileup technologists can start > developing the "DX/Contest Busy Detector" with > SSB and PSK and RTTY and CW, the most common modes. I see your point, but 2001 has come and gone and we still have no HAL9000's to say "can't let you do that OM" when the SSB operator keys his microphone. However, a busy detector could have a fighting chance in unattended digital operation. [snip] -- 73, Stelios, M0GLD.
Re: [digitalradio] using fldigi
> On Fri, 20 Nov 2009 22:13:46 -0500, "DANNY DOUGLAS" > said: > Been pulling what is left of my hair out here, trying to get fldigi to > operate CAT with the TS570sg, but so far it just sits there. Is there not a > Yahoo group for fildigi? Cannot find any such thing in Yahoo. Is there > another generaql group for them, anywhere? All I find is groups using it, > with specific modes, specific this, specific that. But I need someone who > has got it working that can setp me thru what settings I have wrong here. * linuxham group General discussion on fldigi, related software and other ham radio topics http://groups.yahoo.com/group/linuxham/join * win-fldigi group For Windows users of fldigi http://groups.yahoo.com/group/win-fldigi/ * NBEMSham group Special focus on NBEMS operation http://groups.yahoo.com/group/NBEMSham/ * fldigi-alpha list Discussion of fldigi testing and related subjects http://lists.berlios.de/mailman/listinfo/fldigi-alpha * fldigi-devel list Fldigi development topics http://lists.berlios.de/mailman/listinfo/fldigi-devel * fldigi-announce list Fldigi announcements http://lists.berlios.de/mailman/listinfo/fldigi-announce -- 73, Stelios, M0GLD.
Re: [digitalradio] ZS pigeon 'faster than broadband'
> On Thu, 10 Sep 2009 17:44:30 +0200, "Barry Murrell ZS2EZ" > said: > The real drawback with pigeons is that they stand a good chance of becoming > someone's dinner before reaching their destination!! This is why you need retransmissions [1], Barry :-) And if the pigeon physical layer is not robust enough, there are some very large herbivores native to the African continent that could be used to run what would probably be the very first real LFN [2]. (I'll go away now!) [1] http://tools.ietf.org/html/rfc1149 http://tools.ietf.org/html/rfc2549 [2] http://en.wikipedia.org/wiki/Long_fat_network -- 73, Stelios, M0GLD.
[digitalradio] Fldigi users' survey
The Fldigi Users' Survey 2009 is open: http://www.survs.com/survey?id=0G4NPBMP&channel=FF95UTI7N4 If you are a current or past user, please take our survey and help us improve fldigi. If you have never used fldigi[1] before, we invite you to try it now! The survey is anonymous and will only take a few minutes of your time. Raw results and some analysis will be made available shortly after the closing date (currently set for 30-Nov-2009). Thanks & 73, Your fldigi development team. [1] Fldigi is a digital modem program designed primarily for amateur radio operators. It is Free software, licensed under the GPL. URL: http://www.w1hkj.com/Fldigi.html
Re: [digitalradio] Re: Soliciting suggestions
> On Tue, 11 Aug 2009 18:02:29 -, "Howard Z." said: [...] > OK, then there is Olivia. Nobody in our group wants to use > Fldigi/Flarq because we are forced to use a custom mode. Olivia is not a custom mode. It is well supported and most (all?) useful bandwidth/tones pairs can be set via RSID. It is also not the only effective mode for NBEMS. > We can't just customize it and leave it alone. Every time we select > it - up pops a window to confuse people into diddling with it. We > don't need our custom mode embedded in fldigi software, just let us > set it up and then have the software leave us alone when we select it. You can choose any available combination of tones and bandwidth and save it, and fldigi will remember it the next time you run it. There are a few commonly used presets (e.g. 8/250, 16/500 etc.) in a menu for quick access. We could possibly add your preferred settings if you ask. We also plan to make Olivia presets available as macro buttons. > But, there is a worse problem. The fldigi 3.12 is a nightmere that > often will not even start - it pops up error messages and fails right > and left - an unreliable useless software product. 3.12 made some very extensive changes to the Windows side of things; little, if any, OS support code was left untouched. 3.12 was tested by many users before release and I can assure you that it does not fail right away for them or the developers. It's likely that more time will be needed until it is up to par with 3.11 (which had more than one year of testing) in stability, but obviously we had to release it! > However the fldigi 3.11 has possibilities - but try to get a group to > all be using the same version of anything? Especially tell them to > not use the latest version? And not the past 3 latest versions? Ok - > fldigi is a joke and waste of time - it's taken a global leaps > backwards. "This application has requested the Runtime to terminate > it in an unusual way. Please contact the application's support team > for more information" - uh - no thank you. Great, now please explain how we can possibly fix bugs that we know nothing about. You seem to think that we released a broken version on purpose just so that we could show you the Windows crash handler -- but that would be absurd. > "fldigi.exe has stopped working. Windows is checking for a solution > to the problem" "A problem has caused the program to stop working > correctly.. Windows will close the program and notify you if a > solution is available". Nothing we can do about the "reassuring" Windows messages, sorry. We do not receive those crash reports. Please report bugs to us and we'll do our best to squash them. Basic bug report guidelines here: http://groups.yahoo.com/group/linuxham/message/7201 If you do not wish to email us directly or subscribe to any mailing lists in order to report bugs, there is a bug tracker here (BerliOS account required to file new reports, will try to get this changed): http://developer.berlios.de/mantis/set_project.php?project_id=9149 And if you subscribe to this list you'll receive regular notifications of new test releases (including win32 binaries): http://lists.berlios.de/mailman/listinfo/fldigi-alpha (This list is also used for discussion. I will create an announcements-only list shortly.) Whatever problems are preventing you from using fldigi will be fixed much sooner if you help. [...] -- 73, Stelios, M0GLD.
Re: [digitalradio] Compressing Data
> On Sat, 01 Aug 2009 14:52:10 +0200, Rein Couperus > said: > PSKmail uses normal zip compression and B64 encoding. > On small files with english text the compression reached by using varicode > alone is better. > That is why I abandoned compression for email text. Also, when you want > to use simple compression schemes your result has to be 1-bit clean, > which requires ARQ in all cases. I expect lzma to do better than zip. As you say, for some modes it will be more efficient to send plain text rather than compress and base64 encode it. Flwrap will have no way of knowing how the data will be transmitted, but it will have options to disable the compression or use it only for binaries. -- 73, Stelios, M0GLD.
Re: [digitalradio] Zapped PCs, data recovery, and Windows !
> On Thu, 23 Jul 2009 18:38:00 -0400, "Andrew O'Brien" > said: > My local computer store tells me that one cannot simply take a hard > drive from a old Pc and place it in a new PC even if you have a > Windows license disc for the new PC. Is this correct? I expect you'll have all kinds of driver issues. Also, Windows treats its users as maybe-criminals and requires permission from the mothership every time the hardware changes significantly. On a Linux system you have neither of these problems. I would expect the transplanted hard drive to work on a new machine (after all, the LiveCD runs everywhere) and of course there's none of that activation nonsense. As for running Windows software, I hear that VirtualBox works very well these days :-) -- 73, Stelios, M0GLD.
Re: [digitalradio] Compressing Data
> On Thu, 23 Jul 2009 09:45:54 +0200, "Simon (HB9DRV)" > said: > Thinking to myself - when we use a mode such as Olivia / MT63 with extensive > error correction, why don't we compress the text? > Given that fldigi has the wrap feature then surely compression could be / > should be considered for some modes? I've been planning to do some testing with fldigi's file "wrapping" using lzma compression. Because the modems used for this are not 8bit-clean, flwrap uses base64 encoding for binary files, which adds a sizeable overhead to any compressed transfer. Nevertheless, I expect that in most cases compression will result in a speed-up. And because the file sizes involved are usually tiny, even lzma compression only takes a few milliseconds, so you can always compress and simply throw away the result if it turns out to be larger than the original. -- 73, Stelios, M0GLD.
Re: [digitalradio] Re: Digital modes and old husband's tales
> On Tue, 14 Jul 2009 12:28:34 -, "Ralph Lambert" > said: [...] > Hint: fldigi by itself good, fldigi and xlog or similar application together > not good. Please explain and we might be able to improve things. The communication between fldigi and xlog is one-way. Fldigi places the information in shared memory and xlog picks it up and adds it to the log. This also works if xlog was not running at the time. > - 73 > Ralph (AJ4GR) -- 73, Stelios, M0GLD.
Re: [digitalradio] possible purchase
>>>>> On Tue, 14 Jul 2009 13:59:55 +0200, "Simon (HB9DRV)" >>>>> said: > Hah, > Actually the 480 does have nice 500Hz filters so you can use this for > getting rid of signals. The beauty of the TS-480SAT is that it's a pure > analogue radio, the audio is good and pleasant to listen to. I do have a 500Hz mechanical IF filter in the FT-857 and use it for both RX and TX. It's a very big improvement over the 2.8 kHz filter but still lets a lot of splatter through when the band is busy, and IF shifting can only help so much. I know this method works very well but I consider it "legacy". My definition of best rig for digital modes requires adjustable IF filters that can be narrowed to 50 Hz or so via (documented!) CAT control, so that the software can do this stuff automatically when the user clicks on a signal on the waterfall. > Simon Brown, HB9DRV > www.ham-radio-deluxe.com > - Original Message - > From: "Stelios Bounanos" >> >> IF DSP includes the tunable bandpass filters. I like the idea of >> rejecting QRM with an adjustable digital filter before it hits the audio >> stage. This is the only kind of DSP that I would find remotely useful >> for digital modes. >> -- 73, Stelios, M0GLD.
Re: [digitalradio] possible purchase
>>>>> On Mon, 13 Jul 2009 15:57:54 +0200, "Simon (HB9DRV)" >>>>> said: > 1Hz tuning, Huh, so it is. I was looking at the specs as advertised on Universal Radio. I assume that 1 Hz tuning is available via CAT without having to use front panel controls. > IF DSP not desirable for digital modes, IF DSP includes the tunable bandpass filters. I like the idea of rejecting QRM with an adjustable digital filter before it hits the audio stage. This is the only kind of DSP that I would find remotely useful for digital modes. For other modes I can do all kinds of audio processing with jack-rack or gAlan and LADSPA effects plugins [1]. Something to keep that quad-core processor warm. [1] http://plugin.org.uk/ > Rock-solid stable, > Remote-mount the radio head next to your monitor, > Excellent value for money (especially the 100watt version) - it's a Kenwood! No argument about it being excellent value. > Simon Brown, HB9DRV > www.ham-radio-deluxe.com > - Original Message - > From: "Stelios Bounanos" >> >> Errr, 10Hz tuning, no IF DSP, no external reference input. Perhaps the >> best for some unspecified definitions of "market" and "digi use"? :-) >> -- 73, Stelios, M0GLD.
Re: [digitalradio] possible purchase
> On Mon, 13 Jul 2009 08:20:21 -0500, John Bradley > said: [...] > The 480 is perhaps the best rig on the market right now for digi use, > in my not-so-humble opinion Errr, 10Hz tuning, no IF DSP, no external reference input. Perhaps the best for some unspecified definitions of "market" and "digi use"? :-) > cheers > John > VE5MU -- 73, Stelios, M0GLD.
Re: [digitalradio] Re: Get more out of digital with RISD
Hello Dan, > On Sun, 12 Jul 2009 20:24:17 -, "d_ziolkowski" > said: > I use FLDIGI 3.1 for Linux, I set it up for RSID. I get nothing, all > decoding stops. Is this normal? or did I miss something. At present, RSID is mutually exclusive with normal decoding. This makes the audio "plumbing" simpler from our point of view, though I believe also that there hasn't been much demand for concurrent RSID from users. After all, when you turn RSID on you say that it's OK for fldigi to change the mode and frequency at any time, which makes it unlikely that you'll be having a QSO during that period. Of course if you could decode at the same time you might decide to turn RSID off and do something else (e.g., work that DX station), and it's a little annoying to see signals on the waterfall and not be able to receive them. This will be addressed in some way. The next version of fldigi (3.12) will have a generic pattern matching and notification engine that can also be extended for RSID. At that point it will definitely make more sense to implement background RSID decoding because it will be possible to specify actions other than "switch to that mode and/or frequency immediately" for RSID events. So, in summary, this will be fixed in the near future, possibly for 3.12. > I also noticed the waterfall speeds up significantly This is "normal". > Thanks Dan kc2sta -- 73, Stelios, M0GLD.
Re: [digitalradio] Possible Purchase
> On Sun, 12 Jul 2009 09:25:10 -0500, Rick W said: > As was mentioned, construction may be impractical for many hams. In my > case, I have been soldering since around age 13 or so with my first > crystal radio kit and later many kits and dozens of projects over the > years, so it is not too difficult to make a simple interface. > Today, because of my age, it is increasingly difficult to do close work > without special help. I normally wear trifocals and the close-in > distance is for book reading at around a foot, but it is very much at > the bottom of the glasses and difficult to use so I sometimes use > magnifying googles. There must be a lot of cheap second hand camcorders out there, many with both analogue and digital video outputs and plenty of optical zoom. I imagine you could easily display a good 10-20x image of the work on your monitor (perhaps with the aid of an external lens). That's a lot of magnification and as a bonus you can sit straight and not spend hours hunched over your desk looking at the work with magnifying goggles on. You also inhale less flux fumes and avoid solder splashes. -- 73, Stelios, M0GLD.
Re: [digitalradio] The usual OS Flame war thread....
> On Thu, 02 Apr 2009 10:41:46 -0500, Rick W said: [...] > Needless to say I won't even respond the the impertinent comments by Hal > since they are basically an attack on the intelligence and abilities of > most computer users rather than on any merits. Those of us who have > tried different OS's, some for decades, find good and bad in each OS, > but the bottom line is which one has the most practical value right > now. While most here in the U.S. overwhelmingly choose Microsoft, there > are a modest, but increasing number, who like Mac. Linux is still very > small. Much, much smaller than I expected by now. I have spent a LOT of > time with Linux and have been surprisingly disappointed. And I did not > expect to be. Rick, I must say that I can't remember the last time I heard of someone who has tried so hard and for so long and has been as disappointed as you. Is your hardware not supported? Are there problems with the software? Have you asked on the forums or mailing lists? Filed bug reports or feature requests? Q: When will Linux be ready for me? A: Sooner if you help. BTW, users "overwhelmingly choose" the preinstalled OS. Back on topic... there seem to be around a dozen pskmail servers on HF in Europe; apparently sufficient for pskmail's (increasing) userbase. How many would you need in North America? I think that whatever the answer may be, there must be enough hams there who either use Linux already, or aren't afraid they might get the Linux cooties :-) As a case in point, I count just less than 1000 unique callsigns in the list of IRLP nodes in the U.S. This tells me that Linux isn't going to be an obstacle to pskmail adoption in the U.S. or anywhere else. Particularly if someone comes up with some kind of pskmail appliance, e.g. a low-cost ARM-based device such as the ones I mentioned earlier. 73, Stelios, M0GLD.
Re: [digitalradio] PSKMail Windows server?
> On Tue, 31 Mar 2009 15:50:11 +0200, Rein Couperus > said: > Yes, the server is linux only at the moment. Ultimate goal is to use a > LAMP server without a GUI in future, but fldigi needs the GUI :) Fldigi needs an X11 display (on Linux/FreeBSD), which makes it non-straightforward to use in "server mode". But it's possible with a "fake" X server such as Xvfb. Excerpt from Xvfb(1): Xvfb is an X server that can run on machines with no display hardware and no physical input devices. It emulates a dumb framebuffer using virtual memory. Here's how you'd use it with fldigi: ssh remote-host Xvfb -ac :99 & fldigi -display :99 & Debian (and I expect Ubuntu as well) has a convenient shell script wrapper for this, xvfb-run: xvfb-run fldigi -display :99 This ssh command runs fldigi on a remote host and also forwards fldigi's xml-rpc port so that you can then control it with fldigi-shell (or other client): ssh -L 7362:localhost:7362 remote-host xvfb-run fldigi -display :99 You could in addition forward port 7322 to tunnel the ARQ connection so that the pskmail server can be run locally. I'm guessing that you manage the remote pskmail server and fldigi using VNC. If that's only because you need to interact with fldigi, you may find that the xml-rpc interface has all you need, and that you can use the above method to simplify the setup somewhat. A "headless" fldigi can be very useful; for example you could run a fldigi/pskmail server on a Marvell SheevaPlug or a Beagle Board. Take a look at the xml-rpc methods (fldigi --xmlrpc-list) and let us know if there's anything that could be added for pskmail. The main thing that's missing right now is functions to change RTTY and Olivia parameters (I plan to add them RSN), but I don't think pskmail uses these modems. 73, Stelios, M0GLD.
Re: [digitalradio] PSK Reporter with FLdigi ?
> On Sun, 01 Mar 2009 23:15:38 -, "Andrew O'Brien" > said: > I have PSK Reporter working with DM780, but no reception reports are > sent to PSK Reporter when I use FLdigi. Is there a special trick to > setting it up ? I have my call sign, name and grid square in the > FLdigi configure area. I have the autospot box checked in the set up > area in FL Digi. I did press initialize but nothing visible happened, > is something supposed to appear indicating it is/is not initialized ? Short answer: you want to click the Spot button in the main window. Long answer: pressing initialize with the autospot box checked should reveal a Spot button at the top right cornet of the main window. If it is unlit, the autospotter receives no data and never calls the PSK Reporter module. This may seem superfluous, but the underlying spotting "framework" is supposed to be able to accommodate other things besides PSK reporter (none of which has yet materialised). The Spot button would then toggle all of that potentially expensive pattern matching. 73, Stelios, M0GLD.
Re: [digitalradio] Comparing data modes
> On Tue, 30 Sep 2008 00:04:19 -0400, Tony <[EMAIL PROTECTED]> said: >> What were the sampling rates used by each of those 5 applications, Tony? >> 73, Dave, AA6YQ > The sample rates were 11025 Hz for Mixw and IZ8BLY MT63 terminal. Looks like > 8000 Hz for DM780 and Multipsk. Not sure what's going on with Fldigi. I'm > using the Vista version. The MT63 modem works at 8000 Hz as Simon noted. However, fldigi's default behaviour is to open the sound card at its default (native) sample rate, usually 48 or 44.1 KHz, and then resample to/from the modem rate using one of the converters from Erik de Castro Lopo's excellent libsamplerate. The converter is chosen based on a short speed test that is done the first time fldigi is run. On all reasonably recent processors, that converter will be one of the "good" SINC interpolators. It can always be changed later. We basically did this to avoid the not too uncommon situation where a sound card/driver combination claims to support the modem's sample rate only to return mangled audio. To really open the sound card at the modem frequency, which is currently 11025 Hz for Thor and DominoEX 5/11/22, and 8000 Hz for everything else, use the Capture and Playback menus in the Audio settings. The default value is Native (see above). Auto will try the modem rate first and, if that fails, fall back to Native. You may want to try Auto if you know that the OS can do better/faster resampling. The other options in those menus are the rates supposedly supported by the sound card. I say "supposedly" because the driver may be telling some slight fibs here, i.e., if it reports the hardware native rates together with those that it can resample to in software. It's almost certainly doing that if it lists every standard rate from 8KHz up to 192KHz. Experience suggests that we can trust the default (native) sample rate, at least on the cards and platforms tested so far. The other rates give audio of uncertain quality. Anyway, if you force a rate that is different to the current modem's, fldigi will need to resample. It will also resample, using the same configured conveter, if the TX or RX ppm corrections are nonzero. Of course it's smart enough to combine both kinds of resampling into one step. I don't know enough about Vista's audio system to be able to say what happens if you run multiple programs that want different rates. Possibly some of them will see slightly increased latency. Regarding CPU usage, you should make sure that you have enough CPU cycles for everything; maybe aim to keep the system load at < 50%. Fldigi can tell you if it's dropping audio because the CPU is too busy but only in debug builds; perhaps something to change in a future version. 73, Stelios, M0GLD.
Re: [digitalradio] Re: fldigi qrz.com look up
Hi Graham, > On Mon, 08 Sep 2008 18:31:48 -, "Graham" <[EMAIL PROTECTED]> said: > Thanks for the link, Stelios, I'n not quite sure of the final > situation, I know i can access via digipan or dm780, however are 'you' > using a differant service from qrz ?, as nither of the other packages > need a user name or pass word ? > is there a problem over access rights ? Before version 2.0, fldigi was able to look up callsigns by "screen scraping" the QRZ html pages (which is _possibly_ what digipan and dm780 do now -- I really don't know). Later, QRZ changed its web page format and its owner also made it clear that he neither approved of screen scrapers, nor would he make any particular effort to accommodate them. At the time, we were planning to use XML for an unrelated purpose and so, rather than try to play catch-up, we wrote a client for QRZ's XML access interface. The XML insterface is a bit faster and has so far worked without fault. It does require a user account and paid subscription as described here: http://online.qrz.com/ 73, Stelios, M0GLD.
Re: [digitalradio] fldigi qrz.com look up
> On Mon, 08 Sep 2008 17:29:56 -, "Graham" <[EMAIL PROTECTED]> said: > ? ok Ive entered my qrz.com login details in the right boxes ..select a > call .. click and get the reply 'details required' ... > what have I missed ? ..digipan system is working so web link is ok This was recently discussed on the linuxham list: http://groups.yahoo.com/group/linuxham/messages/4133?threaded=1&m=e&var=1&tidx=1 73, Stelios, M0GLD.
Re: [digitalradio] Move away from PSK63 /31 in NBEMS?
> On Mon, 18 Aug 2008 21:04:22 -0400, "Andrew O'Brien" <[EMAIL PROTECTED]> > said: > I note the new release of FL-Digi does not list PSK31 or 63 under > NBEMS modes. I realize that Dave , Skip, and others never really > intended NBEMS to have much use on HF , hence PSK250/125, but was > wondering why the option of slower PSK modes has been removed. There is nothing special about the "NBEMS modes" submenu. It lists modes that NBEMS users are likely to want to use, but nothing that is not also available elsewhere in the main "Op Mode" menu -- it's just a convenience. I suppose you could use any of the modes that can handle the ARQ protocol, including the slower PSK modes. 73, Stelios, M0GLD. --
Re: [digitalradio] Online HF Receivers?
> On Tue, 29 Jul 2008 22:00:53 -0400, Tony <[EMAIL PROTECTED]> said: > All, > Anyone know of any online receivers / remote base stations on the internet? > The W4MQ remote base seems to be having problems these days. Often use > remotes on HF/VHF for meteor scatter / digital mode tests. Here is another one: http://websdr.ewi.utwente.nl:8901/ 73, Stelios, M0GLD.
Re: [digitalradio] DV Equalizer
> On Fri, 13 Jun 2008 04:43:48 -0400, Tony <[EMAIL PROTECTED]> said: > All, > Does anyone know of a good audio EQ program similar to the Romac 10 band EQ? > Need one that can use different sound cards for mic / speaker input / > outputs. An open source program would be ideal. Take a look at the JACK audio server: http://jackaudio.org/ In particular the jackdmp version for Windows: http://www.grame.fr/~letz/jackdmp.html There are various JACK-aware applications that can do EQ, and even things like compression and filtering. A long list can be found here: http://jackaudio.org/applications JAMin is pretty powerful, as is gAlan with the LADSPA plugins. Just about all of the listed programs are Free Software and run on Linux, and some may have been ported to Windows. > The Romac 30 hour trial we're using to experiment with digital voice is > about to run out. Never used Romac, but I'd be very surprised if there isn't at least one Linux program with the same functionality. Asking a developer nicely may be all you need to do to get a Windows version. Or maybe get the DV ported to Linux instead? ;-) > Thanks > Tony - K2MO 73, Stelios, M0GLD.
[digitalradio] Mac OS X / MT-63 (was: Re: April QST page 35)
> On Tue, 25 Mar 2008 23:25:13 -0500, chas > <[EMAIL PROTECTED]> was rumoured to have said: > wow! so, what is the Mac OS-X version called ??? > STILL looking for MT-63 for the Mac. Thanks to a kind ham who gave us remote access to his OS X machine, we have been able to get fldigi 2.10 to build and run on the Mac. This version also supports MT-63. Unfortunately, we do not have OS X binaries. But if you are able to install packages for the FLTK, PortAudio and samplerate libraries, it should be easy to compile fldigi yourself. There are instructions in the INSTALL file inside the source tarball, which can be found here: http://www.w1hkj.com/Fldigi.html It should be far easier to add OS X support to flarq, if there is demand for this... > chas > K5DAM 73, Stelios, M0GLD
