Re: [digitalradio] Re: Keeping NBEMS in mind
Nice store Rick. Enjoyed reading it. I for one never did give up on the black boxes. Still have all 5 of them. Going back to the first one (PK-232MBX) that was about 1986 or 1987. I even still have the G3PLX board for Amtor when I jumped into that band wagon. That was my first non RTTY digital mode. Using a Kenwood TS-520 (no S or anything) and still using that 520 with both the 28 machines. My main HAM computer still runs DOS 6.22 with no sound card. does every thing I need it do, running TNC's, controlling the satellites antennas and the FT-847. I use a dell laptop with the 2 sound card modes that I do operate (HELL MT63). Never did take a liking to PSK-31. Like a ARQ QSO? You can find me on almost any evening sitting on 7078.9 center frequency. Andy - next time you fire up on MT63 let me know. Sorry I missed you the other night. John, W0JAB At 11:10 PM 3/2/2008, you wrote: 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
Re: [digitalradio] Re: Keeping NBEMS in mind
John, Our NBEMS for Linux now supports DominoEX-11, DominoEX-16, and DominoEX-22 with ARQ. You might want to experiment with using DominoEx to combat flutter. However, I suggest that yhou disable the AFC on fldigi to keep random noise from dragging the receive frequency around. DominoEX is very tolerant to mistuning, and seems to work well without AFC, even on 2m. In order to compensate for the latency of DominoEx and MFSK16, we have added 9 additional SOH characters to the beginning of each transmission, which is allowed under the ARQ specification, so DominoEx modes will only work under ARQ with the NBEMS flarq program. The comparisons for a 3.3K text file transfer on VHF are: MFSK16: 724 sec PSK63: 403 sec DominoEx16: 378 sec DominoEx22: 276 sec PSK125: 207 sec PSK250: 120 sec Winlink average on HF (Pactor-3) for a 3.3K file: about 224 sec For comparison, Patrick's numbers for his Domino (DF), which is probably DominoEx-8, is -12 db for the lowest S/N. For PSK63, it is -7 dB. For PSK125 it is -5 dB. For MFSK16, it is -13.5 dB. So, the advantage in using DominoEx will mostly be to counter flutter and mistuning. MFSK16 will still hold up the best under deep QSB fades, but is slower and harder to tune. You can download the NBEMS EMCpup ISO from this link: http://www.w1hkj.com/emcpup.html . Just burn a bootable CD and try DominoEx with flarq on a Windows system by booting with the CD and running it live to compare, but you will need someone else also using EMCpup or NBEMS on Linux to test with. Since you will probably be testing on HF, there is probably someone on this list already set up to test with. In fact, I can do it with you on HF. We would be very interested in any results you come up with. 73, Skip NBEMS Development Team - Original Message - From: John Bradley [EMAIL PROTECTED] To: digitalradio@yahoogroups.com Sent: Sunday, March 02, 2008 10:45 PM Subject: 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
RE: [digitalradio] Re: Keeping NBEMS in mind
Thanks for the info I have had absolutely no luck with linux, so will wait for a windows update. John VE5MU From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of kh6ty Sent: Monday, March 03, 2008 9:46 AM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Re: Keeping NBEMS in mind John, Our NBEMS for Linux now supports DominoEX-11, DominoEX-16, and DominoEX-22 with ARQ. You might want to experiment with using DominoEx to combat flutter. However, I suggest that yhou disable the AFC on fldigi to keep random noise from dragging the receive frequency around. DominoEX is very tolerant to mistuning, and seems to work well without AFC, even on 2m. In order to compensate for the latency of DominoEx and MFSK16, we have added 9 additional SOH characters to the beginning of each transmission, which is allowed under the ARQ specification, so DominoEx modes will only work under ARQ with the NBEMS flarq program. The comparisons for a 3.3K text file transfer on VHF are: MFSK16: 724 sec PSK63: 403 sec DominoEx16: 378 sec DominoEx22: 276 sec PSK125: 207 sec PSK250: 120 sec Winlink average on HF (Pactor-3) for a 3.3K file: about 224 sec For comparison, Patrick's numbers for his Domino (DF), which is probably DominoEx-8, is -12 db for the lowest S/N. For PSK63, it is -7 dB. For PSK125 it is -5 dB. For MFSK16, it is -13.5 dB. So, the advantage in using DominoEx will mostly be to counter flutter and mistuning. MFSK16 will still hold up the best under deep QSB fades, but is slower and harder to tune. You can download the NBEMS EMCpup ISO from this link: http://www.w1hkj.com/emcpup.html . Just burn a bootable CD and try DominoEx with flarq on a Windows system by booting with the CD and running it live to compare, but you will need someone else also using EMCpup or NBEMS on Linux to test with. Since you will probably be testing on HF, there is probably someone on this list already set up to test with. In fact, I can do it with you on HF. We would be very interested in any results you come up with. 73, Skip NBEMS Development Team - Original Message - From: John Bradley [EMAIL PROTECTED] mailto:jbradley%40sasktel.net To: digitalradio@yahoogroups.com mailto:digitalradio%40yahoogroups.com Sent: Sunday, March 02, 2008 10:45 PM Subject: 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:digitalradio%40yahoogroups.com [mailto:digitalradio@yahoogroups.com mailto:digitalradio%40yahoogroups.com ] On Behalf Of kh6ty Sent: Sunday, March 02, 2008 9:13 PM To: digitalradio@yahoogroups.com mailto:digitalradio%40yahoogroups.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 mailto:jbradley%40sasktel.net To: digitalradio@yahoogroups.com mailto:digitalradio%40yahoogroups.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
Re: [digitalradio] Re: Keeping NBEMS in mind
Not only are EOC's that far away, but when a hurricane hits the Gulf Coast, you can have all communications interrupted for much more than 100 miles. 73, Walt/K5YFW John Bradley wrote: 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
Re: [digitalradio] Re: Keeping NBEMS in mind
In that case, it will be necessary to switch to HF and use NVIS antennas, which extends the range to 300 miles but with somewhat less throughput using ARQ due to static crashes. Using ARQ will still get the messages through without errors - it just takes longer. 73, Skip KH6TY Not only are EOC's that far away, but when a hurricane hits the Gulf Coast, you can have all communications interrupted for much more than 100 miles. 73, Walt/K5YFW
Re: [digitalradio] Re: Keeping NBEMS in mind
Skip, We do plan on using HD, NVIS antennas and data modes as long as they are faster than I can receive CW (about 15 WPM accurately. The noise level is what is so high after a hurricane...and it stays that way for 2-4 days. Walt/K5YFW kh6ty wrote: In that case, it will be necessary to switch to HF and use NVIS antennas, which extends the range to 300 miles but with somewhat less throughput using ARQ due to static crashes. Using ARQ will still get the messages through without errors - it just takes longer. 73, Skip KH6TY Not only are EOC's that far away, but when a hurricane hits the Gulf Coast, you can have all communications interrupted for much more than 100 miles. 73, Walt/K5YFW
Re: [digitalradio] Re: Keeping NBEMS in mind
Walt, Give DominoEx-22 or DominoEX-16 a try. Speed will probably a litttle less than using Pactor-3. Running Emcpup live is pretty simple. You don't even need to know anything about Linux. Patrick includes all the Domino modes in Multipsk and you can try DominoEx under Windows, but without ARQ. When using ARQ, the throughput will be about half as much as without ARQ, but there will be no errors. As Rein says, the big problem on HF is not S/N (on VHF it is S/N and multipath reflections), but QRN and QRM, so you might find that DominoEx works pretty well in the presence of QRN, but I have not had an opportunity to find out myself. The DominoEx website says that it has been optimized for NVIS propagation. NVIS antennas on both ends should help reduce the static noise level, since the takeoff angles of NVIS antennas are very high, but noise generally arrives at a low angle. I can demonstrate the difference here, since I have both NVIS and regular 80m antennas. I have found around 2 S-units of static noise reduction using the NVIS antenna. 73, Skip KH6TY We do plan on using HD, NVIS antennas and data modes as long as they are faster than I can receive CW (about 15 WPM accurately. The noise level is what is so high after a hurricane...and it stays that way for 2-4 days. Walt/K5YFW
[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] 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
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] 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
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
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)
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
