[digitalradio] ST. VINCENT, J8. SSTV
ST. VINCENT, J8. Dave, G3TBK will be QRV as J88DR for one week. This includes an entry in the ARRL SSB DX contest. Afterwards, he will be active on all bands using CW, SSB, RTTY and possibly SSTV. QSL to home call. ARRL- -- Andy K3UK www.obriensweb.com (QSL via N2RJ)
[digitalradio] Re: Keeping NBEMS in mind
--- In digitalradio@yahoogroups.com, n0sya [EMAIL PROTECTED] wrote: How does nbems fare in weak signal conditions compared to other modes such as olivia and mt63? NBEMS is the software package, not an actual mode. It includes PSK31, PSK63, PSK 125, PSK250, MFSK16 and RTTY. MT63 and Olivia are not offered. One primary goal for this software is high speed message transfers on VHF and UHF where something like PSK250 can be used with good outcome. On HF, the noise level does not usually support the higher speed PSK operations but PSK31 and PSK63 do quite well on HF. The software uses ARQ ... the message is sent, the other stations sends an acknowledgment from time to time. If there was a error (due to no decode of a weak signal for example) the section of the message would be repeated until the station acknowledges receipt. Thus the transfer rate can be slow but the text/copy will be 100% if the files xfer is successful. While Olivia and MT63 are vastly superior to PSK31 under most weak signal situations, the ARQ aspects of NBEMS will make it more reliable if accuracy is what you desire. ALE 400 and RFSM-8000 offer alternatives . ALE-400 is available in Multipsk but is not widely used. RFSM is even less used and some baud rates are not legal for USA amateurs to use. I believe the authors of NBEMS had a goal of facilitating the accurate transfer of messages via methods widely used by hams in everyday application. Thus PSK and RTTY, very commonly used. While they will not perform as well as ALE 400, RSFM 8000, Winlink, Pactor II, III, in some circumstances, the expectation is that a PSK based NBEMS system will make up for it's lack of sophisticated modulation schemes via its accuracy and simplicity. One observation to keep in mind...when I have used NBEMS and have been receiving files via PSK31 ARQ , the received text in VBdigi (without ARQ) is almost always as good as the ARQ PSK via FLARQ. Most of the digital modes under average conditions will give you the ability to send a highly accurate message. NBEMS, ALE 400 and RSFM offer the comfort that it will be 100% accurate if the file transfer is completed. Thus, in theory , if that emergency message you intercept says my latitude is 40.0446 and Olivia decodes it as 49.0046 , we have a problem. The error correction in NBEMS and ALE400 will ensure it is accurate. The dilemma: Under bad conditions you might get perhaps 70% of a message in Olivia with several errors, while under the same bad conditions you may only get 30% using PSK, ALE 400 or RSFM (hypothetical numbers) and not enough to complete the file transfer. Andy K3UK
Re: [digitalradio] Re: Keeping NBEMS in mind
How does nbems fare in weak signal conditions compared to other modes such as olivia and mt63? NBEMS uses the PSK modes for simplicity of tuning, narrowness, and speed. Other, wider modes, like Olivia and MT63, work further down under the noise threshold than the PSKmodes. This makes them better for casual communicating on HF, over longer distances, where the QSB fading is often very deep, fading 10 dB or more. NBEMS is designed primarily for emcomm messaging over distances up to 100 miles, and wherever possible, 2m SSB (using digital modes) is recommended so there is almost no fading to contend with and antennas are smaller and more portable. On 2m, once you achieve a detectable signal on the waterfall (which is needed for tuning and therefore has to at least be visible in the noise), it generally stays at that level (up to 100 miles), so the ability to continue copy far down under the noise threshold is not needed. In hilly regions, where 2m VHF will not work due to shadowing by the hills, the alternative is to use single-hop HF, with NVIS antennas, on 80m or 40m, and the fading is less than on multi-hop paths, but not as good as on VHF. For very difficult HF conditions, NBEMS had been designed to also support MFSK16 for ARQ transfers. Transfer times are much longer compared to the PSK modes, but the message does eventually get through without any errors. Since few disasters, requiring emergency communications, span more than 100 miles, narrowband PSK modes work just fine for the purpose, just as PSK31 works well enough for casual operating, even though wider modes work better under fading conditions. It is desirable, in order to be seen by as many potential message forwarding operators as possible, to have all the NBEMS stations appear on the waterfall at one dial setting, just like most PSK31 stations on HF do now. In order to do this within the 2500 Hz-wide receiver passbands most people have, the narrowband modes need to be used. For most short emcomm messages, the speed of PSK63 is quite sufficient, up to 25 PSK63 stations can share 2500 Hz of spectrum, and all can be seen at the same time, thereby maximizing the number of potential forwarding stations. The reason that NBEMS is described as a system is that it integrates several elements, such as particularly using VHF 2m, particularly using NVIS for HF, and using narrowband modes, instead of wider modes, for the most effective and reliable emergency messaging over distances up to 100 miles. 73, Skip KH6TY NBEMS Development Team No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.21.2/1305 - Release Date: 2/29/2008 6:32 PM
[digitalradio] Re: Keeping NBEMS in mind
I guess that Skip and I were typing at the same time! Andy
[digitalradio] Re: Keeping NBEMS in mind
--- In digitalradio@yahoogroups.com, Andrew O'Brien [EMAIL PROTECTED] wrote: I guess that Skip and I were typing at the same time! Andy Thanks for all the input, guys! Chris/n0syq
Re: [digitalradio] Some thoughts on antenna polarization for emergency use
I recall reading years ago horz TV may have been picked over vert because some test showed there to be less multipath and therefore less reflections and ghosts on the picture. I have no idea whether that is true. I remember seeing vert TV antennas in some other countries. AL7BX/ George
Re: [digitalradio] Re: Keeping NBEMS in mind
I can see that some digital modes would not work very well for ARQ that is decoded in real time. MT-63 and MFSK16 both have latency due to their design. I am surprised that MFSK16 was considered, but perhaps this was due to being the most narrow mode that also can work very deep into the noise? Olivia is so very slow relative to the bandwidth, that I would not think of it as a good candidate. The one mode that seems to be a ready made mode for this kind of communication is FAE400 since it already is an ARQ mode and is reasonably narrow for its throughput. This is the best mode I have ever used for an ARQ sound card solution, especially considering how narrow it is for the sensitivity and speed. Alternatively, couldn't the ALE400 mode be incorporated into the NBEMS system since it would then become an ARQ mode, although would work differently than FAE400 and perhaps not as fast? One thing I don't follow completely with Skip is the idea that you need all these signals on one waterfall. I would never tune in a signal very far off from my sweet spot on my rig (varies depending upon rig design) and normally want digital modes to be centered on 1500 Hz in order to be able to use the filtering available to me. It can make a big difference in difficult conditions or when very strong signals or splattering signals are close in. If we had an emergency situation, it seems to me that you would not be having multiple streams of different stations sending data. Especially not for e-mail capability. It may be difficult to even find more than one or two stations that you can connect to and who have a computer interfaced with their rig with the NBEMS program suite installed and know how to use it. Once you were able to find someone, you would likely want to work with them (assuming a savvy operator, no different than other modes), and route your traffic in that manner. They could coordinate with others outside the disaster area and have them come up on frequency as needed for relief. One thing that has concerned me here in the U.S., is the near total lack of interest in developing some method of using voice intermixed with text data, the very thing we most need for emergency communications. While we can legally do it under the Part 97 rules on 160 meters and on 6 meters and up, the bandplans do not reflect that. Why do so few support this capability? It is used everyday by the SSTV and hams doing large data transfers of this type. Maybe we could at least use it on VHF? But I have not found a common frequency in the bandplans. As far as the wide bandwidth and faster modes such as RFSM, this could work under some conditions. Tremendously faster than the NBEMS system, although it does not have the fall back to the weaker signals and requires better signals than what is normally required for very weak SSB. Has anyone done any further testing on VHF with RFSM? It is completely legal to do so here in the U.S. on 6 meters and up. As Andy points out, there are times when the ARQ text digital modes don't work at all, but with FAE400 this seems like much less of a problem considering that it may be able to perform better than PSK31 without ARQ. 73, Rick, KV9U Andrew O'Brien wrote: NBEMS is the software package, not an actual mode. It includes PSK31, PSK63, PSK 125, PSK250, MFSK16 and RTTY. MT63 and Olivia are not offered. One primary goal for this software is high speed message transfers on VHF and UHF where something like PSK250 can be used with good outcome. On HF, the noise level does not usually support the higher speed PSK operations but PSK31 and PSK63 do quite well on HF. The software uses ARQ ... the message is sent, the other stations sends an acknowledgment from time to time. If there was a error (due to no decode of a weak signal for example) the section of the message would be repeated until the station acknowledges receipt. Thus the transfer rate can be slow but the text/copy will be 100% if the files xfer is successful. While Olivia and MT63 are vastly superior to PSK31 under most weak signal situations, the ARQ aspects of NBEMS will make it more reliable if accuracy is what you desire. ALE 400 and RFSM-8000 offer alternatives . ALE-400 is available in Multipsk but is not widely used. RFSM is even less used and some baud rates are not legal for USA amateurs to use. I believe the authors of NBEMS had a goal of facilitating the accurate transfer of messages via methods widely used by hams in everyday application. Thus PSK and RTTY, very commonly used. While they will not perform as well as ALE 400, RSFM 8000, Winlink, Pactor II, III, in some circumstances, the expectation is that a PSK based NBEMS system will make up for it's lack of sophisticated modulation schemes via its accuracy and simplicity. One observation to keep in mind...when I have used NBEMS and have been receiving files via PSK31 ARQ , the received text in
[digitalradio] Some success with PSKmail
I recently revisited PSKmail as I had previously downloaded fldigi and was thinking that I had that program working. I did the necessary unzip and untar, although I could not get the regular GUI program to do it. It indicated no directory to put it in and so I just used the terminal program. I am using Kubutu, but tried to follow the detailed downloads required for Ubuntu and ran into lots of problems with it not finding or being able to do things with the rather large numbers of files, but kept trying various ways from other Linux variants and somehow managed to get everything installed. As an aside, Linux developers have to figure out how to make this all a part of the program or the OS or whatever. It is amazingly difficult and convoluted to do all this stuff just to get one program to work. Windows is so incredibly superior to this downside of Linux that it will be (or is already) a non starter for most computer users. You can call people dumb and all that, as some of the Linux zealots do on a rather regular basis, but this is a huge stumbling block. And very retro in today's advanced operating systems. Like my wife says, I just want it to work. I was able to eventually figure out how to get everything to work and attempted connecting with several of the listed e-mail stations and did connect to the 5 station once I got on the correct QRG. That was impressive. I did not have anything connected up yet to an e-mail program so that will require more configuration but I thought I might just try and send just anything from the keyboard. Ooops, I crashed X Windows. Then I recalled that some time back, this was an on-going problem with my computer:( Does anyone else have this problem with fldigi? It has something to do with entering any data in the transmit window and X just goes into an immediate reboot. Or perhaps a later version has this fixed? Are any stations using PSKmail here in the U.S.? Can you tell us of your experiences? After using NBEMS at bit, am I right that the error correction ARQ is the same or very close to the way that PSKmail does this? If so, why can't this be ported over to MS OS? This would give us an additional tool for emergencies as well as some practical e-mail capability that is very narrow mode. 73, Rick, KV9U
RE: [digitalradio] Re: Keeping NBEMS in mind
true John, but function beats pretty most of the time.. As far as FAE400 goes, I would like to try it. Too bad one can only get it from one source. (gee that kind of makes it just like pactor 3. I don't hear any anyone screaming bloody murder about that.) Multipsk may be a very fine software package but the screen looks like crap. Just way way to much un-needed garbage there. Are you listing Patrick ? If it was my software I think I would have a drop down window to pick the mode of operation. And only what was needed for that mode would be on that screen. John VE5MU
Re: [digitalradio] Some success with PSKmail
For people who don't want the 'hassle' of installing some perl modules via CPAN there are 2 possibilities: * Run pskmail and fldigi from the pskmail_puppy live CD. It boots in 45 seconds the second time if you save some files on your C drive after first use. This will give you fldigi 2.09 and pskmail client version 0.6. * This also works from a 256MB bootable USB drive. As it runs totally in RAM it is lightning fast. * Run pskmail inside windows. This is as easy as unzipping a zip file in your C drive and installing 1 driver (KQEMU). Also a 1-click affair. You need at least 256 MB Ram for this. If you tell it to do so it will automatically saveyour config data and mail afterwards (also to a separate USB stick). Uses VESA only. 1024x768 is works fine in XP. It is impossible for me to port it to window$, as the program uses a lot of Linux native tools. The APRS part (yes, pskmail is a full-fledged HF APRS messenger) has been done for windows by UT1HZM. The arq part is more difficult... In EU I can use 4 servers at the moment from where I am. IS0GRB-3, PI4TUE, DL9YCS, SM0RWO. Depending on time of day. Most beacons are qsl'ed by 2 servers all the time. Using 20 Watts from my RV on a campsite in Spain. Last email session on 19:30 local with DL9YCS on 30 meters PSK250 with zero repeats. Several servers are operated in the US and 1 in Australia. Best set up a server yourself for initial testing... http://pskmail.wikispaces.com http://www.freelists.org/archives/pskmail/ http://www.pskmail.de 73, Rein EA/PA0R/P -Ursprüngliche Nachricht- Von: digitalradio@yahoogroups.com Gesendet: 02.03.08 19:24:46 An: digitalradio@yahoogroups.com Betreff: [digitalradio] Some success with PSKmail I recently revisited PSKmail as I had previously downloaded fldigi and was thinking that I had that program working. I did the necessary unzip and untar, although I could not get the regular GUI program to do it. It indicated no directory to put it in and so I just used the terminal program. I am using Kubutu, but tried to follow the detailed downloads required for Ubuntu and ran into lots of problems with it not finding or being able to do things with the rather large numbers of files, but kept trying various ways from other Linux variants and somehow managed to get everything installed. As an aside, Linux developers have to figure out how to make this all a part of the program or the OS or whatever. It is amazingly difficult and convoluted to do all this stuff just to get one program to work. Windows is so incredibly superior to this downside of Linux that it will be (or is already) a non starter for most computer users. You can call people dumb and all that, as some of the Linux zealots do on a rather regular basis, but this is a huge stumbling block. And very retro in today's advanced operating systems. Like my wife says, I just want it to work. I was able to eventually figure out how to get everything to work and attempted connecting with several of the listed e-mail stations and did connect to the 5 station once I got on the correct QRG. That was impressive. I did not have anything connected up yet to an e-mail program so that will require more configuration but I thought I might just try and send just anything from the keyboard. Ooops, I crashed X Windows. Then I recalled that some time back, this was an on-going problem with my computer:( Does anyone else have this problem with fldigi? It has something to do with entering any data in the transmit window and X just goes into an immediate reboot. Or perhaps a later version has this fixed? Are any stations using PSKmail here in the U.S.? Can you tell us of your experiences? After using NBEMS at bit, am I right that the error correction ARQ is the same or very close to the way that PSKmail does this? If so, why can't this be ported over to MS OS? This would give us an additional tool for emergencies as well as some practical e-mail capability that is very narrow mode. 73, Rick, KV9U -- http://pa0r.blogspirit.com Announce your digital presence via our Interactive Sked Page at http://www.obriensweb.com/sked Check our other Yahoo Groups http://groups.yahoo.com/group/dxlist/ http://groups.yahoo.com/group/contesting http://groups.yahoo.com/group/themixwgroup Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/digitalradio/ * Your email settings: Individual Email | Traditional * To change settings online go to: http://groups.yahoo.com/group/digitalradio/join (Yahoo! ID required) * To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
[digitalradio] Multipsk appearance
John, One major advantage of Multipsk is that it works on next-to-nothing for a PC, you can use it on old 486 machines! Every drop-down box and fancy bell and whistle usually adds CPU and RAM demand. To compare ALE400 in Multipsk with Pactor's copyright is absurd . ALE 400 is FREE whereas PIII is getting close to $2000 these days (it takes 1.5 US dollars to buy one Euro). Andy K3UK On Sun, Mar 2, 2008 at 1:51 PM, John Becker, WØJAB [EMAIL PROTECTED] wrote: After reading this thread with great intrust I still fail to see the difference between it and what has been done with the Pactor modes. That is other than being narrow. I have copies Pactor that has to say the least been about 2 DB under ESP. As far as FAE400 goes, I would like to try it. Too bad one can only get it from one source. (gee that kind of makes it just like pactor 3. I don't hear any anyone screaming bloody murder about that.) Multipsk may be a very fine software package but the screen looks like crap. Just way way to much un-needed garbage there. Are you listing Patrick ? If it was my software I think I would have a drop down window to pick the mode of operation. And only what was needed for that mode would be on that screen. Yeah I know - that's just my option. Everyone has one. And I'm sitting on mine. John, W0JAB in the center of fly over country -- Andy K3UK www.obriensweb.com (QSL via N2RJ)
Re: [digitalradio] Re: Keeping NBEMS in mind
After reading this thread with great intrust I still fail to see the difference between it and what has been done with the Pactor modes. That is other than being narrow. I have copies Pactor that has to say the least been about 2 DB under ESP. As far as FAE400 goes, I would like to try it. Too bad one can only get it from one source. (gee that kind of makes it just like pactor 3. I don't hear any anyone screaming bloody murder about that.) Multipsk may be a very fine software package but the screen looks like crap. Just way way to much un-needed garbage there. Are you listing Patrick ? If it was my software I think I would have a drop down window to pick the mode of operation. And only what was needed for that mode would be on that screen. Yeah I know - that's just my option. Everyone has one. And I'm sitting on mine. John, W0JAB in the center of fly over country
Re: [digitalradio] Re: Keeping NBEMS in mind
All high-latency modes are unsuitable for ARQ. A persistent misconception is that you would be using signals near the noise level. As I have stated many times, noise is hardly ever the problem unless it is S8. The problem is multi-path causing QSB (up to 80 dB on path we are using) and QRM from other stations firing up their gear on top of your QSO. PSkmail arq takes care of this very well by repeating the stuff that has been unreadable in the qsb. QRN is taken care of by automatically shortening of the packets when the error rate goes up, which decreases the chance of a packet being hit. Again, noise is seldom the problem, we pick a better path if necessary, depending on time of day. Signal levels are normally around S5-S9 here in EU, depending on time/distance. 73, Rein EA/PA0R/P on a campsite in Spain (3 years experience with PSK63ARQ (2005), PSK125ARQ(2006) and PSK250ARQ(2007,2008). -Ursprüngliche Nachricht- Von: digitalradio@yahoogroups.com Gesendet: 02.03.08 18:52:31 An: digitalradio@yahoogroups.com Betreff: Re: [digitalradio] Re: Keeping NBEMS in mind I can see that some digital modes would not work very well for ARQ that is decoded in real time. MT-63 and MFSK16 both have latency due to their design. I am surprised that MFSK16 was considered, but perhaps this was due to being the most narrow mode that also can work very deep into the noise? Olivia is so very slow relative to the bandwidth, that I would not think of it as a good candidate. The one mode that seems to be a ready made mode for this kind of communication is FAE400 since it already is an ARQ mode and is reasonably narrow for its throughput. This is the best mode I have ever used for an ARQ sound card solution, especially considering how narrow it is for the sensitivity and speed. Alternatively, couldn't the ALE400 mode be incorporated into the NBEMS system since it would then become an ARQ mode, although would work differently than FAE400 and perhaps not as fast? One thing I don't follow completely with Skip is the idea that you need all these signals on one waterfall. I would never tune in a signal very far off from my sweet spot on my rig (varies depending upon rig design) and normally want digital modes to be centered on 1500 Hz in order to be able to use the filtering available to me. It can make a big difference in difficult conditions or when very strong signals or splattering signals are close in. If we had an emergency situation, it seems to me that you would not be having multiple streams of different stations sending data. Especially not for e-mail capability. It may be difficult to even find more than one or two stations that you can connect to and who have a computer interfaced with their rig with the NBEMS program suite installed and know how to use it. Once you were able to find someone, you would likely want to work with them (assuming a savvy operator, no different than other modes), and route your traffic in that manner. They could coordinate with others outside the disaster area and have them come up on frequency as needed for relief. One thing that has concerned me here in the U.S., is the near total lack of interest in developing some method of using voice intermixed with text data, the very thing we most need for emergency communications. While we can legally do it under the Part 97 rules on 160 meters and on 6 meters and up, the bandplans do not reflect that. Why do so few support this capability? It is used everyday by the SSTV and hams doing large data transfers of this type. Maybe we could at least use it on VHF? But I have not found a common frequency in the bandplans. As far as the wide bandwidth and faster modes such as RFSM, this could work under some conditions. Tremendously faster than the NBEMS system, although it does not have the fall back to the weaker signals and requires better signals than what is normally required for very weak SSB. Has anyone done any further testing on VHF with RFSM? It is completely legal to do so here in the U.S. on 6 meters and up. As Andy points out, there are times when the ARQ text digital modes don't work at all, but with FAE400 this seems like much less of a problem considering that it may be able to perform better than PSK31 without ARQ. 73, Rick, KV9U Andrew O'Brien wrote: NBEMS is the software package, not an actual mode. It includes PSK31, PSK63, PSK 125, PSK250, MFSK16 and RTTY. MT63 and Olivia are not offered. One primary goal for this software is high speed message transfers on VHF and UHF where something like PSK250 can be used with good outcome. On HF, the noise level does not usually support the higher speed PSK operations but PSK31 and PSK63 do quite well on HF. The software uses ARQ ... the message is sent, the other stations sends an acknowledgment from time to time. If there was a
Re: [digitalradio] Re: Keeping NBEMS in mind
John, The difference is HUGE! Pactor is a proprietary mode and the primary use is for radio e-mail. The cost is quite high for just that one function and very few of us digital operators will buy a single sourced foreign product for that purpose unless we are boaters or RV'ers and want the free e-mail service. (I am not suggesting that doing this is proper or the right thing to do just because you can do it, but that is the way of the world at this time). Due to the ready availability of the multimode software that runs on a computer, and using just the soundcard, we can pick and choose from many different software packages, most of them free as in beer. This gives us dozens of different modes to experiment with and decide what we will use for our operating preferences. If I had all the modes available on a given program, I would likely select Ham Radio Deluxe with the Digital Master 780 digital mode addition. This is the most refined digital program, but it does require plenty of power to run. Multipsk has many more modes, including ALE/FAE400 which is the mode that I find the most powerful for ARQ messaging at this time. The interface is what Patrick prefers and he is the programmer and allows you to use most of the program features for free. It is hard to understand why you would criticize such a product with such strong language! It is one thing to ask, as many of us have, if the program could be made more professional looking and acting, but he just prefers it his way. 73, Rick, KV9U John Becker, WØJAB wrote: After reading this thread with great intrust I still fail to see the difference between it and what has been done with the Pactor modes. That is other than being narrow. I have copies Pactor that has to say the least been about 2 DB under ESP. As far as FAE400 goes, I would like to try it. Too bad one can only get it from one source. (gee that kind of makes it just like pactor 3. I don't hear any anyone screaming bloody murder about that.) Multipsk may be a very fine software package but the screen looks like crap. Just way way to much un-needed garbage there. Are you listing Patrick ? If it was my software I think I would have a drop down window to pick the mode of operation. And only what was needed for that mode would be on that screen. Yeah I know - that's just my option. Everyone has one. And I'm sitting on mine. John, W0JAB in the center of fly over country
Re: [digitalradio] Re: Keeping NBEMS in mind
Hello John, As far as FAE400 goes, I would like to try it. Too bad one can only get it from one source. (gee that kind of makes it just like pactor 3. Pactor 2 and 3 have private detailed specifications which forbid to even decode them (however it would be impossible to work them in ARQ with a PC) whereas ARQ FAE has public specifications (on my WEB site). Any Ham, in theory, could program ARQ FAE (but it's true that it would be a bit long as they are over-specifications on ALE specifications). I don't hear any anyone screaming bloody murder about that.) Multipsk may be a very fine software package but the screen looks like crap. As written previously: You see it cluttered, I see it in perfect order. This GUI corresponds to what I need i.e.: * not to waste time in searching the wished command or to switch of mode or sub-mode (minimum of menus, maximum of buttons, panel of modes...), * always the maximum of information directly available on the screen (many hints, contextual help with right click, QRGs, actual configuration...). I haven't any desire to change anything to this GUI. 73 Patrick - Original Message - From: John Becker, WØJAB To: digitalradio@yahoogroups.com Sent: Sunday, March 02, 2008 7:51 PM Subject: Re: [digitalradio] Re: Keeping NBEMS in mind After reading this thread with great intrust I still fail to see the difference between it and what has been done with the Pactor modes. That is other than being narrow. I have copies Pactor that has to say the least been about 2 DB under ESP. As far as FAE400 goes, I would like to try it. Too bad one can only get it from one source. (gee that kind of makes it just like pactor 3. I don't hear any anyone screaming bloody murder about that.) Multipsk may be a very fine software package but the screen looks like crap. Just way way to much un-needed garbage there. Are you listing Patrick ? If it was my software I think I would have a drop down window to pick the mode of operation. And only what was needed for that mode would be on that screen. Yeah I know - that's just my option. Everyone has one. And I'm sitting on mine. John, W0JAB in the center of fly over country
RE: [digitalradio] Re: Keeping NBEMS in mind
you know what Patrick? it works really, really well and can live with the GUI however you want it. John VE5MU From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Patrick Lindecker Sent: Sunday, March 02, 2008 1:59 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Re: Keeping NBEMS in mind Hello John, As far as FAE400 goes, I would like to try it. Too bad one can only get it from one source. (gee that kind of makes it just like pactor 3. Pactor 2 and 3 have private detailed specifications which forbid to even decode them (however it would be impossible to work them in ARQ with a PC) whereas ARQ FAE has public specifications (on my WEB site). Any Ham, in theory, could program ARQ FAE (but it's true that it would be a bit long as they are over-specifications on ALE specifications). I don't hear any anyone screaming bloody murder about that.) Multipsk may be a very fine software package but the screen looks like crap. As written previously: You see it cluttered, I see it in perfect order. This GUI corresponds to what I need i.e.: * not to waste time in searching the wished command or to switch of mode or sub-mode (minimum of menus, maximum of buttons, panel of modes...), * always the maximum of information directly available on the screen (many hints, contextual help with right click, QRGs, actual configuration...). I haven't any desire to change anything to this GUI. 73 Patrick - Original Message - From: mailto:[EMAIL PROTECTED] John Becker, WØJAB To: digitalradio@yahoogroups.com Sent: Sunday, March 02, 2008 7:51 PM Subject: Re: [digitalradio] Re: Keeping NBEMS in mind After reading this thread with great intrust I still fail to see the difference between it and what has been done with the Pactor modes. That is other than being narrow. I have copies Pactor that has to say the least been about 2 DB under ESP. As far as FAE400 goes, I would like to try it. Too bad one can only get it from one source. (gee that kind of makes it just like pactor 3. I don't hear any anyone screaming bloody murder about that.) Multipsk may be a very fine software package but the screen looks like crap. Just way way to much un-needed garbage there. Are you listing Patrick ? If it was my software I think I would have a drop down window to pick the mode of operation. And only what was needed for that mode would be on that screen. Yeah I know - that's just my option. Everyone has one. And I'm sitting on mine. John, W0JAB in the center of fly over country
Re: [digitalradio] Re: Keeping NBEMS in mind
- Original Message - From: Rick [EMAIL PROTECTED] To: digitalradio@yahoogroups.com Sent: Sunday, March 02, 2008 12:52 PM Subject: Re: [digitalradio] Re: Keeping NBEMS in mind I can see that some digital modes would not work very well for ARQ that is decoded in real time. MT-63 and MFSK16 both have latency due to their design. I am surprised that MFSK16 was considered, but perhaps this was due to being the most narrow mode that also can work very deep into the noise? Rick, we already had MFSK16 in VBdigi and originally could not use it with ARQ because of the latency you correctly identify. We made it work by adding 10 SOH control characters (allowed by the ARQ specification) to give time for the MFSK16 syncronization to lock in. It is a poor solution, as that additiona slows down the mode even more, but better than nothing when conditions are very poor and it is important to get messages out, even if it takes extra time. Olivia is so very slow relative to the bandwidth, that I would not think of it as a good candidate. The one mode that seems to be a ready made mode for this kind of communication is FAE400 since it already is an ARQ mode and is reasonably narrow for its throughput. This is the best mode I have ever used for an ARQ sound card solution, especially considering how narrow it is for the sensitivity and speed. Alternatively, couldn't the ALE400 mode be incorporated into the NBEMS system since it would then become an ARQ mode, although would work differently than FAE400 and perhaps not as fast? One thing I don't follow completely with Skip is the idea that you need all these signals on one waterfall. I would never tune in a signal very far off from my sweet spot on my rig (varies depending upon rig design) and normally want digital modes to be centered on 1500 Hz in order to be able to use the filtering available to me. It can make a big difference in difficult conditions or when very strong signals or splattering signals are close in. NBEMS does not use an orgarnized army of robots like Winlink does, but depends upon individual hams and emcomm groups to provide forwarding stations. Consider the difficulty of trying to achieve a connect on Winlink. As we discussed, and I pointed out, that sometimes takes as long as 20 minutes. In the recenty MARS Winlink test, as related by Stuart Carter, propagation did not allow connecting locally, and it was necessary to use a PMBO in Utah, so it is easy to realize that one limitation of using approved PMBO robots is the number of robots not currently busy or in range. Assume you have a major hurricane and there are 25 shelters full of people wishing to send health and welfare messages to their friends and family. The existing Winlink network only has about 25 PMBO's in the US, and many of those will not be in range at any given time, or if they are, are busy handling traffic on their primary frequency or on their alternate scanned frequency. The result is that in a real emergency, not just a test, hams that have set up at a shelter for communications will often have to queue up and wait in line to get their messages out. Now, compare that to the NBEMS system, using narrowband modes. As I mentioned previously, as many as 25 separate signals can share the passband of a radio with a SSB filter, meaning that there can be as many as 25 stations at shelters passing traffic at the same time, as long as there are forwarding stations in range to accept the traffic. The NBEMS software is free, and will always be free, and the cost to use the software is no more than the cost of in interface, if you do not already have one. The idea is that this low cost of entry will make it possible for many, many, hams to be prepared to assist in emcomm when called upon. Perhaps, and most likely, the ham locally will be the one who can get to a shelter to help out, and in a widespread emergency, hams outside the disaster area that would like to help simply have to beam toward the disaster area (if on 2m VHF) or monitor the PSK63 watering holes for CQ's to pass traffic with NBEMS software. If this concept, which returns emergency communications back to the hams instead of controlled by an army of robots, is to be successful, the NBEMS software must be as basic and simple as possible just to accomplish the basic NBEMS emcomm task. We have intentionally kept the software that way for the Windows version. If you want more complication, and can handle Linux, fldigi has almost all the popular digital modes, and also works with flarq. It has taken us two man-years to develop the VBdigi/flarq combination just to include the modes we now offer. Sure it would be nice to add even more modes so there are more choices to use on HF, but for the 100 mile range needed for emcomm, the PSK modes on 2m VHF do the job very well, and all the stations calling CQ Emergency Traffic will be found on a single frequency,
[digitalradio] Fw: [multipsk] Test of JT65 on Multipsk / Essai du JT65 sur Multipsk
For important information about JT65 on Multipsk. 73 Patrick you know what Patrick? it works really, really well and can live with the GUI however you want it. TKS John! - Original Message - From: Patrick Lindecker To: [EMAIL PROTECTED] ; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, March 02, 2008 9:29 PM Subject: [multipsk] Test of JT65 on Multipsk / Essai du JT65 sur Multipsk I forgot to precise two points: 1) as JT65 manage many frequencies, it is important and indispensable to autocalibrate the sound card: Sampling freq button (Fréq. échantil. for French users), 2) by default, you use the hard-decision Reed-Solomon decoder. It works down to -24 dB. If you push on the button KVASD decoder which is a soft-decision Reed-Solomon decoder, you will work down to -26 dB but you will have (very rarely) a false decoding. Good tests! 73 Patrick - Original Message - From: Andrew O'Brien To: [EMAIL PROTECTED] Sent: Sunday, March 02, 2008 9:03 PM Subject: Re: [multipsk_team] Test of JT65 on Multipsk / Essai du JT65 sur Multipsk It works ! On Sun, Mar 2, 2008 at 2:55 PM, Andrew O'Brien [EMAIL PROTECTED] wrote: Testing it now Patrick On Sun, Mar 2, 2008 at 2:28 PM, Patrick Lindecker [EMAIL PROTECTED] wrote: Hello all, I have issued a new test version of Multipsk which adds the JT65 mode (RX/TX), for the ones interested by tests. This mode is interesting as it can decode very weak signals down to a S/N=-25 dB (according to my measures and considering a reference noise bandwidth of 3000 Hz, as for the other modes of Multipsk). A 4.8 Multipsk test version in a ZIP test package is available in my site. It contains the Multipsk test version and help files + the KVASD.EXE file. http://f6cte.free.fr/MULTIPSK_TEST_02_03_2008.ZIP Paste this adress in your Internet Explorer or equivalent. Download the file. Create a tempory folder (C:\TEST, for example), unzip the file in it and start C:\TEST\Multipsk.exe (the auxiliary files will be created automatically). I propose a test in JT65A, 14074 KHz USB on the XCVR (AF about 1300 Hz) the next saturday at 11h00 UTC. I will call CQ. Important: the transmission of a JT65 frame must begin one second after the minute with a tolerance on +/-1 sec on the PC clock. So it will be necessary before beginning to do JT65, to set your PC clock to the right time. For help about JT65, click on the right button of the mouse when you are over any button relative to JT65. You can also look at the hints on each button. If you are equipped, you can also try to do EME QSO ( Earth - Moon - Earth ), in VHF and UHF. TKS to report bugs and transmissions done. 73 Patrick ** Here are some information about JT65 Created by: Joseph Taylor (K1JT) in 2004 Description : Baud rate : 2,69 (11025/4096) or 0.372 second by 6 bits symbol Messages : a message of 46.8 seconds duration begins at t=1 sec after the beginning of the UTC minute and lasts until t=47.8 sec (it is necessary that the PC may be synchronised on a standard clock). It is composed of 126 symbols, each one with a lenght of 4096 audio samples (0.372 seconde). 63 carry a synchronization tone at 1270,5 Hz. 63 6 bits symbols carry the message (allowing the Reed-Solomon coding of 72 bits). The 72 bits consist of (non exhaustive): * call 1 (28 bits) + call 2 (28 bits) + 4 characters Locator (15 bits) plus the bit 72 to inform that it is a formatted message, * call 1 + call 2 (+ prefix or ending, example: F6CTE/P or ON/F6CTE) plus the bit 72 to inform that it is a formatted message, * call 1 (+ prefix or suffix, example: F6CTE/P or ON/F6CTE) + call 2 plus the bit 72 to inform that it is a formatted message, * CQ + call + 4 characters Locator plus the bit 72 to inform that it is a formatted message, * plain text: 13 characters Speed : 72 bits (or 13 characters maximum in plain text) by 60 sec period (with only one message by period) or 2,2 wpm ... -- Andy K3UK www.obriensweb.com (QSL via N2RJ) -- Andy K3UK www.obriensweb.com (QSL via N2RJ)
Re: [digitalradio] Re: Keeping NBEMS in mind
and the LATEST beta to the test team has a major surprise ! tease... On Sun, Mar 2, 2008 at 3:21 PM, John Bradley [EMAIL PROTECTED] wrote: you know what Patrick? it works really, really well and can live with the GUI however you want it. John VE5MU From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Patrick Lindecker Sent: Sunday, March 02, 2008 1:59 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Re: Keeping NBEMS in mind Hello John, As far as FAE400 goes, I would like to try it. Too bad one can only get it from one source. (gee that kind of makes it just like pactor 3. Pactor 2 and 3 have private detailed specifications which forbid to even decode them (however it would be impossible to work them in ARQ with a PC) whereas ARQ FAE has public specifications (on my WEB site). Any Ham, in theory, could program ARQ FAE (but it's true that it would be a bit long as they are over-specifications on ALE specifications). I don't hear any anyone screaming bloody murder about that.) Multipsk may be a very fine software package but the screen looks like crap. As written previously: You see it cluttered, I see it in perfect order. This GUI corresponds to what I need i.e.: * not to waste time in searching the wished command or to switch of mode or sub-mode (minimum of menus, maximum of buttons, panel of modes...), * always the maximum of information directly available on the screen (many hints, contextual help with right click, QRGs, actual configuration...). I haven't any desire to change anything to this GUI. 73 Patrick - Original Message - From: John Becker, WØJAB To: digitalradio@yahoogroups.com Sent: Sunday, March 02, 2008 7:51 PM Subject: Re: [digitalradio] Re: Keeping NBEMS in mind After reading this thread with great intrust I still fail to see the difference between it and what has been done with the Pactor modes. That is other than being narrow. I have copies Pactor that has to say the least been about 2 DB under ESP. As far as FAE400 goes, I would like to try it. Too bad one can only get it from one source. (gee that kind of makes it just like pactor 3. I don't hear any anyone screaming bloody murder about that.) Multipsk may be a very fine software package but the screen looks like crap. Just way way to much un-needed garbage there. Are you listing Patrick ? If it was my software I think I would have a drop down window to pick the mode of operation. And only what was needed for that mode would be on that screen. Yeah I know - that's just my option. Everyone has one. And I'm sitting on mine. John, W0JAB in the center of fly over country -- Andy K3UK www.obriensweb.com (QSL via N2RJ)
[digitalradio] Re: [multipsk] Test of JT65 on Multipsk / Essai du JT65 sur Multipsk
Hi Patrick! This was great news! I am ready for testing form 160m to 10m . Calling on 14074 right now . 73 de LA5VNA Steinar Patrick Lindecker skrev: Hello all, I have issued a new test version of Multipsk which adds the JT65 mode (RX/TX), for the ones interested by tests. This mode is interesting as it can decode very weak signals down to a S/N=-25 dB (according to my measures and considering a reference noise bandwidth of 3000 Hz, as for the other modes of Multipsk). A 4.8 Multipsk test version in a ZIP test package is available in my site. It contains the Multipsk test version and help files + the KVASD.EXE file. http://f6cte.free.fr/MULTIPSK_TEST_02_03_2008.ZIP http://f6cte.free.fr/MULTIPSK_TEST_02_03_2008.ZIP Paste this adress in your Internet Explorer or equivalent. Download the file. Create a tempory folder (C:\TEST, for example), unzip the file in it and start C:\TEST\Multipsk.exe (the auxiliary files will be created automatically). I propose a test in JT65A, 14074 KHz USB on the XCVR (AF about 1300 Hz) the next saturday at 11h00 UTC. I will call CQ. __ _Important_: the transmission of a JT65 frame must begin one second after the minute with a tolerance on +/-1 sec on the PC clock. *So it will be necessary before beginning to do JT65, to set your PC clock to the right time. * For help about JT65, click on the right button of the mouse when you are over any button relative to JT65. You can also look at the hints on each button. If you are equipped, you can also try to do EME QSO ( Earth - Moon - Earth ), in VHF and UHF. TKS to report bugs and transmissions done. 73 Patrick ** Here are some information about JT65 __ _Created by_: Joseph Taylor (K1JT) in 2004 _ Description : _ Baud rate : 2,69 (11025/4096) or 0.372 second by 6 bits symbol Messages : a message of 46.8 seconds duration begins at t=1 sec after the beginning of the UTC minute and lasts until t=47.8 sec (it is necessary that the PC may be synchronised on a standard clock). It is composed of 126 symbols, each one with a lenght of 4096 audio samples (0.372 seconde). 63 carry a synchronization tone at 1270,5 Hz. 63 6 bits symbols carry the message (allowing the Reed-Solomon coding of 72 bits). The 72 bits consist of (non exhaustive): * call 1 (28 bits) + call 2 (28 bits) + 4 characters Locator (15 bits) plus the bit 72 to inform that it is a formatted message, * call 1 + call 2 (+ prefix or ending, example: F6CTE/P or ON/F6CTE) plus the bit 72 to inform that it is a formatted message, * call 1 (+ prefix or suffix, example: F6CTE/P or ON/F6CTE) + call 2 plus the bit 72 to inform that it is a formatted message, * CQ + call + 4 characters Locator plus the bit 72 to inform that it is a formatted message, * plain text: 13 characters Speed : 72 bits (or 13 characters maximum in plain text) by 60 sec period (with only one message by period) or 2,2 wpm ... No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.21.3/1306 - Release Date: 3/1/2008 5:41 PM
Re: [digitalradio] Re: Keeping NBEMS in mind
I earlier mentioned ARQ in real time, but if you use the programming technique that KN6KB used when he developed SCAMP, (Sound Card Amateur Messaging Protocol), he used RDFT. While this was not practical to decode during each cycle, he was able to work in the background with the past packet that was received and do the necessary processing. This almost completely avoids any issues with latency, unless the latency exceeds the cycle time. I suspect that someday this will be the approach taken for the newest sound card modes. Before he came up with this technology, others were basically saying it could not be done. But he did figure out a sophisticated way to do it. One other thing that Pactor modes have proven rather well to me, is that a two tone system, separated by some distance will give you one of the most robust modes possible by adding in some redundancy/FEC, etc. In my location, there is no misconception about working close to the atmospheric noise level. Right now on my ICOM 756 Pro 2, the S meter readings are: Preamp off: 160 S-1, 80 S0, 40 S0 to S4 due to static crashes from storm, 30 same as 40, 20 S0 Preamp on at maximum (second step): 17 meter through 6 meters S0 With better antennas, this would be stronger on the higher bands and with more propagation. Of course I sometimes have a locale RFI problem (TV, and something else that I have not figured out on the lower bands). Typically, my main loss of contact with other stations (not including Pactor or wide mode ALE signals coming on top of my frequency) is because they fade into the noise. And QSB can be difficult unless you have an ARQ mode. I have seen some multiipath, especially when I have tested PSK31 on VHF, but much of that was from aircraft. I am not sure how I can discern multipath when on HF. Is there any clue in the waterfall or do you go by the sound? 73, Rick, KV9U Rein Couperus wrote: All high-latency modes are unsuitable for ARQ. A persistent misconception is that you would be using signals near the noise level. As I have stated many times, noise is hardly ever the problem unless it is S8. The problem is multi-path causing QSB (up to 80 dB on path we are using) and QRM from other stations firing up their gear on top of your QSO. PSkmail arq takes care of this very well by repeating the stuff that has been unreadable in the qsb. QRN is taken care of by automatically shortening of the packets when the error rate goes up, which decreases the chance of a packet being hit. Again, noise is seldom the problem, we pick a better path if necessary, depending on time of day. Signal levels are normally around S5-S9 here in EU, depending on time/distance. Announce your digital presence via our Interactive Sked Page at http://www.obriensweb.com/sked Check our other Yahoo Groups http://groups.yahoo.com/group/dxlist/ http://groups.yahoo.com/group/contesting http://groups.yahoo.com/group/themixwgroup Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/digitalradio/ * Your email settings: Individual Email | Traditional * To change settings online go to: http://groups.yahoo.com/group/digitalradio/join (Yahoo! ID required) * To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: [digitalradio] Re: Keeping NBEMS in mind
I have seen some multiipath, especially when I have tested PSK31 on VHF, but much of that was from aircraft. I am not sure how I can discern multipath when on HF. Is there any clue in the waterfall or do you go by the sound? 73, Rick, KV9U You will see three kinds of multipath on VHF, which you can see on the waterfall. One is reflections from airplanes, which tends to look like a ghost signal accelerating across the main signal. When it coincides with the main signal, all copy will be momentarily lost, no matter how strong the signal. The second correlates with wind conditions, and the ghost signal moves slightly in and out of the main signal during wind gusts, especially when a weather front is moving through. The third is reflections from fixed objects, and the ghost signal tends to stay a fixed distance away from the main signal. PSK63 is less affected by multipath reflections than PSK31 is on VHF, and PSK125 even less so. When cancellation does occur, if you are using ARQ, that frame is just resent and the transfer is delayed by that much. Of course, only ARQ is going to guarantee error-free copy. FEC only helps, but does not insure no errors. QRN seems to be the biggest problem on HF and QSB second. During a period of thunderstorm activity, as we often have in South Carolina, and more especially in Florida, PSK125 is greatly disturbed and PSK250 so much that it is unusable, but PSK63 not nearly as much. All the decoders seem to have this problem, and there may be a way to improve that cascaded loss of sync in the faster modes, due to QRN, but we have not yet tackled this problem. Fortunately, for our 100 mile emcomm uses, QRN and QSB are not problems on VHF, and ARQ takes care of the multipath reflection problem. 73, Skip KH6TY Announce your digital presence via our Interactive Sked Page at http://www.obriensweb.com/sked Check our other Yahoo Groups http://groups.yahoo.com/group/dxlist/ http://groups.yahoo.com/group/contesting http://groups.yahoo.com/group/themixwgroup Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/digitalradio/ * Your email settings: Individual Email | Traditional * To change settings online go to: http://groups.yahoo.com/group/digitalradio/join (Yahoo! ID required) * To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: [digitalradio] Re: Keeping NBEMS in mind
I earlier mentioned ARQ in real time, but if you use the programming technique that KN6KB used when he developed SCAMP, (Sound Card Amateur Messaging Protocol), he used RDFT. While this was not practical to decode during each cycle, he was able to work in the background with the past packet that was received and do the necessary processing. In pskmail the receiver tells the sender what to send next. This is necessary to prepend missing blocks to the next frame. This way you can realize a full duplex k-to-k mode. When downloading a file on a good channel you send 8 blocks x 64 = 512 characters in a frame before you listen for the ack. At PSK250 this is faster than reading speed. I have seen some multiipath, especially when I have tested PSK31 on VHF, but much of that was from aircraft. I am not sure how I can discern multipath when on HF. Is there any clue in the waterfall or do you go by the sound? You see it in the phase indicator and in the quality indicator (horizontal bar below the phase indicator). Typically happens when F1 and F2 propagation takes place simultaneously, especially in mountainous areas. At home I live near Eindhoven airport and the airplane echo doppler also happens on 30 meters. You don't see it on the S-meter, but the 2 signals corrupt the phase completely which is visible on the quality indicator. At this moment IS0GRB-3 is still S8 on 10148.25, noise (from switching power supplies in neighbouring campers) is S5, with peaks to S9+10. Fldigi log: RX (2008-03-02 22:02Z): - 2eUSSOH00uIS0GRB-3:72 Pskmail Server v.0.5.4.1 -Cagliari (Sardinia IT) RX (2008-03-02 22:03Z): - 22:03:02 18FAEOT TX (2008-03-02 22:07Z): USSOH00uPA0R:26 185CEOT RX (2008-03-02 22:07Z): USSOHQSL PA0R de IS0GRB-3EOT RX (2008-03-02 22:09Z): USSOH0kIS0GRB-3:24 DB3CF:1024 5AE26EOT RX (2008-03-02 22:09Z): USSOH0p E5FEEOT error-free channel at the moment. The other 3 servers are now gone completely. 73, Rein EA/PA0R/P -- http://pa0r.blogspirit.com Announce your digital presence via our Interactive Sked Page at http://www.obriensweb.com/sked Check our other Yahoo Groups http://groups.yahoo.com/group/dxlist/ http://groups.yahoo.com/group/contesting http://groups.yahoo.com/group/themixwgroup Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/digitalradio/ * Your email settings: Individual Email | Traditional * To change settings online go to: http://groups.yahoo.com/group/digitalradio/join (Yahoo! ID required) * To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
RE: [digitalradio] Re: Keeping NBEMS in mind
This may be true at lower latitudes, but up here at 50 degrees north, we get sustained aurora flutter or Doppler on HF and VHF. Sometimes the audio has a distinct echo. PSK125 and 250 are worse. we do have days where we have strong signals but cannot decode anything. it would be nice to have something a little faster than regular MFSK for a robust mode John VE5MU -Original Message- From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of kh6ty Sent: Sunday, March 02, 2008 4:18 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Re: Keeping NBEMS in mind I have seen some multiipath, especially when I have tested PSK31 on VHF, but much of that was from aircraft. I am not sure how I can discern multipath when on HF. Is there any clue in the waterfall or do you go by the sound? 73, Rick, KV9U You will see three kinds of multipath on VHF, which you can see on the waterfall. One is reflections from airplanes, which tends to look like a ghost signal accelerating across the main signal. When it coincides with the main signal, all copy will be momentarily lost, no matter how strong the signal. The second correlates with wind conditions, and the ghost signal moves slightly in and out of the main signal during wind gusts, especially when a weather front is moving through. The third is reflections from fixed objects, and the ghost signal tends to stay a fixed distance away from the main signal. PSK63 is less affected by multipath reflections than PSK31 is on VHF, and PSK125 even less so. When cancellation does occur, if you are using ARQ, that frame is just resent and the transfer is delayed by that much. Of course, only ARQ is going to guarantee error-free copy. FEC only helps, but does not insure no errors. QRN seems to be the biggest problem on HF and QSB second. During a period of thunderstorm activity, as we often have in South Carolina, and more especially in Florida, PSK125 is greatly disturbed and PSK250 so much that it is unusable, but PSK63 not nearly as much. All the decoders seem to have this problem, and there may be a way to improve that cascaded loss of sync in the faster modes, due to QRN, but we have not yet tackled this problem. Fortunately, for our 100 mile emcomm uses, QRN and QSB are not problems on VHF, and ARQ takes care of the multipath reflection problem. 73, Skip KH6TY Announce your digital presence via our Interactive Sked Page at http://www.obriensweb.com/sked Check our other Yahoo Groups http://groups.yahoo.com/group/dxlist/ http://groups.yahoo.com/group/contesting http://groups.yahoo.com/group/themixwgroup Yahoo! Groups Links -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.21.3/1306 - Release Date: 3/1/2008 5:41 PM
Re: [digitalradio] Re: Keeping NBEMS in mind
John, Over what distance are you getting flutter or Doppler on VHF? I only get the flutter (usually all the time!) when I try to work Charlotte, NC from Charleston, SC on 70 cm, which is 173 miles away, but I am not far enough north for Aurora. For emcomm, we only need to span up to 100 miles. I am interested to know if you also find flutter on VHF within 100 miles. Skip KH6TY - Original Message - From: John Bradley [EMAIL PROTECTED] To: digitalradio@yahoogroups.com Sent: Sunday, March 02, 2008 9:30 PM Subject: RE: [digitalradio] Re: Keeping NBEMS in mind This may be true at lower latitudes, but up here at 50 degrees north, we get sustained aurora flutter or Doppler on HF and VHF. Sometimes the audio has a distinct echo. PSK125 and 250 are worse. we do have days where we have strong signals but cannot decode anything. it would be nice to have something a little faster than regular MFSK for a robust mode John VE5MU -Original Message- From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of kh6ty Sent: Sunday, March 02, 2008 4:18 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Re: Keeping NBEMS in mind I have seen some multiipath, especially when I have tested PSK31 on VHF, but much of that was from aircraft. I am not sure how I can discern multipath when on HF. Is there any clue in the waterfall or do you go by the sound? 73, Rick, KV9U You will see three kinds of multipath on VHF, which you can see on the waterfall. One is reflections from airplanes, which tends to look like a ghost signal accelerating across the main signal. When it coincides with the main signal, all copy will be momentarily lost, no matter how strong the signal. The second correlates with wind conditions, and the ghost signal moves slightly in and out of the main signal during wind gusts, especially when a weather front is moving through. The third is reflections from fixed objects, and the ghost signal tends to stay a fixed distance away from the main signal. PSK63 is less affected by multipath reflections than PSK31 is on VHF, and PSK125 even less so. When cancellation does occur, if you are using ARQ, that frame is just resent and the transfer is delayed by that much. Of course, only ARQ is going to guarantee error-free copy. FEC only helps, but does not insure no errors. QRN seems to be the biggest problem on HF and QSB second. During a period of thunderstorm activity, as we often have in South Carolina, and more especially in Florida, PSK125 is greatly disturbed and PSK250 so much that it is unusable, but PSK63 not nearly as much. All the decoders seem to have this problem, and there may be a way to improve that cascaded loss of sync in the faster modes, due to QRN, but we have not yet tackled this problem. Fortunately, for our 100 mile emcomm uses, QRN and QSB are not problems on VHF, and ARQ takes care of the multipath reflection problem. 73, Skip KH6TY Announce your digital presence via our Interactive Sked Page at http://www.obriensweb.com/sked Check our other Yahoo Groups http://groups.yahoo.com/group/dxlist/ http://groups.yahoo.com/group/contesting http://groups.yahoo.com/group/themixwgroup Yahoo! Groups Links -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.21.3/1306 - Release Date: 3/1/2008 5:41 PM No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.21.3/1306 - Release Date: 3/1/2008 5:41 PM
Re: [digitalradio] Re: Keeping NBEMS in mind
Yes you must buy a box to play the mode. What did you do before the sound card? Maybe watch your corn grow. As far as the email comment, I can tell you have not seen to much if any of the pactor or packet traffic of late. Just going on what other have said. John At 01:30 PM 3/2/2008, you wrote: John, The difference is HUGE! Pactor is a proprietary mode and the primary use is for radio e-mail.
RE: [digitalradio] Re: Keeping NBEMS in mind
on occasion less than 100 miles on VHF and sometimes as little as 30 miles on 80M HF I disagree with the assumption that for Emcomms we only need span 100 miles. That may be true in higher population areas, and where the state is broken down into counties. Up here we will be working into provincial EOC's, which could be up to 500km away (300 Miles), too far for VHF point to point. Furthermore we don't have the density of hams in the rural areas which we allow for relay points. We have good cellular coverage along our highways, but once off the major roads rural cellular service is very spotty. Internet access via cellular to pass text messages cannot be relied upon, so that throws us back to HF as the most likely link (besides sat Phone) I really don't understand the restrictions that you have in the USA on baud rate and mode restrictions. Your mode works well but would be wonderful a little faster. RFSM 8000 works well, but is wide, and am still not sure how it will work under poor HF conditions. ALE400 works well into the weeds, and it would be great to see you and Patrick team up to combine NBEMS and Ale400 in one package. John VE5MU From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of kh6ty Sent: Sunday, March 02, 2008 9:13 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Re: Keeping NBEMS in mind John, Over what distance are you getting flutter or Doppler on VHF? I only get the flutter (usually all the time!) when I try to work Charlotte, NC from Charleston, SC on 70 cm, which is 173 miles away, but I am not far enough north for Aurora. For emcomm, we only need to span up to 100 miles. I am interested to know if you also find flutter on VHF within 100 miles. Skip KH6TY - Original Message - From: John Bradley [EMAIL PROTECTED] mailto:jbradley%40sasktel.net To: digitalradio@yahoogroups.com mailto:digitalradio%40yahoogroups.com Sent: Sunday, March 02, 2008 9:30 PM Subject: RE: [digitalradio] Re: Keeping NBEMS in mind This may be true at lower latitudes, but up here at 50 degrees north, we get sustained aurora flutter or Doppler on HF and VHF. Sometimes the audio has a distinct echo. PSK125 and 250 are worse. we do have days where we have strong signals but cannot decode anything. it would be nice to have something a little faster than regular MFSK for a robust mode John VE5MU -Original Message- From: digitalradio@yahoogroups.com mailto:digitalradio%40yahoogroups.com [mailto:digitalradio@yahoogroups.com mailto:digitalradio%40yahoogroups.com ] On Behalf Of kh6ty Sent: Sunday, March 02, 2008 4:18 PM To: digitalradio@yahoogroups.com mailto:digitalradio%40yahoogroups.com Subject: Re: [digitalradio] Re: Keeping NBEMS in mind I have seen some multiipath, especially when I have tested PSK31 on VHF, but much of that was from aircraft. I am not sure how I can discern multipath when on HF. Is there any clue in the waterfall or do you go by the sound? 73, Rick, KV9U You will see three kinds of multipath on VHF, which you can see on the waterfall. One is reflections from airplanes, which tends to look like a ghost signal accelerating across the main signal. When it coincides with the main signal, all copy will be momentarily lost, no matter how strong the signal. The second correlates with wind conditions, and the ghost signal moves slightly in and out of the main signal during wind gusts, especially when a weather front is moving through. The third is reflections from fixed objects, and the ghost signal tends to stay a fixed distance away from the main signal. PSK63 is less affected by multipath reflections than PSK31 is on VHF, and PSK125 even less so. When cancellation does occur, if you are using ARQ, that frame is just resent and the transfer is delayed by that much. Of course, only ARQ is going to guarantee error-free copy. FEC only helps, but does not insure no errors. QRN seems to be the biggest problem on HF and QSB second. During a period of thunderstorm activity, as we often have in South Carolina, and more especially in Florida, PSK125 is greatly disturbed and PSK250 so much that it is unusable, but PSK63 not nearly as much. All the decoders seem to have this problem, and there may be a way to improve that cascaded loss of sync in the faster modes, due to QRN, but we have not yet tackled this problem. Fortunately, for our 100 mile emcomm uses, QRN and QSB are not problems on VHF, and ARQ takes care of the multipath reflection problem. 73, Skip KH6TY Announce your digital presence via our Interactive Sked Page at http://www.obriensweb.com/sked Check our other Yahoo Groups http://groups.yahoo.com/group/dxlist/ http://groups.yahoo.com/group/contesting http://groups.yahoo.com/group/themixwgroup Yahoo! Groups Links -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus
Re: [digitalradio] Re: Keeping NBEMS in mind
It is precisely because of the sound card that we no longer buy expensive boxes, cards, etc. When I got back into ham radio in 1980, it was not long before I found that I enjoyed the digital modes. When I moved from our first farm back to the city, I was very surprised to see one local ham who I had known when I was first licensed back in 1963, who was operating RTTY ... but on VHF! I had no idea such a thing was done. We had a regular local group with a regenerative repeater. Most of us used very simple TU's along with homebrew loop supplies to run our Model 15's, 19's, 33's, etc. I made a homebrew XR chip design I think I have discussed before, that was really only decoding one tone on RTTY to my Model 15. Then enter the computer and everything changed. I used a number of different types of interfaces, including the Commodore 64 MBA-TOR software, the Kantronics UTU, the AEA CP-1 plus the BMK-Multy software. Then I had to make the big decision. Would it be HAL or SCS? I went with HAL, and spent what would today be probably around the price of the SCS boxes. HAL had serious problems trying to clone Pactor with their first attempt with the P-38 card. It never worked right for me as it would link and then drop the link with no warning. They kept promising they would fix the software and I was basically being an Alpha tester for them as they sent several updates. But they never worked for Pactor. Clover II was OK, but even that mode could not handle the weak signals that we now can handle with sound card modes. I eventually gave up on them, returned their defective digital hardware/software solution and only was given back 80% of my money due to their restocking fee. Needless to say HAL is NOT on my list of approved vendors! And since I had sold all my other equipment to partially pay for the HAL product so digital HF modes were off line for a number of years. It was not until sound card modes became available that I ventured back into the digital HF world. In the meantime, packet radio had peaked and was dying out as a networked system. Today things are quite amazing to me, considering the quality of freely available software (not just digital or even ham software, but in general with the movement to free and open source) and the new modes. It is the best time ever for those of us interested in this kind of technology. You never run out of things to do. As far as corn, we stopped growing it some years ago, although our small 150 acre farming operation does have a corn base. There is still some subsidies for that but with the markets the way they have been, there is no LDP anymore for corn farmers. Judy, N9LGV, and I still handle a small number of dairy heifers each summer on what is now a strictly grazing farm. Even at the peak, we generally have no more than 100 head of dairy cattle here during the grazing season. Typically we will have some very small weaned calves that do require grain as well as pasture, then some breeding age heifers, and we do promote bringing in dry cows if they are not close up which as you probably can imagine is a problem with shipping. We no longer direct market our specialty beef products to the public, but of course we have them for ourselves and family. We do still sell a few pumpkins and berries, that sort of thing, but no farmer's markets anymore. We have worked out a pretty good arrangement for pasture based farming and if you or others stop by we are always happy to give you a tour. I have had several dairy farmers stop by that I have met via the internet discussion groups (I still co-moderate the Grazersedge yahoogroup) and one was from Washington and most surprisingly one was from NZ. So you never know who you might be able to meet in person someday:) 73, Rick, KV9U John Becker, WØJAB wrote: Yes you must buy a box to play the mode. What did you do before the sound card? Maybe watch your corn grow. As far as the email comment, I can tell you have not seen to much if any of the pactor or packet traffic of late. Just going on what other have said. John
