[digitalradio] Seventh ANNUAL 070 CLUB PSKFEST 12 January 2008
Seventh ANNUAL 070 CLUB PSKFEST Sponsored by the Penn-Ohio DX Society (PODXS) PURPOSE To work as many stations as possible in the allotted time using PSK31 mode. ENTRY CATEGORIES (SINGLE OP ONLY) QRP Single Band (max power 5 watts output) QRP Multiband (max power 5 watts output) Low Power (max power 50 watts output) Medium Power (max power 100 watts output). DATE: Z-2400Z, 12 January 2008 EXCHANGE: Call sign, signal report and state/province/country (SPC). Call CQ PSKFEST. BANDS: 80 thru 10 meters, no WARC bands. Work each station once/band. All contacts must be 2-way PSK31. No repeater, cross-mode or cross-band contacts allowed. SCORING: QSO points - Each contact counts one (1) QSO point, dupes count (0) points. Multipliers - Each different state/province/country (SPC) worked. Use current ARRL DXCC list for country reference. Final Score = (Total QSO Points) x (Total Different SPC's). Scoring Notes: First U.S. station worked counts as two (2) multipliers (country and state). First VE station worked counts as two (2) multipliers (country and province). First Alaska station worked counts as two (2) multipliers (country and state). First Hawaii station worked counts as two (2) multipliers (country and state). AWARDS: Top score will receive a trophy, courtesy of the Penn-Ohio DX Society (PODXS). Top scores from each continent will receive a certificate. All 070 Club member entries received will automatically qualify for an Attaboy. For more info on the 070 Club check out http://www.podxs.com/html/070_club.html. ENTRIES: Send log data showing date, time(z), band, exchange received and claimed score. For entries with 100 contacts or more include a dupe sheet listing contacts in call sign alphanumeric order. Be sure to also include your call sign, address, e-mail address, entry class and 070 Club member number if applicable. Send your entry as a .txt file via E-mail (best way) to [EMAIL PROTECTED] or via post to: JAY BUDZOWSKI 070 CLUB PSKFEST 109 S. NORTHVIEW AVE. NEW CASTLE, PA 16102-1633 USA All entries must be received by February 15, 2008. A listing of logs received and claimed scores will be posted on the 070 Club web site http://mysite.verizon.net/jbudzowski/2008_pskfest_results.htm. Entries with excessive dupes will be listed as check logs. All entries are subject to verification. PSKFEST LINKS: Rules - http://www.podxs.com/html/pskfest.html. 2008 Results - http://mysite.verizon.net/jbudzowski/2008_pskfest_results.htm. Results Archives - http://mysite.verizon.net/jbudzowski/pskfest_results.htm. PODXS 070 Club - http://www.podxs.com/html/070_club.html. The Penn-Ohio DX Society (PODXS) reserves the right to disqualify entries deemed not in accordance with the above rules or contrary to the spirit of this event. Please direct all inquiries regarding this event to [EMAIL PROTECTED]73 de Jay N3DQU --- -- Andy K3UK www.obriensweb.com (QSL via N2RJ)
[digitalradio] Robust Packet-Radio (RPR)
I found the item (below) on the SCS web site. Anyone use this new class of packet ? Robust Packet-Radio (RPR) Up to now Packet-Radio over shortwave has been basically a non-starter, it has even been heavily criticized because of the low effective throughput and repeats. AX.25 is for shortwave not an ideal protocol, but with automatic FRack-setting and a small MAXFrame value the protocol should, however, function much better on a shortwave channel than has previously been the case generally. One cannot of course expect an asynchrone protocol to reach the same efficiency as a tight synchrone ARQ protocol (e.g. PACTOR), but for some applications a multi-user service, with very uncritical transmit/receive switching, as well as almost zero power holding up a connection when no data passing, brings a real advantage that outweighs the lower data throughput. What finally are the reasons that up to now HF-PR works so poorly, and apart from forwarding is hardly ever used? One finds a simple answer: The current modulation type for HF-PR namely uncoded 300 Bd FSK is really unsuitable for normal HF channels. The symbols are much too short even with moderate Multi-Path effect (delay spread) to work. Additionally, because no sort of error correction code is used, even short troughs or static will destroy a many seconds long Packet. Just one missing bit leads to a repeat of the whole packet. To help cure this problem, SCS has developed a new class of robust modulations types especially for Packet-Radio. As a special feature for all the variants of this Robust PR, a completely new synchronizations algorithm with catch properties that were not possible before has been realized. Frequency deviations of ±250 Hz are immediately recognized and without any loss of sensitivity compensated, and this with signals that are buried deep in the noise. Because of this it's possible to remove a tuning display. One can say with good conscience that this is Plug and Play for shortwave. The currently available Robust PR modulation types have the following properties: Bandwidth: 500 Hz @ -30 dB Modulation: Pulse-Shaped OFDM (BPSK, QPSK), similar to PACTOR-III Average Throughput: 200 or 600 Bit/sec Crestfaktor:3.0 or 4.2 dB Delay-Spread: up to ±8 msec is tolerated Coding: High performance convolutional code, full-frame interleaved, rate/2 or rate3/4 Digipeater and APRS Gateway DB0UAL DialModePath 3610.0 USB RPR APRS DB0UAL 14102.0 USB RPR APRS DB0UAL APRS Gateway XY0XYZ DialModePath 10147.3 USB RPR FSK300 APXY RELAY WIDE 14103.3 LSB RPR FSK300 APXY RELAY WIDE DH1TI DialModePath 10147.3 USB RPR APRS OE3XMU-4 DialModePath 10147.3 USB RPR FSK300 APRS OE3KJN DialModePath 10147.3 USB RPR APRS ZS1AAZ DialModePath 10147.3 USB RPR APRS Note: To use the following features you need the current Firmware for the SCS DSP-TNC: Legende: Recommendation: For transmitting position data with the Tracker/DSP TNC, we suggest always to use the frequencies as shown in the list with the respective sideband. The position data can then be transmitted either only in RPR, or in RPR and FSK alternately (%AH = 1). In both operating conditions all physical channels are then automatically set in the correct way. (In case of an alternating transmission, i.e. %AH = 1, the Tracker automatically uses %F = 2000 Hz, in order to set the correct interval of 500 Hz between RPR and FSK channels without any user intervention.) With gateways offering RPR and FSK 300 on one channel simultaneously, it is assumed that the center audio frequency of the FSK demodulator (%F-parameter) is 500 Hz higher than the center audio frequency of the RPR demodulator. The space between the center frequencies of a simultaneous FSK/RPR channel pair is always 500 Hz. Basically, gateways receiving RPR and FSK300 simultaneously can also be reached in FSK300 with the %F standard setting of the Tracker (center frequency of 1700 Hz) in LSB mode. In this case, if LSB is actually used, 3.7 kHz have to be added to the figure shown in USB dial frequency listings. In case of an LSB channel, 0.3 kHz have to be deducted from the listed frequency. Gateways shown in the list as 10147.3 kHz USB can hence be reached in LSB mode with the standard setting of the Tracker (%F = 1700 Hz, %AH = 0) on the standard dial frequency of 10151.0 kHz. Gateways listed as 14103.3 kHz LSB, can be reached in LSB with the default setting of the Tracker (%F = 1700, %AH = 0) on the standard dial frequency of 14103.0 kHz. In case of alternating RPR and FSK transmissions (%AH = 1), the frequencies shown in the list and the respective side bands have to be programmed. For example, the dial frequencies of 10151.0 kHz LSB or 14103.0 kHz USB MUST NOT be set, as neither the RPR, nor the FSK channel would be reached correctly. -- Andy
[digitalradio] Software for the digital ham that multi-tasks while sleeping ?
If you are like me, there is SO MUCH happening in the amateur radio digital world that it is hard to keep up with , more fun to be had than can be squeezed in to 24 hours. Some software ,like WSJT, can be left active overnight or when out of the shack and the user gets time stamped information about stations detected while they were out. This is very useful but it is static, simply monitoring one frequency and one mode. What would it take to develop an application that can scan different frequencies at larger time intervals that the scan mode in modern rigs. Perhaps something that is user defined. Something that might monitor 14070 for 15 minutes and then automatically move to 3581 for an hour , then to 7034 for 30 minutes . Not only would this software change frequency at designated times, it might switch modes too. Listening on 14070 in PSK31 , changing to JT65A and QSYing to 14076 for 20 minutes, and even listening to Olivia on 3581 , etc etc. I guess this could be a major add-on to something like Multipsk or DM780 but maybe it would take another form , something akin to DX Lab Launcher. DX Lab Launcher enables the user to launch varying DX Lab Suit applications , something like this could be used to launch and close different applications at specified times. Example: At 1400Z it launches Winwarbler in RTTY mode, at 1500 it closes Winwarbler and launches Multipsk in Olivia 500/16 and at 1700 it launches VB-Digi/FLARQ in PSK250 . Anyone care to invent this ? -- Andy K3UK www.obriensweb.com (QSL via N2RJ)
Re: [digitalradio] Software for the digital ham that multi-tasks while sleeping ?
Andy, I believe that somehow it has been already done and is hidden to most of us. How ? I have not tried to run the recent Linux ham apps from the command line, but the cron can be used to start and stop tasks in one minute intervals. You can invoke either applications or scripts with arguments. Years ago (some 8+ years ago), I used the FBB cron to switch bands with an automatic antenna tuner / switch, that even allowed remote QSY of the BBS with a simple CAT program I wrote for the FT-757. I am crossposting this reply to both linuxham* lists and the WSJT Group, because that even when I have not done it, somebody might already have done it and might comment about this. 73, Jose, CO2JA -- Andrew O'Brien wrote: If you are like me, there is SO MUCH happening in the amateur radio digital world that it is hard to keep up with , more fun to be had than can be squeezed in to 24 hours. Some software ,like WSJT, can be left active overnight or when out of the shack and the user gets time stamped information about stations detected while they were out. This is very useful but it is static, simply monitoring one frequency and one mode. What would it take to develop an application that can scan different frequencies at larger time intervals that the scan mode in modern rigs. Perhaps something that is user defined. Something that might monitor 14070 for 15 minutes and then automatically move to 3581 for an hour , then to 7034 for 30 minutes . Not only would this software change frequency at designated times, it might switch modes too. Listening on 14070 in PSK31 , changing to JT65A and QSYing to 14076 for 20 minutes, and even listening to Olivia on 3581 , etc etc. I guess this could be a major add-on to something like Multipsk or DM780 but maybe it would take another form , something akin to DX Lab Launcher. DX Lab Launcher enables the user to launch varying DX Lab Suit applications , something like this could be used to launch and close different applications at specified times. Example: At 1400Z it launches Winwarbler in RTTY mode, at 1500 it closes Winwarbler and launches Multipsk in Olivia 500/16 and at 1700 it launches VB-Digi/FLARQ in PSK250 . Anyone care to invent this ? -- MSc. Jose Angel Amador Fundora Departamento de Telecomunicaciones Facultad de Ingenieria Electrica, CUJAE Calle 114 #11901 e/ 119 y 127 Marianao 19390, Ciudad de la Habana, Cuba Tel:(53 7) 266-3445 Email: [EMAIL PROTECTED] __ Participe en Universidad 2008. 11 al 15 de febrero del 2008. Palacio de las Convenciones, Ciudad de la Habana, Cuba http://www.universidad2008.cu
Re: [digitalradio] Robust Packet-Radio (RPR)
At 09:27 PM 1/11/2008, Andy wrote: I found the item (below) on the SCS web site. Anyone use this new class of packet ? Robust Packet-Radio (RPR) Up to now Packet-Radio over shortwave has been basically a non-starter, it has even been heavily criticized because of the low effective throughput and repeats. AX.25 is for shortwave not an ideal protocol, but with automatic FRack-setting and a small MAXFrame value the protocol should, however, function much better on a shortwave channel than has previously been the case generally. One cannot of course expect an asynchrone protocol to reach the same efficiency as a tight synchrone ARQ protocol (e.g. PACTOR), but for some applications a multi-user service, with very uncritical transmit/receive switching, as well as almost zero power holding up a connection when no data passing, brings a real advantage that outweighs the lower data throughput. What finally are the reasons that up to now HF-PR works so poorly, and apart from forwarding is hardly ever used? One finds a simple answer: The current modulation type for HF-PR namely uncoded 300 Bd FSK is really unsuitable for normal HF channels. The symbols are much too short even with moderate Multi-Path effect (delay spread) to work. Additionally, because no sort of error correction code is used, even short troughs or static will destroy a many seconds long Packet. Just one missing bit leads to a repeat of the whole packet. To help cure this problem, SCS has developed a new class of robust modulations types especially for Packet-Radio. As a special feature for all the variants of this Robust PR, a completely new synchronizations algorithm with catch properties that were not possible before has been realized. Frequency deviations of ±250 Hz are immediately recognized and without any loss of sensitivity compensated, and this with signals that are buried deep in the noise. Because of this it's possible to remove a tuning display. One can say with good conscience that this is Plug and Play for shortwave. The currently available Robust PR modulation types have the following properties: Bandwidth:500 Hz @ -30 dB Modulation:Pulse-Shaped OFDM (BPSK, QPSK), similar to PACTOR-III Average Throughput:200 or 600 Bit/sec Crestfaktor:3.0 or 4.2 dB Delay-Spread:up to ±8 msec is tolerated Coding:High performance convolutional code, full-frame interleaved, rate/2 or rate3/4 Digipeater and APRS Gateway DB0UAL DialModePath 3610.0 USBRPRAPRS DB0UAL 14102.0 USBRPRAPRS DB0UAL APRS Gateway XY0XYZ DialModePath 10147.3 USBRPR FSK300APXY RELAY WIDE 14103.3 LSBRPR FSK300APXY RELAY WIDE DH1TI DialModePath 10147.3 USBRPRAPRS OE3XMU-4 DialModePath 10147.3 USBRPR FSK300APRS OE3KJN DialModePath 10147.3 USBRPRAPRS ZS1AAZ DialModePath 10147.3 USBRPRAPRS Note: To use the following features you need the current Firmware for the SCS DSP-TNC: Legende: Recommendation: For transmitting position data with the Tracker/DSP TNC, we suggest always to use the frequencies as shown in the list with the respective sideband. The position data can then be transmitted either only in RPR, or in RPR and FSK alternately (%AH = 1). In both operating conditions all physical channels are then automatically set in the correct way. (In case of an alternating transmission, i.e. %AH = 1, the Tracker automatically uses %F = 2000 Hz, in order to set the correct interval of 500 Hz between RPR and FSK channels without any user intervention.) With gateways offering RPR and FSK 300 on one channel simultaneously, it is assumed that the center audio frequency of the FSK demodulator (%F-parameter) is 500 Hz higher than the center audio frequency of the RPR demodulator. The space between the center frequencies of a simultaneous FSK/RPR channel pair is always 500 Hz. Basically, gateways receiving RPR and FSK300 simultaneously can also be reached in FSK300 with the %F standard setting of the Tracker (center frequency of 1700 Hz) in LSB mode. In this case, if LSB is actually used, 3.7 kHz have to be added to the figure shown in USB dial frequency listings. In case of an LSB channel, 0.3 kHz have to be deducted from the listed frequency. Gateways shown in the list as 10147.3 kHz USB can hence be reached in LSB mode with the standard setting of the Tracker (%F = 1700 Hz, %AH = 0) on the standard dial frequency of 10151.0 kHz. Gateways listed as 14103.3 kHz LSB, can be reached in LSB with the default setting of the Tracker (%F = 1700, %AH = 0) on the standard dial frequency of 14103.0 kHz. In case of alternating RPR and FSK transmissions (%AH = 1), the frequencies shown in the list and the respective side bands have to be programmed. For example, the dial frequencies of 10151.0 kHz LSB or 14103.0 kHz USB MUST NOT be set, as neither the RPR, nor the FSK channel would be reached correctly. -- Andy K3UK www.obriensweb.com (QSL via N2RJ) Its been around for a while :-) Works well too. But dontcha know?Packet is no good, its outdated, can't stream Video across
[digitalradio] Re: Curmudgions and an idea for digital operation
I've been remiss in answering some of your questions. You'll either have the start of a pactor type emission or an illegal emission type. I had this argument several years ago when pactor 3 showed up. If you look at J7D, it is defined as Single-sideband, suppressed carrier; with two or more channels containing quantized or digital information; consisting of data transmission, telemetry, telecommand. I'm still not sure how pactor 3 got designated as J2D rather than J7D. The only answer I got was that pactor 3 modems are designed to be connected to one computer at a time and the single data stream is multiplexed over all the tones that are in use. In other words, the modem itself is not a multiplexing device and there are not individual channels for different data streams. It seems to me that if you did the multiplexing in your computer so that you end up with only one data stream and did not dedicate psk channels to a given data channel then you would be ok. This would require some demuxing at the far end computer. You'll need to be careful in your design to make sure it doesn't get classed as J7D, which is not allowed on the amateur bands. Jim WA0LYK --- In digitalradio@yahoogroups.com, Alan Barrow [EMAIL PROTECTED] wrote: snip But back to digital radio I've got an idea to stack 3 psk signals together side by side and run in a normal SSB radio. Multiplex the data across the multiple psk paths. I think that would be legal, and technically possible. No restriction I see on multiple transmissions with different data streams. Any single signal meets symbol rate bandwidth fcc restrictions even as proposed by the new petition. Might could even do 4! Or maybe do the same with Pactor 1 to get ARQ, already looking at the linux source. Kind of like the fsk/afsk debate. Is it a different mode if you can't tell the signal's apart remotely? Turing test for radio. That's what I'll move to if we ban the wider data modes. Think it will work? Have fun, Alan
Re: [digitalradio] Software for the digital ham that multi-tasks while sleeping ?
In my own case I can record the incoming audio and play it back later. At the moment I leave DM780 running all night picking up SSTV pictures. I'm not sure I would want a scheduler but were I to add one I would use a UI similar to Outlook's calendar. Simon Brown, HB9DRV - Original Message - From: Peter G. Viscarola [EMAIL PROTECTED] What you're describing could be done quite easily from within a particular program. It could easily be built as an external program that sends ActiveX commands to MixW, for example.
Re: [digitalradio] Ale Sounding: What is it and how does it work?
John, Your message below is easy to summarize succinctly, thanks. At 09:48 PM 1/10/2008, you wrote: Chris , ZL1BOE you will be told by others that ALE is widely used to set up QSOs and QSYs using the one line message ability . You will also be told that it is used widely for keyboard to keyboard QSOs and that there are thousands of Hams using ALE ( last figure I heard was 6000) . These are folks who are using PCALE, who have aggressively set aside frequencies for ALE use in all bands, and are promoting ALE as the answer to emergency communications. FALSE Granted, PCALE, in its MARS form may be a great piece of software to pass messages from overseas TRUE NOTE: MARS does not make use of ALE for OCONUS traffic relay. but that ability is certainly not evident on the ham bands. FALSE The reality is that there are likely under 50 hams active with PCALE worldwide, those using PCALE spend most of the time sounding , with little , if any message traffic passed, and no QSOs. PCALE does not work very well into the noise, and is certainly not user friendly when setting up a rig and computer to run the program. Beyond using the sounding function there appears not to be much interest in running nets, or exploring emergency communications aspect of PCALE. FALSE ALE400 (multiPSK) might be closer to your needs since it is narrow band and works well into the noise. It can be readily used for soundings, file transfer, and is a pleasure to use for digital QSOs, keyboard to keyboard. The author is constantly working on the software, and appears to be moving closer to the Holy Grail of being able to pass messages and files from HF to the internet. It is simple to install, simple to use, (although the screen can be a little overwhelming at first) .There is a plan afoot which would see some extensive cross Canada testing of this mode to determine its suitability for emergency communications. TRUE There are some other software out there to look at. NBEMS has promise, but , since it uses BPSK for the most part, suffers from multipath flutter and other ozone maladies. The authors state that its intention was to run over VHF/UHF, and , while I havent tried it, would probably work very well. This software is also under active development so will be interesting to see what other capabilities it will have. TRUE RFSM8000 gets very little mention on these reflectors, since hams in the USA cannot exceed 300baud speed. Dimitry and his team have posted the latest version which looks interesting , but havent tried it, but is something we can run here in Canada on most bands except 30m.( bandwidth issues rather than speed) It apparently has the ability to pass traffic to and from the internet from HF, using a sound card modem. TRUE So much software, so little time . SO TRUE /s/ Steve, N2CKH 73s John VE5MU
Re: [digitalradio] Re: Emergency agencies/ ham equipment/ hams in emcomm
You have led a sheltered life. Try operating in the Philipines after a volcano blows, or in Mexico after the same incident, or in Africa after a transvaal fire, then tell me Hams are not needed. It's too bad we are getting comments like this from the uninformed with no experience. Get some beard growth and you'll rapidly change your mind. 73 Les At 08:13 AM 1/11/2008, jgorman01 wrote: --- In mailto:digitalradio%40yahoogroups.comdigitalradio@yahoogroups.com, Alan Barrow [EMAIL PROTECTED] wrote: snip I personally had a Red Cross shelter leader run after my truck and flag me down because she thought we were packing up. quote: You don't know how much we still need you guys. Until you arrived we had no communications since the big green helicopter landed and kicked out pallets or MRE's. The phones still don't work, please do not leave. Don't think that did not change my perspective and disillusionment. This is not an ego thing, exactly the opposite. Made me realize that independent of what I thought we could or should do (my ego), we had a job to do. I should set aside my annoyances preferences, that what we were doing was important and needed. Your first paragraph indicates that the shelter was so remote and isolated that it required helicopter delivery of food and water. Yet you also indicate that you were in your truck which indicates you could drive to the shelter. Maybe you were driving a monster truck? Some of this appears to be an appeal to emotion. I HAVE been around long enough to know neither the ARC or SA would open a shelter in a location that was not reachable by regular supply vehicles nor that had SOME kind of communications. I am pretty sure that the government authorities would not authorize this either. To do otherwise is simply asking for the shelter staff to require 'rescuing' at some time in the future thereby adding to the problem. Consequently, when you say no communications, you are overstating the facts. Now maybe, a runner in a vehicle may the only means of communication, but never the less, it is communications. snip I guess the core difference is some are saying we have no business even providing emergency service. And I believe that is a very extreme and unsound position. Your guess is wrong. No one I have seen post is saying that we have no business providing emergency communications where appropriate and in a manner that support the public best. snip So what's this have to do with digital radio? I think we have a large opportunity to contribute. We all want an alternative to $1k proprietary modems. But until we get that alternative there is some value there. That does not mean we can or should compromise operation in the rest of the bands. But there needs to be a place. Just like there should be for other digital modes, current and future. The whole idea that a legal limit rtty contest op is somehow appropriate allowed, yet other digi sigs should not be is non-sensical. Some of the new modes offer incredible performance efficiency. they can be fun for casual work. But they could also offer significant value in an emergency if harnessed. You might have continued and made an argument for full blown pactor 3 bandwidth for emergencies but you blew it by including casual use. The use of wide signals within a limited spectrum WILL displace several others that want to use narrow signals. It is obvious that you have no love for rtty, yet several rtty signals can fit into the bandwidth of a 2.2 kHz pactor 3 signal. Would you impinge upon their preferred mode of operation for your casual use? It sounds like it. No one is guaranteed a time or place to operate. The wider the signal you wish to use, the fewer places and times there are that you can use it. That's life, move on. I also assume you are upset over rm-11392 that would limit bandwidths. You really haven't made a case for casual use of anything wider than the 1.5 kHz that is being asked for. Remember, this bandwidth limit has been there for a long time, it just wasn't codified. The current rules were adequate prior to the introduction of ofdm modulation to the amateur bands. Pactor 3 is simply EXPLOITING a loophole in the way that the regulations are currently written. Perhaps you should write a comment to the fcc that you believe bandwidth limits are ok for all data modes except for ofdm emissions which should have no limits on their bandwidth. It sounds like that is what you wish. snip Have fun, Alan Jim WA0LYK No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.0/1218 - Release Date: 1/10/2008 1:32 PM
[digitalradio] Re: Emergency agencies/ ham equipment/ hams in emcomm
--- In digitalradio@yahoogroups.com, Alan Barrow [EMAIL PROTECTED] wrote: snip I personally had a Red Cross shelter leader run after my truck and flag me down because she thought we were packing up. quote: You don't know how much we still need you guys. Until you arrived we had no communications since the big green helicopter landed and kicked out pallets or MRE's. The phones still don't work, please do not leave. Don't think that did not change my perspective and disillusionment. This is not an ego thing, exactly the opposite. Made me realize that independent of what I thought we could or should do (my ego), we had a job to do. I should set aside my annoyances preferences, that what we were doing was important and needed. Your first paragraph indicates that the shelter was so remote and isolated that it required helicopter delivery of food and water. Yet you also indicate that you were in your truck which indicates you could drive to the shelter. Maybe you were driving a monster truck? Some of this appears to be an appeal to emotion. I HAVE been around long enough to know neither the ARC or SA would open a shelter in a location that was not reachable by regular supply vehicles nor that had SOME kind of communications. I am pretty sure that the government authorities would not authorize this either. To do otherwise is simply asking for the shelter staff to require 'rescuing' at some time in the future thereby adding to the problem. Consequently, when you say no communications, you are overstating the facts. Now maybe, a runner in a vehicle may the only means of communication, but never the less, it is communications. snip I guess the core difference is some are saying we have no business even providing emergency service. And I believe that is a very extreme and unsound position. Your guess is wrong. No one I have seen post is saying that we have no business providing emergency communications where appropriate and in a manner that support the public best. snip So what's this have to do with digital radio? I think we have a large opportunity to contribute. We all want an alternative to $1k proprietary modems. But until we get that alternative there is some value there. That does not mean we can or should compromise operation in the rest of the bands. But there needs to be a place. Just like there should be for other digital modes, current and future. The whole idea that a legal limit rtty contest op is somehow appropriate allowed, yet other digi sigs should not be is non-sensical. Some of the new modes offer incredible performance efficiency. they can be fun for casual work. But they could also offer significant value in an emergency if harnessed. You might have continued and made an argument for full blown pactor 3 bandwidth for emergencies but you blew it by including casual use. The use of wide signals within a limited spectrum WILL displace several others that want to use narrow signals. It is obvious that you have no love for rtty, yet several rtty signals can fit into the bandwidth of a 2.2 kHz pactor 3 signal. Would you impinge upon their preferred mode of operation for your casual use? It sounds like it. No one is guaranteed a time or place to operate. The wider the signal you wish to use, the fewer places and times there are that you can use it. That's life, move on. I also assume you are upset over rm-11392 that would limit bandwidths. You really haven't made a case for casual use of anything wider than the 1.5 kHz that is being asked for. Remember, this bandwidth limit has been there for a long time, it just wasn't codified. The current rules were adequate prior to the introduction of ofdm modulation to the amateur bands. Pactor 3 is simply EXPLOITING a loophole in the way that the regulations are currently written. Perhaps you should write a comment to the fcc that you believe bandwidth limits are ok for all data modes except for ofdm emissions which should have no limits on their bandwidth. It sounds like that is what you wish. snip Have fun, Alan Jim WA0LYK
RE: [digitalradio] Software for the digital ham that multi-tasks while sleeping ?
Anyone care to invent this ? What you're describing could be done quite easily from within a particular program. It could easily be built as an external program that sends ActiveX commands to MixW, for example. The only hang-up that I see is in terms of tuning: So, you tune to 14070 in PSK31 mode and listen for 20 minutes, or whatever. Suppose the station is on 14070.5? My point is that especially with these narrow modes, wouldn't what you're describing require activity directly on the frequency in question? PSK31 tuning is pretty fussy. de Peter K1PGV
Re: [digitalradio] PACTO! I CQ
Copying you FB in South Carolina, Howard, using DigiPan 2.0. Sorry - No Pactor 1 transmit capability - my PK-232 is in mothballs! Skip - Original Message - From: w6ids [EMAIL PROTECTED] To: digitalradio@yahoogroups.com; [EMAIL PROTECTED] Sent: Friday, January 11, 2008 2:10 PM Subject: [digitalradio] PACTO! I CQ Just for info, I'm on 18.085 running PACTOR I and calling CQ.pointed Westerly. I'm posted on the spotting page: http://www.projectsandparts.com/pactor/ if anyone might be interested.in trying it Howard W6IDS Richmond, IN No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.1/1219 - Release Date: 1/11/2008 10:19 AM
Re: [digitalradio] Re: Emergency agencies/ ham equipment/ hams in emcomm
Thanks Robert, I support you 100% 73 de LA5VNA Steinar n4ijs skrev: Hello! I am new to this forum, so please forgive me if this comes across off base. But, I came here looking for information on digital modes for Amateur Radio - not various, multi-post messages about various peoples opinion (and arguments) on unrelated topics. I am sure that these discussions are important to a select group of folks, but are there no other places for these types of discussions to take place? I belong to several Ham related Yahoo! forums and this one certainly produces (by far) the most emails; however, few are related to the topic at hand. So, I have to weed through these other messages to get to the real ones. If this just the way of this forum, that's fine - I will just unsubscribe. I hope that isn't the case, but, if it is, can anyone recommend a forum for exploring digital modes within Ham Radio? Thanks and 73, Robert - N4IJS --- In digitalradio@yahoogroups.com mailto:digitalradio%40yahoogroups.com, Rud Merriam [EMAIL PROTECTED] wrote: In Katrina and Rita shelters were opened where there were people in need. Whether supplies could readily reach them was a problem to be solved, not a requirement for shelter location. You are not understanding the widespread nature of these disasters. It was easier to solve the supply problem than the rescue problem. A supply truck or helicopter with supplies can make it in once a day. The multiple vehicles, trucks or helicopters, to evacuate people were not available. Your hypothetical versus others real world experience is misleading you. Rud Merriam K5RUD ARES AEC Montgomery County, TX http://TheHamNetwork.net http://TheHamNetwork.net Your first paragraph indicates that the shelter was so remote and isolated that it required helicopter delivery of food and water. Yet you also indicate that you were in your truck which indicates you could drive to the shelter. Maybe you were driving a monster truck? Some of this appears to be an appeal to emotion. I HAVE been around long enough to know neither the ARC or SA would open a shelter in a location that was not reachable by regular supply vehicles nor that had SOME kind of communications. I am pretty sure that the government authorities would not authorize this either. To do otherwise is simply asking for the shelter staff to require 'rescuing' at some time in the future thereby adding to the problem. Consequently, when you say no communications, you are overstating the facts. Now maybe, a runner in a vehicle may the only means of communication, but never the less, it is communications. Jim WA0LYK
[digitalradio] PACTO! I CQ
Just for info, I'm on 18.085 running PACTOR I and calling CQ.pointed Westerly. I'm posted on the spotting page: http://www.projectsandparts.com/pactor/ if anyone might be interested.in trying it Howard W6IDS Richmond, IN
[digitalradio] Re: Emergency agencies/ ham equipment/ hams in emcomm
Hello! I am new to this forum, so please forgive me if this comes across off base. But, I came here looking for information on digital modes for Amateur Radio - not various, multi-post messages about various peoples opinion (and arguments) on unrelated topics. I am sure that these discussions are important to a select group of folks, but are there no other places for these types of discussions to take place? I belong to several Ham related Yahoo! forums and this one certainly produces (by far) the most emails; however, few are related to the topic at hand. So, I have to weed through these other messages to get to the real ones. If this just the way of this forum, that's fine - I will just unsubscribe. I hope that isn't the case, but, if it is, can anyone recommend a forum for exploring digital modes within Ham Radio? Thanks and 73, Robert - N4IJS --- In digitalradio@yahoogroups.com, Rud Merriam [EMAIL PROTECTED] wrote: In Katrina and Rita shelters were opened where there were people in need. Whether supplies could readily reach them was a problem to be solved, not a requirement for shelter location. You are not understanding the widespread nature of these disasters. It was easier to solve the supply problem than the rescue problem. A supply truck or helicopter with supplies can make it in once a day. The multiple vehicles, trucks or helicopters, to evacuate people were not available. Your hypothetical versus others real world experience is misleading you. Rud Merriam K5RUD ARES AEC Montgomery County, TX http://TheHamNetwork.net Your first paragraph indicates that the shelter was so remote and isolated that it required helicopter delivery of food and water. Yet you also indicate that you were in your truck which indicates you could drive to the shelter. Maybe you were driving a monster truck? Some of this appears to be an appeal to emotion. I HAVE been around long enough to know neither the ARC or SA would open a shelter in a location that was not reachable by regular supply vehicles nor that had SOME kind of communications. I am pretty sure that the government authorities would not authorize this either. To do otherwise is simply asking for the shelter staff to require 'rescuing' at some time in the future thereby adding to the problem. Consequently, when you say no communications, you are overstating the facts. Now maybe, a runner in a vehicle may the only means of communication, but never the less, it is communications. Jim WA0LYK
Re: [digitalradio] Re: Emergency agencies/ ham equipment/ hams in emcomm
Robert, All these issues on exploring the digital modes are and should be discussed. It depends upon what interests the posters who are willing to share that information. Be thankful that they do. Many of these discussions are vital to amateur radio. The decisions to come will affect you personally. Perhaps in ways you like and then again perhaps in ways you do not like. You can choose to ignore them and not participate, this is up to each individual. As far as weeding, it does take work. I have to remove many posts that do not interest me such as on individuals making contacts through the group, that sort of thing, so it does sometimes take an extra minute per day to do this. For specific discussion on emergency communications, there is the hfdec (hams for disaster and emergency communication). There have been times I have asked a digital specific question and received no help. Probably because no one knows the answer. On the other hand, there have been many times that I have asked a question and received help. What specific digital information were you looking for that you can not find elsewhere? 73, Rick, KV9U n4ijs wrote: Hello! I am new to this forum, so please forgive me if this comes across off base. But, I came here looking for information on digital modes for Amateur Radio - not various, multi-post messages about various peoples opinion (and arguments) on unrelated topics. I am sure that these discussions are important to a select group of folks, but are there no other places for these types of discussions to take place? I belong to several Ham related Yahoo! forums and this one certainly produces (by far) the most emails; however, few are related to the topic at hand. So, I have to weed through these other messages to get to the real ones. If this just the way of this forum, that's fine - I will just unsubscribe. I hope that isn't the case, but, if it is, can anyone recommend a forum for exploring digital modes within Ham Radio? Thanks and 73, Robert - N4IJS
RE: [digitalradio] Re: Emergency agencies/ ham equipment/ hams in emcomm
In Katrina and Rita shelters were opened where there were people in need. Whether supplies could readily reach them was a problem to be solved, not a requirement for shelter location. You are not understanding the widespread nature of these disasters. It was easier to solve the supply problem than the rescue problem. A supply truck or helicopter with supplies can make it in once a day. The multiple vehicles, trucks or helicopters, to evacuate people were not available. Your hypothetical versus others real world experience is misleading you. Rud Merriam K5RUD ARES AEC Montgomery County, TX http://TheHamNetwork.net Your first paragraph indicates that the shelter was so remote and isolated that it required helicopter delivery of food and water. Yet you also indicate that you were in your truck which indicates you could drive to the shelter. Maybe you were driving a monster truck? Some of this appears to be an appeal to emotion. I HAVE been around long enough to know neither the ARC or SA would open a shelter in a location that was not reachable by regular supply vehicles nor that had SOME kind of communications. I am pretty sure that the government authorities would not authorize this either. To do otherwise is simply asking for the shelter staff to require 'rescuing' at some time in the future thereby adding to the problem. Consequently, when you say no communications, you are overstating the facts. Now maybe, a runner in a vehicle may the only means of communication, but never the less, it is communications. Jim WA0LYK
Re: [digitalradio] Robust Packet-Radio (RPR)
Rick, Well, its just another mode, to add to the pile! You get RPR with the SCS DSP Tracker, APRS is also using it and the DSP Tracker will send BOTH mode APRS frames out, that is a standard 300 baud HF Packet data frame, THEN the next one out is an RPR frame, alternating. This is so any RPR OR standard 300 baud stations or IGATEs will pick up the signals. At least in this case, SCS thought of the 300 baud HF Packet users on APRS, when they developed this TNC. The other SCS PTC models also have the RPR mode too. I think the mode is a good one, given it is a hardware based one, that can be used in a reasonable cost piece of hardware. https://www.scs-ptc.com/controller.html 73s Jack VK4JRC At 06:02 AM 1/12/2008, Rick wrote: Andy, What I don't understand is if you already have a suite of modes, Pactor, Pactor 2, and Pactor 3, then why create another mode like they did? This is not compatible with existing packet, right? So you would have to have SCS products on both ends? Then why not use Pactor modes, especially the Pactor 2 mode which is of a similar bandwidth and throughput? 73, Rick, KV9U Andrew O'Brien wrote: I found the item (below) on the SCS web site. Anyone use this new class of packet ? Robust Packet-Radio (RPR) Up to now Packet-Radio over shortwave has been basically a non-starter, it has even been heavily criticized because of the low effective throughput and repeats. AX.25 is for shortwave not an ideal protocol, but with automatic FRack-setting and a small MAXFrame value the protocol should, however, function much better on a shortwave channel than has previously been the case generally. One cannot of course expect an asynchrone protocol to reach the same efficiency as a tight synchrone ARQ protocol (e.g. PACTOR), but for some applications a multi-user service, with very uncritical transmit/receive switching, as well as almost zero power holding up a connection when no data passing, brings a real advantage that outweighs the lower data throughput. What finally are the reasons that up to now HF-PR works so poorly, and apart from forwarding is hardly ever used? One finds a simple answer: The current modulation type for HF-PR namely uncoded 300 Bd FSK is really unsuitable for normal HF channels. The symbols are much too short even with moderate Multi-Path effect (delay spread) to work. Additionally, because no sort of error correction code is used, even short troughs or static will destroy a many seconds long Packet. Just one missing bit leads to a repeat of the whole packet. To help cure this problem, SCS has developed a new class of robust modulations types especially for Packet-Radio. As a special feature for all the variants of this Robust PR, a completely new synchronizations algorithm with catch properties that were not possible before has been realized. Frequency deviations of ±250 Hz are immediately recognized and without any loss of sensitivity compensated, and this with signals that are buried deep in the noise. Because of this it's possible to remove a tuning display. One can say with good conscience that this is Plug and Play for shortwave. The currently available Robust PR modulation types have the following properties: Bandwidth:500 Hz @ -30 dB Modulation:Pulse-Shaped OFDM (BPSK, QPSK), similar to PACTOR-III Average Throughput:200 or 600 Bit/sec Crestfaktor:3.0 or 4.2 dB Delay-Spread:up to ±8 msec is tolerated Coding:High performance convolutional code, full-frame interleaved, rate/2 or rate3/4
Re: [digitalradio] PACTO! I CQ
- Original Message - From: kh6ty [EMAIL PROTECTED] To: digitalradio@yahoogroups.com Sent: Friday, January 11, 2008 2:14 PM Subject: Re: [digitalradio] PACTO! I CQ Copying you FB in South Carolina, Howard, using DigiPan 2.0. Sorry - No Pactor 1 transmit capability - my PK-232 is in mothballs! Super! Thanks, Skip. Well, shucks, would have been neat to pick you up, Skip. I picked up NT3K (Ken) in Las Cruces, NM with an S9 signal both ways on 14.078 and it made for pretty well 100% copy using FEC. Had no problems at all. The contact lasted about an hour or so. He was using his MultiPSK package. No one bother us for using PACTOR, had no apparent problems with any PMBOs either. I know, I know, PACTOR I is verrry retro but what the heck - it was great fun. C'mon, Skip. I know you've got a few things on your plate, what with NBEMS and all, but take a few sometime; break out that PK and play with it. It's still viable - it's better than just leaving the electrolytics to dry up if it isn't broke. Thanks again.. Howard W6IDS Richmond, IN
Re: [digitalradio] Re: Emergency agencies/ ham equipment/ hams in emcomm
Yeah...that would be the one where you buy a book and sit in the corner and not insult other peoples intelligence with your arrogance...Especially as an newbie...:) Gary n8gsj n4ijs wrote: Hello! I am new to this forum, so please forgive me if this comes across off base. But, I came here looking for information on digital modes for Amateur Radio - not various, multi-post messages about various peoples opinion (and arguments) on unrelated topics. I am sure that these discussions are important to a select group of folks, but are there no other places for these types of discussions to take place? I belong to several Ham related Yahoo! forums and this one certainly produces (by far) the most emails; however, few are related to the topic at hand. So, I have to weed through these other messages to get to the real ones. If this just the way of this forum, that's fine - I will just unsubscribe. I hope that isn't the case, but, if it is, can anyone recommend a forum for exploring digital modes within Ham Radio? Thanks and 73, Robert - N4IJS --- In digitalradio@yahoogroups.com, Rud Merriam [EMAIL PROTECTED] wrote: In Katrina and Rita shelters were opened where there were people in need. Whether supplies could readily reach them was a problem to be solved, not a requirement for shelter location. You are not understanding the widespread nature of these disasters. It was easier to solve the supply problem than the rescue problem. A supply truck or helicopter with supplies can make it in once a day. The multiple vehicles, trucks or helicopters, to evacuate people were not available. Your hypothetical versus others real world experience is misleading you. Rud Merriam K5RUD ARES AEC Montgomery County, TX http://TheHamNetwork.net Your first paragraph indicates that the shelter was so remote and isolated that it required helicopter delivery of food and water. Yet you also indicate that you were in your truck which indicates you could drive to the shelter. Maybe you were driving a monster truck? Some of this appears to be an appeal to emotion. I HAVE been around long enough to know neither the ARC or SA would open a shelter in a location that was not reachable by regular supply vehicles nor that had SOME kind of communications. I am pretty sure that the government authorities would not authorize this either. To do otherwise is simply asking for the shelter staff to require 'rescuing' at some time in the future thereby adding to the problem. Consequently, when you say no communications, you are overstating the facts. Now maybe, a runner in a vehicle may the only means of communication, but never the less, it is communications. Jim WA0LYK Announce your digital presence via our Interactive Sked Page at http://www.obriensweb.com/sked DRCC contest info : http://www.obriensweb.com/drcc.htm Yahoo! Groups Links
Re: [digitalradio] Robust Packet-Radio (RPR)
Actually, Jack, this makes more sense. In a way, this would be one way of interoperability between modes. For those of us who did Amtor and later Pactor and Clover II, the old Aplink and later Winlink systems allowed us to connect to a MBO (Mail Box Operation, I think that was what they used to call them) with any of the modes and the station would be able to switch to the correct mode and store and play the messages. RTTY Journal (or it could have been renamed RTTY Digital Journal) had an extensive article on how this was done. Manageable, but a bit messy to do it. So no matter what mode we had, we could still communicate with these MBO's and they in turn would forward the traffic world wide or whatever was needed. Otherwise, just having a new mode would not make much sense to put that much energy into development. But since regular 300 baud packet is so very poor on HF, just about any improved modulation scheme would be so much better. For sound card modes today, we have the 110 baud packet mode which does work much better, but of course is about a third the speed of 300 baud packet and you would need to match your speed to anyone with that mode. Even then, other modes are so much better now, particularly the ALE400 mode or better yet the 8FSK50 FAE 400 ARQ mode. 73, Rick, KV9U Jack Chomley wrote: Rick, Well, its just another mode, to add to the pile! You get RPR with the SCS DSP Tracker, APRS is also using it and the DSP Tracker will send BOTH mode APRS frames out, that is a standard 300 baud HF Packet data frame, THEN the next one out is an RPR frame, alternating. This is so any RPR OR standard 300 baud stations or IGATEs will pick up the signals. At least in this case, SCS thought of the 300 baud HF Packet users on APRS, when they developed this TNC. The other SCS PTC models also have the RPR mode too. I think the mode is a good one, given it is a hardware based one, that can be used in a reasonable cost piece of hardware. https://www.scs-ptc.com/controller.html 73s Jack VK4JRC
[digitalradio] Re: Emergency agencies/ ham equipment/ hams in emcomm
Where did I say hams weren't needed for support communications? Jeez, when did ham radio volunteers become first line search and rescue personnel? Too many people seem to miss the distinction between communications emergency and search and rescue operations. Emergency communications doesn't mean being in the front line right alongside the search and rescue folks. I certainly am not trained to be in that kind of an area even if only doing communications work! What I did say was that hams, acting as hams, shouldn't put themselves in a position where they could add to the load on the search and RESCUE personnel. If a ham is also a search and rescue member that is a different story. Here in the US, neither the ARC or SA will open shelters that are not fully supportable by their own personnel. They do not open shelters that are only supportable by search and rescue personnel. In most cases I've been involved with, the authorities won't even let them into a disaster area until it has been cleared. I already have the beard growth! Jim WA0LYK --- In digitalradio@yahoogroups.com, Les Warriner [EMAIL PROTECTED] wrote: You have led a sheltered life. Try operating in the Philipines after a volcano blows, or in Mexico after the same incident, or in Africa after a transvaal fire, then tell me Hams are not needed. It's too bad we are getting comments like this from the uninformed with no experience. Get some beard growth and you'll rapidly change your mind. 73 Les At 08:13 AM 1/11/2008, jgorman01 wrote: --- In mailto:digitalradio%40yahoogroups.comdigitalradio@yahoogroups.com, Alan Barrow ml9003@ wrote: snip I personally had a Red Cross shelter leader run after my truck and flag me down because she thought we were packing up. quote: You don't know how much we still need you guys. Until you arrived we had no communications since the big green helicopter landed and kicked out pallets or MRE's. The phones still don't work, please do not leave. Don't think that did not change my perspective and disillusionment. This is not an ego thing, exactly the opposite. Made me realize that independent of what I thought we could or should do (my ego), we had a job to do. I should set aside my annoyances preferences, that what we were doing was important and needed. Your first paragraph indicates that the shelter was so remote and isolated that it required helicopter delivery of food and water. Yet you also indicate that you were in your truck which indicates you could drive to the shelter. Maybe you were driving a monster truck? Some of this appears to be an appeal to emotion. I HAVE been around long enough to know neither the ARC or SA would open a shelter in a location that was not reachable by regular supply vehicles nor that had SOME kind of communications. I am pretty sure that the government authorities would not authorize this either. To do otherwise is simply asking for the shelter staff to require 'rescuing' at some time in the future thereby adding to the problem. Consequently, when you say no communications, you are overstating the facts. Now maybe, a runner in a vehicle may the only means of communication, but never the less, it is communications. snip I guess the core difference is some are saying we have no business even providing emergency service. And I believe that is a very extreme and unsound position. Your guess is wrong. No one I have seen post is saying that we have no business providing emergency communications where appropriate and in a manner that support the public best. snip So what's this have to do with digital radio? I think we have a large opportunity to contribute. We all want an alternative to $1k proprietary modems. But until we get that alternative there is some value there. That does not mean we can or should compromise operation in the rest of the bands. But there needs to be a place. Just like there should be for other digital modes, current and future. The whole idea that a legal limit rtty contest op is somehow appropriate allowed, yet other digi sigs should not be is non-sensical. Some of the new modes offer incredible performance efficiency. they can be fun for casual work. But they could also offer significant value in an emergency if harnessed. You might have continued and made an argument for full blown pactor 3 bandwidth for emergencies but you blew it by including casual use. The use of wide signals within a limited spectrum WILL displace several others that want to use narrow signals. It is obvious that you have no love for rtty, yet several rtty signals can fit into the bandwidth of a 2.2 kHz pactor 3 signal. Would you impinge upon their preferred mode of operation for your casual use? It sounds like it. No one is guaranteed a time or place to operate. The wider the signal you wish to use, the
RE: [digitalradio] Software for the digital ham that multi-tasks while sleeping ?
WinWarbler can decode all PSK31 or PSK63 QSOs within any 3.5 khz band segment, determine the stations involved, and maintain a Stations Heard window like this: http://www.dxlabsuite.com/winwarbler/Heard.jpg WinWarbler can be configured insert station's heard into SpotCollector's database, thereby enabling long-term capture and analysis. Awhile back, 4X1DA used this to assemble this interesting analysis of 8 hours of 20m PSK monitoring from his QTH: http://www.dxlabsuite.com/winwarbler/4X1DA.xls 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] Behalf Of Peter G. Viscarola Sent: Friday, January 11, 2008 8:46 AM To: DIGITALRADIO Subject: RE: [digitalradio] Software for the digital ham that multi-tasks while sleeping ? Anyone care to invent this ? What you're describing could be done quite easily from within a particular program. It could easily be built as an external program that sends ActiveX commands to MixW, for example. The only hang-up that I see is in terms of tuning: So, you tune to 14070 in PSK31 mode and listen for 20 minutes, or whatever. Suppose the station is on 14070.5? My point is that especially with these narrow modes, wouldn't what you're describing require activity directly on the frequency in question? PSK31 tuning is pretty fussy. de Peter K1PGV
Re: [digitalradio] Robust Packet-Radio (RPR)
Andy, What I don't understand is if you already have a suite of modes, Pactor, Pactor 2, and Pactor 3, then why create another mode like they did? This is not compatible with existing packet, right? So you would have to have SCS products on both ends? Then why not use Pactor modes, especially the Pactor 2 mode which is of a similar bandwidth and throughput? 73, Rick, KV9U Andrew O'Brien wrote: I found the item (below) on the SCS web site. Anyone use this new class of packet ? Robust Packet-Radio (RPR) Up to now Packet-Radio over shortwave has been basically a non-starter, it has even been heavily criticized because of the low effective throughput and repeats. AX.25 is for shortwave not an ideal protocol, but with automatic FRack-setting and a small MAXFrame value the protocol should, however, function much better on a shortwave channel than has previously been the case generally. One cannot of course expect an asynchrone protocol to reach the same efficiency as a tight synchrone ARQ protocol (e.g. PACTOR), but for some applications a multi-user service, with very uncritical transmit/receive switching, as well as almost zero power holding up a connection when no data passing, brings a real advantage that outweighs the lower data throughput. What finally are the reasons that up to now HF-PR works so poorly, and apart from forwarding is hardly ever used? One finds a simple answer: The current modulation type for HF-PR namely uncoded 300 Bd FSK is really unsuitable for normal HF channels. The symbols are much too short even with moderate Multi-Path effect (delay spread) to work. Additionally, because no sort of error correction code is used, even short troughs or static will destroy a many seconds long Packet. Just one missing bit leads to a repeat of the whole packet. To help cure this problem, SCS has developed a new class of robust modulations types especially for Packet-Radio. As a special feature for all the variants of this Robust PR, a completely new synchronizations algorithm with catch properties that were not possible before has been realized. Frequency deviations of ±250 Hz are immediately recognized and without any loss of sensitivity compensated, and this with signals that are buried deep in the noise. Because of this it's possible to remove a tuning display. One can say with good conscience that this is Plug and Play for shortwave. The currently available Robust PR modulation types have the following properties: Bandwidth:500 Hz @ -30 dB Modulation: Pulse-Shaped OFDM (BPSK, QPSK), similar to PACTOR-III Average Throughput: 200 or 600 Bit/sec Crestfaktor: 3.0 or 4.2 dB Delay-Spread: up to ±8 msec is tolerated Coding: High performance convolutional code, full-frame interleaved, rate/2 or rate3/4
Re: [digitalradio] Re: Emergency agencies/ ham equipment/ hams in emcomm
Robert, I may be in a minority, but I don't think you're off base. If you stick around you WILL find posts that are more to what you (and I) sought as a focus of a digital radio forum. You just have to sort through a myriad of repetitive philosophical postings on topics that sometimes seem to range a bit wide (take a peek at the subject line of this thread to which you replied, for example), or not infrequently include condescending comments (as in one earlier reply to your query). Although I don't consider myself a newbie (licensed in '62, working digital for well over 20 years, and a member of this forum for quite some time), I think it's time for me to again stop receiving email postings. I'll just update my forum options and visit via the web from time to time. And yes, I DO actively participate in emergency and disaster communications, both digital and voice. OK guys, flame me if you wish. They won't clutter my mail box. 73 to all. Truly. Nothing personal, Andy. See you all on the digital modes. John Hirth W2KI
Re: [digitalradio] Software for the digital ham that multi-tasks while sleeping ?
This would be an excellent client to write for znudigi. 73, Leigh/WA5ZNU On Fri, 11 Jan 2008 3:51 am, Andrew O'Brien wrote: If you are like me, there is SO MUCH happening in the amateur radio digital world that it is hard to keep up with , more fun to be had than can be squeezed in to 24 hours. Some software ,like WSJT, can be left active overnight or when out of the shack and the user gets time stamped information about stations detected while they were out. This is very useful but it is static, simply monitoring one frequency and one mode. What would it take to develop an application that can scan different frequencies at larger time intervals that the scan mode in modern rigs. Perhaps something that is user defined. Something that might monitor 14070 for 15 minutes and then automatically move to 3581 for an hour , then to 7034 for 30 minutes . Not only would this software change frequency at designated times, it might switch modes too. Listening on 14070 in PSK31 , changing to JT65A and QSYing to 14076 for 20 minutes, and even listening to Olivia on 3581 , etc etc. I guess this could be a major add-on to something like Multipsk or DM780 but maybe it would take another form , something akin to DX Lab Launcher. DX Lab Launcher enables the user to launch varying DX Lab Suit applications , something like this could be used to launch and close different applications at specified times. Example: At 1400Z it launches Winwarbler in RTTY mode, at 1500 it closes Winwarbler and launches Multipsk in Olivia 500/16 and at 1700 it launches VB-Digi/FLARQ in PSK250 . Anyone care to invent this ? -- Andy K3UK www.obriensweb.com (QSL via N2RJ) Announce your digital presence via our Interactive Sked Page at http://www.obriensweb.com/sked DRCC contest info : http://www.obriensweb.com/drcc.htm Yahoo! Groups Links
[digitalradio] Re: Software for the digital ham that multi-tasks while sleeping ?
--- In digitalradio@yahoogroups.com, Simon Brown [EMAIL PROTECTED] wrote: In my own case I can record the incoming audio and play it back later. At the moment I leave DM780 running all night picking up SSTV pictures. I'm not sure I would want a scheduler but were I to add one I would use a UI similar to Outlook's calendar. Simon Brown, HB9DRV would it be possible to write something like that via the macro Manager? exampl. if_time: 2205 freq: 14076 if_time: 2245 freq: 7072 and so on? just an idea The if_time: macro could also come in handy on contests ... using it in the limit on Band changes per hour. 73 Steve, W1CDX
[digitalradio] Re: Software for the digital ham that multi-tasks while sleeping ?
- would it be possible to write something like that via the macro Manager? exampl. if_time: 2205 freq: 14076 if_time: 2245 freq: 7072 and so on? just an idea The if_time: macro could also come in handy on contests ... using it in the limit on Band changes per hour. 73 Steve, W1CDX Now there's an interesting idea.
[digitalradio] Re: Robust Packet-Radio (RPR)
--- In digitalradio@yahoogroups.com, Rick [EMAIL PROTECTED] wrote: Andy, What I don't understand is if you already have a suite of modes, Pactor, Pactor 2, and Pactor 3, then why create another mode like they did? This is not compatible with existing packet, right? So you would have to have SCS products on both ends? Then why not use Pactor modes, especially the Pactor 2 mode which is of a similar bandwidth and throughput? Maybe not. Seems like that say it doesn't involve tight timing the way Pactor does, so potentially it is a mode that can be implemented on sound cards, either by reverse engineering or by their publishing complete specs.
[digitalradio] Re: ALE Sounding and How does it work?
If the statement below is False, why are there not more call signs showing up on the main ALE frequencies? I can leave my rig on 14109.5 or 10145.5 for 24 hours and only see, at most 4 or 5 stations? Ditto for the ALE website At HFlink. And 99% of those are soundings. So where are the QSO's and the like? Who is up for testing the ability of PCALE to handle a standard test document between 2 distant stations, compared to 141A or ALE400. Ditto for a file transfer? I can't on PCALE since I can only receive, since I have a problem getting the software to TX. Anyway , in the past I have told you guys at least 20 million times not to exaggerate.. John VE5MU At 09:48 PM 1/10/2008, you wrote: Chris , ZL1BOE you will be told by others that ALE is widely used to set up QSO's and QSY's using the one line message ability . You will also be told that it is used widely for keyboard to keyboard QSO's and that there are thousands of Hams using ALE ( last figure I heard was 6000) . These are folks who are using PCALE, who have aggressively set aside frequencies for ALE use in all bands, and are promoting ALE as the answer to emergency communications. FALSE
Re: [digitalradio] Re: ALE Sounding and How does it work?
Now, 20 million + 1 73 At 08:05 PM 1/11/2008, you wrote: If the statement below is False, why are there not more call signs showing up on the main ALE frequencies? I can leave my rig on 14109.5 or 10145.5 for 24 hours and only see, at most 4 or 5 stations? Ditto for the ALE website At HFlink. And 99% of those are soundings. So where are the QSOs and the like? Who is up for testing the ability of PCALE to handle a standard test document between 2 distant stations, compared to 141A or ALE400. Ditto for a file transfer? I cant on PCALE since I can only receive, since I have a problem getting the software to TX. Anyway , in the past I have told you guys at least 20 million times not to exaggerate John VE5MU At 09:48 PM 1/10/2008, you wrote: Chris , ZL1BOE you will be told by others that ALE is widely used to set up QSOs and QSYs using the one line message ability . You will also be told that it is used widely for keyboard to keyboard QSOs and that there are thousands of Hams using ALE ( last figure I heard was 6000) . These are folks who are using PCALE, who have aggressively set aside frequencies for ALE use in all bands, and are promoting ALE as the answer to emergency communications. FALSE No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.1/1220 - Release Date: 1/11/2008 6:09 PM
Re: [digitalradio] Re: ALE Sounding and How does it work?
John, Sorry but I know the relative level of activity at times. There is far less ALE than various other modes and more ALE than various other modes as well. It all depends on your point of reference, just as there is Hellscriber than GTOR and more CW than PSK31, regardless your statement as to the amount of activity is false, but its also moot in my opinion. I view ALE within the scope of Amateur Radio application as tool that needs to trained on and have networks in place for use as necessary, not necessarily used daily by all, although such use is just fine and the best tool for many pursuits within ARS, however its the application of ALE for ECOM where I see ALE having the biggest benefits to the ARS. Rather than sitting on 20 meters you should try programming all the ALE frequencies into your choice of ALE controller and scanning for 24 hours with appropriate antenna for NVIS below 14Mhz and Skywave above 10Mhz for Amateur Radio and if you are properly configured you your results will be much different. As to you what you are seeing on Channel One, it will depend on the geographic location of the HFlinkNet stations and what they are hearing based on the antenna type being used. Some are using NVIS antenna only, others Skywave antenna only, some are using something thing in between, those using automated antenna selection will be optimum, I do not know what all the stations are running. The MARS-ALE software which is being used by HFlinkNet stations supports programmable antenna selection during scanning using various devices, the CAT ANT ports in radios, external PC controlled ATU's with ant ports and dedicated antenna switches under PC control. /s/ Steve, N2CKH At 11:05 PM 1/11/2008, you wrote: If the statement below is False, why are there not more call signs showing up on the main ALE frequencies? I can leave my rig on 14109.5 or 10145.5 for 24 hours and only see, at most 4 or 5 stations? Ditto for the ALE website At HFlink. And 99% of those are soundings. So where are the QSOs and the like? Who is up for testing the ability of PCALE to handle a standard test document between 2 distant stations, compared to 141A or ALE400. Ditto for a file transfer? I cant on PCALE since I can only receive, since I have a problem getting the software to TX. Anyway , in the past I have told you guys at least 20 million times not to exaggerate John VE5MU
