Re: [digitalradio] RE:Packet radio with sound card
Rick, You have a point. I did not stop to think about the possibility of multicast fills. 73, Jose, CO2JA -- Rick W wrote: Hi Jose, The advantage of using manual ARQ fills after the transmission of the data, is that it can be used as a one to many transmission. If any stations did not receive the data perfectly, they can send a request to repair defective portions. This is not possible with a handshaking type connection. Ideally, you would be able to do it either way. The main advantage of Pactor, Clover II and Gtor were the ability to make some changes in the speed and modulation in order to more closely match the path conditions. SCAMP could do this within a narrow limit, but it was not capable of working down to the weak signal level that the developer had expected, which was around zero dB SNR. Instead, it was closer to perhaps ~ +8 dB and needed to have a slower (more robust) mode to compete at all with Pactor. It is hard to believe that 4 years have gone by since we started beta testing SCAMP, but better something late than never. In the meantime, no one else was able to come up with an adaptive mode suitable for amateur use, so this could be the next big thing ... 73, Rick, KV9U Jose A. Amador wrote: I can understand that procedure in sake of simplicity, but hardly an efficient one. Obviously, ARQ should be automatic. VI Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética 9 - 12 de Junio 2009, Palacio de las Convenciones ...Por una cultura energética sustentable www.ciercuba.com
Re: [digitalradio] RE:Packet radio with sound card
Rick , Just on a side note, yep I have dabbled on HF packet, just connecting to european nodes etc. Never had much success, I'd have thought NVIS on 80m be quite good. Anyway there are some promising HF sound card ARQ modes coming out at the moment, Like psk mail and flarq for FL digi (even windoze version). Surly some of these ARQ modes could be implemented into a local BBS system somehow. Just thinking out loud. Regards Merry Xmas everyone from Dark Winter Scotland. Toby MM0TOB ---Original Message--- From: Rick W Date: 17/12/2008 14:59:31 To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] RE:Packet radio with sound card Similary, I have used Multipsk's packet modes on both HF and VHF with Success. With the advance of technology, I moved away from packet around 15 years ago! It is just not robust enough for HF and can only go a Short distance on VHF, compared with newer modes What seems like an unfulfilled need is a framework similar to packet, With the ability to insert different modes as they are developed. You Would not have to keep inventing the wheel over and over. This would mostly have practical value for groups that want to set up a BBS system. For example, I have monitored the packets on an 80 meter BBS Here in my state where most of the transmissions are retries. And this Is during the day under NVIS conditions. A much more robust mode needs To be used. Then you would be able to send and receive direct or time Shifted messages. This is the one thing we can not do with any other System, but there does not seem to be any interest in developing such a System. At this time, it is true that a slower baud rate packet system could be Used, such as the software 110 baud speed available in Multipsk. This is Why hardware packet TNC's are a poor choice for our advancing technology And why almost no one uses them anymore. You are locked into a mode Developed over 30 years ago with no FEC or ability to be adaptive for Conditions. And yet, I admit that if you want a BBS system today, what Other choices do you have? 73, Rick, KV9U Bev Jerry Chambers wrote: I have used MixW for packet, both on 2 meters and on HF and found it to work fine. Jerry - W6LQR __ Plan ahead with a quick and convenient rental car. Click now. http://thirdpartyoffers.Juno com/TGL2142/fc/PnY6rw2i4Kl14diV4YFfqj9NVa0ZLTLXxwC4c6Z897wGFONyq2THo/ -- No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.9.19/1853 - Release Date: 12/17/2008 8:31 AM
Re: [digitalradio] RE:Packet radio with sound card (thanks to all)
Thanks for your input, I do have MultiPSK and will look into as well I will look into MixW, Yes to your responces with all the other modes provided from other programs, However I am looking at Satelitte Packet 1200 , So tnx agn 73 Russell = IN GOD WE TRUST ! = Russell Blair (NC5O) Skype-Russell.Blair Hell Field #300 DRCC #55 30m Dig-group #693 --- On Wed, 12/17/08, Rick W mrf...@frontiernet.net wrote: From: Rick W mrf...@frontiernet.net Subject: Re: [digitalradio] RE:Packet radio with sound card To: digitalradio@yahoogroups.com Date: Wednesday, December 17, 2008, 8:58 AM Similary, I have used Multipsk's packet modes on both HF and VHF with success. With the advance of technology, I moved away from packet around 15 years ago! It is just not robust enough for HF and can only go a short distance on VHF, compared with newer modes What seems like an unfulfilled need is a framework similar to packet, with the ability to insert different modes as they are developed. You would not have to keep inventing the wheel over and over. This would mostly have practical value for groups that want to set up a BBS system. For example, I have monitored the packets on an 80 meter BBS here in my state where most of the transmissions are retries. And this is during the day under NVIS conditions. A much more robust mode needs to be used. Then you would be able to send and receive direct or time shifted messages. This is the one thing we can not do with any other system, but there does not seem to be any interest in developing such a system. At this time, it is true that a slower baud rate packet system could be used, such as the software 110 baud speed available in Multipsk. This is why hardware packet TNC's are a poor choice for our advancing technology and why almost no one uses them anymore. You are locked into a mode developed over 30 years ago with no FEC or ability to be adaptive for conditions. And yet, I admit that if you want a BBS system today, what other choices do you have? 73, Rick, KV9U Bev Jerry Chambers wrote: I have used MixW for packet, both on 2 meters and on HF and found it to work fine. Jerry - W6LQR _ _ _ _ _ _ Plan ahead with a quick and convenient rental car. Click now. http://thirdpartyof fers.juno. com/TGL2142/ fc/PnY6rw2i4Kl14 diV4YFfqj9NVa0ZL TLXxwC4c6Z897wGF ONyq2THo/ - - - - - - No virus found in this incoming message. Checked by AVG - http://www.avg. com Version: 8.0.176 / Virus Database: 270.9.19/1853 - Release Date: 12/17/2008 8:31 AM
Re: [digitalradio] RE:Packet radio with sound card
The closer you are to the MUF with a path between two points often results in the most stable path. That is why HF packet worked well during peak times of the sunspot cycle where higher frequencies, especially 10 meters worked very well. I have used fldigi on both Windoze and Linsux operating systems and also include flarq for ARQ testing. It seems a bit unwieldly to me and I have not had much success in getting others to try this function. As an alpha tester, I am very supportive and impressed with fldigi which is the only cross platform multi-mode digital program. It does not have any BBS features, but like you point out, if someone implemented these features into a local BBS system ... 73, Rick, KV9U Toby Burnett wrote: Rick , Just on a side note, yep I have dabbled on HF packet, just connecting to european nodes etc. Never had much success, I'd have thought NVIS on 80m be quite good. Anyway there are some promising HF sound card ARQ modes coming out at the moment, Like psk mail and flarq for FL digi (even windoze version). Surly some of these ARQ modes could be implemented into a local BBS system somehow. Just thinking out loud. Regards Merry Xmas everyone from Dark Winter Scotland. Toby MM0TOB
Re: [digitalradio] RE:Packet radio with sound card
Similary, I have used Multipsk's packet modes on both HF and VHF with success. With the advance of technology, I moved away from packet around 15 years ago! It is just not robust enough for HF and can only go a short distance on VHF, compared with newer modes What seems like an unfulfilled need is a framework similar to packet, with the ability to insert different modes as they are developed. You would not have to keep inventing the wheel over and over. This would mostly have practical value for groups that want to set up a BBS system. For example, I have monitored the packets on an 80 meter BBS here in my state where most of the transmissions are retries. And this is during the day under NVIS conditions. A much more robust mode needs to be used. Then you would be able to send and receive direct or time shifted messages. This is the one thing we can not do with any other system, but there does not seem to be any interest in developing such a system. At this time, it is true that a slower baud rate packet system could be used, such as the software 110 baud speed available in Multipsk. This is why hardware packet TNC's are a poor choice for our advancing technology and why almost no one uses them anymore. You are locked into a mode developed over 30 years ago with no FEC or ability to be adaptive for conditions. And yet, I admit that if you want a BBS system today, what other choices do you have? 73, Rick, KV9U Bev Jerry Chambers wrote: I have used MixW for packet, both on 2 meters and on HF and found it to work fine. Jerry - W6LQR Plan ahead with a quick and convenient rental car. Click now. http://thirdpartyoffers.juno.com/TGL2142/fc/PnY6rw2i4Kl14diV4YFfqj9NVa0ZLTLXxwC4c6Z897wGFONyq2THo/ No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.9.19/1853 - Release Date: 12/17/2008 8:31 AM
Re: [digitalradio] RE:Packet radio with sound card
Howard Brown escribió: GM Jose, There is one point in your post I would like to bring up. Where you say: Multitasking cannot handle tight ARQ timing windows. It is a pity that noone has come forward (as far as I know) a real time OS (RTL, for instance) with a proposal usable on an old PC as packet engine with a sound card as modem. The problem is not the PC itself, but the prevalent OS's. Why not challenge the need for the tight timing windows? This creates more wear and tear and the radio but what real benefit does it provide? I believe that the NBEMS package and the RFSM8000 package prove that you can have effective ARQ without the fast switching. Examples of tight timing and succesful implementation are P-II and P-III, not only AMTOR, with its hair raising clicking I never tried SCAMP, which seemingly did well running under Windows. Actually, I have entrenched on my mind what gave me good results, but certainly, that may not be the only way for success, I have to admit. Examples of the success of tight timing are WSPR and WSJT, and certainly, knowing WHEN to expect input is a bonus. None of them generate such a high wear and tear. WHEN may be absolute, like in WSJT, related to the UTC time scale, or relative, in some time measure after the last received packet. I have had little luck with RFSM8000, because of my perennial lack of time in recent times and the little user mass it has generated. I would love to see Linux used more and not need to deal with Windows but still, the quick switching seems to be of little value. It was a way, which certainly, has been proven not to be the only one. You cannot entirely disegard trends, that may vary in time. I was the sysop of three BBS's at a time, on MSDOS (even with Desqview multitasking), Linux and Windows (the last one was a quick hack and an exercise in lazyness) and I liked BBS's. Forwarding over radio links, with all the freedoms it provides, and some associated extra responsibilities too. But I fail to see the comeback of the BBS's. Winlink may be useful, but it hardly substiututes the packet network the way it operated in the 90's. I have very good memories of the Linux based systems I ran (node, FBB, JNOS, DXNET), both were highly resilient and almost bulletproof. Uptime was usually more than 30 days, and the PC's ran without battery backups. I always used hardware TNC's, Kantronics and SCS. Pactor allowed 1 MB per day of forwarding on HF easily. Packet (300 baud) hardly ever exceeded 100 kb per day. 73, Jose, CO2JA
Re: [digitalradio] RE:Packet radio with sound card
SCAMP had no problem at all with the switching times from the testing I did. As a former Amtor and Pactor user from years earlier, it proved to me that my concerns about switching were unwarranted. Then along comes RFSM2400 with its frequent switching back and forth to maintain a link, even with no data flow, and you realize that computers can switch in a few tens of milliseconds, even with non-real time operating systems. Try toggling the PTT control with a typical multimode program and see how fast you can switch back and forth. It is not all that slow. I am skeptical about the wear and tear issue. Many rigs have QSK capabilities to allow switching between TX and RX many times per second. Even at 60 wpm with CW! So twice per second for older technology such as Amtor would not be that difficult to handle and new technology with less than one cycle per a few seconds, hardly noticeable. Although RFSM (MIL-STD 188-110A) can not be used in the HF RTTY/Data U.S. bands due to the high baud rate, other MIL-STD parallel tone modems could, even though it is not something that common. One of the methods would be to use some of the SCAMP technology and leverage it with the newer non RFDT modulation of SSTV/data such as QAM and do it with on the fly ARQ instead of manually after the completion of the transmission as it is done now with most of these programs. From my understanding that is what Winmor effectively does, plus it will have the necessary adaptive technology for ramping speeds up and down for conditions. This is something that any new, successful messaging system MUST have to succeed. The big question for the future is how open Winmor will be so that other adaptations can be made for BBS and peer to peer connections, particularly if you want something that can meet the needs of public service/emergency communication. E-mail can be helpful, but peer connections are vital, and BBS of great value in order to time shift. If there was a BBS system that could use low/no cost sound card adaptive modes for HF and/or VHF, I think it would be popular. I personally would be one of the first to support such a system. This is currently a large hole in what we need since the packet systems have mostly been discontinued. The key is to have at least a local BBS system that can work over a moderate distance of perhaps 30 to 50 miles on VHF (or more) and up to a few hundred miles on HF. 73, Rick, KV9U José A. Amador wrote: Examples of tight timing and succesful implementation are P-II and P-III, not only AMTOR, with its hair raising clicking I never tried SCAMP, which seemingly did well running under Windows. Actually, I have entrenched on my mind what gave me good results, but certainly, that may not be the only way for success, I have to admit. Examples of the success of tight timing are WSPR and WSJT, and certainly, knowing WHEN to expect input is a bonus. None of them generate such a high wear and tear. WHEN may be absolute, like in WSJT, related to the UTC time scale, or relative, in some time measure after the last received packet. I have had little luck with RFSM8000, because of my perennial lack of time in recent times and the little user mass it has generated. - - - It was a way, which certainly, has been proven not to be the only one. You cannot entirely disegard trends, that may vary in time. I was the sysop of three BBS's at a time, on MSDOS (even with Desqview multitasking), Linux and Windows (the last one was a quick hack and an exercise in lazyness) and I liked BBS's. Forwarding over radio links, with all the freedoms it provides, and some associated extra responsibilities too. But I fail to see the comeback of the BBS's. Winlink may be useful, but it hardly substiututes the packet network the way it operated in the 90's. I have very good memories of the Linux based systems I ran (node, FBB, JNOS, DXNET), both were highly resilient and almost bulletproof. Uptime was usually more than 30 days, and the PC's ran without battery backups. I always used hardware TNC's, Kantronics and SCS. Pactor allowed 1 MB per day of forwarding on HF easily. Packet (300 baud) hardly ever exceeded 100 kb per day. 73, Jose, CO2JA Announce your digital presence via our Interactive Sked Page at http://www.obriensweb.com/sked Yahoo! Groups Links No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.9.19/1853 - Release Date: 12/17/2008 8:31 AM
Re: [digitalradio] RE:Packet radio with sound card
Rick W wrote: SCAMP had no problem at all with the switching times from the testing I did. As a former Amtor and Pactor user from years earlier, it proved to me that my concerns about switching were unwarranted. Cold switching (no RF until contacts are closed, or opened while RF is flowing) should be harmless. My 600 W output homebrew linear can handle 40 wpm full break in using a current driven, run of the mill Potter and Brumfield 12 V 3P2T relay. But other replacement relays may be not as easy to find. Then along comes RFSM2400 with its frequent switching back and forth to maintain a link, even with no data flow, and you realize that computers can switch in a few tens of milliseconds, even with non-real time operating systems. Try toggling the PTT control with a typical multimode program and see how fast you can switch back and forth. It is not all that slow. I am skeptical about the wear and tear issue. My first experiences with AMTOR were frightening... but proved harmless to my gear. Many rigs have QSK capabilities to allow switching between TX and RX many times per second. Even at 60 wpm with CW! So twice per second for older technology such as Amtor would not be that difficult to handle and new technology with less than one cycle per a few seconds, hardly noticeable. Although RFSM (MIL-STD 188-110A) can not be used in the HF RTTY/Data U.S. bands due to the high baud rate, other MIL-STD parallel tone modems could, even though it is not something that common. One of the methods would be to use some of the SCAMP technology and leverage it with the newer non RFDT modulation of SSTV/data such as QAM QAM is as far as you can go without losing appreciable robustness. and do it with on the fly ARQ instead of manually after the completion of the transmission as it is done now with most of these programs. I can understand that procedure in sake of simplicity, but hardly an efficient one. Obviously, ARQ should be automatic. From my understanding that is what Winmor effectively does, plus it will have the necessary adaptive technology for ramping speeds up and down for conditions. This is something that any new, successful messaging system MUST have to succeed. That is what SCS boxes have done for a long time. The big question for the future is how open Winmor will be so that other adaptations can be made for BBS and peer to peer connections, particularly if you want something that can meet the needs of public service/emergency communication. Some sort of input is necessary, as MultiPSK can be used as modem for KISS streams. I have not enough details about Winmor to understand what it packs and what it misses. E-mail can be helpful, but peer connections are vital, and BBS of great value in order to time shift. If there was a BBS system that could use low/no cost sound card adaptive modes for HF and/or VHF, I think it would be popular. I think likewise. I personally would be one of the first to support such a system. This is currently a large hole in what we need since the packet systems have mostly been discontinued. The key is to have at least a local BBS system that can work over a moderate distance of perhaps 30 to 50 miles on VHF (or more) and up to a few hundred miles on HF. ...in order to regain what has been lost. BBS's here, beyond allowing local contacts, also allowed to access the worldwide packet network, which was a window to the ham world. 73, Jose, CO2JA
Re: [digitalradio] RE:Packet radio with sound card
Hi Jose, The advantage of using manual ARQ fills after the transmission of the data, is that it can be used as a one to many transmission. If any stations did not receive the data perfectly, they can send a request to repair defective portions. This is not possible with a handshaking type connection. Ideally, you would be able to do it either way. The main advantage of Pactor, Clover II and Gtor were the ability to make some changes in the speed and modulation in order to more closely match the path conditions. SCAMP could do this within a narrow limit, but it was not capable of working down to the weak signal level that the developer had expected, which was around zero dB SNR. Instead, it was closer to perhaps ~ +8 dB and needed to have a slower (more robust) mode to compete at all with Pactor. It is hard to believe that 4 years have gone by since we started beta testing SCAMP, but better something late than never. In the meantime, no one else was able to come up with an adaptive mode suitable for amateur use, so this could be the next big thing ... 73, Rick, KV9U Jose A. Amador wrote: I can understand that procedure in sake of simplicity, but hardly an efficient one. Obviously, ARQ should be automatic.
Re: [digitalradio] RE:Packet radio with sound card
Rick Correct me if I'm wrong. But reading between the lines of you post on this subject I feel you are saying - don't hold you breath for a sound card mode that will replace the ARQ modes such as Pactor or Amtor. John, W0JAB
Re: [digitalradio] RE:Packet radio with sound card
Hi John, Amtor was never that good. If you recall, it would start allowing erroneous data through when signals become weak enough. And when that happened, the signals were of what we would today call reasonably good signal strength for PSK31, MFSK16, etc. Pactor was much better. I did not have similar problems with bad data. Clover II would not allow bad data to go through but it did not work that well into the noise either and was a huge disappointment to me as I liquidated all my equipment to buy the HAL P-38 card that was supposed to also do Pactor, which it never could work properly. Pactor II and Pactor III are claimed to be much better than Pactor, however, like most digital hams, I won't ever be using them so it is a moot point. If Winmor can work reasonably close to the expectations of the developer, it should perform as well as or even better than Pactor II, but it may need a wider footprint for similar speed. Unlike Pactor modes, Winmor will have three different bandwidth modes. It will be very interesting to see how they perform. It is not expected to reach the top speeds of Pactor III, but then again, how often does P3 reach the higher speeds via its wide bandwidth and more complex constellation? Not very often from what observers have seen. It is often operating at Speed Levels several steps down from the top level due to band conditions. We don't know if there will be a peer to peer mode. If there is none, then it will primarily find limited use for e-mail. I know some think this is the most important thing to have. In my area, it would get rather infrequent use, but a connected mode, or better yet, a BBS system that could tie a group together would be the most useful. Unlike packet, it should be much more sensitive with weak signals and allow stations to connect, that currently can not when they use simplex phone. With a BBS it could also time shift so that more radio amateurs could participate since you would not be beholden to a specific net time. In my Section, they actually have hams promoting the sending of e-mail to a central server as somehow participating in a net operation. And you don't even have to use RF, just use the internet! We need to completely turn around this kind of approach and move to a robust method of connecting hams through HF and VHF. Imagine using a multimode/multiband transceiver, as many now have, to one simple interface and laptop and work with one basic system across HF and VHF. 73, Rick, KV9U John Becker, WØJAB wrote: Rick Correct me if I'm wrong. But reading between the lines of you post on this subject I feel you are saying - don't hold you breath for a sound card mode that will replace the ARQ modes such as Pactor or Amtor. John, W0JAB
