Re: [digitalradio] The Makrothen Contest RTTY Saturday 00:00-07:59 UTC and 16:00-23:59 UTC and Sunday
Another contest... S Andrew O'Brien wrote: The Makrothen Contest TMC - The Rules - 2008 Last Update: 4-October-2008 TMC logo Date and Time: The contest takes place on the second full weekend of October each year. The next contest dates are Saturday 11th and Sunday 12th October 2008, with three separate periods: Saturday 00:00-07:59 UTC and 16:00-23:59 UTC and Sunday 08:00-15:59 UTC. Objective: The object of the contest is for amateurs around the world using RTTY to contact as many amateurs in other parts of the world as possible during the three contest periods. Terms of Competition for all classes: All entrants must operate within the limits of their chosen class when performing any activity that could impact their submitted score. Only the entrant's call sign can be used to aid the entrant's score. A station operating from a DXCC Entity different from that indicated by its call sign is required to sign portable. All antennas must be physically connected by wires to the transceiver/s, transmitter/s and receiver/s used by the entrant. All used transceivers, transmitters and receivers must be located within a 500 meter diameter area or within property limits of the station licensee, whichever is greater. All operation must take place from the same operating site. Any form of DX alerting assistance is permitted in all classes. Self spotting of any form on spotting nets is not permitted for any class. Self spotting is defined as generating packet radio or web site spots for your contest call sign, including - for example - this methods: using your own call sign; spotting your call sign while using another call sign; spotting of your call sign by other stations as a result of prearranged solicitation. To notify the locator of a station via any form of DX alerting assistance is unwanted and this unsportsmanlike behaviour can lead to a disqualification. Classes: Class 1: Single, All Band, Low Power * SO/Single Xcvr LP Class 2: Single, All Band, High Power * SO/Single Xcvr HP Class 3: Multi, All Band, Low Power * SO/Multi Xcvr LP (S/M) * MO/Single Xcvr LP (M/S) * MO/Multi Xcvr LP (M/M) Class 4: Multi, All Band, High Power * SO/Multi Xcvr HP (S/M) * MO/Single Xcvr HP (M/S) * MO/Multi Xcvr HP (M/M) Class 1 and 3: The output power shall not exceed 100 watts. Class 1 and 2: Single operator and single transceiver - or - single transmitter and single receiver. Class 3 and 4: S/M = Single operator and multiple transceivers, transmitters and receivers (see note). M/S = Multiple operator and single transceiver - or - single transmitter and single receiver. M/M = Multiple operator and multiple transceivers, transmitters and receivers (see note). Note: No limit to transceivers, transmitters and receivers, but only one signal and running station allowed per band. Bands: The 80, 40, 20, 15 and 10 meter bands may be used only. Exchange: No RST required. You have to send the first 4 characters of the Maidenhead Grid Square Locator (locator) at your QTH. (i.e.: FM19 or: JO41). Your log must show the correct locator sent and received for each contact. You must send the same locator in each QSO. Only portable /p, mobile /m, maritime mobile /mm and marine stations (example: VEØ***, HC9***) may change their locator every 60 minutes. QSO Points: A station may be worked once on each band for QSO points credit. The points for the QSO are equal to the distance in kilometer (rounded to an integer value) between the two stations exchanging their locator. IOW: one point is equal to one kilometer. Weighting of points on the lower bands: For a QSO on 40m you must multiply the points per kilometer with the factor 1.5 and for a QSO on 80m you must multiply the points per kilometer with the factor 2.0. The result must be rounded to an integer value. Special case - Exception: If both stations are located in the same square, then both stations - regardless of the band - get 100 points for this QSO finally. Don't multiply this 100 points with any weighting factor! Distance: The calculation of the distance should assume the earth is a perfect sphere with a radius of 6378.16 km. The base point for the distance calculation is the center of the Maidenhead Grid Square. The formula: distance = acos(cos(a1) x cos(b1) x cos(a2) x cos(b2) + cos(a1) x sin(b1) x cos(a2) x sin(b2) + sin(a1) x sin(a2)) x radius a1 = latitude of station-1 b1 = longitude of station-1 a2 = latitude of station-2 b2 = longitude of station-2 a1, b1, a2, b2 in radians radians = degrees x PI / 180 PI = 3.1415926535897932384626433832795 The distance must be rounded to an integer value. Multipliers: No multipliers. Scoring: Your total score is the total sum of total points of each band. For each valid QSO the distance and the
Re: [digitalradio] Contestia 1K vs MT63?
Hello Tony, According to my measures (under noise only): * 16-1K: Fast 16 tones, bandwidth=1000 Hz, speed=62.5 bauds, 78.2 wpm, lowest S/N =-9 dB, * MT63 1K: 100 wpm, lowest S/N - 5 dB for 10 bauds (perhaps -7dB with the original program) but due to the Pmean/Ppeak: 0.1, it is only theoritical, except if you prefer QRP transmissions. I'm not sure if that's an accurate assessment as to why there is a difference, but it would seem so. Wonder if anyone can shed some light on this. The difference in Selective Fading conditions is perhaps due to the modulation speeds which are rather different. 73 Patrick - Original Message - From: Tony To: digitalradio@yahoogroups.com Sent: Saturday, October 11, 2008 7:44 AM Subject: [digitalradio] Contestia 1K vs MT63? All, I was playing with the Contestia mode in an attempt to duplicate the wpm rate of MT63. I configured Contestia with 16 tones and a bandwidth of 1K. The sensitivity of the two seemed to be the same and the wpm rate appeared to be close. I then tested both modes with the HF path simulator dialed-in for selective fading with the SNR set a few db above the minimum decode threshold. As you can see below, print was better with MT63. The deep fades caused garbled characters with Contestia and it would appear the better copy with MT63 is a result of the redundancy built into the mode. I'm not sure if that's an accurate assessment as to why there is a difference, but it would seem so. Wonder if anyone can shed some light on this. Tony, K2MO Path Simulation : Selective Fading SNR : -3db / -6db Contestia 1K / 16 tone SNR -3db THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOS OVER TH- G THE BROWN FOXMPS OVER THE LAZY DOG THE QUICRO,N FOX JUMPS OVELAZY DOG SNR -6db TE QUCK BROW FOX JUMPS OVER THE LAZY DOG THE QUG2NOWNS YVER THOEG THE BROWN FO#UBR OVER TE LAZY DOG THE QUIC^_^N FOX JUMPS OVELAZY DOG MT63 1K SNR -3db *DE K2MO* THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG *EOT* SNR -6db *DE K2M TH QUICK AOWN FOX JUOP; OVrR THE LAZY ROG THE Q%ICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWNFOX JUMPS OVER THE LAZY DOG *EOT*
[digitalradio] Re: Sound card question
Vojtech and Patrick thanks you for the reply. I effectively didn't realize synchronization was so critical too. Interesting. Just a comment/question to both, since you are both developers of widely used programs (and I take this opportunity to thank you both for that), I discovered the THOR mode as release by Dave in Fldigi and I have to say based on the preliminary test that I have done (and echoed by tests done by Rein developer of the PSKmail system), that I am very impressed by the performance I get. It is also an ifsk mode like DominoEx but for some reason performs much better at least as implemented in fldigi. Not sure if it is the permanent FEC but is seems quite robust in my tests between VK and ZL. Have you had any comments or request for implementation in your software or is it just too new, or not different enough? 73s, John VK2ETA (And for Patrick, Ex FK8DV. Merci)
[digitalradio] MEPT/WSPR A proposal..
-- Forwarded message -- From: Colin J Thomson [EMAIL PROTECTED] Date: Sat, Oct 11, 2008 at 6:30 AM Subject: [Knightsqrss] A proposal.. To: Knights-List [EMAIL PROTECTED] Hi Graphical Knights.. A proposal.. although a little too late now I think. With the ever increasing QRO IE 500mW and up WSPR signals (most seem to be 5W!! or more in the EU) on 30m, what I would like to see is the section from 10140.100-200 to be ***QRP something like a max of 200mW or maybe less*** above 10.140,200 they can run what they like. The reason being it just wrecks grabbing the few graphical stations who are still QRV between 10.140.0-100. Even with my very very narrow CW Xtal filters and DSP599++ filter it is, most of the time hopeless and weekends it is a waste of time grabbing during the day.. Just have to look at the grabbers on the compendium sites... maybe that's why a lot are QRT ?? I am also saddened to see even more EU WSPR signals (In OUR section) between 10.140.000-100, this morning being a classic case with one being on ~10140.000 another on 085 and one on ~110 who has peaked S6!! Maybe someone could be FWD'd to the relevant WSPR sites/groups.. 73 G6AVK - JO01ho -- Hi Colin, I feel your pain too! Some of the WSPR stations are running 50 or even 100 watts and seem oblivious to the purpose of QPR WSPR! Also a few have terrible stability! I have notified a few ops over here and they did change frequency at least. I think that some rigs won't allow power out below about 5 watts which is way too much power! 73 Larry WB3ANQ
Re: [digitalradio] Re: Sound card question
Hello John, As far as I know, there are no public specifications or description of THOR modes. 73 Patrick - Original Message - From: vk2eta [EMAIL PROTECTED] To: digitalradio@yahoogroups.com Sent: Saturday, October 11, 2008 12:01 PM Subject: [digitalradio] Re: Sound card question Vojtech and Patrick thanks you for the reply. I effectively didn't realize synchronization was so critical too. Interesting. Just a comment/question to both, since you are both developers of widely used programs (and I take this opportunity to thank you both for that), I discovered the THOR mode as release by Dave in Fldigi and I have to say based on the preliminary test that I have done (and echoed by tests done by Rein developer of the PSKmail system), that I am very impressed by the performance I get. It is also an ifsk mode like DominoEx but for some reason performs much better at least as implemented in fldigi. Not sure if it is the permanent FEC but is seems quite robust in my tests between VK and ZL. Have you had any comments or request for implementation in your software or is it just too new, or not different enough? 73s, John VK2ETA (And for Patrick, Ex FK8DV. Merci) Announce your digital presence via our Interactive Sked Page at http://www.obriensweb.com/sked 30M digital activity at http://www.projectsandparts.com/30m Recommended software : DM780, Multipsk, FLDIGI, Winwarbler ,MMVARI. Yahoo! Groups Links
Re: [digitalradio] Re: Sound card question
Patrick, John, This is all we have published at the moment. More will be released at a later date. We are busy with the launch of NBEMS and have no time right now to write detailed specifications. http://w1hkj.com/FldigiHelp/Thor.html 73, Skip KH6TY NBEMS Development Team - Original Message - From: Patrick Lindecker To: digitalradio@yahoogroups.com Sent: Saturday, October 11, 2008 9:25 AM Subject: Re: [digitalradio] Re: Sound card question Hello John, As far as I know, there are no public specifications or description of THOR modes. 73 Patrick - Original Message - From: vk2eta [EMAIL PROTECTED] To: digitalradio@yahoogroups.com Sent: Saturday, October 11, 2008 12:01 PM Subject: [digitalradio] Re: Sound card question Vojtech and Patrick thanks you for the reply. I effectively didn't realize synchronization was so critical too. Interesting. Just a comment/question to both, since you are both developers of widely used programs (and I take this opportunity to thank you both for that), I discovered the THOR mode as release by Dave in Fldigi and I have to say based on the preliminary test that I have done (and echoed by tests done by Rein developer of the PSKmail system), that I am very impressed by the performance I get. It is also an ifsk mode like DominoEx but for some reason performs much better at least as implemented in fldigi. Not sure if it is the permanent FEC but is seems quite robust in my tests between VK and ZL. Have you had any comments or request for implementation in your software or is it just too new, or not different enough? 73s, John VK2ETA (And for Patrick, Ex FK8DV. Merci) Announce your digital presence via our Interactive Sked Page at http://www.obriensweb.com/sked 30M digital activity at http://www.projectsandparts.com/30m Recommended software : DM780, Multipsk, FLDIGI, Winwarbler ,MMVARI. Yahoo! Groups Links Internal Virus Database is out of date. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.6.6/1626 - Release Date: 8/21/2008 6:54 PM
Re: [digitalradio] Re: Sound card question
Patrick, John, The link on the Thor web page, http://w1hkj.com/FldigiHelp/Thor.html, provides some additional technical specifications for Thor: http://w1hkj.com/FldigiHelp/Modes/THORdesc.htm To answer John's question, Thor uses full time FEC. 73, Skip KH6TY NBEMS Development Team - Original Message - From: Patrick Lindecker To: digitalradio@yahoogroups.com Sent: Saturday, October 11, 2008 9:25 AM Subject: Re: [digitalradio] Re: Sound card question Hello John, As far as I know, there are no public specifications or description of THOR modes. 73 Patrick - Original Message - From: vk2eta [EMAIL PROTECTED] To: digitalradio@yahoogroups.com Sent: Saturday, October 11, 2008 12:01 PM Subject: [digitalradio] Re: Sound card question Vojtech and Patrick thanks you for the reply. I effectively didn't realize synchronization was so critical too. Interesting. Just a comment/question to both, since you are both developers of widely used programs (and I take this opportunity to thank you both for that), I discovered the THOR mode as release by Dave in Fldigi and I have to say based on the preliminary test that I have done (and echoed by tests done by Rein developer of the PSKmail system), that I am very impressed by the performance I get. It is also an ifsk mode like DominoEx but for some reason performs much better at least as implemented in fldigi. Not sure if it is the permanent FEC but is seems quite robust in my tests between VK and ZL. Have you had any comments or request for implementation in your software or is it just too new, or not different enough? 73s, John VK2ETA (And for Patrick, Ex FK8DV. Merci) Announce your digital presence via our Interactive Sked Page at http://www.obriensweb.com/sked 30M digital activity at http://www.projectsandparts.com/30m Recommended software : DM780, Multipsk, FLDIGI, Winwarbler ,MMVARI. Yahoo! Groups Links Internal Virus Database is out of date. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.6.6/1626 - Release Date: 8/21/2008 6:54 PM
[digitalradio] Re: Contestia 1K vs MT63?
Hi Tony. Even though the simulation results look promising for MT63, they do not take real HAM SSB transceiver into account. SSB PA of an average HAM TRX is usually not very linear and the many carriers of MT63 will mix with each other, which will show up as an added noise. Also MT63 has very low crest factor, so the effective transmitted power will be much lower than of Contestia if you do not overdrive the TX. I bet you will be better of to use Contestia on the air using let's say an average 100W YaeComWood. 73, Vojtech --- In digitalradio@yahoogroups.com, Tony [EMAIL PROTECTED] wrote: All, I was playing with the Contestia mode in an attempt to duplicate the wpm rate of MT63. I configured Contestia with 16 tones and a bandwidth of 1K. The sensitivity of the two seemed to be the same and the wpm rate appeared to be close. I then tested both modes with the HF path simulator dialed-in for selective fading with the SNR set a few db above the minimum decode threshold. As you can see below, print was better with MT63. The deep fades caused garbled characters with Contestia and it would appear the better copy with MT63 is a result of the redundancy built into the mode. I'm not sure if that's an accurate assessment as to why there is a difference, but it would seem so. Wonder if anyone can shed some light on this. Tony, K2MO Path Simulation : Selective Fading SNR : -3db / -6db Contestia 1K / 16 tone SNR -3db THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOS OVER TH- G THE BROWN FOXMPS OVER THE LAZY DOG THE QUICRO,N FOX JUMPS OVELAZY DOG SNR -6db TE QUCK BROW FOX JUMPS OVER THE LAZY DOG THE QUG2NOWNS YVER THOEG THE BROWN FO#UBR OVER TE LAZY DOG THE QUIC^_^N FOX JUMPS OVELAZY DOG MT63 1K SNR -3db *DE K2MO* THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG *EOT* SNR -6db *DE K2M TH QUICK AOWN FOX JUOP; OVrR THE LAZY ROG THE Q%ICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWNFOX JUMPS OVER THE LAZY DOG *EOT*
Re: [digitalradio] Re: Sound card question
There is a basic outline of THOR at: http://www.w1hkj.com/FldigiHelp/Modes/THORdesc.htm Perhaps someone can help us understand the difference between THOR and DEX/FEC (Domino EX with FEC). Aren't they very much the same concept, or is there a design difference? 73, Rick, KV9U Patrick Lindecker wrote: Hello John, As far as I know, there are no public specifications or description of THOR modes. 73 Patrick
[digitalradio] Global SET, Saturday, November 8 0400 - 0800 UTC
-Original Message- From: Hans Zimmermann [mailto:[EMAIL PROTECTED] Sent: Friday, October 10, 2008 05:33 To: [EMAIL PROTECTED] Subject: GlobalSET - November 2008 To all participants of GAREC-05-06-07-08: The next GlobalSET has been announced for 8 November 2008. Below please find the details for this second global emergency communications exercise, provided by the organizer of the event, Greg Mossop, G0DUB. PSE QSP - pass on the information to your emergency communications groups ! TNX in advance and 73 Hans, F5VKP / HB9AQS IARU International Coordinator for Emergency Communications (This message is being sent to all participants of GAREC-05, -06, -07, -08; I have tried to consolidate all the addresses, but please let me know in case you receive more than one copy, so that I can correct the list accordingly, tnx.) - Global Simulated Emergency Test - November 2008 *Saturday November 8th 2008 04.00 - 08.00 UTC* IARU Region 1 invites the HQ-Stations of all IARU member societies and stations of Emergency Communications Groups to participate in a Global Simulated Emergency Test on Saturday November 8th, 2008 04.00 - 08.00 UTC. The operation will take place on and near the emergency Centre-of-Activity (CoA) frequencies on 80, 40, 20, 17 and 15 metres (+-QRM ). The objectives of the test are; 1/ increase the common interest in emergency communications. 2/ test how usable the CoA frequencies are across ITU regions. 3/ create practices for international emergency communication and 4/ practice the relaying of messages using all modes. Please remember that this is not a contest, it is an emergency communications exercise ! Following the recommendation of the GAREC conferences, participating stations are requested to use /D in their callsign (D=distress/disaster) where permitted by their licensing administration. Traffic may be passed on voice (SSB), Data or CW modes as detailed below. Voice mode Each IARU Region will have a HQ station operating on voice as follows: Region 1 - TBA Region 2 - TBA Region 3 - TBA HQ stations will be QRV simultaneously on all CoA frequencies appropriate to their region +- QRM as shown below. Region 1 Region 2 Region 3 3760 3750 or 3985 3760 7060 7060, 7240 or 7290 7060 14300 18160 21360 Stations intending to participate are requested to send their callsigns to [EMAIL PROTECTED] before the exercise so that HQ stations can be aware of the number of stations calling them. A list of participating stations will also be available at www.raynet-hf.net To practice relaying messages, each participating station is allowed to send six (6) messages: three during the first two hours and three more during the last two hours of the test. After sending their own messages, participating stations should start to relay messages of other stations, when a message has been relayed twice it should then be sent to the HQ station of their own region. It is very useful if messages 'jump'' between countries and/or Regions. Participating stations should call 'CQ GLOBALSET' giving their callsign and organisation ( ARES,RAYNET, NETMAR etc. ). Each participating station will send up to six messages to their Regional HQ station as follows; - Time of sending the message in UTC - The callsign of the sending station - Message number - 1,2 or 3 in the first half of the exercise, 4,5 or 6 in the second half. - Bands available for use - use the meter band designation NOT frrequency. - Number of operators at the station - Emergency power available - 1=None, 2=Battery, 3=Generator (of any kind), 4= Battery and Generator. - Emergency Communications Group or National Society - As messages are relayed, add via... via... to show the callsigns of stations which have relayed this message. A one-character prefix will be used before each part of the message in order to make it easier to decode Where: - M(ike) = Message number - B(ravo) = Band available - O(scar) = Operators - P(apa) = Power available When a station other than an HQ station receives a message, it should relay the message towards the destination in whatever way it can. For example :- a message originated by SU1KM in Egypt for the Region 1 HQ station might be passed initially to a station in Malta on 40m, from there to a French station on 80m, and finally to the destination HQ station on 80m. For example :- 1. ZS6BUU sending message number 1 at 0430UTC, 80,40,20,10m bands available, 3 operators, no emergency power, member of HAMNET. 0430 ZS6BUU M1 B80 B40 B20 B10 O03 P1 HAMNET 2. MM3UJL/P sending message number 4 at 0700UTC, 160,80,40,20,10m bands available, 2 operators, both battery and generator available, member of RAYNET 0700 MM3UJL/P M4 B160 B80 B40 B20 B10 O02 P4 RAYNET Regional HQ stations will not sending messages, only receive them.
Re: [digitalradio] Re: Sound card question
Hello Skip, TKS for the information. I read the specifications. It seems to be a DominoEX with a MFSK16 interleaver (in the FEC DominoEx, in accord with Murray Greenman, I had reduced it as it seemed to me that the delay was a bit long). Do you confirm that it is the only difference? If so, due to the longer interleaver, the Thor mode must be a bit more robust than DominoEx Fec but with a longer delay. 73 Patrick - Original Message - From: kh6ty To: digitalradio@yahoogroups.com Sent: Saturday, October 11, 2008 4:07 PM Subject: Re: [digitalradio] Re: Sound card question Patrick, John, The link on the Thor web page, http://w1hkj.com/FldigiHelp/Thor.html, provides some additional technical specifications for Thor: http://w1hkj.com/FldigiHelp/Modes/THORdesc.htm To answer John's question, Thor uses full time FEC. 73, Skip KH6TY NBEMS Development Team - Original Message - From: Patrick Lindecker To: digitalradio@yahoogroups.com Sent: Saturday, October 11, 2008 9:25 AM Subject: Re: [digitalradio] Re: Sound card question Hello John, As far as I know, there are no public specifications or description of THOR modes. 73 Patrick - Original Message - From: vk2eta [EMAIL PROTECTED] To: digitalradio@yahoogroups.com Sent: Saturday, October 11, 2008 12:01 PM Subject: [digitalradio] Re: Sound card question Vojtech and Patrick thanks you for the reply. I effectively didn't realize synchronization was so critical too. Interesting. Just a comment/question to both, since you are both developers of widely used programs (and I take this opportunity to thank you both for that), I discovered the THOR mode as release by Dave in Fldigi and I have to say based on the preliminary test that I have done (and echoed by tests done by Rein developer of the PSKmail system), that I am very impressed by the performance I get. It is also an ifsk mode like DominoEx but for some reason performs much better at least as implemented in fldigi. Not sure if it is the permanent FEC but is seems quite robust in my tests between VK and ZL. Have you had any comments or request for implementation in your software or is it just too new, or not different enough? 73s, John VK2ETA (And for Patrick, Ex FK8DV. Merci) Announce your digital presence via our Interactive Sked Page at http://www.obriensweb.com/sked 30M digital activity at http://www.projectsandparts.com/30m Recommended software : DM780, Multipsk, FLDIGI, Winwarbler ,MMVARI. Yahoo! Groups Links Internal Virus Database is out of date. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.6.6/1626 - Release Date: 8/21/2008 6:54 PM
Re: [digitalradio] Re: Contestia 1K vs MT63?
Hello Vojtech and Tony, has very low crest factor, so the effective transmitted power will be An example, with a 100 watts HF transceiver, keeping linear: * you can transmit 10 watts of MT63, * you can transmit 76 watts of Contestia. 73 Patrick - Original Message - From: Vojtech Bubnik [EMAIL PROTECTED] To: digitalradio@yahoogroups.com Sent: Saturday, October 11, 2008 4:08 PM Subject: [digitalradio] Re: Contestia 1K vs MT63? Hi Tony. Even though the simulation results look promising for MT63, they do not take real HAM SSB transceiver into account. SSB PA of an average HAM TRX is usually not very linear and the many carriers of MT63 will mix with each other, which will show up as an added noise. Also MT63 has very low crest factor, so the effective transmitted power will be much lower than of Contestia if you do not overdrive the TX. I bet you will be better of to use Contestia on the air using let's say an average 100W YaeComWood. 73, Vojtech --- In digitalradio@yahoogroups.com, Tony [EMAIL PROTECTED] wrote: All, I was playing with the Contestia mode in an attempt to duplicate the wpm rate of MT63. I configured Contestia with 16 tones and a bandwidth of 1K. The sensitivity of the two seemed to be the same and the wpm rate appeared to be close. I then tested both modes with the HF path simulator dialed-in for selective fading with the SNR set a few db above the minimum decode threshold. As you can see below, print was better with MT63. The deep fades caused garbled characters with Contestia and it would appear the better copy with MT63 is a result of the redundancy built into the mode. I'm not sure if that's an accurate assessment as to why there is a difference, but it would seem so. Wonder if anyone can shed some light on this. Tony, K2MO Path Simulation : Selective Fading SNR : -3db / -6db Contestia 1K / 16 tone SNR -3db THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOS OVER TH- G THE BROWN FOXMPS OVER THE LAZY DOG THE QUICRO,N FOX JUMPS OVELAZY DOG SNR -6db TE QUCK BROW FOX JUMPS OVER THE LAZY DOG THE QUG2NOWNS YVER THOEG THE BROWN FO#UBR OVER TE LAZY DOG THE QUIC^_^N FOX JUMPS OVELAZY DOG MT63 1K SNR -3db *DE K2MO* THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG *EOT* SNR -6db *DE K2M TH QUICK AOWN FOX JUOP; OVrR THE LAZY ROG THE Q%ICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWNFOX JUMPS OVER THE LAZY DOG *EOT* Announce your digital presence via our Interactive Sked Page at http://www.obriensweb.com/sked 30M digital activity at http://www.projectsandparts.com/30m Recommended software : DM780, Multipsk, FLDIGI, Winwarbler ,MMVARI. Yahoo! Groups Links
[digitalradio] Decoding differences
Just this morning I came across a net running in Olivia 8-tone/1000Hz. It decoded poorly in one SW package, better in another, and best of all in a third. I think this must be due to the decoding algorithms of the software packages, as I get different rankings in other modes. Cortland KA5S
Re: [digitalradio] Contestia 1K vs MT63?
Patrick, I get the same minimum SNR for Contestia but can squeeze -8db out of MT63 when using DM780 and IZ8BLY. Some MT63 programs have a higher decode threshold for reasons you've mentioned previously. The threshold difference shows on-air as well as under controlled conditions and so it would seem that the best way to get the most out of MT63 is to use software that decodes deeper into the noise. The 10-to-1 peak-to-average power ratio is an excellent point and it's obvious that Contestia will put more RF into the air on average. There's no doubt in my mind that the Contestia 16-1K will do better most of the time. On the other hand, it does not seem to recover from the complete drop-outs that occur during deep fading or with lightning static the way MT63 does. I've tested this theory by removing short 1-to-3 second segments of the signal at random intervals and the mode continues to print despite the missing 'chunks'. As you say, this could be due to the difference in modulation speeds. Is there an alternative mode that I can test that might have similar characteristics? Thanks, Tony, K2MO - Original Message - From: Patrick Lindecker [EMAIL PROTECTED] To: digitalradio@yahoogroups.com Sent: Saturday, October 11, 2008 5:02 AM Subject: Re: [digitalradio] Contestia 1K vs MT63? Hello Tony, According to my measures (under noise only): * 16-1K: Fast 16 tones, bandwidth=1000 Hz, speed=62.5 bauds, 78.2 wpm, lowest S/N =-9 dB, * MT63 1K: 100 wpm, lowest S/N - 5 dB for 10 bauds (perhaps -7dB with the original program) but due to the Pmean/Ppeak: 0.1, it is only theoritical, except if you prefer QRP transmissions. I'm not sure if that's an accurate assessment as to why there is a difference, but it would seem so. Wonder if anyone can shed some light on this. The difference in Selective Fading conditions is perhaps due to the modulation speeds which are rather different. 73 Patrick - Original Message - From: Tony To: digitalradio@yahoogroups.com Sent: Saturday, October 11, 2008 7:44 AM Subject: [digitalradio] Contestia 1K vs MT63? All, I was playing with the Contestia mode in an attempt to duplicate the wpm rate of MT63. I configured Contestia with 16 tones and a bandwidth of 1K. The sensitivity of the two seemed to be the same and the wpm rate appeared to be close. I then tested both modes with the HF path simulator dialed-in for selective fading with the SNR set a few db above the minimum decode threshold. As you can see below, print was better with MT63. The deep fades caused garbled characters with Contestia and it would appear the better copy with MT63 is a result of the redundancy built into the mode. I'm not sure if that's an accurate assessment as to why there is a difference, but it would seem so. Wonder if anyone can shed some light on this. Tony, K2MO Path Simulation : Selective Fading SNR : -3db / -6db Contestia 1K / 16 tone SNR -3db THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOS OVER TH- G THE BROWN FOXMPS OVER THE LAZY DOG THE QUICRO,N FOX JUMPS OVELAZY DOG SNR -6db TE QUCK BROW FOX JUMPS OVER THE LAZY DOG THE QUG2NOWNS YVER THOEG THE BROWN FO#UBR OVER TE LAZY DOG THE QUIC^_^N FOX JUMPS OVELAZY DOG MT63 1K SNR -3db *DE K2MO* THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG *EOT* SNR -6db *DE K2M TH QUICK AOWN FOX JUOP; OVrR THE LAZY ROG THE Q%ICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWNFOX JUMPS OVER THE LAZY DOG *EOT*
Re: [digitalradio] Decoding differences
Nope - the code is almost the same - it'll be soundcard calibration issues. Simon Brown, HB9DRV www.ham-radio-deluxe.com - Original Message - From: Cortland [EMAIL PROTECTED] Just this morning I came across a net running in Olivia 8-tone/1000Hz. It decoded poorly in one SW package, better in another, and best of all in a third. I think this must be due to the decoding algorithms of the software packages, as I get different rankings in other modes.
[digitalradio] Thor Technical Description
The following is an excerpt from the web page Sights and Sounds of Digital Signals, http://www.w1hkj.com/FldigiHelp/Modes/index.htm. THOR Modes General Description THOR is a family of offset incremental multi-frequency shift keyed modes with low symbol rate, closely related to DominoEX. A single carrier of constant amplitude is stepped between 18 tone frequencies in a constant phase manner. As a result, no unwanted sidebands are generated, and no special amplifier linearity requirements are necessary. The tones change according to an offset algorithm which ensures that no sequential tones are the same or adjacent in frequency, considerably enhancing the inter-symbol interference resistance to multi-path and Doppler effects. The mode has full-time Forward Error Correction, so is extremely robust. The default speed (11 baud) was designed for NVIS conditions (80m at night), and other speeds suit weak signal LF, and high speed HF use. The use of incremental keying gives the mode complete immunity to transmitter-receiver frequency offset, drift and excellent rejection of propagation induced Doppler. Protocol These are unconnected, manually controlled message asynchronous simplex chat modes, using binary convolutional Forward Error Correction. The default calling mode is THOR11. Coding and Character Set A binary varicode with ASCII-256 user interface (same as MFSK16) is used. Lower case characters are sent faster. An ASCII-128 secondary character set extension allows a fixed (typically ID) message to be sent whenever the transmitter is idle. Modulation uses two dibit pairs, symbol synchronous, differential. The FEC system uses binary convolution to generate two dibits per varicode bit, and halves the corrected data rate compared to the equivalent DominoEX mode. Rate R=1/2, Constraint length K=7, Interleaver L=10 (40 bits). *Operating Parameters* *Mode* *Symbol Rate* *Typing Speed^1 * *Duty Cycle^2 * *Bandwidth^3 * *ITU Designation^4 * THOR4^5 3.90625 baud14 wpm 100%173 Hz 173HF1B THOR5^5 5.3833 baud 22 wpm 100%244 Hz 244HF1B THOR8^5 7.8125 baud 28 wpm 100%346 Hz 346HF1B THOR11^610.766 baud 40 wpm 100%262 Hz 262HF1B THOR16 15.625 baud 58 wpm 100%355 Hz 355HF1B THOR22 21.533 baud 78 wpm 100%524 Hz 524HF1B *Notes:* 1. WPM is based on an average 5 characters per word, plus word space. Values based on sending 100 paris words. 2. Transmitter average power output relative to a constant carrier of the same PEP value. 3. This is the Necessary Bandwidth as defined by the ITU. 4. A summary of the ITU Designation system can be found at http://en.wikipedia.org/wiki/Types_of_radio_emissions 5. Double spaced mode. 6. Default and normal calling mode. Implementation details are contained in the GPL software source code for fldigi which can be downloaded from the following site: http://www.w1hkj.com/fldigi-distro/fldigi-3.03.tar.gz This is a tar zipped format that will be familiar to all Unix, Linux, Free BSD and OS X developers. Windows developers can unzip this type of archive using one of several archive managers including PKZIP. Fldigi is open source source software that is licensed under the General Public License, http://www.gnu.org/copyleft/gpl.html. You are free to use the source intact, to modify, to improve and even to incorporate into a commercial product. You must however abide by the the license under which it has been developed and published. To date one other amateur product has used fldigi source with great success, DM-780, by Simon Brown. 73, Dave, W1HKJ
[digitalradio] Re: Sound card question
The following is an excerpt from the web page Sights and Sounds of Digital Signals, http://www.w1hkj.com/FldigiHelp/Modes/index.htm. THOR Modes General Description THOR is a family of offset incremental multi-frequency shift keyed modes with low symbol rate, closely related to DominoEX. A single carrier of constant amplitude is stepped between 18 tone frequencies in a constant phase manner. As a result, no unwanted sidebands are generated, and no special amplifier linearity requirements are necessary. The tones change according to an offset algorithm which ensures that no sequential tones are the same or adjacent in frequency, considerably enhancing the inter-symbol interference resistance to multi-path and Doppler effects. The mode has full-time Forward Error Correction, so is extremely robust. The default speed (11 baud) was designed for NVIS conditions (80m at night), and other speeds suit weak signal LF, and high speed HF use. The use of incremental keying gives the mode complete immunity to transmitter-receiver frequency offset, drift and excellent rejection of propagation induced Doppler. Protocol These are unconnected, manually controlled message asynchronous simplex chat modes, using binary convolutional Forward Error Correction. The default calling mode is THOR11. Coding and Character Set A binary varicode with ASCII-256 user interface (same as MFSK16) is used. Lower case characters are sent faster. An ASCII-128 secondary character set extension allows a fixed (typically ID) message to be sent whenever the transmitter is idle. Modulation uses two dibit pairs, symbol synchronous, differential. The FEC system uses binary convolution to generate two dibits per varicode bit, and halves the corrected data rate compared to the equivalent DominoEX mode. Rate R=1/2, Constraint length K=7, Interleaver L=10 (40 bits). Operating Parameters Mode Symbol Rate Typing Speed1 Duty Cycle2 Bandwidth3 ITU Designation4 THOR45 3.90625 baud14 wpm 100%173 Hz 173HF1B THOR55 5.3833 baud 22 wpm 100%244 Hz 244HF1B THOR85 7.8125 baud 28 wpm 100%346 Hz 346HF1B THOR116 10.766 baud 40 wpm 100%262 Hz 262HF1B THOR16 15.625 baud 58 wpm 100%355 Hz 355HF1B THOR22 21.533 baud 78 wpm 100%524 Hz 524HF1B Notes: 1. WPM is based on an average 5 characters per word, plus word space. Values based on sending 100 paris words. 2. Transmitter average power output relative to a constant carrier of the same PEP value. 3. This is the Necessary Bandwidth as defined by the ITU. 4. A summary of the ITU Designation system can be found at http://en.wikipedia.org/wiki/Types_of_radio_emissions 5. Double spaced mode. 6. Default and normal calling mode. Implementation details are contained in the GPL software source code for fldigi which can be downloaded from the following site: http://www.w1hkj.com/fldigi-distro/fldigi-3.03.tar.gz This is a tar zipped format that will be familiar to all Unix, Linux, Free BSD and OS X developers. Windows developers can unzip this type of archive using one of several archive managers including PKZIP. Fldigi is open source source software that is licensed under the General Public License, http://www.gnu.org/copyleft/gpl.html. You are free to use the source intact, to modify, to improve and even to incorporate into a commercial product. You must however abide by the the license under which it has been developed and published. To date one other amateur product has used fldigi source with great success, DM-780, by Simon Brown. DominoEX-FEC and THOR differ in two ways: The FEC table structures in DominoEX-FEC have been manipulated in a way that prevents the transmission of control codes. THOR uses the same FEC table as MFSK and can transmit the full ASCII character set. The interleave used in THOR is longer than used in DominoEX-FEC, and it will have a slower throughput but greater immunity againts multi-path. Fldigi can encode and decode both DominoEX-FEC and THOR. 73, Dave, W1HKJ
Re: [digitalradio] Contestia 1K vs MT63?
TKS Tony for the information, I've tested this theory by removing short 1-to-3 second segments of the signal at random intervals and the mode continues to print despite the missing 'chunks'. Yes MT63 has a good frequency and time diversity. And at 100 wpm, there are no many modes... A Contestia 32 / 1K could be a better alternative than the 16/1K. 73 Patrick - Original Message - From: Tony To: digitalradio@yahoogroups.com Sent: Saturday, October 11, 2008 8:40 PM Subject: Re: [digitalradio] Contestia 1K vs MT63? Patrick, I get the same minimum SNR for Contestia but can squeeze -8db out of MT63 when using DM780 and IZ8BLY. Some MT63 programs have a higher decode threshold for reasons you've mentioned previously. The threshold difference shows on-air as well as under controlled conditions and so it would seem that the best way to get the most out of MT63 is to use software that decodes deeper into the noise. The 10-to-1 peak-to-average power ratio is an excellent point and it's obvious that Contestia will put more RF into the air on average. There's no doubt in my mind that the Contestia 16-1K will do better most of the time. On the other hand, it does not seem to recover from the complete drop-outs that occur during deep fading or with lightning static the way MT63 does. I've tested this theory by removing short 1-to-3 second segments of the signal at random intervals and the mode continues to print despite the missing 'chunks'. As you say, this could be due to the difference in modulation speeds. Is there an alternative mode that I can test that might have similar characteristics? Thanks, Tony, K2MO - Original Message - From: Patrick Lindecker [EMAIL PROTECTED] To: digitalradio@yahoogroups.com Sent: Saturday, October 11, 2008 5:02 AM Subject: Re: [digitalradio] Contestia 1K vs MT63? Hello Tony, According to my measures (under noise only): * 16-1K: Fast 16 tones, bandwidth=1000 Hz, speed=62.5 bauds, 78.2 wpm, lowest S/N =-9 dB, * MT63 1K: 100 wpm, lowest S/N - 5 dB for 10 bauds (perhaps -7dB with the original program) but due to the Pmean/Ppeak: 0.1, it is only theoritical, except if you prefer QRP transmissions. I'm not sure if that's an accurate assessment as to why there is a difference, but it would seem so. Wonder if anyone can shed some light on this. The difference in Selective Fading conditions is perhaps due to the modulation speeds which are rather different. 73 Patrick - Original Message - From: Tony To: digitalradio@yahoogroups.com Sent: Saturday, October 11, 2008 7:44 AM Subject: [digitalradio] Contestia 1K vs MT63? All, I was playing with the Contestia mode in an attempt to duplicate the wpm rate of MT63. I configured Contestia with 16 tones and a bandwidth of 1K. The sensitivity of the two seemed to be the same and the wpm rate appeared to be close. I then tested both modes with the HF path simulator dialed-in for selective fading with the SNR set a few db above the minimum decode threshold. As you can see below, print was better with MT63. The deep fades caused garbled characters with Contestia and it would appear the better copy with MT63 is a result of the redundancy built into the mode. I'm not sure if that's an accurate assessment as to why there is a difference, but it would seem so. Wonder if anyone can shed some light on this. Tony, K2MO Path Simulation : Selective Fading SNR : -3db / -6db Contestia 1K / 16 tone SNR -3db THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOS OVER TH- G THE BROWN FOXMPS OVER THE LAZY DOG THE QUICRO,N FOX JUMPS OVELAZY DOG SNR -6db TE QUCK BROW FOX JUMPS OVER THE LAZY DOG THE QUG2NOWNS YVER THOEG THE BROWN FO#UBR OVER TE LAZY DOG THE QUIC^_^N FOX JUMPS OVELAZY DOG MT63 1K SNR -3db *DE K2MO* THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG *EOT* SNR -6db *DE K2M TH QUICK AOWN FOX JUOP; OVrR THE LAZY ROG THE Q%ICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWNFOX JUMPS OVER THE LAZY DOG *EOT*
[digitalradio] THOR robustness or lack thereof
Great information, Dave, On other thing that I can not understand is why THOR's performance proved to be so poor on Tony's tests. The robustness to multipath and Doppler does not seem to show up although sensitivity at -15 dB SNR seems quite good. It might be understandable with the more severe amounts such as high latitude 7 msec path delay and 30 Hz Doppler, where the test indicated no copy with THOR11 even at -3 dB SNR. But even at more modest low latitude 6 ms path delay with 10 Hz Doppler and a -8 dB SNR there is still no copy. And most surprising is the Mid-Latitude 2 ms path delay with only 1 Hz Doppler at -8 dB and THOR11 was decoding only 80%. At most of these conditions, Olivia 500/16, and Olivia 500/8, and often MFSK16, provided perfect copy and THOR11 showed no copy at all. Can anyone explain how this can be? 73, Rick, KV9U David Freese wrote: The following is an excerpt from the web page Sights and Sounds of Digital Signals, http://www.w1hkj.com/FldigiHelp/Modes/index.htm. THOR Modes General Description THOR is a family of offset incremental multi-frequency shift keyed modes with low symbol rate, closely related to DominoEX. A single carrier of constant amplitude is stepped between 18 tone frequencies in a constant phase manner. As a result, no unwanted sidebands are generated, and no special amplifier linearity requirements are necessary. The tones change according to an offset algorithm which ensures that no sequential tones are the same or adjacent in frequency, considerably enhancing the inter-symbol interference resistance to multi-path and Doppler effects. The mode has full-time Forward Error Correction, so is extremely robust. The default speed (11 baud) was designed for NVIS conditions (80m at night), and other speeds suit weak signal LF, and high speed HF use. The use of incremental keying gives the mode complete immunity to transmitter-receiver frequency offset, drift and excellent rejection of propagation induced Doppler. Protocol These are unconnected, manually controlled message asynchronous simplex chat modes, using binary convolutional Forward Error Correction. The default calling mode is THOR11. Coding and Character Set A binary varicode with ASCII-256 user interface (same as MFSK16) is used. Lower case characters are sent faster. An ASCII-128 secondary character set extension allows a fixed (typically ID) message to be sent whenever the transmitter is idle. Modulation uses two dibit pairs, symbol synchronous, differential. The FEC system uses binary convolution to generate two dibits per varicode bit, and halves the corrected data rate compared to the equivalent DominoEX mode. Rate R=1/2, Constraint length K=7, Interleaver L=10 (40 bits). Operating Parameters Mode Symbol Rate Typing Speed1 Duty Cycle2 Bandwidth3ITU Designation4 THOR453.90625 baud14 wpm 100%173 Hz 173HF1B THOR555.3833 baud 22 wpm 100%244 Hz 244HF1B THOR857.8125 baud 28 wpm 100%346 Hz 346HF1B THOR116 10.766 baud 40 wpm 100%262 Hz 262HF1B THOR1615.625 baud 58 wpm 100%355 Hz 355HF1B THOR2221.533 baud 78 wpm 100%524 Hz 524HF1B Notes: 1. WPM is based on an average 5 characters per word, plus word space. Values based on sending 100 paris words. 2. Transmitter average power output relative to a constant carrier of the same PEP value. 3. This is the Necessary Bandwidth as defined by the ITU. 4. A summary of the ITU Designation system can be found at http://en.wikipedia.org/wiki/Types_of_radio_emissions 5. Double spaced mode. 6. Default and normal calling mode. Implementation details are contained in the GPL software source code for fldigi which can be downloaded from the following site: http://www.w1hkj.com/fldigi-distro/fldigi-3.03.tar.gz This is a tar zipped format that will be familiar to all Unix, Linux, Free BSD and OS X developers. Windows developers can unzip this type of archive using one of several archive managers including PKZIP. Fldigi is open source source software that is licensed under the General Public License, http://www.gnu.org/copyleft/gpl.html. You are free to use the source intact, to modify, to improve and even to incorporate into a commercial product. You must however abide by the the license under which it has been developed and published. To date one other amateur product has used fldigi source with great success, DM-780, by Simon Brown. DominoEX-FEC and THOR differ in two ways: The FEC table structures in DominoEX-FEC have been manipulated in a way that prevents the transmission of control codes. THOR uses the same FEC table as MFSK and can transmit the full ASCII character set. The interleave used in THOR is longer than used in DominoEX-FEC, and it will have a slower throughput but greater immunity againts multi-path. Fldigi can encode and decode both
Re: [digitalradio] Decoding differences
Hello Cortland, Yes this is due to different sound card speeds. With a perfect sound card speed for each application, the decodings are very similar. Olivia is very sensitive to soundcard speed accuracy, not as much as MT63 but... 73 Patrick - Original Message - From: Simon Brown (KNS) [EMAIL PROTECTED] To: digitalradio@yahoogroups.com Sent: Saturday, October 11, 2008 9:25 PM Subject: Re: [digitalradio] Decoding differences Nope - the code is almost the same - it'll be soundcard calibration issues. Simon Brown, HB9DRV www.ham-radio-deluxe.com - Original Message - From: Cortland [EMAIL PROTECTED] Just this morning I came across a net running in Olivia 8-tone/1000Hz. It decoded poorly in one SW package, better in another, and best of all in a third. I think this must be due to the decoding algorithms of the software packages, as I get different rankings in other modes. Announce your digital presence via our Interactive Sked Page at http://www.obriensweb.com/sked 30M digital activity at http://www.projectsandparts.com/30m Recommended software : DM780, Multipsk, FLDIGI, Winwarbler ,MMVARI. Yahoo! Groups Links
Re: [digitalradio] Decoding differences
I thought that might be the case, but having calibrated the sound card clock in each of the three packages MultiPSK, fldigi and MixW, the differences persist.I may try a better sound card. Cortland KA5S [Original Message] From: Simon Brown \(KNS\) [EMAIL PROTECTED] To: digitalradio@yahoogroups.com Date: 10/11/2008 3:25:39 PM Subject: Re: [digitalradio] Decoding differences Nope - the code is almost the same - it'll be soundcard calibration issues. Simon Brown, HB9DRV www.ham-radio-deluxe.com - Original Message - From: Cortland [EMAIL PROTECTED] Just this morning I came across a net running in Olivia 8-tone/1000Hz. It decoded poorly in one SW package, better in another, and best of all in a third. I think this must be due to the decoding algorithms of the software packages, as I get different rankings in other modes.
Re: [digitalradio] Contestia 1K vs MT63?
Tony wrote: Patrick, I get the same minimum SNR for Contestia but can squeeze -8db out of MT63 when using DM780 and IZ8BLY. Yesterday I had no luck with DM780 while monitoring Tony's QSO's on 14106. Of course, I have not calibrated DM780, so that is no surprise. Propagation was not good, but MultiPSK did fairly well. The threshold difference shows on-air as well as under controlled conditions and so it would seem that the best way to get the most out of MT63 is to use software that decodes deeper into the noise. No doubt... The 10-to-1 peak-to-average power ratio is an excellent point and it's obvious that Contestia will put more RF into the air on average. There's no doubt in my mind that the Contestia 16-1K will do better most of the time. I have doubts on this department. If the peak amplitudes are the same, as may be happening with the audio tests, the decoding on those conditions should be equally valid. Of course, Vojtech points out that MT63 is more sensitive to distortions which are pretty common with some not so careful operators. Fast attack slow decay ALC could have a chance of correcting some of the overloads after the transmit IF, but the rest of the chain, from the audio input to the IF should receive proper audio levels. I have seen rebel cases of distorted PSK-31 when people closes the mic gain and distortion remains... because the early stages of the transceiver are already overloaded, and I had a real bad luck when explaining that to the other operator. People should know their way around... On the other hand, it does not seem to recover from the complete drop-outs that occur during deep fading or with lightning static the way MT63 does. I was browsing my references this afternoon (local) and I I decided not to send a reply, since it seemed that Vojtech had a good point and was not worth arguing about it. Nevertheless, I wonder how the degradating effect of -30 to -20 dB IMD, the usually accepted values when adding that to the channel noise. Even more when I read that Contestia was devised with a flat envelope on mind (nonlinearity does not affect it) and uses about the same Walsh-Hadamard code. But it _might_ mean, conversely, that Contestia is more power greedy, an important consideration for emergency operation. I've tested this theory by removing short 1-to-3 second segments of the signal at random intervals and the mode continues to print despite the missing 'chunks'. As you say, this could be due to the difference in modulation speeds. Is there an alternative mode that I can test that might have similar characteristics? I did not find any details on my references, but seemingly interleaving is done both in the time and frequency domains, so there is more chance for MT63 to get the message thru, specially with long interleave. On the other hand, if someone pulls the carpet (heavy doppler) there is a risk that MT63 will fail strepitously with bits falling on the wrong bins while a mode with less, wider frequency bins (like Contestia or Olivia) will really shine. I had really a low esteem for MT-63, but it had been hard to make a MT-63 QSO before Tony started the present tests campaign. It just happens that each mode should be used according to its most promiment strengths. I still have low steem for Chip-64... 8-) 73, Jose, CO2JA
[digitalradio] More Going ATV Digitally
http://www.arrl.org/news/features/2008/10/10/10380/ Surfin': More Going ATV Digitally By Stan Horzepa, WA1LOU Contributing Editor October 10, 2008 This week's Surfin' again considers Web sites related to Amateur Television (ATV) going digital. Amateur Television in Central Ohio (ATCO) has had the first US digital ATV (D-ATV) repeater system on the air for three years. Back to last week's Surfin' http://www.arrl.org/news/features/2008/10/03/10374/ about Amateur Television (ATV) going digital, I received some comments that are worth repeating here. Steve Lampereur, KB9MWR, recommended these resources for further information on the topic: Fundamentals of Digital Television Transmission, by Gerald W. Collins, PE (ISBN 0-471-21376-4) and Digital Amateur Television (D-ATV), by Don Rotolo, N2IRZ, in the June 2004 issue of CQ Magazine. Bob Hale, N1WBD, commented that Dish Network uses MPEG-2/DVB in their satellite service to US customers: One could homebrew a MPEG-2/DVB receiver and/or transmitter for use in D-ATV, or for that matter possibly modify a Dish Network receiver for use on D-ATV. Sjaak Van Dam, W4RIS (ex-PA3GVR), revealed that ATV hams in Europe have been experimenting with D-ATV for almost 10 years. The standard that they use is DVB-S, which is widely used in the US by free-to-air satellite providers. Art Towslee, WA8RMC, wrote that Amateur Television in Central Ohio (ATCO) in Columbus, Ohio, also has an operational D-ATV repeater system on the air and were the first ones in the US to do so. On the air for more than three years with excellent results, ATCO uses DVB-S modulation because of its simplicity, availability of inexpensive receivers and the ability to receive while in motion. In fact, they have had success with mobile digital ATV. You can learn more at the ATCO Web site http://www.atco.tv/. Until next time, keep on surfin'! Editor's note: Stan Horzepa, WA1LOU, still wonders if program content will also improve when commercial television goes digital on February 17. To communicate with Stan, send him e-mail or add comments to his blog. By the way, every installment of Surfin' is indexed here, so go look it up. Page last modified: 08:00 AM, 10 Oct 2008 ET Page author: [EMAIL PROTECTED] Copyright © 2008, American Radio Relay League, Inc. All Rights Reserved.
Re: [digitalradio] Global SET, Saturday, November 8 0400 - 0800 UTC
I had good intentions for the last GAREC SET and had even announced this at our county wide amateur radio club, however, I managed to completely slip up remembering and hope to do better this time around. Are any of you digital operators planning to participate, especially if using CW or digital modes during this event? I am not sure what mode(s) I might use but will operate as a single operator unless there is local interest. As noted in the information Mark had sent out, there will be no HQ stations that will have digital modes. I would have expected that there might be more interest in digital modes from originating stations to the HQ stations, but the main focus seems to be on e-mail delivery via digital mail systems such as Winlink 2000 and PSKmail or by e-mailing (after the two relays) to [EMAIL PROTECTED] Perhaps we can demonstrate that MFSK16 and Olivia (the most robust sound card modes) can well support this kind of event? Of course NBEMS would be another sound card approach using an ARQ sound card system for error free messaging. The use of CW appears to be as a back up if conditions are difficult enough that other modes won't work. Speed of CW is required to be 15 wpm maximum, so that might help attract some operators (like me) who would normally shy away from traffic handler type speeds, HI. You need to relay the structured message through at least two relay stations so you would only e-mail the messages to the HQ station in your region if you are the second relay. Maximum power is intended to be 100 watts or less and this makes it easier for those of us with emergency power. I have a generator system, but also have a good sized AGM 85 Amp/Hour battery which I would surely use. The information below can be accessed at the Global SET web site from the UK on RAY-NET at: http://www.raynet-hf.net/ http://www.raynet-hf.net/tiki-index.php What do you think? 73, Rick, KV9U Mark Thompson wrote: -Original Message- From: Hans Zimmermann [mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]] Sent: Friday, October 10, 2008 05:33 To: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Subject: GlobalSET - November 2008 To all participants of GAREC-05-06-07-08: The next GlobalSET has been announced for 8 November 2008. Below please find the details for this second global emergency communications exercise, provided by the organizer of the event, Greg Mossop, G0DUB. PSE QSP - pass on the information to your emergency communications groups ! TNX in advance and 73 Hans, F5VKP / HB9AQS IARU International Coordinator for Emergency Communications (This message is being sent to all participants of GAREC-05, -06, -07, -08; I have tried to consolidate all the addresses, but please let me know in case you receive more than one copy, so that I can correct the list accordingly, tnx.) - Global Simulated Emergency Test - November 2008 *Saturday November 8th 2008 04.00 - 08.00 UTC* IARU Region 1 invites the HQ-Stations of all IARU member societies and stations of Emergency Communications Groups to participate in a Global Simulated Emergency Test on Saturday November 8th, 2008 04.00 - 08.00 UTC. The operation will take place on and near the emergency Centre-of-Activity (CoA) frequencies on 80, 40, 20, 17 and 15 metres (+-QRM ). The objectives of the test are; 1/ increase the common interest in emergency communications. 2/ test how usable the CoA frequencies are across ITU regions. 3/ create practices for international emergency communication and 4/ practice the relaying of messages using all modes. Please remember that this is not a contest, it is an emergency communications exercise ! Following the recommendation of the GAREC conferences, participating stations are requested to use /D in their callsign (D=distress/disaster) where permitted by their licensing administration. Traffic may be passed on voice (SSB), Data or CW modes as detailed below. Voice mode Each IARU Region will have a HQ station operating on voice as follows: Region 1 - TBA Region 2 - TBA Region 3 - TBA HQ stations will be QRV simultaneously on all CoA frequencies appropriate to their region +- QRM as shown below. Region 1Region 2Region 3 37603750 or 39853760 70607060, 7240 or 7290 7060 14300 18160 21360 Stations intending to participate are requested to send their callsigns to [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] before the exercise so that HQ stations can be aware of the number of stations calling them. A list of participating stations will also be available at www.raynet-hf.net http://www.raynet-hf.net/ To practice relaying messages, each participating station is allowed to send six (6) messages: three during the first two hours and three more
