[digitalradio] RE: HF packet
Thanks for the info on HF Packet. My friend is not licenced yet so he cant TX but wants to check it out. Thanks again73BarryWB1EDI _ Windows Live™: E-mail. Chat. Share. Get more ways to connect. http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_HM_AE_Faster_022009
Re: [digitalradio] HF packet
No...I was thinking of his actually using the program to connect to a BBS. I should have made that clear. 73 Mark --- On Wed, 2/4/09, Jose A. Amador ama...@electrica.cujae.edu.cu wrote: From: Jose A. Amador ama...@electrica.cujae.edu.cu Subject: Re: [digitalradio] HF packet To: digitalradio@yahoogroups.com Date: Wednesday, February 4, 2009, 9:23 PM Mark Milburn wrote: if you want to dig in a little deeper, you may need to download and install a program that decodes compressed packets. If I can be helpful, let me know how. 73 Mark KQ0I Des Moines, IA Mark, Do you know any program that does that, on the fly and on the air? I was a long time FBB Sysop and I could not copy anything but the header, the rest was all garbled, if it was in unnconnected state. I was the sysop of CO2JA.#HAV.CUB.NA, CO2BQQ.#HAV.CUB.NA (later CO9BQQ) and CO2BSS.#HAV.CUB.NA. Just curious, Jose, CO2JA 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 Announce your digital presence via our Interactive Sked Page at http://www.obriensweb.com/sked Yahoo! Groups Links
[digitalradio] Re: HF packet
--- In digitalradio@yahoogroups.com, Mark Milburn markk...@... wrote: Yes, there are a LOT of repeats when the bands are poor. Signal strength is not the only criteria. I don't have a technical background to explain it or even understand it, but there are plenty of days when a signal of S7 will be solid copy..and other days when it will not. Part of the problem is that at 300 baud the bit length is only 3.3 milliseconds. You can have multipath echoes that smear the short bits even when signals are strong. (That's one reason why 110 baud ASCII never caught on with hams, and even 75 baud Baudot can be dicey.)
[digitalradio] discussion wanted - JNOS (or any app) + multipsk modem
Okay, I now have an 'attach multipsk ...' command on my JNOS system, and a receiver process to handle the incoming data. So NOW the fun part begins. How do *we* want to do this ? It's very easy for me to make it so that we can use JNOS + multipsk modem to pass RAW ip over HF - I already have a RAW ip interface that I was experimenting with about a year ago. I put a small header on the RAW ip packet (callsign, and something to identify it as a RAW ip packet), then text encode, then compress, then out to the radio port. * an obvious issue is that this would only work JNOS to JNOS, since the method of using the header, text encoding, etc is *something* that I came up with. Anyone have existing standards in mind ? I know that there is a KISS interface for AX25 (packet), but I understand that it's limited to serial port only. I'd like to use the tcp/ip control of multipsk to pass AX25 (similar to how I do the RAW ip above). * at issue again perhaps is standards on 'how do we do this with the non-arq modes like bpsk, mfsk, mt63, etc'. BUT, at the same time, I would like to just have a MAILBOX (like the JNOS bbs prompt) for anyone using any of the multipsk supported modes to *connect* to JNOS and be able to list or read messages, etc. ANYONE ? - ideas, comments, criticisms, flames, whatever ! Regards, Maiko Langelaar / VE4KLM * http://www.langelaar.net/projects/jnos2
Re: [digitalradio] HF packet
Hi Mark, I am not sure why any legal issues are involved. To my knowledge there has been only one major mode that has been prohibited by the FCC. Even AM is still grandfathered, however it is also true that if AM was used extensively, there would be a groundswell to have to eliminated due to the extreme bandwidth requirements in a very limited environment. It is mostly used by a few who like using legacy equipment (which when I was first licensed was state of the art, HI), and I suspect a few other reasons, such as audio quality, ease of tuning, even if it does take a much larger amount of power to have equal range. I completely agree with you about packet and signal strength vs quality of the ionosphere. As another ham mentioned, packet has severe limitations on HF. In an ideal world it would never have been used for HF, but consider that at the time we had no other choice available at that speed and I believe that some have pointed out that we were in a good sun spot condition in the early 1980's when first developed so it could work even on 10 meters for substantial distances and even at 1200 baud. For a technical reason, modes that require stable ionospheric conditions, can get that from the bands that are open and as close to (but not exceeding) the MUF (Maximum Usable Frequency). If you have followed the incredibly valuable information from Tony, K2MO, with many tests of various modes, you should be able to see the pattern of which modes fail or succeed and why. The technical issues are very important to understand and my perspective is that we have three main parameters affected by the path: 1) mode sensitivity, or SNR (Signal to Noise Ratio) required 2) ISI (Inter Symbol Interference) or how much multipath is present at any one time 3) Doppler or frequency spread of an individual symbol Some modes are more resistant than others and this has been one of the most interesting things for me to follow over several decades of improvements in our digital technology. We do know that without either training pulses (MIL-STD-188-110A, et al) or with baud rates above about 50, even modest ISI can make communications impossible with modes with no FEC. And conversely, modes with low baud rates, that can tolerate extreme ISI, can ironically fail because their slow baud rate leads to susceptibility to Doppler. This is why Pactor developers selected 100 baud and only 100 baud for P2 and P3. They make up for the higher baud rate which would normally be a problem, with FEC active at all times, and then change the modulation (and with P3, the number of tones and spacing of tones) to adjust for conditions. The modulation used for packet was developed by adapting existing FSK (RTTY) techniques for a simple mode that could be accomplished without any computer or DSP since this was not available back in the late 1970's. This worked fairly well for VHF and higher where you had a stable path. It was not as successful for effective use on HF similar to the situation with ASCII which turned out to be a disaster on HF after all the work to get FCC approval. Packet is really ASCII with an ARQ checksum but no FEC thus the predictable performance, or lack of it due to its requirement for a good signal to noise, almost no Doppler or ISI. Unfortunately, not always easy to come by with HF:( I can well understand why you continue to use it. What other choice is there? It has to dovetail with the existing infrastructure that is already in place. At one time we had a well developed packet system, even a world wide system with some assists from HF forwarding and yes, wormholes which were really the early internet running on mostly non RF paths. Some areas are impossible to bridge such as across the Great Plains of the U.S. without HF. But it became obsolete when the internet preempted it. Your characterization of nets, is very accurate. There is a mindset that there is nothing we can do about it. Of course there are things that can be done, but due to inertia, maybe some agendas, etc., they don't get done and things do not progress. Even something very basic like moving below the FoF2 frequency for NVIS use is rarely done. I have specifically asked our STM about this within the last two months and although they realized it could be done, there is little interest in making such a change. Same thing with using modes such as Olivia in place of CW, especially now that the speeds of traffic handling seem to be slowing down and few new hams are taking up the slack with CW, but maybe they would with digital? Some of us get into a lot of trouble because we ask the questions that make people uncomfortable. I am surely one of those. We have a number of dramatically better technologies and in some cases they are not being used to improve what we already have in place because like you point out thats the way it is. It is fortuitous timing, but in recent days, Maiko,VE4KLM,
Re: [digitalradio] HF packet
I believe that nowadays 110 baud (or 100 baud) should fare better. Sadly, PAX only passes unproto in Multipsk as modem (but maybe UI packets are enough for TCPIP) I would have to reinstall JNOS and try with Multipsk. 73, Jose, CO2JA Mark Milburn escribió: No...I was thinking of his actually using the program to connect to a BBS. I should have made that clear. 73 Mark 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] HF packet
We have been talking about using Q15x25 but it turns out to be more talk than doing so we haven't really done much. I think it's quite possible using FBB or MSYS and then using MixW as the TNC. That way you have the error correction of the bbs program and the ability to vary the Q15x25 for a wider or more narrow transmission. Actually, I think 300 baud does quite well. Of course it is slow, but that is a term relative to your expectations. It is now 2 PM here and I have taken in over 20 messages and have forwarded 35 out today on 40 meters and there are probably five or six more hours of forwarding time before the band closes up between myself and my forwarding partners. That is pretty good, I think. Mark --- On Thu, 2/5/09, José A. Amador ama...@electrica.cujae.edu.cu wrote: From: José A. Amador ama...@electrica.cujae.edu.cu Subject: Re: [digitalradio] HF packet To: digitalradio@yahoogroups.com Date: Thursday, February 5, 2009, 12:32 PM I believe that nowadays 110 baud (or 100 baud) should fare better. Sadly, PAX only passes unproto in Multipsk as modem (but maybe UI packets are enough for TCPIP) I would have to reinstall JNOS and try with Multipsk. 73, Jose, CO2JA Mark Milburn escribió: No...I was thinking of his actually using the program to connect to a BBS. I should have made that clear. 73 Mark 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 Announce your digital presence via our Interactive Sked Page at http://www.obriensweb.com/sked Yahoo! Groups Links
Re: [digitalradio] discussion wanted - JNOS (or any app) + multipsk modem
maybe patrick can builtin such a mailbox without stuck on packet :-) why not a mailbox that can be used with ANY mode maybe also with arq and fec dg9bfc sigi - Original Message - From: maiko4 To: digitalradio@yahoogroups.com Sent: Thursday, February 05, 2009 7:15 PM Subject: [digitalradio] discussion wanted - JNOS (or any app) + multipsk modem Okay, I now have an 'attach multipsk ...' command on my JNOS system, and a receiver process to handle the incoming data. So NOW the fun part begins. How do *we* want to do this ? It's very easy for me to make it so that we can use JNOS + multipsk modem to pass RAW ip over HF - I already have a RAW ip interface that I was experimenting with about a year ago. I put a small header on the RAW ip packet (callsign, and something to identify it as a RAW ip packet), then text encode, then compress, then out to the radio port. * an obvious issue is that this would only work JNOS to JNOS, since the method of using the header, text encoding, etc is *something* that I came up with. Anyone have existing standards in mind ? I know that there is a KISS interface for AX25 (packet), but I understand that it's limited to serial port only. I'd like to use the tcp/ip control of multipsk to pass AX25 (similar to how I do the RAW ip above). * at issue again perhaps is standards on 'how do we do this with the non-arq modes like bpsk, mfsk, mt63, etc'. BUT, at the same time, I would like to just have a MAILBOX (like the JNOS bbs prompt) for anyone using any of the multipsk supported modes to *connect* to JNOS and be able to list or read messages, etc. ANYONE ? - ideas, comments, criticisms, flames, whatever ! Regards, Maiko Langelaar / VE4KLM * http://www.langelaar.net/projects/jnos2
Re: [digitalradio] discussion wanted - JNOS (or any app) + multipsk modem
Hello Mailko, Glad you connect the TCP/IP link (in local loop I suppose). I know that there is a KISS interface for AX25 (packet), but I understand that it's limited to serial port only. I'd like to use the tcp/ip control of multipsk to pass AX25 (similar to how I do the RAW ip above). With virtual serial port, it's not very different from TCP/IP. However, I could change the TCP/IP multipsk protocol to send/receive Kiss frames, but i would need time... At least about APRS, it seems some Hams would like PSK31 support to send/receive AX25 APRS UI frames. I don't imagine connected Packet in PSK31. But in Dominoex 22 or in PSK220F why not? 73 Patrick - Original Message - From: maiko4 mai...@yahoo.com To: digitalradio@yahoogroups.com Sent: Thursday, February 05, 2009 7:15 PM Subject: [digitalradio] discussion wanted - JNOS (or any app) + multipsk modem Okay, I now have an 'attach multipsk ...' command on my JNOS system, and a receiver process to handle the incoming data. So NOW the fun part begins. How do *we* want to do this ? It's very easy for me to make it so that we can use JNOS + multipsk modem to pass RAW ip over HF - I already have a RAW ip interface that I was experimenting with about a year ago. I put a small header on the RAW ip packet (callsign, and something to identify it as a RAW ip packet), then text encode, then compress, then out to the radio port. * an obvious issue is that this would only work JNOS to JNOS, since the method of using the header, text encoding, etc is *something* that I came up with. Anyone have existing standards in mind ? I know that there is a KISS interface for AX25 (packet), but I understand that it's limited to serial port only. I'd like to use the tcp/ip control of multipsk to pass AX25 (similar to how I do the RAW ip above). * at issue again perhaps is standards on 'how do we do this with the non-arq modes like bpsk, mfsk, mt63, etc'. BUT, at the same time, I would like to just have a MAILBOX (like the JNOS bbs prompt) for anyone using any of the multipsk supported modes to *connect* to JNOS and be able to list or read messages, etc. ANYONE ? - ideas, comments, criticisms, flames, whatever ! Regards, Maiko Langelaar / VE4KLM * http://www.langelaar.net/projects/jnos2 Announce your digital presence via our Interactive Sked Page at http://www.obriensweb.com/sked Yahoo! Groups Links
[digitalradio] QRV -- MFTTY 14072.0
All, I'm QRV MFTTY 14072.0 1/2 speed FEC mode. Its 20:15z -- February 5th. Tony - K2MO
Re: [digitalradio] discussion wanted - JNOS (or any app) + multipsk modem
Hello Sigi, There is yet a modest mailbox for ARQ (Packet/Pax/FAE) modes (as the messages must be error free). 73 Patrick - Original Message - From: Siegfried Jackstien To: digitalradio@yahoogroups.com Sent: Thursday, February 05, 2009 8:54 PM Subject: Re: [digitalradio] discussion wanted - JNOS (or any app) + multipsk modem maybe patrick can builtin such a mailbox without stuck on packet :-) why not a mailbox that can be used with ANY mode maybe also with arq and fec dg9bfc sigi - Original Message - From: maiko4 To: digitalradio@yahoogroups.com Sent: Thursday, February 05, 2009 7:15 PM Subject: [digitalradio] discussion wanted - JNOS (or any app) + multipsk modem Okay, I now have an 'attach multipsk ...' command on my JNOS system, and a receiver process to handle the incoming data. So NOW the fun part begins. How do *we* want to do this ? It's very easy for me to make it so that we can use JNOS + multipsk modem to pass RAW ip over HF - I already have a RAW ip interface that I was experimenting with about a year ago. I put a small header on the RAW ip packet (callsign, and something to identify it as a RAW ip packet), then text encode, then compress, then out to the radio port. * an obvious issue is that this would only work JNOS to JNOS, since the method of using the header, text encoding, etc is *something* that I came up with. Anyone have existing standards in mind ? I know that there is a KISS interface for AX25 (packet), but I understand that it's limited to serial port only. I'd like to use the tcp/ip control of multipsk to pass AX25 (similar to how I do the RAW ip above). * at issue again perhaps is standards on 'how do we do this with the non-arq modes like bpsk, mfsk, mt63, etc'. BUT, at the same time, I would like to just have a MAILBOX (like the JNOS bbs prompt) for anyone using any of the multipsk supported modes to *connect* to JNOS and be able to list or read messages, etc. ANYONE ? - ideas, comments, criticisms, flames, whatever ! Regards, Maiko Langelaar / VE4KLM * http://www.langelaar.net/projects/jnos2
[digitalradio] Re: discussion wanted - JNOS (or any app) + multipsk modem
Hello Patrick, However, I could change the TCP/IP multipsk protocol to send/receive Kiss frames That would be very nice (if you think it's an okay idea). This will be easy. It's just a matter of passing incoming kiss frames to an existing KISS handler function. It will take no time at all then to have JNOS use multipsk as a packet modem. but i would need time... There is no hurry. Thank you. Maiko Langelaar / VE4KLM
Re: [digitalradio] HF packet
Rick, You can try Q15X25 if you have MixW and can find someone else to experiment with. See http://www.mixw.net/index.php?j=downloads for the .dll file instuctions. KE7HPV. Rick W wrote: I meant to bring up Q15X25 since this was going to be the solution for HF packet a number of years ago but no one really knew much about it and the only comments we ever heard was that it just did not work well. And yet when you look at the modulation method and tones, it just seems like it would be a very good mode, even though some might criticize its width since it is always going to be operating at 2000 Hz bandwidth. Or can it vary the number of tones and BW? The raw speed is 2500 bps and so that seems very acceptable to me. The ARRL web site description says it is a KISS/AX.25 packet modem designed for AX.25 and TCP/IP. Since it uses 15 QPSK tones it has FEC and each tone is a reasonable 83.33 baud rate spaced at 125 Hz. The design is from non other than Pawel Jalocha who created a number of other modes including Olivia. Does anyone really have the definitive answer one what is or is not the truth about Q15X25? The 2FSK300 mode currently used has good speed for its bandwidth, if, and it is a big if, it has a frequency that has minimal Doppler and ISI and better than zero dB SNR. We know how fast PSK250 can work with NBEMS, again, if you have a perfect path, HI. 73, Rick, KV9U
Re: [digitalradio] HF packet
PAX and PAX2 can only handle the 6 bit ASCII character set. We would need at least a 7 bit ASCII character set for upper and lower case, control characters, etc. If you only wanted to use it for something like standard message traffic though it could be implemented since you can then use it across the lowest common denominator which means the characters that can be passed with CW. One of the (many) interesting things about Multipsk is that it also has a 110 baud packet mode. Has anyone considered using this in place of 300 baud? The biggest obstacle, of course, is that the hardware designs probably do not support the slower speed, but I think you will find that the slower speed will often allow traffic through that would have no chance at all with 300 baud. Is anyone using this now or ever tried it but found it just did not work for out? 73, Rick, KV9U José A. Amador wrote: I believe that nowadays 110 baud (or 100 baud) should fare better. Sadly, PAX only passes unproto in Multipsk as modem (but maybe UI packets are enough for TCPIP) I would have to reinstall JNOS and try with Multipsk. 73, Jose, CO2JA
[digitalradio] MFTTY On Air Sensitivity
All, Had another opportunity to test MFTTY on air today. As expected, sensitivity goes hand-in-hand with character speed and the slower 1/8 mode is probably close to what you might expect from say PSK31. Path simulations seem to indicate that the mode is probably more stable than PSK31 when HF path distortion becomes an issue. I'd appreciate any thoughts / experiences with MFTTY performance; slow vs. fast mode etc. Tony - K2MO
[digitalradio] Q15X25 Packet test
I am set up with Q15X25 tonight. Anyone willing to test this? 20 meters seems to be shutting down so maybe 40 meters (7088?) Also, is there any way for Tony, K2MO, to test this mode with his computer model so we can determine the limits of its ISI, Doppler, and sensitivity? 73, Rick, KV9U Sholto Fisher wrote: Rick, You can try Q15X25 if you have MixW and can find someone else to experiment with. See http://www.mixw.net/index.php?j=downloads for the .dll file instuctions. KE7HPV.
