Re: [digitalradio] Announcing the 2009 Digitalradio Radio Awards
Hello all, It misses the most dynamic Ham for promotion of digital modes: Andy (K3UK). 73 Patrick Selon Andy obrien k3uka...@gmail.com: Digital Ham of The Year : Patrick F6CTE. Tremendous innovations is his software Multipsk in the past year. Patrick listens well, he is open to new ideas, and very talented in taking new ideas and making them work. The SDR capabilities already in Multipsk could be the way of the new decade. Best New Software: SDR-Console by Simon Brown HB9DRV. Just arrived in time for a new decade. Has taken SDR software to a new level. Still very early in development and missing some digital mode decoding integration, but what is already there is amazing. Matched with DM780 in 2010 look out. Best Logging Software: DX Keeper by Dave AA6YQ, again ! Biggest Surprise Of The Year: 1. RMS Express. A very nicely designed application with much promise for 2010 in the emcomm world. While Winmor was highly anticipated on 2009, the total RMS Package is the suprise. Combines Telnet and Winmor messaging with a useful mail client. 2. Increase in Olivia activity. Was almost dead but made a comeback in 2009 . 3. Decline of MFSK16, has taken Olivia's place on the digital death bed. 4. A new release of WSJT . Improvements have made my Bozo's Guide obsolete. Organization of the Year: WPA-NBEMS ( http://wpanbems.org/ ) WPA ARES . Via a well structured and polite approach to digital communication for Emcomm, they have succeeded in doing what many thought was impossible moved FM bound voice-repeater anchored RACES/ARES groups in to the modern age. Have also convinced the world that there is more to emcomm than packet! Their weekly digital practice nets are a model for all to follow. Innovators of the Year: Fldigi team: WRAP and FLICS added to FLDIGI/NBEMS have made this package an absolute must for emcomm hams. FLdigi has continued to develop way beyond a mere multimode application. The Picasso Award: Simon Brown HB9DRV . Two year in a row, but this year for SDR-Console stunningly useful AND looks GREAT. Best Digital Mode Website : PSKreporter by Philip Gladstone... Google maps with Grey Line overlay. LOTW and eQSL alerts, view any mode, etc , etc. The most useful website anyone looking for QSOs. Now being served by DM780, Multipsk, and Fldigi. Oddest Mode in 2009: Text messaging in Multipsk . OMG ! Wishes Come True Award: PSKMAIL for Windows. Nice to see Windows PSKMAIL client, a very useful application for emcomm and travelling hams. This was on the list of needs inventing in 2009. Needs Inventing in 2010 1. New codec for FDMDV, still ! 2. Softrock kits that actually exist. 3. Macro Zapper. Built in to all apps, declines to allow use of more than three macros in any one digital QSO! Disables transmit for one hour if you actually use the macro that counts how many DominoEx QSOs you have had on 12 meters! Most Anticipated Event in 2010: 1. Release of revised/upgraded PC-ALE . Some really cool stuff planned for what already is quite a remarkable application.. 2. Non-beta release of JT65-HF by Joe W6CQZ. The alpha-beta versions demonstrated this application to be the easiest way to get on the air with the most robust digital mode. The awards are based on the suggestions of the 3000+ membership of digitalradio and determined by Andy K3UK (because he knows best ). Andy K3UK Suggested frequencies for calling CQ with experimental digital modes = 3584,10147, 14074 USB on your dial plus 1000Hz on waterfall. Announce your digital presence via our Interactive Sked Pages at http://www.obriensweb.com/sked Yahoo! Groups Links
Re: [digitalradio] AFCW and keyed cw programs
Hello, Keying directly gives possibility to put a true keyer in parallel to the computerized keying, this to be able to either type letters or key the letters according to the feeling of the day. However, in hard keying , if the speed is not too much fast (=25 wpm), computerized dashes ans dots are OK but the precision of the duration being limited under Windows, very fast keying will be not very good (as far as i know). 73 Patrick Selon DANNY DOUGLAS n...@comcast.net: NO- AFCW is NOT better, and if you use it, half your contacts with tell you they hear some audio getting into your keying. I used it a few times, early on, and that is the results. Remember, you also will be using SSB, versus continus wave keying signals, and thus outputting less RF signal. Stay away from it, if at all possible. I hadnt gotten that far with FLDIGI, but if it uses only AFCW, Im gone. Danny Douglas N7DC ex WN5QMX ET2US WA5UKR ET3USA SV0WPP VS6DD N7DC/YV5 G5CTB All 2 years or more (except Novice). Short stints at: DA/PA/SU/HZ/7X/DU CR9/7Y/KH7/5A/GW/GM/F Pls QSL direct, buro, or LOTW preferred, I Do not use, but as a courtesy do upload to eQSL for those who do. Moderator DXandTALK http://groups.yahoo.com/group/DXandTalk Digital_modes http://groups.yahoo.com/group/digital_modes/?yguid=341090159 - Original Message - From: James French To: digitalradio@yahoogroups.com Sent: Wednesday, December 30, 2009 4:43 PM Subject: [digitalradio] AFCW and keyed cw programs I have used a couple of programs for generating cw and have found that I prefer a 'direct' keyed method (MixW) compared to the AFCW that some programs use (FlDigi). Running Linux BTW here. Was wondering why some programs used direct keying of the radio and others have gone the AFCW method? Is there something that I am missing here that makes AFCW a better choice or is it just a program writer/designer choice? Doing AFCW just doesn't 'sound' right to me when I am doing cw compared to the 'old' method. Are there any linux distroed programs that will do the direct keyed method? I haven't found any yet..:( MixW crashes when I try to run it in WINE here. James W8ISS
Re: [digitalradio] Re: RS ID
Hello all, To complete what Votjech wrote, for technical aspects of RS ID there is a paper about RS ID under the PAPERS on my Web site (http://f6cte.free.fr/PAPERS.ZIP). The hashing method introduced by Votjech is really very powerful and i integrated it in the last RS ID sources (in Pascal). 73 Patrick Selon Vojtech bubn...@seznam.cz: Reed-Solomon identification it is Google-able. A form of error correction or as we use it here, a form of mode /rate / number of tones etc identification. Technically, this explanation is a bit misnomer. While the Reed-Solomon codes are designed to detect and fix errors and there are various complex algorithms to do it, Patrick just used the Reed Solomon theory to generate a set of codes, which are most different from each other and from their mirror images when listening with reversed sideband. The RSID detector is much simpler than the true Reed Solomon decoder. Patrick in his original code was doing exhaustive search for all codes accepting two receive errors. Current implementations of RSID decoder in all applications supporting it take advantage of hashing method to speed up the exhaustive search. 73, Vojtech OK1IAK Suggested frequencies for calling CQ with experimental digital modes = 3584,10147, 14074 USB on your dial plus 1000Hz on waterfall. Announce your digital presence via our Interactive Sked Pages at http://www.obriensweb.com/sked Yahoo! Groups Links
[digitalradio] Re: ALE400 and FAE
Hello Rick and John, when to use ALE 400 and when to use FAE 400. Personally, I would rather I see this as in ALE (but I'm not a specialist): you can do soundings or calls (QRZ for example) to say notify your presence in the band and after the link with a Ham, you both begin exchanging messages in AMD, DTM, DBM or FAE or do a QSO in FAE or Unproto, or sending your APRS position in FAE. If you make a call on ALE 400, whether individual or group, or some kind of CQ (but I am not sure about how you call CQ other than maybe a QRZ selection?), and the other person is monitoring FAE 400, my understanding is that they will not decode your transmissions. The same thing happens the other way too. If they are monitoring on ALE 400 mode and you send a CQ on FAE 400, there would not be a connection. Is this correct? And if so, shouldn't we standardize on one mode or the other? All the sub-modes are decoded from any sub-mode you are (the sub-mode decoded is also displayed). number of modes, with about the same number of operators, there are fewer and fewer on a given mode at a given time (with the majority still staying on PSK31). Yes that's true. 73 Patrick
[digitalradio] Re: Shameless promotion of FAE 400
Rick, RR for all the experimentation done. with the typing speed. Since you can not backspace for an error (similar to RTTY) I do tend to make some xxx characters at times As, some time ago, you pointed out this issue, I fixed it in the very last version of Multipsk. Now you can use backspace as in PSK31... 73 Patrick
[digitalradio] Re: Licensing of Pactor modes - Source code and detailed specifications
Hello Simon, There is so much work involved in writing a fool-proof program with a good user interface that having to also write the encoding / decoding interface RR for all. Yes I understand and it's true that detailed specifications + source code as Peter have done with PSK31 was the best. But we are not all perfect... I hope, however, that we will be able to understand the JT65 code and so we will have the satisfaction to have gain in knowledge. 73 Patrick There is so much work involved in writing a fool-proof program with a good user interface that having to also write the encoding / decoding interface would make sure projects unfeasible for a single programmer who codes in his spare time. Simon HB9DRV
[digitalradio] Licensing of Pactor modes - Source code and detailed specifications
Hello Demetre and all, writers who although they allow everyone to use their program, they keep their code to themselves. Of course it is everyone's right to protect their code and I do not blame anyone here, I am just stating a fact. As I belong to this category (Multipsk author), here is my opinion about that. The source code is good but it is much better to have the detailed specifications. When I have only the source code, it is an ordeal to reverse engineers the detailed specifications from the source code. Do you imagine, if you have 10 lines of code, the amount of work it is to extract what it is important... However, you can directly use the code without understand it but it is not the way I do because it is without interest. So my philosophy is to supply detailed specifications to give possibility for others to be able to program their own decoding application. It's what I have ever done (included for ARQ FAE). Moreover, I think it is moral that a programmer has to do a bit of work to decode a mode. I saw that a professional decoder decodes some of my modes simply with my published specifications. And I'm quite sure that if I had published the source code but not the specifications, he would not have decoded those modes. So in conlusion, PSE don't keep on thinking that, naturally, if you have the code you have all the necessary. It is a false idea. 73 Patrick Note: in Pactor 1, you have detailed specifications...this mode can be decoded and I've done it (however, for an pure ARQ mode, there are some lacks). In Pactor 2 and 3: you have general specifications but not the detailed ones, so these modes can't be decoded.
Re: [digitalradio] Microham Router and MulitPSK 3.9
Hello Ron, I'm the author of this program. When you have set up a Com port on Multipsk, the Com port is opened (by extracting which is called a "handle") which causes a micro-second in TX. In all cases (Com set up or no), I check all the possible (16) com ports by trying to open them one after one and note the ones available on the list proposed to the user... 73 Patrick The K3UK DIGITAL MODES SPOTTING CLUSTER AT telnet://208.15.25.196/ More info at http:///www.obriensweb.com YAHOO! GROUPS LINKS Visit your group "digitalradio" on the web. To unsubscribe from this group, send an email to:[EMAIL PROTECTED] Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
[digitalradio] New release (3.8) of MULTIPSK (FM HELL, OLIVIA DF..)
New release (3.8) of MULTIPSK
RX/TX: PSK10/BPSK31/QPSK31/PSKFEC31/PSK63/PSKAM10-31-50/PSK63F - PSK220F + DIGISSTV "Run"/CW/CCW/THROB/THROBX/MFSK8/MFSK16 (+ SSTV)/OLIVIA DF/MT63/RTTY 45/ASCII/AMTOR FEC/ PACKET 300-1200 + APRS+ DIGISSTV "Run"/FELD HELL/PSK HELL/FM HELL/HELL 80/HF-FAX/SSTV/
RX only: AMTOR ARQ/NAVTEX/RTTY 50+SYNOP+SHIP/RTTY 75-100/PACTOR 1
DSP: FILTERS + CW binaural reception
PANORAMIC (RX 23 channels simultaneously): BPSK31/PSK63/PSKFEC31, with automatic reception
Programmation of Multipsk reception
+ CLOCK 1.5.2 (FRANCE-INTER, DCF77, HBG, RUGBY, WWVB, WWV, WWVH, GPS)
Hello to all Ham and SWL,
The new releases of MULTIPSK (3.8) and CLOCK (1.5.2) are in my Web site (http://members.aol.com/f6cte/).
The main mirror site is Earl's, N8KBR: http://multipsk.eqth.org/index.html
Another mirror site isTerry's: http://www.hamsoft.co.uk/
Multispk associated to Clock are freeware programs but with functions submitted to a licence (by user key).
Les nouvelle versions de MULTIPSK (3.8) et de CLOCK (1.5.2) sont sur mon site Web (http://members.aol.com/f6cte/)
Le principal site miroir est celui de Earl N8KBR: http://multipsk.eqth.org/index.html
Il y a également le site miroir de Terry: http://www.hamsoft.co.uk/
Multispk associé à Clock sont des programmes de type "graticiel" ("freeware") mais avec des fonctions soumises à licence (par clé utilisateur).
The main modifications of MULTIPSK (3.8) are the following:
1) possibility to code/decode the Hellschreiber mode FM HELL (see specifications further on),
2) RX/TX of GPS positions and altitudes (NMEA 183) in APRS
3) possibility to code/decode the OLIVIA Default mode (see specifications further on, the recommended frequencies being 7038.5 and 14107.5 KHz),
4) Help in German by Oskar (DL8MBF)...www.8ung.at/oskar.pickert
5) PDF file of the help by Terry: www.hamsoft.co.uk
6) AFC (Automatic Frequency Control) in RTTY.
7) A DLL (freeware) F6CTE_DLL_RX_SOUND_CARD_V_1 and two Delphi/C++ test programs are proposed to Hams and SWL who want to manage a sound card (RX), in a simple way.
8) correction de "bugs" sur CLOCK 1.5.2
For information, for all the Multipsk exotic modes (PSKFEC31, PSK10, PSKAM, PSK63F, PSK220F (+DIGISSTV), CCW, MFSK8, THROBX, OLIVIA...), I propose the QRP frequency: 14075 Khz USB (AF around 1000 Hz), at 17h00 UTC.
Les principales modifications de MULTIPSK V. 3.8 sont les suivantes:
1) possibilité de coder/décoder le mode Hellschreiber FM HELL (voir plus loin les spécifications),
2) RX/TX des positions et altitudes GPS (NMEA 183) en APRS,
3) possibilité de coder/décoder le mode OLIVIA par défault (voir plus loin les spécifications, les fréquences recommandées étant 7038,5 et 14107,5 KHz),
4) Aide en allemand par Oskar (DL8MBF)...www.8ung.at/oskar.pickert
5) Fichier PDF (en anglais) par Terry: www.hamsoft.co.uk
6) CAF (Contrôle Automatique de Fréquence) en RTTY.
7) Une DLL (graticiel) F6CTE_DLL_RX_SOUND_CARD_V_1 et deux programmes de test en Delphi/C++ sont proposés aux OM et SWL qui veulent gérer une carte son (RX), de manière simple,
8) correction de bugs sur CLOCK 1.5.2
Pour information, pour tous les modes exotiques de Multispk (PSKFEC31, PSK10, PSKAM, PSK63F, PSK220F (+DIGISSTV), CCW, MFSK8, THROBX, OLIVIA...) je propose la fréquence QRP: 14075 Khz USB (BF autour de 1000 Hz), à 17h00 UTC.
Description of the FM HELL mode
Createad by : Nino Porcino (IZ8BLY) and Murray Greenman (ZL1BPU)Baud rate : 105 or 245 (only 245 bauds on Multipsk)Matrix : for FM HELL 105 bauds…height: 6 pixels and width: 7 pixels for FM HELL 245 bauds…height: 7 pixels and width: 14 pixels Speed : 25 wpmModulation : MSK with a "minimum" shift between tones of 122.5 Hz (at 245 bauds). The white is at the upper frequency and the black at the lower one.Receive mode: USBCharacter set : all ASCII printable characters except small letters, carriage return (+ line feed) and error correction character. The used font (FeldHell) is derived from the font of G3PLX (Peter Martinez),Shape of pulse : rectangularBandwidth : about 130 Hz for 105 bauds and 300 Hz for 245 bauds,Synchronization: no need, each column is displayed vertically 2 times (but transmitted once)Pmean/Ppeak : 1Lowest S/N : - 10 dB for the 245 bauds modeDescription of the OLIVIA DF ("DeFault mode")
Creator : Pawel Jalocha SP9VRC in 2005
Baud rate : 31.25
Speed : 2.44 characters/sec so 24 wpm
Modulation : FSK 32 tones (5 bits arranged in a Gray form), with a shift between tones of 31.25 Hz (1000 Hz bandwidth). A block is composed of 64 symbols of 5 bits (in other words it is a matrix of 64 columns (following the time) on 5 lines). Each of the 5 block lines of this block corresponds to a character which has been encoded, on a 64 bits vector, using a Walsh-Hadamard transform to provide a high level of redundancy.
...
Reception mode: sensible to the side (USB or LSB), USB is recommended
Shape
Re: [digitalradio] Re: Olivia - tests ans questions
Hello Jerry and ON4CCX, TKS for all the information. I'll continue my investigation. 73 Patrick [Non-text portions of this message have been removed] The K3UK DIGITAL MODES SPOTTING CLUSTER AT telnet://208.15.25.196/ Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/digitalradio/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
[digitalradio] Olivia - tests ans questions
Hello to all, I have done some tests in Olivia modes between 2 XP computers, one with a good sound card and the other with a bad sound card (shift: 1.1 % at Sf (Sampling frequency)=8000 samples/sec and 0.7 % at 11025 samples/sec). I tested first the default Olivia mode: 32 tones, BW=1000 Hz. The criteria being a text transmitted without errors with an Olivia signal generated without noise, I found that the tolerance on the sound card Sf shift was equal to 0,5 %. This value is low compared to the scale of actual sound card shifts (up to 1,1 % or more?) and must pose problems to a big fraction of modern sound card, if the exact Sf of the sound card is not known (the most probable case will be a curious bad quality when decoding good signals). The solution is to use a 16 tones as in MFSK16 (with the hypothesis of speed in bauds equal to the gap between tones) or less (8 for example). So, with the Sf perfectly corrected, I tried the 16 tones mode and I noted that I had a lot of errors. Then I try 8 tones, 4 tones, 256 tones, BW=2000 Hz, 500 Hz, in all cases I had more or less errors (with a pure Olivia signal). And there, I have no logic answer to this. Question to Olivia users: do you meet that sort of problem on no-default speeds? Do you have ideas of the cause? TKS for answers 73 Patrick [Non-text portions of this message have been removed] The K3UK DIGITAL MODES SPOTTING CLUSTER AT telnet://208.15.25.196/ Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/digitalradio/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
[digitalradio] Olivia - Pawel e-mail adress
Hello Pawel (author of Olivia modes), I'm author of some softwares (Multipsk, Clock...) and interested to include one of the Olivia modes. I have sent you a mail (about precisions on specifications) but I have not received any answer. As I'm not sure (at all) of your e-mail adress, please tell me if you have not received the previous mail. My e-mail adress: [EMAIL PROTECTED] 73 Patrick [Non-text portions of this message have been removed] The K3UK DIGITAL MODES SPOTTING CLUSTER AT telnet://208.15.25.196/ Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/digitalradio/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
[digitalradio] New release (3.6) of MULTIPSK
New release (3.6) of MULTIPSK
RX/TX: PSK10/BPSK31/QPSK31/PSKFEC31/PSK63/PSKAM10-31-50/PSK63F - PSK220F + DIGISSTV "Run"/CW/CCW/THROB/THROBX/MFSK8/
MFSK16 (+ SSTV)/MT63/RTTY 45/ASCII/AMTOR FEC/PACKET 300-1200 + APRS/FELD HELL/PSK HELL/HELL 80/HF-FAX/SSTV/
RX only: AMTOR ARQ/NAVTEX/RTTY 50-75-100/PACTOR 1
DSP: FILTERS + CW binaural reception
PANORAMIC (RX 23 channels simultaneously): BPSK31/PSK63/PSKFEC31, with automatic reception
Programmation of Multipsk reception
+ CLOCK 1.4 (FRANCE-INTER, DCF77, HBG, RUGBY, WWVB, WWV, WWVH)
Hello to all Ham and SWL,
The new 3.6 release of MULTIPSK and the new release 1.4 of CLOCK are in my Web site (http://members.aol.com/f6cte/).
The main mirror site is the N8KBR Earl's one: http://multipsk.eqth.org/index.html
Another mirror site is the Terry's one: http://www.hamsoft.tk./
Multispk associated to Clock are freeware programs but with functions submitted to a licence (by user key).
La nouvelle version 3.6 de MULTIPSK (+ la nouvelle version 1.4 de CLOCK) est sur mon site Web (http://members.aol.com/f6cte/)
Le principal site miroir est celui de Earl N8KBR: http://multipsk.eqth.org/index.html
Il y a galement le site miroir de Terry: http://www.hamsoft.tk./
Multispk associ Clock sont des programmes de type "graticiel" ("freeware") mais avec des fonctions soumises licence (par cl utilisateur).
The main modifications of MULTIPSK V. 3.6 and CLOCK V. 1.4 are the following:
1) possibility to code/decode the new mode PSK220F (see specifications further on),
PSK220F is rapid (200 wpm in small letters) and, under not too bad conditions, is rather sensitive (S/N min=-7 dB) and reliable (due to Viterbi decoder) but it's not, of course, a QRP mode. It can support big drifts (up to 150 Hz/min) and is easy to tune.
2) only in PSK63F and PSK220F for instance, possibility to compress/transmit and receive digital pictures according to a new DIGISSTV protocol called "Run" (see description further on),
3) addition of a "Your logbook" menu with logbooks using the DXKeeper DDE link for exchange: DXKeeper (Dave AA6YQ) of the DXLAB suite and wxLogbook (Dave W1HKJ).
4) Clock V. 1.4 decodes now the WWVB time-radiotransmitter (50 KW on 60 KHz (LW), located at Fort-Collins in the state of Colorado (USA)). Moreover, algorithms have been improved.
I propose to focus calls on PSK63F or PSK220F + DIGISSTV "Run" at the following frequencies and times:
* 14078 Khz USB (AF around 1000 Hz), at 17h00 UTC if few traffic,
* 10148 kHz USB (AF around 1000 Hz), at 22h00 UTC if few traffic,
* 144.620 MHz USB (AF around 1000 Hz), at 20h00 UTC if few traffic.
Les principales modifications de MULTIPSK V. 3.6 et de CLOCK V. 3.4 sont les suivantes:
1) possibilit de coder/dcoder le mode PSK220F (voir plus loin les spcifications),
Le PSK220F est rapide (200 mpm en minuscules) et, dans des conditions pas trop mauvaises, sensible (S/N min=-7 dB) et fiable (du fait d'un dcodeur Viterbi) mais ce n'est, videmment pas, un mode QRP. Il peut supporter de grandes drives (jusqu' 150 Hz/min) et il est facile de se rgler dessus.
2) seulement en PSK63F et PSK220F pour l'instant, possibilit de comprimer/transmettre et recevoir des images numriques suivant un nouveau protocole DIGISSTV appel "Run" (voir description plus loin).
3) ajout d'un menu "Votre carnet de trafic" avec des carnets de trafic utilisant la liaison DDE de DXKeeper pour l'change d'information: DXKeeper (Dave AA6YQ) de la suite DXLAB et wxLogbook (Dave W1HKJ).
4) Clock V. 1.4 dcode maintenant l'metteur de signaux horaires WWVB (50 KW sur 60 KHz (GO), situ Fort-Collins dans l'tat du Colorado aux Etats-Unis).
D'autre part, les algorithmes ont t amliors.
Je propose de concentrer les appels en PSK63F ou PSK220F + DIGISSTV "Run" aux frquences et horaires suivants:
* 14078 Khz USB (BF autour de 1000 Hz), 17h00 UTC si peu de trafic,
* 10148 kHz USB (BF autour de 1000 Hz) 22h00 UTC si peu de trafic,
* 144,620 MHz USB (BF autour de 1000 Hz) 20h00 UTC si peu de trafic.
Description of PSK220F
Created by: Patrick Lindecker F6CTE (2005)
Baud rate : 220.5
Speed : 140 wpm in capital letters and 200 wpm in small letters (average)
Modulation : DBPSK
Reception mode: indifferent (LSB or USB)
Character set : ASCII characters + almost all ANSI extended characters + an error reset character (Varicode characters)
Shape of pulse : raised cosine
Bandwidth : about 430 Hz (max - 30 dB),
Synchronization: automatic using the signal
Correctioncode: no
Convolution code: R(Rate)=1/2, K (Constraint length)=7 with Viterbi type decoder, both coder outputs being sent successively,
Drift tolerance: 2.5 Hz/sec (+/- depending on signal-to-noise ratio)
Pmean/Ppeak : 0.79
Lowest S/N : - 7 dB in text and -5 dB in DIGISSTV
Interleaving : no
Note: this mode is simply PSK63F (of Nino Porcino IZ8BLY) carried to 220.5 bauds.
Description of the DIGISSTV "Run"
Created by: Patrick
