Re: [digitalradio] Re: Linux versis Windows: Let the debate begin!!
On Thu, 2006-11-30 at 17:50 -0800, Leigh L Klotz, Jr. wrote: This is an interesting point of view, to take it from an economic and performance tradeoff. If I might ask (if this threa continues), would you all mind posting your rig and antenna systems as well? It would be interesting to see if there is a correlation between OS choice and rig choice. Homebrewers and Linux, or IC7800 and Windows, etc. 73, Leigh/WA5ZNU I use a Ten Tec ORION, an Elecraft K2 and an FT897D with UBUNTU Linux. (or with Mandriva Linux if using the pskmail live CD). Rein PA0R
Re: [digitalradio] Re: Linux versis Windows: Let the debate begin!!
OK Leigh, Hope this is what you're looking for. OS LINUX debIAN, etch (testing, release) runing on two laptops, and four desktop/server machines. since they all run the same OS, they all network easily and paly nicely with the router. RIGS HF = Kenwood TS 850 and FT 897 (coupled/controled with the Acer 3000 laptop. using HAMlib and a variety of other linux programs too numerous to mention here. SSTV to PSK and APRS. I'm patiently waiting for something For ALE and DRM. VHF RIGS. old Radio shack 2mtr base. yaesu 2800M. Several handis. (yaesu 409RH =APRS mobile.) antennas. HF =G5RV at 35 feet. 6mtr homebrewed 5element log-Yagi. tower= 10 ft armstrong stepladder. 2merter = various homebred concoctions. and bed springs. other boxes include antenna tunners and switches. two old PK232 MBX modems that were used for packet and Pactor. mt63 and PSK now seem to fill those nitches with less noise and frustration. in short... my homebrewing, building, experimenting, and testing is done mainly on the computers and antennas. I live in far norther Wisconsin on Lake Superior and back in the woods. by the time the UPS man gets here with the parts I order over the internet, I've forgotten where they fit in whaterver projects I had going on. LInux provides a fine platform to vent all my fiddling puttering and fix-it urges. HArv, N9AI On 11/30/06, Leigh L Klotz, Jr. [EMAIL PROTECTED] wrote: This is an interesting point of view, to take it from an economic and performance tradeoff. If I might ask (if this threa continues), would you all mind posting your rig and antenna systems as well? It would be interesting to see if there is a correlation between OS choice and rig choice. Homebrewers and Linux, or IC7800 and Windows, etc. 73, Leigh/WA5ZNU I wonder if we might get people to post their On Thu, 30 Nov 2006 4:09 pm, Dave Corio wrote: Having just finished experimenting with a dual-boot system, I would like to add my two cents worth. In my humble opinion, and if all things were equal, I would choose LINUX as my OS over Windows in a second. As far as using it for all else than ham radio, it is superb in most ways. While it does have a pretty steep learning curve, anyone who was used to the old DOS way of doing things can pick it up pretty quickly. But all things are not equal. While there is certainly some excellent amateur radio software for LINUX, and more coming out all the time, there simply isn't the wealth of development going into that area to produce programs that are truly competitive with what exists for Windows. Add that to the problem of compiling the programs and finding the necessary parts for assembling them, it is too early in the lifespan of the OS to expect that level of competition. I found that LINUX folks are amazing in their willingness to help a neophyte learn the ropes of the system, and some of the amateur software will be absolutely amazing given time. But, for me at least, that time isn't now. When it is, I'll be the first to recant my association with Windoze and jump on the LINUX bandwagon! I hope that day is sooner rather than later! 73 Dave KB3MOW
Re: [digitalradio] best mode to use for weak signal HF work and other mode discussions
Brett, There are several sound card modes commonly used in addition to the most popular PSK31 and 45 baud RTTY That would be MFSK16, Olivia, Hell, and Throb/ThrobX. Although there are others, I rarely, if ever hear them. I no longer seem to hear any MT-63 and the CHIP modes came and went quickly. I wanted to do more experimenting with DominoEX and last night I got to work some 160 meter NVIS. We started out on MFSK16 but I have been having a lot of problems with this mode as of late and maybe it is because my soundcard is not calibrated correctly, but I find that I have to use about 10 to 20 Hz offset RIT in order to print the other station. MFSK16 really does require extremely accurate tuning of perhaps 4 Hz or so. My rig is an ICOM 756 Pro 2 which is supposed to have very good stability at 0.5 ppm. The other station and I tried some PSK31 for a short time when I lost him on MFSK16 and was just able to get him to try DominoEX at 11 baud. His signal was close to the noise although it was not that noisy on 160 since we are in the winter season. The print was very poor at 11 baud, so we dropped to 8 baud and things got better. Even at 8 baud, the speed of transmission is still faster than MFSK16. We had a CW station come up about 50 Hz below us and when that station was transmitting, it drastically affected the print of the DEX mode, even at 8 wpm. The one thing that DEX has going for it is that it is less critical to tune in. If often wonder if a mode that has a very wide ability to print even if not tuned in well has to have some tradeoffs in robustness compared with critical to tune modes. Anyone have specific information about that? We probably should have tried even slower speeds because later on I had great difficulty copying him and took lots of hits. He is running Linux so did not have the FEC version of DEX. My experience in the past was that the Viterbi coding helps a great deal in good printing, even at 11 baud, but of course your speed drops by all of 50% so you are just a bit slower at 11 baud/FEC than you would be with MFSK16. It would be interesting to hear of other station's experience with DEX and DEX/FEC and various speeds with and without FEC, particularly with the lower baud rates on low band NVIS type operation. One of the things that I have to accept is that almost none of these modes will work very well on the lower bands with high QRN levels from summer static. Can anyone say with some degree of certainly what modes you think will get through on the low bands with high QRN levels? 73, Rick, KV9U Brett Owen Rees VK2TMG wrote: All, I find that I normally use PSK31 - as that is what most other stations use and is popular. But, I see a lot of stations that I cannot work - yet I can see their trace on the waterfall. Often, they are responding to my CQ and they just don't make it. Why do people respond to a 2 * 3 call with a 1*1 or 1*2 call? There seems to be a strategy for psk31 mode that involves sending information multiple times - like a poor man's FEC. I expect that is why they know who I am - from listening to my 2 * 3 call. The thing is - is there a mode that if I can see them on the waterfall then I can work them? I see no reason why we can't just go narrower/slower/more FEC and go right down into the noise. And why not have it be adaptive - and be able to become faster and wider if conditions are good - and even have a feature of being able to set a max bandwidth for those who may be constrained or for where a number of stations are sharing a 2.4KHz segment? Things I like about PSK31: - easy to tune with start bars, idle bars and ending tail (sorry, my naming scheme here) - narrow bandwidth - popular Things I dislike: - lack of RX sensitivity at times - errors at low SN Features that would be nice: - reliable, verified delivery - ability to use as part of a 'stack' so as to use for APRS or TCP/IP or file transfer or ALE or sounding or whatever - easy tuning - highly adaptive under trying conditions - be basis of keyboard mode DX mode - Open Source Please - I would like your opinions on this. Perhaps one of the current modes could be adapted - or am I trying to re-invent the wheel? What is the best that is out there currently and can we make use of it? In an ideal world what would be the theoretical best that we could aim for? I understand that with Turbo codes that it is possible to come very close to theoretical limits - are amateur protocols using such techniques? Having done some reading about DominoEX there appears to be various workarounds which may be required in order to make a mode practical - like being able to work around a carrier on the frequency. 73 de Brett VK2TMG No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database:
RE: [digitalradio] Linux versis Windows: Let the debate begin!!
Are you referring to ham radio applications or other more normal applications? I haven't had any problems with normal/regular Linux programs and even many ham radio programs...but I'll admit that some of the ham radio progrmas take a lot of work to get them loaded correctly and running correctly. Walt/K5YFW -Original Message- From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] Behalf Of Michael P. Brininstool Sent: Wednesday, November 29, 2006 10:12 AM To: digitalradio@yahoogroups.com Subject: RE: [digitalradio] Linux versis Windows: Let the debate begin!! From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Kevin O'Rorke Sent: Tuesday, November 28, 2006 5:47 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Linux versis Windows: Let the debate begin!! Seriously, until Linux programs can be installed as easily and reliably as Windows programs (I HAVE NEVER EVER HAD AN INSTALLATION PROBLEM IN WIN) then Linux has not a dogs chance in Hell of competing with Windows. I enjoy the challenge of fighting with Linux and consider myself an apprentice geek in that realm, but really what John says is, unfortunately true. . I have been using *NIX since 1986 (before Windows) and have never like Windows. The installation problem to which you refer will probably never be fixed in Linux. That is because, to do so, means standardizing distros and configs --something die-hard *NIX fans will not stand for. The reason I prefer *NIX is that I can have it my way. The analogy I like to use is this: You go in the the M$ (MicroSoft) restaurant and sit down, the waiter brings out your meal. You do not have a choice in what to order, or how it is prepared, just how many copies of the meal. I go into the *NIX restaurant, and talk to the cattle barron, and negotiate which cow he will let me purchase and for how much. He then hands me a butcher knife and sends me into the field. As much as I do not want to have to butcher my own meat, if that is the only way to get beef instead of the mystery meat of the year, and get it cooked to my specifications, then I will do it that way. Pre-packaged distros are just paying someone to butcher and wrap the meat for you. The problem I see, is that Linux interfaces are trying to become M$ Windows, and are starting to lose their original appeal.
[digitalradio] Rfsm2400 v.045
Hi all, Version 045 is out http://home.broadpark.no/~saanes/rfsm2400_v045.zip From the readme file: Changes in version 0.42. (+) RFSM-2400 allow simple remote control and IPC (option AutoTranseive). Directory TRANSEIVE is permanently scanned for files (remote commands). Allowed next remote commands: 1) Text file with name connect - command Connect, content of file is name of called abonent. 2) File with name disconnect - command Disconnect, file is empty. 3) Text file with name sendfile - command Send file, content of file is full name of transfered file (NOT required place transfered file to directory TRANSEIVE ;). 4) File with name stoptrans - command Stop transfer, file is empty. After operations is done, files will be deleted. So, file sendfile will be deleted after transfer is doing. Changes in version 0.45. (+) Option AutoTranseive renamed to Enable file-based IPC. Program writing to directory TRANSEIVE two files for display current status: - connected - when connected; - transfer - when sending or receiving files. When connect is lost or abonent is disconnected, file connected will be deleted. When transfer is doing or stoped, file transfer will be deleted. (+) Languages switch support. See options and directory LANGUAGES. Sorry, but system messages not translated in this version. Coming soon. (+) New option - Delayed user messages. Enabled - display user messages only when sended, grayed - display when typed (gray color) and when sended, disabled - display when typed (old style). (-) Fix bugs in packet monitor. 73 de LA5VNA Steinar --- In digitalradio@yahoogroups.com, Steinar Aanesland [EMAIL PROTECTED] wrote: Hi all, Go to http://rfsm2400.narod.ru/ and download the latest MIL-STD 188-110 Modem. (Or use my link, it's faster) http://home.broadpark.no/~saanes/rfsm2400_v42.zip 73 de LA5VNA Steinar
RE: [digitalradio] Re: USA: No Advanced Digital HF Data Comms
Red Cross, Salvation Army and the like frequencies are just commercial frequencies requiring the same bandwidth as other users of the frequencies...they have no special frequencies. However, I would think that DHS would approach the FCC about setting aside disaster communications frequencies that don't reside within the commercial frequencies. What is unfortunate is that the ITU really controls the bandwidth of the frequencies on HF world wide so there is not really any or many available frequencies on HF that can be used for wideband use EXCEPT the hambands. Even our military frequencies that we in the U.S. (Region II) cannot be used in other parts of the world. The clostest thing we have to a disaster frequency is the 5 MHz frequency that is used in Alaska. When you consider the actual needs of frequencies set aside for disaster communications, there just isn't enough bandwidth available...what IS available is amateur radio frequencies. I fear that if amateur radio operators in the U.S. don't accommodate NGO HF communications needs...and choose to give the NGOs their own disaster frequencies, those frequencies will come out of the hambands. It may be a case of play with the NGOs and meet their sometime communications needs or lose frequencies to them altogether. Walt/K5YFW -Original Message- From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] Behalf Of jgorman01 Sent: Thursday, November 30, 2006 7:06 PM To: digitalradio@yahoogroups.com Subject: [digitalradio] Re: USA: No Advanced Digital HF Data Comms Let me paraphrase N7DC's comment. The local, state, and federal governments and NGO's want our help - then they should provide the equipment and the bandwidth for its use- and that bandwidth is out there, assigned to agencies and NGO's now. I've checked and both the Red Cross and Salvation Army have HF frequencies assigned to them. I'm sorry they can't afford the equipment to use these assignments. With the recent letters to the FCC about how Homeland Security money would be wasted if the 500 Hz bandwidth restriction wasn't changed I wonder why the NGO's have not applied for and received Homeland Security money to provide their own equipment needed to use these assignments. The money is obviously available! This is where I philosophically disagree with your position. I believe you are saying since they can't afford it, then lets change the amateur bands so we can support the NGO's business needs, i.e. wide bandwidth high capacity HF links for disaster communications. I wholeheartedly disagree with this. For example, for general class licensees on 80m there would only be space for about seven 8 kHz channels. I am sure that if 8 kHz bandwidths were allowed, there would be a sufficient number of hams who would fill up the space thereby driving out all other modes and causing a lot of hams to cease operating entirely. This could easily end up having an unforeseen detremental effect, one of limiting the number of hams available for disaster support. Please ask yourself the question why, if the FCC won't let them use wide bandwidth modes on their own frequencies, should amateur radio do it for them especially when it has a detremental effect on our own service? I think the ham bands should be set up for what hams need on a day to day basis. Then, if this can help support NGO's or even governmental agencies, then fine. If they won't accept the level of service we can provide, well that is their loss. I am afraid that if we begin defining the ham band allocations, modes, and bandwidths based upon what non-ham organizations need to support their business plans (disaster services) we are on a very slippery slope that can lead to unintended consequences to the amateur service. Jim WA0LYK --- In digitalradio@yahoogroups.com, DuBose Walt Civ AETC CONS/LGCA [EMAIL PROTECTED] wrote: Most emergency communications is in reality disaster communications and is NOT in support of governments but rather non-governmental agencies, i.e. the Red Cross, Salvation Army, etc. These organizations do need very high-speed throughput modes that are robust to meet their operational needs and do not have the funding to provide hardware to support the need. Since the agencies supported are not government organizations (NGO), they cannot provide frequencies or bandwidth to support their communications needs. If the NGO has HF frequency/frequencies, they are controlled by the FCC and have strict bandwidth limits for their type of service. Even governmental agencies/organizations are controlled by a federal agency that limits their frequency use, power and bandwidth. Amateur radio is the only source that actually has a change for providing frequencies and bandwidths to meet NGO needs. But needing higher-speed and more robust modes is not the only need of NGOs...they also need robust chat and text modes that are robust for instant command and control operations...much
Re: [digitalradio] best mode to use for weak signal HF work and other mode discussions
Hello Rick, If often wonder if a mode that has a very wide ability to print even if not tuned in well has to have some tradeoffs in robustness compared with critical to tune modes. Anyone have specific information about that? The ability of DominoEx to be tuned very easily is that the modulation is an IFK one and not a MFSK one. It means that you measure a difference of frequency not a frequency in absolute as in MFSK. The good point it is easy to tune (no absolute reference of frequency) but the bad point is that when you do an error, the second symbol is also in error...you double the error (it's a bit like in PSK31, which one measures a difference of phase: if you do a error on one symbol, the next symbol will be also in error). Can anyone say with some degree of certainly what modes you think will get through on the low bands with high QRN levels? I think Olivia must be good but Contestia is more close to ideal as twice quicker than Olivia with a minimum S/N just 1 or 1.5 dB superior to Olivia. 73 Patrick - Original Message - From: KV9U To: digitalradio@yahoogroups.com Sent: Friday, December 01, 2006 7:49 PM Subject: Re: [digitalradio] best mode to use for weak signal HF work and other mode discussions Brett, There are several sound card modes commonly used in addition to the most popular PSK31 and 45 baud RTTY That would be MFSK16, Olivia, Hell, and Throb/ThrobX. Although there are others, I rarely, if ever hear them. I no longer seem to hear any MT-63 and the CHIP modes came and went quickly. I wanted to do more experimenting with DominoEX and last night I got to work some 160 meter NVIS. We started out on MFSK16 but I have been having a lot of problems with this mode as of late and maybe it is because my soundcard is not calibrated correctly, but I find that I have to use about 10 to 20 Hz offset RIT in order to print the other station. MFSK16 really does require extremely accurate tuning of perhaps 4 Hz or so. My rig is an ICOM 756 Pro 2 which is supposed to have very good stability at 0.5 ppm. The other station and I tried some PSK31 for a short time when I lost him on MFSK16 and was just able to get him to try DominoEX at 11 baud. His signal was close to the noise although it was not that noisy on 160 since we are in the winter season. The print was very poor at 11 baud, so we dropped to 8 baud and things got better. Even at 8 baud, the speed of transmission is still faster than MFSK16. We had a CW station come up about 50 Hz below us and when that station was transmitting, it drastically affected the print of the DEX mode, even at 8 wpm. The one thing that DEX has going for it is that it is less critical to tune in. If often wonder if a mode that has a very wide ability to print even if not tuned in well has to have some tradeoffs in robustness compared with critical to tune modes. Anyone have specific information about that? We probably should have tried even slower speeds because later on I had great difficulty copying him and took lots of hits. He is running Linux so did not have the FEC version of DEX. My experience in the past was that the Viterbi coding helps a great deal in good printing, even at 11 baud, but of course your speed drops by all of 50% so you are just a bit slower at 11 baud/FEC than you would be with MFSK16. It would be interesting to hear of other station's experience with DEX and DEX/FEC and various speeds with and without FEC, particularly with the lower baud rates on low band NVIS type operation. One of the things that I have to accept is that almost none of these modes will work very well on the lower bands with high QRN levels from summer static. Can anyone say with some degree of certainly what modes you think will get through on the low bands with high QRN levels? 73, Rick, KV9U Brett Owen Rees VK2TMG wrote: All, I find that I normally use PSK31 - as that is what most other stations use and is popular. But, I see a lot of stations that I cannot work - yet I can see their trace on the waterfall. Often, they are responding to my CQ and they just don't make it. Why do people respond to a 2 * 3 call with a 1*1 or 1*2 call? There seems to be a strategy for psk31 mode that involves sending information multiple times - like a poor man's FEC. I expect that is why they know who I am - from listening to my 2 * 3 call. The thing is - is there a mode that if I can see them on the waterfall then I can work them? I see no reason why we can't just go narrower/slower/more FEC and go right down into the noise. And why not have it be adaptive - and be able to become faster and wider if conditions are good - and even have a feature of being able to set a max bandwidth for those who may be constrained or for where a number of stations are
Re: [digitalradio] Re: Linux versis Windows: Let the debate begin!!
Leigh L Klotz, Jr. wrote: This is an interesting point of view, to take it from an economic and performance tradeoff. If I might ask (if this threa continues), would you all mind posting your rig and antenna systems as well? It would be interesting to see if there is a correlation between OS choice and rig choice. Homebrewers and Linux, or IC7800 and Windows, etc. 73, Leigh/WA5ZNU Interesting idea... Rig: currently IC-718 with TCXO, purchased in February 06 to replace my TS-430S which was purchased new in 1982. :) Computer: P4 3.4 GHz purchased Dec 2004 to replace my old Asus T2P4 motherboard which was running a K6/2 at 233 MHz (which replaced the original K5 processor I had in it) OS: Fedora Core 3 (the K6/2 runs Red Hat 6.2) Crossover version 4.2 to support MS-Office 2000. Antennas: Inverted Vees and Dipoles that will cover 160-10 with a Heath roller-inductor tuner, and tuner built from an old ARC-5 to cover 160m. I only rarely venture above 60m anyway, and do a lot more tinkering and listening than I ever do transmitting. Soundcard interface and CI-V interface - homebrew designed and built. I probably don't fit the description of either a typical ham or a typical computer user. - ps
Re: [digitalradio] USA: No Advanced Digital HF Data Comms
Hello Leigh and Jose, The parameters to look for from Patrick are the RS code groups and maximum correction coefficient. It is likely that the same seed data p is used in all cases, so there is no need for a registry of data codes. (I.e., if you can decode it, you don't need to know what it means since you have already found the right decoder g and frequency f). I use a limited sub-set of the RS code groups because through translation in time and in frequency RS codes are not orthogonal between themselves which is logic as RS has a set of solutions which are cyclic by parts (I don't see this in the litterature but it is obvious when you see the solutions...). The problem is to stay with a fix relationship between each RS solution and its mode label (0 for BPSK31...), exactly as in SSTV each code sent previously to the SSTV picture is related to a given SSTV code. 73 Patrick - Original Message - From: Leigh L Klotz, Jr. To: digitalradio@yahoogroups.com Sent: Friday, December 01, 2006 5:38 AM Subject: Re: [digitalradio] USA: No Advanced Digital HF Data Comms From what I can gather, the code is just an ECC'd data block and the contents of the data aren't that important; it is the decodability itself that is. If you can use arbitrary modem decoder g() and decode data p with center frequency f with g(p,f) yielding null|(q,r) where r is the correction coefficient, then you iterate over all decoders g and pick the one that produces the highest r, without reference to q. In all likelihood, only one decoder g() will yield a non-null result, however, if you also iterate over frequencies f then you may get multiple succesful decodes. The parameters to look for from Patrick are the RS code groups and maximum correction coefficient. It is likely that the same seed data p is used in all cases, so there is no need for a registry of data codes. (I.e., if you can decode it, you don't need to know what it means since you have already found the right decoder g and frequency f). 73, Leigh/WA5ZNU On Thu, 30 Nov 2006 1:08 pm, Jose A. Amador wrote: I see it would be interesting to register and publish the codes that Patrick used by some central authority (maybe, Patrick himself). For me, it is similar to the I2C codes that the semiconductor industry uses, and Philips, as inventor of the concept, is the registering authority.
[digitalradio] Re: best mode to use for weak signal HF work and other mode discussions
Hello Brett, Not sure there is a best modeall are trade-offs to some degree in terms of speed/bandwidth/sensitivity/robustness/other-stuff. Suspect if there was one best mode we would all use itThe variety of modes is part of the appeal; you want psk31 but also FEC? Use psk31F (for example). verified delivery - well then an ARQ mode such as Amtor/Pactor/PAX/PAX2/AX.25 and othersmore sensitivity? Try WSJT JT65, about the best I know of offhandspeed? PSK220/220F burns along if you have a good path..Chip and MT63 seem very robust but, like the rest, at a price. Tuning tolerance? DominoEX seems to only care if you take a stab in the dark at the correct frequency.Would consider few other than SlowFeldXPas for aircraft reflection work on VHF...very short signal bursts? Try JT6M 0r FSK441; heck, I even use CW sometimes :) Not trying to be flip and know I included modes outside your question about weak signal HF modes, but I think it pays to be flexible in terms of mode, conditions, band, and desires. Best advice I can give is to try them all and see what you like and what suits your operation conditions and style. Be well, 73 Bill, N9DSJ --- In digitalradio@yahoogroups.com, Brett Owen Rees VK2TMG [EMAIL PROTECTED] wrote: All, I find that I normally use PSK31 - as that is what most other stations use and is popular. But, I see a lot of stations that I cannot work - yet I can see their trace on the waterfall. Often, they are responding to my CQ and they just don't make it. Why do people respond to a 2 * 3 call with a 1*1 or 1*2 call? There seems to be a strategy for psk31 mode that involves sending information multiple times - like a poor man's FEC. I expect that is why they know who I am - from listening to my 2 * 3 call. The thing is - is there a mode that if I can see them on the waterfall then I can work them? I see no reason why we can't just go narrower/slower/more FEC and go right down into the noise. And why not have it be adaptive - and be able to become faster and wider if conditions are good - and even have a feature of being able to set a max bandwidth for those who may be constrained or for where a number of stations are sharing a 2.4KHz segment? Things I like about PSK31: - easy to tune with start bars, idle bars and ending tail (sorry, my naming scheme here) - narrow bandwidth - popular Things I dislike: - lack of RX sensitivity at times - errors at low SN Features that would be nice: - reliable, verified delivery - ability to use as part of a 'stack' so as to use for APRS or TCP/IP or file transfer or ALE or sounding or whatever - easy tuning - highly adaptive under trying conditions - be basis of keyboard mode DX mode - Open Source Please - I would like your opinions on this. Perhaps one of the current modes could be adapted - or am I trying to re-invent the wheel? What is the best that is out there currently and can we make use of it? In an ideal world what would be the theoretical best that we could aim for? I understand that with Turbo codes that it is possible to come very close to theoretical limits - are amateur protocols using such techniques? Having done some reading about DominoEX there appears to be various workarounds which may be required in order to make a mode practical - like being able to work around a carrier on the frequency. 73 de Brett VK2TMG -- === Brett Rees VK2TMG http://lisp.homeunix.net
Re: [digitalradio] Re: best mode to use for weak signal HF work and other mode discussions
Ive had good luck with psk-31 --- Bill McLaughlin [EMAIL PROTECTED] wrote: Hello Brett, Not sure there is a best modeall are trade-offs to some degree in terms of speed/bandwidth/sensitivity/robustness/other-stuff. Suspect if there was one best mode we would all use itThe variety of modes is part of the appeal; you want psk31 but also FEC? Use psk31F (for example). verified delivery - well then an ARQ mode such as Amtor/Pactor/PAX/PAX2/AX.25 and othersmore sensitivity? Try WSJT JT65, about the best I know of offhandspeed? PSK220/220F burns along if you have a good path..Chip and MT63 seem very robust but, like the rest, at a price. Tuning tolerance? DominoEX seems to only care if you take a stab in the dark at the correct frequency.Would consider few other than SlowFeldXPas for aircraft reflection work on VHF...very short signal bursts? Try JT6M 0r FSK441; heck, I even use CW sometimes :) Not trying to be flip and know I included modes outside your question about weak signal HF modes, but I think it pays to be flexible in terms of mode, conditions, band, and desires. Best advice I can give is to try them all and see what you like and what suits your operation conditions and style. Be well, 73 Bill, N9DSJ --- In digitalradio@yahoogroups.com, Brett Owen Rees VK2TMG [EMAIL PROTECTED] wrote: All, I find that I normally use PSK31 - as that is what most other stations use and is popular. But, I see a lot of stations that I cannot work - yet I can see their trace on the waterfall. Often, they are responding to my CQ and they just don't make it. Why do people respond to a 2 * 3 call with a 1*1 or 1*2 call? There seems to be a strategy for psk31 mode that involves sending information multiple times - like a poor man's FEC. I expect that is why they know who I am - from listening to my 2 * 3 call. The thing is - is there a mode that if I can see them on the waterfall then I can work them? I see no reason why we can't just go narrower/slower/more FEC and go right down into the noise. And why not have it be adaptive - and be able to become faster and wider if conditions are good - and even have a feature of being able to set a max bandwidth for those who may be constrained or for where a number of stations are sharing a 2.4KHz segment? Things I like about PSK31: - easy to tune with start bars, idle bars and ending tail (sorry, my naming scheme here) - narrow bandwidth - popular Things I dislike: - lack of RX sensitivity at times - errors at low SN Features that would be nice: - reliable, verified delivery - ability to use as part of a 'stack' so as to use for APRS or TCP/IP or file transfer or ALE or sounding or whatever - easy tuning - highly adaptive under trying conditions - be basis of keyboard mode DX mode - Open Source Please - I would like your opinions on this. Perhaps one of the current modes could be adapted - or am I trying to re-invent the wheel? What is the best that is out there currently and can we make use of it? In an ideal world what would be the theoretical best that we could aim for? I understand that with Turbo codes that it is possible to come very close to theoretical limits - are amateur protocols using such techniques? Having done some reading about DominoEX there appears to be various workarounds which may be required in order to make a mode practical - like being able to work around a carrier on the frequency. 73 de Brett VK2TMG -- === Brett Rees VK2TMG http://lisp.homeunix.net Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com
[digitalradio] how to make a good mode
a question is it better to spread the componets of a data stream across a band width of frequencies along with some type of redundancy, or have several independent streams with same info in each with maybe some type of time delay per stream ? like maybe 5 or so psk streams of independent data set side by side. david/wd4kpd
Re: [digitalradio] how to make a good mode
Back as far as the 60s, there were multiplex rtty circuits that sent the same info on several channels. When the receiver received the separate streams it then voted on whether the bit was a mark or a space. Whichever one won the vote, (more channels showing that status) the receiver came out with that as the proper data bit. It made it possible to send messages in the same speed as a single channel, but much more accuracy was obtained. We could actually send two messages at a time on that system, since we used double sideband transmissions, with the upper sideband carrying one set of signals, and the lower sideband another set of signals. I believe lthe Navy also used something like that for broadcasts to all ships in an area? Early sattilite systems had Frequency division multiplex - each embassy was assigned a separate modem and a separate frequency on the bird. Later on, it became Time Division Multiplex, which then allowed one channel on the bird, to handle a half dozen or more ground stations all at the same time, and each faster than the older modems - at that. Danny Douglas N7DC ex WN5QMX ET2US WA5UKR ET3USA SV0WPP VS6DD N7DC/YV5 G5CTB all DX 2-6 years each . QSL LOTW-buro- direct As courtesty I upload to eQSL but if you use that - also pls upload to LOTW or hard card. moderator [EMAIL PROTECTED] - Original Message - From: David Michael Gaytko // WD4KPD [EMAIL PROTECTED] To: DIGITALRADIO digitalradio@yahoogroups.com Sent: Friday, December 01, 2006 8:07 PM Subject: [digitalradio] how to make a good mode a question is it better to spread the componets of a data stream across a band width of frequencies along with some type of redundancy, or have several independent streams with same info in each with maybe some type of time delay per stream ? like maybe 5 or so psk streams of independent data set side by side. david/wd4kpd Need a Digital mode QSO? Connect to Telnet://cluster.dynalias.org Yahoo! Groups Links -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.430 / Virus Database: 268.15.3/561 - Release Date: 12/1/2006 6:36 AM
[digitalradio] Re: USA: No Advanced Digital HF Data Comms
Your argument isn't logical. If the NGO's don't have the resources to use the frequencies they currently have assigned, where would the resources come from to allow them to use amateur service frequencies reassigned to the land fixed/mobile service? How would they convince the FCC to allocate and assign new frequencies when they aren't using the ones they have? The ITU controls the segments assigned to different services. For example, 3750 - 4000 kHz in Region 2 can be amateur, land, or aeronautical. The FCC just can't create a new service for this segment without agreement of the signatories of the ITU. Therefore, these frequencies would have to be assigned within the land fixed/mobile service and end up with the same restriction that their current assignments have. Lastly, I just can't understand where so much data is going to come from in a disaster that the FCC could justify moving HF amateur allocations to land fixed/mobile. Amateur radio should not be the primary service that handles megabytes/gigabytes of data on a continuous basis for logistics, etc. for NGO's or the government. This is close to the line of using amateur radio as a full blown communications carrier. If amateurs involved with emcomms are selling this to NGO's and the government they are doing so without consulting with all the other amateur service licensees that share these frequencies and getting their agreement. Jim WA0LYK --- In digitalradio@yahoogroups.com, DuBose Walt Civ AETC CONS/LGCA [EMAIL PROTECTED] wrote: Red Cross, Salvation Army and the like frequencies are just commercial frequencies requiring the same bandwidth as other users of the frequencies...they have no special frequencies. However, I would think that DHS would approach the FCC about setting aside disaster communications frequencies that don't reside within the commercial frequencies. What is unfortunate is that the ITU really controls the bandwidth of the frequencies on HF world wide so there is not really any or many available frequencies on HF that can be used for wideband use EXCEPT the hambands. Even our military frequencies that we in the U.S. (Region II) cannot be used in other parts of the world. The clostest thing we have to a disaster frequency is the 5 MHz frequency that is used in Alaska. When you consider the actual needs of frequencies set aside for disaster communications, there just isn't enough bandwidth available...what IS available is amateur radio frequencies. I fear that if amateur radio operators in the U.S. don't accommodate NGO HF communications needs...and choose to give the NGOs their own disaster frequencies, those frequencies will come out of the hambands. It may be a case of play with the NGOs and meet their sometime communications needs or lose frequencies to them altogether. Walt/K5YFW
Re: [digitalradio] Re: USA: No Advanced Digital HF Data Comms
Well, you're right IMHO, however, there's something more. Generally, in this country we've sacrificed personal freedoms by virtue of the DHS and the Patriot Act, yet no one has complained yet. Any interest by EMCOMM folks or anyone else who would entertain the notion of giving away something else to the DHS for any reason such as you addressed worries me greatly. We're not a commercial service nor should we even try to act like one. Digital Radio and all other forms of technology we help develop should remain within the real scope of this HOBBY. If we help EMCOMM in some fashion, super. If volunteering our services to the extent we have available, kudos to us. But leave it at that and don't sacrifice anything more of our valuable resources. We're already out of sync with the rest of the world, again IMHO for whatever that's worth. Howard W6IDS Richmond, IN - Original Message - From: jgorman01 To: digitalradio@yahoogroups.com Sent: Friday, December 01, 2006 10:35 PM Subject: [digitalradio] Re: USA: No Advanced Digital HF Data Comms Your argument isn't logical. If the NGO's don't have the resources to use the frequencies they currently have assigned, where would the resources come from to allow them to use amateur service frequencies reassigned to the land fixed/mobile service? SNIP SNIP
Re: [digitalradio] USA: No Advanced Digital HF Data Comms
Ok so if there are multiple solutions then there is data to ECC, not 100% ECC of a constant, so it is indeed correct that there is a need for a registry, and I was wrong. Leigh/WA5ZNU On Fri, 1 Dec 2006 4:07 pm, Patrick Lindecker wrote: Hello Leigh and Jose, The parameters to look for from Patrick are the RS code groups and maximum correction coefficient. It is likely that the same seed data p is used in all cases, so there is no need for a registry of data codes. (I.e., if you can decode it, you don't need to know what it means since you have already found the right decoder g and frequency f). I use a limited sub-set of the RS code groups because through translation in time and in frequency RS codes are not orthogonal between themselves which is logic as RS has a set of solutions which are cyclic by parts (I don't see this in the litterature but it is obvious when you see the solutions...). The problem is to stay with a fix relationship between each RS solution and its mode label (0 for BPSK31...), exactly as in SSTV each code sent previously to the SSTV picture is related to a given SSTV code. 73 Patrick - Original Message - From: Leigh L Klotz, Jr. To: digitalradio@yahoogroups.com Sent: Friday, December 01, 2006 5:38 AM Subject: Re: [digitalradio] USA: No Advanced Digital HF Data Comms From what I can gather, the code is just an ECC'd data block and the contents of the data aren't that important; it is the decodability itself that is. If you can use arbitrary modem decoder g() and decode data p with center frequency f with g(p,f) yielding null|(q,r) where r is the correction coefficient, then you iterate over all decoders g and pick the one that produces the highest r, without reference to q. In all likelihood, only one decoder g() will yield a non-null result, however, if you also iterate over frequencies f then you may get multiple succesful decodes. The parameters to look for from Patrick are the RS code groups and maximum correction coefficient. It is likely that the same seed data p is used in all cases, so there is no need for a registry of data codes. (I.e., if you can decode it, you don't need to know what it means since you have already found the right decoder g and frequency f). 73, Leigh/WA5ZNU On Thu, 30 Nov 2006 1:08 pm, Jose A. Amador wrote: I see it would be interesting to register and publish the codes that Patrick used by some central authority (maybe, Patrick himself). For me, it is similar to the I2C codes that the semiconductor industry uses, and Philips, as inventor of the concept, is the registering authority.
Re: [digitalradio] Re: Linux versis Windows: Let the debate begin!!
HF setup I run an Alinco DX-77 with a homebrew interface. KVM cables and old scsi cables make for great shielded wiring. It's all a bit basic with TX keying hanging off the back of DB9s plug etc - but it works. Computer is 2.2 GHz P4 with Debian installed from a Knoppix CD, and then updated over the Internet. 20m antenna is a dipole with coax balun, and 160-40m is an inverted L through a manual ATU situated at the feedpoint to the shack. I build all of my antenna and interfaces but typically buy radios new - less headaches that way. Primary software is fldigi alpha versions. For VHF APRS (VK2TMG-1) I run an ebay special FDC FD-150A HT to a 1/4 wave groundplane, and also an FT-2800M to a copper jpole for local repeater use. This is connected to a 1GHz P3 Windows XP box running AGWPE and UI-View. On my motorcycle (VK2TMG-10) I run an APRS tracker comprising 1/4 wave groundplane, Opentracker and Tait 2020 on 2m - all re-programmed/constructed by myself. Internet setup comprises ADSL router, IPCOP (Linux-based 166 MHz P2) firewall, primary lisp.homeunix.net (Linux Mandrake install) 500 MHz P2 server, Wifi AP, 2 switches, XYL computer (XP) and laptop (Win 2k). If electricity ever get's real expensive I will have to shut some of it down hi hi. 73 de Brett VK2TMG -- === Brett Rees VK2TMG http://lisp.homeunix.net
