[digitalradio] Re: ROS back bigger and better !
g4ilo writes: But why are you all so worked up over this? It is the USA not Soviet Russia, you aren't going to end up in Siberia are you? The late J Edgar Hoover, director of the FBI, used to exile FBI agents he disliked to Alaska, which was as close to Siberia as he could send them. grin However, you are right: the worst penalties which the FCC might plausibly impose on a US ham who lost an argument with them about whether ROS is spread-spectrum would be a fine or license revocation (the latter not likely for a first offense.) OTOH, most hams take seriously our obligation, as a disciplined and largely self-policing radio service, to operate within the both the International Radio Regulations AND the rules promulgated by our respective national administrations. This is independent of the penalties for a violation. There are exceptions, of course, but most of us WANT to follow both the rules and good practices at all times, so we also need to know what the rules are and what they mean. 73 DE KW6H (ex-AE6VW), Chris
Re: [digitalradio] Opposing 60M proposal
James French writes: Can it be 'justified' to 'clog up' a new band with allowing ANY digital mode, and I am also including digitized voice into this, just to have it be there? Why not use what is already staged and developed and on the bands that already have the allocations? The reason for allowing digital modes on 60 is the same as the reason for allocating channels on 60 to hams in the first place: sometimes two stations are too close to work on 40 due to F-layer skip, and too distant to work on 80 due to D-layer absorption, while 60 will permit effective communication. This is equally true for any mode. W.r.t. EMCOMM, if a served agency needs hams for backup record communication using digital modes (whether email or radiograms), we don't want to be unable to serve that agency when propagation fails on both 80 and 40 meters while the phone lines are down, if 60m would work. Nor should we be reduced to reading radiograms over voice radio on 60m if a data mode would be both faster and more reliable. While much EMCOMM traffic is tactical rather than formal, some of it is not: EMCOMM hams should be prepared for both, and the regulations should not prevent us from doing both as effectively as possible. -- 73 de kw6h, ex-ae6vw, Chris
[digitalradio] Why does the ARRL continue to push for Pactor III support...
Rick Ellison writes: ... This just makes no sense to me why you would push Pactor III on a channelized frequency setting.. A good question: I was thinking of sending in a comment on that NPRM, recommending that instead of authorizing only PSK-31 and Pactor-III, that the FCC instead permit all publicly-documented data modes which fit within the authorized bandwidth. However, it appears that the FCC is going to do that in any case. I am still inclined to write in and suggest that digital operation in the 60m band be confined to local or remote control, not automatic, to minimize the chance of interference to the primary users. Unlike some members of this list, I have nothing against Pactor-III on 60m (waste of spectrum when used for keyboard-to-keyboard QSOs is not an issue with the fixed channels on 60m), and nothing against Pactor I and II at all. I do not choose to operate those modes, but neither do I wish to restrict *other* hams to operating as *I* choose. OTOH, I DO object to ham bots interfering with the primary users of spectrum which we share on a secondary basis with other services: it's bad for the amateur service's relationships with other spectrum users. Actually, I even object to the lid-bots on ham-only spectrum outside the automatic-control subbands. I'd like to see the automatic subbands made a bit wider, but the exception removed for automatic stations using 500 Hz or less in response to interrogation by a manually-controlled station. I'll just have to live what we have now, ince the FCC clearly disagrees with me. -- 73 DE KW6H, ex-A6VW, Chris, ae6vw-digitalra...@puffin.com
Re: [digitalradio] Re: Unattended narrow mode transmission protection
Adding to Skip's remarks, I will point out it is considered almost an indecency among the daily-position-report hams to mention 97.113(a)(5) of the FCC rules, which states: (a) No amateur station shall transmit: ... (5) Communications, on a regular basis, which could reasonably be furnished alternatively through other radio services. That means that a US-licensed ham violates the FCC regs when s/he regularly transmits vessel position reports, which could be transmitted using the maritime mobile service, over ham frequencies. Not being a lawyer, I am not qualified to say whether a fixed ham station which received those messages and forwards them to a web page is also in violation, though my unqualified guess is no. I don't know whether hams licensed in other countries are subject to equivalent (or even more stringent) regulations against communications which could be furnished through other radio services, but I suspect that the answer is yes, and that the basis for 97.113(a)(5) is to be found in the International Radio Regulations, which all administrations are required by treaty to implement. A documented confirmation or contradiction of my guess would be welcome. 73 DE KW6H, ex-AE6VW, Chris
Re: [digitalradio] Re: Unattended narrow mode transmission protection
Ed G writes: Using your same logic below, it could well be determined that hams who partake regularly in 75M evening nets, or even regular QSO, etc, should take their conversations to FCC Part D Citizen's band, or other service , because those communications on a regular basis could be easily furnished through those alternative services too. I know, its stupid, but it also carries the same logic as the below example . K7AAT Ragchews or roundtable nets with other hams could not be reasonably accomplished via another radio service, nor could the authorized purpose of improving international understanding via person-to-person contacts on the radio. (Any ham who is using 80m to work other hams within the reliable range of CB class D probably ought to consider QSY to 144 MHz or above, but that is wandering pretty far off the topic of this thread.) Daily vessel position reports, on the other hand, ARE done via the Maritime Mobile Radio Service, so obviously they CAN BE. For exchanges of email messages between yachts at sea and non-hams ashore via MM frequencies, see http://www.sailmail.com for a non-profit connection. I believe that for-profit public coast stations offer such services as well. 73 DE KW6H (ex-AE6VW), Chris
[digitalradio] Adobe Reader incompatible with amateur radio computer?
n0hnj writes: [problems with the latest Adobe Reader and MSIE on a reinstall of MS Windows.] Adobe has a long history of buffer overrun bugs leading to exploits. There are third-party readers for PDF documents that are safer. Since I don't run Windows, the readers I use (Xpdf and Okular) wouldn't work for you, but a web search should find some safer programs for viewing PDFs under MSWin. You should consider switching to Firefox as a safer alternative to the historically buggy and exploit-prone MS Internet Explorer. (I DO strongly recommend installing the NoScript add-on to Firefox, though.) I also suggest downloading PDFs to your local disk and opening them with a separate program, rather than letting your browser try to display them for you. I would expect that to be accomplished by right-clicking on the link and selecting a save as item from a menu, but I don't know whether that applies to MSIE. Sometimes convenience and safety are conflicting values. 73 DE KW6H (ex-AE6VW), Chris Jewell
Re: [digitalradio] Re: illinoisdigital group
I didn't complain either, but after about 5 or so of his messages I added this to my .procmailrc: # advertisements in various Y! ham-radio mailing lists *From: .*wb9...@yahoo.com /dev/null 73 de kw6h, ex-ae6vw Chris Jewell
Re: [digitalradio] Grouply spam/theft attacks
Since the grouply folks, judging by their conduct thus far, don't seem like anyone I would ever want to have contact with, I did the following (output abbreviated.) $ host www.grouply.com www.grouply.com is an alias for grouply.com. grouply.com has address 72.20.121.3 grouply.com mail is handled by 0 smtp.grouply.com. $ host smtp.grouply.com smtp.grouply.com has address 72.20.124.3 $ whois 72.20.121.3 Bay Area Internet Solutions BAYAREA-BLK-1 (NET-72-20-96-0-1) 72.20.96.0 - 72.20.127.255 Grouply BAYA-72-20-121-0 (NET-72-20-121-0-1) 72.20.121.0 - 72.20.121.255 [EMAIL PROTECTED] $ whois 72.20.124.3 Bay Area Internet Solutions BAYAREA-BLK-1 (NET-72-20-96-0-1) 72.20.96.0 - 72.20.127.255 Grouply BAYA-72-20-124-0 (NET-72-20-124-0-1) 72.20.124.0 - 72.20.124.255 $ I then added ... deny ip from 72.20.121.0/24 to any in deny ip from 72.20.124.0/24 to any in ... to my FreeBSD firewall rule set (your firewall syntax may vary), and ... :0 : *Received: from .*72\.20\12[14]\.[0-9]+ /dev/null ... to my .procmailrc, so they cannot spam me via the @arrl.net forwarding service, which passes my firewall. 73 DE KW6H (ex-AE6VW), Chris Jewell
Re: [digitalradio] Grouply spam/theft attacks
Oops! That .procmailrc rule should read ... :0 : *Received: from .*72\.20\.12[14]\.[0-9]+ /dev/null Sorry about the missing period. -- 73 DE KW6H (ex-AE6VW), Chris Jewell
Re: [digitalradio] Re: Digitalradio Group
Rodney writes: Just did a Group search and it's there. It's called, FCCSUCKS, but there's only ONE message on it and who knows if it even has a moderator!. I agree, someone (NOT me) needs to start an FCC Rules discussion group! Rod KC7CJO It appears that the digipol Y!-group was set up for exactly this purpose, but there seem to be no members or messages. I have a vague recollection that our moderator may have established that group so he'd have someplace to which to banish the endless flamewars about the FCC subbands-by-bandwidth NPRM, WL2K sucks|rocks, automatic busy detection for bots should is mandatory|is infeasible, etc, but I'm not sure I'm not confabulating here. :-) 73 DE KW6H (ex-AE6VW) -- Chris Jewell [EMAIL PROTECTED] PO Box 1396 Gualala CA USA 95445
Re: [digitalradio] Re: Gray Areas of Ham Radio Regulations and Rules
kv9u writes: What rule do you think is stopping U.S. hams from using RFSM2400 other than if it is not yet posted with a technical description? 97.307(f)(3) ... The symbol rate may not exceed 300 bauds ... That applies to all the cw,data subbands below 28 MHz. I wish it were otherwise, but it's not. We need regulation by bandwidth only, but that proposal seems to be stalled. :-( -- Chris Jewell [EMAIL PROTECTED] (ex-ae6vw) Gualala CA USA 95445
Re: [digitalradio] Re: FNpsk
Walt DuBose writes: How can 1200 baud = 1320 WPM? In the case of AX.25 baud=bps since a mark-space=one bit. An 8 bit ASCII character with start and stop bits would be 10 bps so 1200 bps=120 CPS. If a word is 6 characters, then 120 CPS = 20 WPM which we know is too slow. (120 chars/sec) / (6 chars/word) = 20 words / second (not per minute) 20 x 60 = 1200 words/minute. Besides, while I don't know a lot about AX.25, I'm pretty sure that X.25, from which AX.25 is derived, is synchronous (no start or stop bits). -- 73 DE KW6H (ex-AE6VW) Chris JewellGualala CA USA
[digitalradio] Re: New 80m USA Keyboarding Digi Frequencies
expeditionradio writes: [snipped] Let's be blunt together, but let's focus on the topic instead of personality. The fact is, there's a proposed solution on the table. If you have a truly constructive suggestion, let's hear it. Sexist or condescending remarks do nothing to advance the discussion. Right on target. The other posters' remarks strike me as regrettably personal and non-constructive. Below are my comments on the proposal. [snipped] 80 meter Bandplan 2007 for USA: == 3500-3540 = CW 3540-3560 = Any Mode, 500Hz Bandwidth 3560-3600 = Any Mode Given what the FCC has done to 80 meters, nobody is going to get everything they'd like out of any new USA band plan. Still, it seems to me that as advocates for the data modes, we are more likely to obtain the cooperation and agreement of those with whom we share 3500-3600 KHz if our proposals leave half of the new band for the CW ops. Accordingly, while I can live with Bonnie's suggestion as presented, I suggest moving the boundaries up by 10 KHz. 3500-3550 = CW 3550-3570 = Any mode up to 500Hz bandwidth 3570-3600 = Any mode That gives general and advanced CW ops 25 KHz of mode-exclusive space instead of 15, and extras 50 KHz instead of 40. It still leaves room for about 12 concurrent 2.5 KHz-wide data-mode QSOs above 3570, or 10 if the wide mode operation are assumed to occupy 3KHz each. I think that's enough. (Of course, I *would* think that, since I'm not much interested in wide data modes below 10M. grin) Now let's move all of the keyboarding frequencies up by 10 Khz from Bonnie's proposals: PSK31 = 3545kHz USB (3545.3-3548.0 kHz) PSK31 = 3555kHz USB (3555.3-3558.0 kHz) QPSK31/PSK63/125 = 3547kHz USB (3547.3-3550.0 kHz) QPSK31/PSK63/125 = 3557kHz USB (3557.3-3560.0 kHz) MFSK = 3548kHz USB (3548.3-3551.0 kHz) MFSK = 3558kHz USB (3558.3-3561.0 kHz) OLIVIA500 = 3549kHz USB (3549.3-3553.0 kHz) OLIVIA500 = 3559kHz USB (3559.3-3563.0 kHz) CONTESTIA/DOMINO, etc = 3550kHz USB (3550.3-3554.0 kHz) CONTESTIA/DOMINO, etc = 3560kHz USB (3560.3-3564.0 kHz) HELL/FMHELL = 3552kHz USB (3552.3-3555 kHz) HELL/FMHELL = 3562kHz USB (3562.3-3565 kHz) RTTY/FSK = 3555+ (3555.3-3565 kHz) RTTY/FSK = 3565+ (3565.3-3575 kHz) PAX/MT63/OLIVIA1000 = 3560kHz USB (3560.5-3563) PAX/MT63/OLIVIA1000 = 3570kHz USB (3570.5-3573) As always, the CW folks, when they need elbow room, are free to move up the band, but we can at least hope that they will go fight it out with the Pactor3/Winlink crowd at the top of the band, rather with the experimenters and narrow-mode operators in between. Comments? -- 73 DE KW6H, ex-AE6VW, Chris Jewell Gualala CA USA
[digitalradio] (unknown)
Skip Teller writes: My suggestion is definitely not to follow your suggestion! Just leave PSK31= activity where it is now! 3525-3600 is open for CW, Data, and RTTY by FCC = RO for all license classes, and there is no reason for PSK31 on 3580-3583 = to move, nor for W1AW CW code practice on 3581.5 to move, just because you= say it should.=20 Hmmm. I wish I had seen Skip's comment before I posted my last one. How about this: 3500-3550 CW only 3550-3580 Any modes, with wide data modes starting just below 3580, and working down 3580-4000 Any modes 500 Hz. Narrow data modes stay where they are now; wide modes grow down, CW grows up, and they meet in the middle as needed. The boundary between suggested CW-only and suggested wide data could be 3540 (like Bonnie's proposal) or 3550 (my previous suggestion), without it mattering too much, since they grow towards each other as needed. -- 73 de kw6h, ex-ae6vwChris Jewell, Gualala CA USA
[digitalradio] USA FCC: Technology Death Row for HF Data
expeditionradio writes: Wow. It appears that the FCC has actually redefined Data below 30MHz at less than 500Hz... data in the common way that 99% of hams send data using digital modes on computers and ham transceivers. I've often said that the antiquated content-based FCC rules have been like a Technology Jail for USA hams. Just when it appeared that we might be given our freedom, joining the rest of the world's hams using state-of-the-art HF digital technology... someone at FCC just sentenced us back to the Digital Dark Ages. Was this cruel act done by intention or was it just a sloppy error? Who knows? 15 December will be a very sad day indeed... USA hams will be sitting on Technology Death Row for HF data. :( Bonnie KQ6XA I agree that the present arrangement is bad, but I'm hoping that the FCC acts soon on regulation-by-bandwidth, at which point all modes less than 3KHz wide will presumably be legal from 3.6 to 4.0 MHz, with regional band-planning rather than government regulation to split the available spectrum among voice, data, SSTV, and whatever we haven't thought of yet. I certainly wish that regulation-by-bandwidth had been rolled into the current rulemaking, but the next-best choice is for the Commission to act promptly on that matter now that the current rules are out. (I also think that the bottom of the extra-class phone or widemodes area should have been at 3650 KHz or higher, because the new rules interfere with existing CW traffic nets, but that's another discussion.) Even so, of course, there will still be isses: the band plan for IARU Region 2 between 3.6 and 4.0 MHz should be such that US General class licensees can use up-to-3KHz data modes to communicate with hams in other countries in the region, or better yet, world-wide, without violating the band plan. 73 DE KW6H (ex ae6vw) Chris
[digitalradio] Re: BPL-Busting Modes/Techniques
jgorman01 writes: just did this using my RF generator. WWV at 5 Mhz is about 10 over S9. The generator is at about S5 with no antenna connected and the lead just resting on top of the transceiver. When I switch the generator on, the S-meter moves not a bit. You would expect it to jump considerably if the RF signals were being added together. If the S-meter calibration is the classic 6 dBs per S-number, the ratio between S5 and S9+10dB is 34 dB, or a factor of more than 2500:1. 1 uW added to 25 mW, for example, should not be expected to make a visible difference in a meter reading. 73 de KW6H, ex AE6VW -- Chris Jewell [EMAIL PROTECTED] Gualala CA USA 95445 Need a Digital mode QSO? Connect to Telnet://cluster.dynalias.org Other areas of interest: The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/ DigiPol: http://groups.yahoo.com/group/Digipol (band plan policy discussion) 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: RTTY Hall of Shame
Dave Cole (NK7Z/NNN0RDO) writes: ... Unless there has been a rule change, enforcement of this must be on a voluntary basis, period, I saw a post about involving the OOs, and the FCC. Has this frequency been officially allocated? If not, then involving an OO would be real abuse of power, as they are supposed to enforce rules not wishes. 14100 kHz +/- 500 Hz at least is designated exclusively for beacon operation in the band plans of all 3 IARU regions. I'm assuming that I decoded the Region 3 plan correctly: it's a MSWord document, and nothing on my system understands those, so I had to guess the meaning of the output from strings | more. Someone who runs Windows is welcome to check my reading w.r.t. Region 3. Whether the FCC (and other national administrations) treat violating an IARU Region band plan as violating the good amateur practice provision of the rules is unclear to me. However, an OO notice, even if not an FCC citation and fine, does seem (IMHO) appropriate for violating the band plan. I do doubt, though, the value of a privately-sponsored public pillory for the offenders. While many contesters operate courteously (I try to on my rare forays into contesting), it is clearly true that some contesters think nothing in the world is more important than their point score. However, I doubt that the kind of lid who QRMs even disaster traffic for the sake of contest points is going to be motivated to improve his manners by appearing in anyone's online Hall of Shame. Such people are probably incapable of shame. If they even notice their nomination, the most they might do is send a reply in gutter language to the OP, and go on behaving at least as badly as before. My first reaction to the Hall of Shame posting was delight that Bonnie had called the lids on their misbehavior, but upon further reflection, I doubt that any good will come from it, beyond Bonnie's personal satisfaction in calling a spade a spade. I'll close by inviting readers' attention to the late Richard Mitchell's essay Yet Another Losing Season: http://www.sourcetext.com/grammarian/newslettersv09/9.6.htm. It makes no mention of ham radio, but if you read it, you'll see why I thought of it in this context. -- 73 DE KW6H, ex AE6VW Chris Jewell Need a Digital mode QSO? Connect to Telnet://cluster.dynalias.org Other areas of interest: The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/ DigiPol: http://groups.yahoo.com/group/Digipol (band plan policy discussion) 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] New to Digital HF -- PACTOR setup and hardware maybe needed???
KV9U writes: Chris, What is your view on using pipelined programming such as what was used in the SCAMP mode to get around this issue with moving the ACK to the next packet. The main penalty is latency for the user, but it seems manageable. I haven't read any detailed specs of the SCAMP protocol, only vague descriptions, and I understand that the source code is not available for public inspection at this time, but in principle a pipelined approach seems like a good way to handle the problem of OS latency in ACK/NAK at the application level, without requiring expert hackery in low-level OS details. My previous reply was just an attempt to describe the problem of non-realtime operating systems and lockstep ARQ modes such as Pactor for someone who had asked. I note that another reply said that there is a alternative real-time-capable kernel for Linux systems, so for those willing and able to use Linux, the ARQ problem may be already solved. However, a solution available to the Windows and Mac users seems like a good thing even so. In TCP, the receiving host periodically sends an ACK that responds NOT to a specific incoming packet, but instead says I have received correctly everything up to byte number N. If the sending host doesn't get an ACK up through the bytes in a given packet within a certain interval, it resends the data and all following data. This allows communication to succeed eventually if some ACKs or NAKs don't get back to the sending station. Of course, TCP/IP was conceived for full-duplex media: the sender can keep the outgoing pipe full, provided the ACKs arrive soon enough. The window size (how many bytes ahead of the ACK the sender may send) needs to be larger for faster circuit, and also larger for a circuit with a long round-trip time, such as via geosynch satellites or with many overloaded routers in the path; the window can be smaller for terrestrial circuits with few routers between the communicating hosts. Partly because incorrect packets are going to be more frequent on HF radio than on land lines, we probably should not duplicate the TCP solution in ham radio, but it gives us a starting point to think about. A system for half-duplex HF radio circuits has to provide for periodic turnaround. Short packets with frequent ACK/NAK cycles a la Pactor or GTOR allow the receiver to promptly notify the sender of changing propagation on the channel. A deep pipeline postpones that feedback, so more data may need to be resent when the circuit is unstable, BUT also makes it straightforward to implement on a typical multitasking OS. It's all a matter of trade-offs. Given that we deal with noiser circuits than were envisioned by the designers of TCP/IP, we probably want a fixed (or periodically adjusted) packet size, and a fixed number of packets sent before turnaround. The ACK would then say which of the packets arrived clean and which need to be resent. The sender could then resend those packets which need it, and add some more new ones to make up the agreed number to be placed in the pipeline. (For the sake of argument, how about 8 Pactor-sized packets followed by an ACK window 8 times as long as Pactor uses?) This is off the top of my head: if anyone has already been thinking more deeply about this and has better suggestions, by all means offer them. I'm an old computer geek but a new ham: I'm happy to learn about either computers or radio from anyone who can improve my understanding. -- 73 DE AE6VW Chris Jewell[EMAIL PROTECTED]Gualala CA USA 95445 Need a Digital mode QSO? Connect to Telnet://cluster.dynalias.org Other areas of interest: The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/ DigiPol: http://groups.yahoo.com/group/Digipol (band plan policy discussion) Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/digitalradio/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
[digitalradio] -tor modes and PCs
jhaynesatalumni writes: I'm willing to believe that the timing tolerances in -tor modes are so tight that ordinary PC operating systems cannot cope with them the way a dedicated processor can. What I don't understand is why the tolerances need to be so tight. The transmitter sends a packet and then listens for an ACK or NAK. Why can't it wait arbitrarily long? The ACK time could be made as long as you like, but the throughput would suffer accordingly. For example, with Pactor I, (according to p. 9-24 of the 2005 ARRL Handbook), the sender sends the packet in 0.96 seconds, then propagation delays and receipt of the ACK takes 0.29 seconds, for a total of 1.25 seconds per packet. If we increase the ACK delay to be the same as the transmit time, the total time per packet would be 1.92 seconds for the same amount of data as Pactor I sends in 1.25 second, and the throughput would be 1.25/1.96 or approximately 0.65 times what the present protocol delivers. Is it doable? Yes. Would most hams want it? I have my doubts. To get the same throughput with a longer ACK time, you have to make the transmit time longer too, so it bears the same relationship to the total time as it does now. That means either a much longer data packet, or a pipelined group of packets covered by a single ACK. The longer the packet, the greater chance that a static crash or other event will corrupt the packet, so we're back to talking about pipelined packets. -- 73 DE AE6VW Chris JewellGualala CA USA Need a Digital mode QSO? Connect to Telnet://cluster.dynalias.org Other areas of interest: The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/ DigiPol: http://groups.yahoo.com/group/Digipol (band plan policy discussion) Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/digitalradio/ * 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] The digital throughput challenge on H
KV9U writes:
If you want to broadcast a message from one to many, then the only
practical alternative is to use a non-ARQ mode, typically with a large
amount of FEC. While this is done on amateur frequencies for sending a
bulletin, calling CQ, and having a roundtable, if your goal is to have
accurate messaging, then I don't see any option other than a good ARQ
system.
A protocol for sending email messages over HF could have the
following behavior:
1. Sending station sends the message in packets of a specified or
negotiated size.
2. Each packet begins and ends with reserved control characters
and is followed with a CRC-16 of the packet.
3. Receiving station keeps track of which packets were received with
good CRC and which were garbled.
4. Upon receiving end-of-message, or at a pause after a defined or
negotiated number of bytes or packets have been sent, the
receiving station acknowledges all, or all up to a certain packet,
or requests repeats of those packets which were received in error.
It sends a complete ack only after all the packets have been
received successfully.
5. The sending station resends the failed packets then continues with
send further packets of this message, or starts the next message
using a higher packet number, or whatever.
This is analogous to CW/voice traffic handling, where the receiving
station either acknowledges receipt or sends ?wa, ?aa, say
again {word|all} after, or the like.
This suggestion has at least one disadvantage compared to ARQ modes:
the sending station does NOT get feedback after each packet telling it
that it can switch to a faster and less robust submode, or that it
should switch to a slower and more-robust one. Therefore, it may take
longer than necessary to get the message through, whether due to
repetitions that wouldn't have been necessary with prompt feedback, or
by sending more slowly than necessary. On the other hand, it
eliminates the ACK turnaround timing problems that prevent both some
radios and some PC OSes from working well for ARQ comms.
In essence, we are moving the reliability issue from the transport
layer to the application layer. Such an email system could sit on top
of anything from unchecked BPSK31 to FEC'ed MFSK-16 or MT-63, though
of course many more retransmissions would be needed with the former
than with the latter. Our choice of mode may depend partly on the
band, BPSK-31, -63, or even -125 on 20M meters and up, but MFSK16 or
MT63 on 160, 80, and 40, for example.
It might be better to establish a separate layer between transport and
application that could be shared by applications such as email, SSTV,
and file transfer.
This is a very old idea: IP sends packets which may get lost; TCP uses
IP but retries until the data gets through, or gives up and tells the
application layer that it failed; SMTP uses TCP's reliable data stream
to deliver email. It's just that a reliable delivery layer for
half-duplex HF radio is quite different from one for a full-duplex
terrestrial WAN or a full-duplex satellite relay, or even PTP which
carries TCP/IP, IPX, etc over landline modems or ISDN. Between half
duplex with longish turnarounds, and such joys as QSB and QRN, the
HF case is much more challenging.
I'm sure that other hams are working on such ideas already, and we may
be able to borrow techniques developed for commercial or military HF
datacomm at small or no monetary cost. PCALE and Open5066 are
examples, though I don't yet know much about the latter, and so have
no opinion as to whether it will prove fit for ham use. Obviously,
the people working on it think it is, and they know much more about it
than I, so I'm hopeful.
--
73 DE AE6VW Chris JewellGualala, CA, USA
Need a Digital mode QSO? Connect to Telnet://cluster.dynalias.org
Other areas of interest:
The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/
DigiPol: http://groups.yahoo.com/group/Digipol (band plan policy discussion)
Yahoo! Groups Links
* To visit your group on the web, go to:
http://groups.yahoo.com/group/digitalradio/
* To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
* Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
[digitalradio] help with digipan
kf4uul writes: Trying to get digipan running on a laptop running xp. Have it downloaded ,when it starts up all I get is a box saying error opening com 4, try again yes or no. If you click yes box stays if you click no, a new box comes up that says digipan has encountered a problem and needs to close. Anyone had this happen, how did you fix it.Thanks for any help. KF4UUL Without direct experience with the program, I'd look for a menu setup item or an entry in a configuration file to tell the program to use COM1 instead of COM4. I doubt that any laptop has a COM4 port. 73 DE AE6VW, Chris -- Chris Jewell [EMAIL PROTECTED] Need a Digital mode QSO? Connect to Telnet://cluster.dynalias.org Other areas of interest: The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/ DigiPol: http://groups.yahoo.com/group/Digipol (band plan policy discussion) Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/digitalradio/ * 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] Preferred PC-to- Rig Interface?
kd4e writes: Hmmm. Sounds as though if I wish to cover all modes I will need something more than a sound card as some of them need more interface help than others! Perhaps not, since you're a Linux user. Although I haven't tried it myself yet, I *think* you'll find that hfterm on Linux runs PACTOR-1 and AMTOR in ARQ mode with a sound card. Windows users need a multimode controller for ARQ modes, because Windows doesn't respond to interrupts quickly enough, but Linux does not. Let us know how hfterm works out for you in the ARQ modes. Good luck. 73 de ae6vw, Chris Need a Digital mode QSO? Connect to telnet://208.15.25.196/ Other areas of interest: The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/ DigiPol: http://groups.yahoo.com/group/Digipol (band plan policy discussion) Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/digitalradio/ * 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] Winlink vs. Winlink 2000 et al
Andrew J. O'Brien writes: For the record, I don't even want to use ANY software that had such potentially disabling code. I may have missed some of this thread, are you talking about software that would disable if there was a signal present on the frequency? I I don't think so. The quoted message was NOT about code to prevent QRMing an existing QSO, which I'm pretty sure everyone on the list would agree is a good idea, if not mandatory. Replacing robot lids with robot considerate ops is surely progress. :-) The Winlink guy said that the programmers SHOULD have put a timebomb in the original WL program, so it wouldn't run after a certain date (now in the past), and added lesson learned, which I interpret to mean that there is probably a timebomb in WL2K, and that there will surely be one in future programs from the same person or team. I think the message you quoted means that timebombed code is bad: I certainly agree, especially w.r.t. emergency communications. I'm a worker-bee emcommer, not the drafter of my local group's plans, but I certainly hope that no one involved in EmComms planning depends on any program supplied by people who think that timebombs are a good idea. Given the earlier message from the WL guy, and the League's position promoting the use of WL2K for emcomms, there is a risk that ham radio may avoidably fail to deliver a message needed to prevent deaths, injuries, or property damage in an emergency. A program that must be reliable, because human safety depends on it, should be a simple as it can be and still get the job done. Features that are not necessary should be omitted, because they may harbor disabling bugs that could get someone killed, or at least could prevent them being saved or assisted. In such a context, a timebomb is certainly an unnecessary feature. Software development decisions that are acceptable for games or business software can get people killed when used in programs critical to human life. 73 DE AE6VW, ex-KG6YLS -- Chris Jewell [EMAIL PROTECTED] PO Box 1396 Gualala CA 95445 Yahoo! Groups Sponsor ~-- Get fast access to your favorite Yahoo! Groups. Make Yahoo! your home page http://us.click.yahoo.com/dpRU5A/wUILAA/yQLSAA/ELTolB/TM ~- The K3UK DIGITAL MODES SPOTTING CLUSTER AT telnet://208.15.25.196/ More info at http:///www.obriensweb.com Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/digitalradio/ * 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/
