Re: [digitalradio] AX.25 vs Something New
Rud Merriam wrote: I suggest anyone interested in this topic start by reading http://citeseer.ist.psu.edu/cache/papers/cs/2504/http:zSzzSzpeople.qualcomm. com/karnz/papers/newlinkpaper.pdf/karn94toward.pdf by Phil Karn KA9Q. If anyone does not recognize his name or call then research him because he is an icon in amateur packet and digital communications. One of the experts. Just to tease the article starts by saying that AX.25 is widely recognized as far from optimal. There are some additional articles by Phil and others that address the issues with AX.25, including the hidden transmitter problem. OK, I will try to get this or the other links. I only have mail at home, and I am on holidays. Of course I know about Phil Karn. I have been an AMSAT-NA Life Member for 28 years and a licensed ham for 36 years. I am also aware that AX.25 is far from optimal, but so far it works. Tearing it all down and redoing or substituting looks scary at the present perspective. It would trash most TNC's and packet software in developed and developing countries, those that do not have the Internet as available as tap water. Would that be fruitful? You mention protocol layers. Which model do you want to use for discussion, OSI or the Internet model? Perhaps not a big question since layers 1 2 are the same but once we start moving up the stack they differ. I have been speaking about the seven layer OSI model. It is the relevant one for AX.25. I quote for reference: This protocol conforms to International Standards Organization (ISO) Information Standards (IS) 3309, 4335 and 7809 High-level Data Link Control (HDLC) and uses terminology found in these documents. It also follows the principles of Consultative Committee in International Telegraph and Telephone (CCITT) Recommendation Q.920 and Q.921 (LAP-D) in the use of multiple links, distinguished by the address field, on a single shared channel. Parameter negotiation was extracted from ISO IS 8885. The data-link service definitions were extracted from ISO IS 8886. I was referring to digipeating with respect to routing. Routing messages is the big problem with a ham network because the connectivity is totally dynamic and the issues with hams changing locations. Overall routing is a layer 3 protocol problem. Well, if packet radio is in the sad status it is nowadays, it would be even harder, if not impossible, to add such capabilities just by the hams effort. It does not seem realistic to me now. Your perspective on the use of AX.25 hardware probably differs from mine. There is little of it in use in the US except for Winlink 2000 VHF/UHF links. Providing gateways and bridges to existing networks is problem to address. We certainly have different perspectives. For me, HF was the way to achieve BBS connectivity and forwarding at large distances. HF forwarding has lost critical mass, and I doubt if it will ever recover it without a sound improvement. Whatever the causes may be, the BBS forwarding network is virtually inexistent, all has gone to WL2K and that is only for email style exchanges, using hard to get controller boxes, and far from the style and content of the old BBS network. That was a way of getting news relevant to hams, DXpeditions, operating events and plain ham to ham contact all around the world. It was important to many hams without email and Internet connectivity here. Packet was window to the world, accesible from your own equipment, that did not require fees or permissions other than an appropiate ham license. This situation is still widely prevailing. The possibility of better modems and a change of paradigm back to HF packet radio (or a suitable substitute) gives me a slight hope that some of the large network that once existed might be regained. First things first, I feel that an reconfigurable modem, or at least, a more suitable one is a priority. If a better protocol ever gets developed to substitute AX.25, it could use it. With the protocol in use, or another, we still have the same modem problem standing as a quarter of a century ago. 73, Jose, CO2JA
Re: [digitalradio] Re: Has anyone looked into FPGA-based digitalmodes?
Improvements at layer 1 and at layer 2 would both be useful. If done right, both could be developed apart from each other. A better layer 1 protocol should work just fine with AX.25 as a data layer, or with some improved future layer 2 implementation. Any improved layer 2 should work fine whether it's using a bell-tone physical layer or some improved magical future layer. While it is true that certain implementation choices at one layer can affect how another layer works, there are broad choices that can be made without affecting other layers. An example of a bad choice would be a layer 1 protocol that required a long leader for sync coupled with a short-timeout/short burst non-windowed ARQ layer 2. I'd love to say that this was a theoretical example, but I've seen people who expected this to work. -- Regards, Robert Thompson ~ Concise, Complete, Correct: Pick Two ~ Faster, Cheaper, Better: Pick Two ~ Pervasive, Powerful, Trustworthy: Pick One ~ Whom the computers would destroy, they first drive mad. ~ -- Anonymous
Re: [digitalradio] Something New - Ham Radio Email delivery time - Use what we have.
Based on the comments that WD8ARZ quoted below, it would seem that there is a basic misunderstanding of the use of e-mail for emergency communications by some hams. If you have taken any of the ARRL ARECC courses, or have a good understanding of basic public service communication, real time communication is not appropriate via e-mail. As Winlink2000 users, and even wire line e-mail users have found out the hard way, you don't coordinate tactical activities through such systems. There can be significant delays of up to several hours, and even several days! There have been cases where some hams have called up an exercise for the weekend and the messages were not actually delivered until Sunday. Needless to say, participation was very low. We need to always keep in mind that phone modes are typically required for tactical traffic during emergencies. Other modes can also be helpful with certain kinds of data that is lengthy or needs to be routed to distant points. Should call ups, priority, or, emergency time value traffic be routed via on e-mail unless there is no other possible way to route such traffic? Rick, KV9U Moderator for HFDEC (Hams for Disaster and Emergency Communication) [EMAIL PROTECTED] WD8ARZ wrote: Dont like to cross post, but I dont know how this topic can be said any better than what is listed below. With out an independent internet or wireless network to span our coverage needs to support our cause, and this isnt going to happen, these issues are not going to go way. However, it must be noted that all the on the air systems working now can be used to establish links to get early event communications out for setting up other modes of communications, such as normal voice to voice schedule arrangements. Thus it is important that all groups and individual users that wish to support emergency activities have as many of the options available as possible (or access to them and know how to use them), so those limited in emergency area's have something to start out with before moving on to activities that suit the situation and time. Get good at using what we got the way it currently works, or it is all a big waste. Many are dedicated to making what we have work, work better, and evolve over time. 73 from Bill - WD8ARZ http://hflink.net/qso/ - Original Message - From: Rick Muething [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, August 06, 2008 4:33 PM Subject: RE: [wl2kemcomm] Re: Email delivery time Vic confirmed the current code tries 8 times in a 4 hour period once ever 30 minutes. Until and unless there is a general standard used by mail servers trying to chase the latest ad-hoc anti spam technique is a significant burden on our very limited programming resources. Shortening to 5 minute attempts for 4 hours (48 tries) could increase the load on the server's significantly especially when there are so many very sluggish servers (e.g. AOL, Hotmail etc) that often take minutes to respond after accepting the initial start of the mail forwarding sessions. If your ISP is blocking mail waiting for multiple retries as a means of trying to control SPAM that is an issue to take up with the ISP. One thing you learn after being in this effort for long is there are continual changes in techniques for SPAM filtering but often these are met by just more aggressive and sophisticated SPAM bots with little real gain in the end. Rick KN6KB From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of n8gfo Sent: Wednesday, August 06, 2008 3:08 PM To: [EMAIL PROTECTED] Subject: [wl2kemcomm] Re: Email delivery time --- In [EMAIL PROTECTED], Rick Muething [EMAIL PROTECTED] wrote: Vic would have to confirm this.there may have been recent changes but it used to try hourly for up to 8 hours. Remember that Winlink delivers each recipients mail (each addressee) independently so a failure or delay with one address doesn't affect any others in the message. Can this be shortened to maybe 10 minutes or even 5 with enough attempts to make it a 4 or 5 hour total? So many servers are using this transient failure spam filtering and it is only going to get worse as time goes on. Having to wait a half an hour to get an email through makes it hard to hold a real-time exercise, much less a real-time emergency. It is also a hinderance to teaching people how to use the system, when they send email to themselves at their ISP address and it goes out but apparently doesn't arrive. I just went through this with someone who was learning packet/airmail from the ground up and it would have helped for him to see success faster. Thanks for your consideration in this.
[digitalradio] Re: Has anyone looked into FPGA-based digitalmodes?
OK , It was simply a concept based on current systems , the original panoramic digipan system capturing all, now expanded to cover rtty and the Olivia recovery in drm780 , my experience with hf packet back in the 80's when you could digi all over the place on 10 Mtr's , the wspr auto beacon software decoding down in to the noise and the latest `cw' skimming software that is capturing the call signe , operating frequency and posting it to a web server... As with the above I should think the calibration of a standard ham ssb set would be good enough to ensure net , as for the communication protocols .. well who knows a sort of lynux (compared to windows) communication system that sits in a small space and uses the advances in computing power and narrow modulation 'modern frequency usage' and allows everyone to join in, with the same dial setting I think the intelegent use of a band of frequencys would reprensent progress in 'ham' data transmission ? --- In digitalradio@yahoogroups.com, Jose A. Amador [EMAIL PROTECTED] wrote: Graham wrote: I really do not understand Graham's proposal: a narrow band spread spectrum system? I really need some more clarification about this.*** Ok may be a bit like calling a steam train a iron horse, dose the same thing but a little differently Spread spectrum : may not be quite the intended system, more like a frequency agile system within a constrained pass band, where data packet are transmitted, by say psk31 type modulation, on random channels within the pass band collision avoidance with multi users, and short data bursts Now I see. Frequency hopping spread spectrum. Those channels are not really random, but pseudo-random. I foresee two problems: 1) Coordination. The necessary codes should be defined. Netting those transmissions is not trivial, calibration issues are important and not all radios are calibrated equally. A heavy task for CAT, indeed. I am not sure it can be done well enough, or without special radios. 2) Administrative. It will be hard to convince communications administrations to let run systems they cannot monitor easily or reliably. PSK31 is not suitable per se, it is not thought for reliable transfers but for casual keyboarding. Emphasis is on quick responsiveness, because features that increase reliability of transfers also increase latency, which is felt as undesirable by many keyboarders. Count me in, I react differently if I want to chat with few erroneous characters that do not obliterate the meaning or if I want to transfer a file reliably. AX25 : merely as comparison to existing mode's of operation, some kind of watered down system that would allow routing via other stations, mail boxes that sort of thing, ok the data rate wont be too high, but just a novel system using the pc as a intelligent modem. could transmit command/route packets and data packets to keep things short Actually, it is not only AX.25, but using the BBS Interface Specification Working Draft 11/28/93 Is there any newer? I have not seen any other, newer or improved. FBB modified some aspects of it, specially regarding compressed transfers, but this is the basic protocol as I understand. I also keep the FBB protocol docs on a backup CD. The FBB and JNOS sources could be a good guide for someone interested in the tiny details. FBB does it better, with Z-modem style transfers that resume the file transfer where the link is cut. That also reduces the spectral footprint. If you views the system on a waterfall display, you would see, what looked like random vary length , short psk31 (type) signals appearing simulations'ly with in the system band with on say fixed channels with the odd collision and extended gaps . Depending on usage why not start to double up on the cannel usage to give a fec function under good conditions A waterfall would be a good thing. It was particularly hard to net in, even with a well calibrated radio without being able to really watch the spectrum using a TNC with no tuning indicator. Summarizing, I believe this is too complex and creates more problems than solutions. That is my personal perception. What I feel is needed is something based on the established technology (AX.25, BBS Spec) with a new modem more suitable for HF than the old Bell 103 modem. I see divided opinions, many prefer the shared frequency concept. This is not without problems. Bad or uncoordinated parameters, hidden stations, collisions, all reduce the transfer efficiency. I still remember that 14095 could be quite messy at times. I participated on a net where one station was the hub and clearinghouse, all had to be coordinated with the net manager, and it worked rather well. Something similar to frequency hopping but not exactly so were the
Re: [digitalradio] Something New - Ham Radio Email delivery time - Use what we have.
I have discussed this many times, but may some have missed it. The SCAMP development was an amazing ham radio software breakthrough. It dispelled many of the claims that you could not develop a sound card modem that would compete with Pactor 3. It solved the issue of the timing of computers by having pipelined (background) calculation of the last packet while the new packet was being received. It solved the problem of transmitting on a busy frequency. It was faster than Pactor 2, but not as fast as Pactor 3, but about as wide as Pactor 3 when P3 operates in the 18 tone form. The speed with compression was around 1000 wpm and was extremely impressive to watch as it linked with one of the three server stations here in the U.S. and Canada and handed off the e-mail message. Although some of us questioned the belief that it could work down to close to zero dB S/N, (those of us who were familiar with the real world experiences with the RDFT protocol as the a major SSTV protocol at the time), the author was convinced that it would be able to do this. Also, he had a VHF version that would work even faster! Expecting the RDFT protocol to perform at much below +8 or 10 dB S/N was not realistic and the software could not support the moderate to weak signals often found on HF paths. It worked best with good signals on HF paths close to the MUF. This concept had the same flaw as we continue to see with sound card modes that attempt to compete with Pactor 2 and 3. It had no ability to negotiate different speed levels/modulation complexity depending upon conditions. This absolutely has to happen to come up with a competitive system. The only current system that can do this is NBEMS, but that has to be done manually. Still, it is a move in the right direction. There is nothing all that mysterious with Pactor modes. They combine several features that add to the capability of getting data through. P2 uses more complex (faster) modes when conditions permit, and P3 does less of that, but instead adds up to 18 tones. Both use memory ARQ and compression that can increase throughput depending upon the type of data. Even P3 drops to only 2 tones (the same as P2 uses all the time) in its most robust form. The main thing is that it adapts to the conditions rather than having only one mode for a condition that is either optimum for speed or optimum for robustness. When they discovered that SCAMP was not going to work deep into the noise, they totally abandoned the entire project, vaporized the yahoogroup, the software was timed to self distruct, and it is a bit surreal as if it had never happened. In fact, I have not seen other hams who were active with this project ever show any follow up interest. SCAMP should have received a huge award for several enormous breakthroughs of that time period. It could have been improved with adding the ability to dynamically adapt to conditions with different protocols. At the very least, it could have been used for VHF if it had been made available. 73, Rick, KV9U Jose A. Amador wrote: Whatever the protocol and network, I still see the need for a better mousetrap, i.e., a better and less costly HF modem. Rick, KN6KB attempted that, and I don't really know what happened, but it got stuck. The need is still there.
[digitalradio] Doppler Shift Digital Voice
Has anyone considered the implications of using narrow-band digital voice in an environment that has Doppler Shift, for example, from space? If you have some thoughts about the challenges, feasiblity approach to using digital voice with Doppler Shift please reply to me OFF-LIST so I can discuss it with you in more depth. Thanks. 73, Mark, WB9QZB Chicago, IL
Re: [digitalradio] Something New - Ham Radio Email delivery time - Use what we have.
I agree. But as we just found out in the 2008 flooding it took days for some sites to get on the air even with radio equipment on hand - on site. Not everyone knows how to operate the equipment. 99.999% can send a text message using a cell phone. Win-link again worked. FYI water got to within 30 feet of the XYL's bookstore. John, W0JAB At 12:28 PM 8/7/2008 -0500, you wrote IN PART: If you have taken any of the ARRL ARECC courses, or have a good understanding of basic public service communication, real time communication is not appropriate via e-mail.
Re: [digitalradio] AX.25 vs Something New
Phil's paper is from many years ago but the reality is that there was no further movement away from the legacy AX.25 equipment toward a new layer, much less toward a completely new protocol. There is some movement... Check out: FX.25 - Forward Error Correction Extension to AX.25 Link Protocol For Amateur Packet Radio (pdf file 138k) The FX.25 extension to AX.25 implements a Forward Error Correction (FEC) ?wrapper? around a standard AX.25 packet and is designed to supplement the existing AX.25 infrastructure without displacing it. http://www.stensat.org/Docs/FX-25_01_06.pdf
Re: [digitalradio] AX.25 vs Something New
Bill Vodall WA7NWP wrote: Phil's paper is from many years ago but the reality is that there was no further movement away from the legacy AX.25 equipment toward a new layer, much less toward a completely new protocol. There is some movement... Check out: FX.25 - Forward Error Correction Extension to AX.25 Link Protocol For Amateur Packet Radio (pdf file 138k) The FX.25 extension to AX.25 implements a Forward Error Correction (FEC) ?wrapper? around a standard AX.25 packet and is designed to supplement the existing AX.25 infrastructure without displacing it. http://www.stensat.org/Docs/FX-25_01_06.pdf http://www.stensat.org/Docs/FX-25_01_06.pdf ... and, perhaps this link http://www.stensat.org/projects/FX-25/FX-25_performance.htm, http://www.stensat.org/projects/FX-25/FX-25_performance.htm but that was in 2006... Chuck AA5J
[digitalradio] THOR
HELLO, WHERE CAN I FIND SOFTWARE FOR THOR MATTHEW A. GREGORY KC2PUA
Re: [digitalradio] THOR
I am not sure THOR has officially been released yet, it was in Beta testing last I checked. On Thu, Aug 7, 2008 at 9:49 PM, matt gregory [EMAIL PROTECTED] wrote: HELLO, WHERE CAN I FIND SOFTWARE FOR THOR MATTHEW A. GREGORY KC2PUA -- Andy K3UK www.obriensweb.com (QSL via N2RJ)
Re: [digitalradio] Something New - Ham Radio Email delivery time - Use what we have.
As usual Rick you take comments and twist them to take off on a tangent and make personal put downs. Worse yet you make associations that were not made and not intended. I will no longer make replies to you or your posts. If your continual mis-directions and abuse of congenial communications continues to get through on the various reflectors we share (your list is shrinking), your address and calls will simply be put into automatic bounce filters and that will be that. Use what we have as best as possible and where appropriate. Do your own programming and put your misdirected energy to better use. As one of the testers of Scamp, its amazing you are still pushing in directions that are not being continued by the originators. WD8ARZ Out - Original Message - From: Rick W. [EMAIL PROTECTED] To: digitalradio@yahoogroups.com Sent: Thursday, August 07, 2008 1:28 PM Subject: Re: [digitalradio] Something New - Ham Radio Email delivery time - Use what we have.
