[digitalradio] Re: Direct RTTY Generation
Hi Andy. If you are up to something simple, reliable and useful, I have a proposal for a PSK31 transmitter. With a VFO, fast XOR gate and a CW shaping circuit you may generate a decent PSK31 signal. You just need a cheap controller to control the XOR gate and CW on/off. I developed a simple protocol, where the commands for the XOR gate and CW on/off are modulated synchronously by a sound card and decoded by a simple algorithm on a cheap controller. Any DIP part (Atmel or PIC) would do. I am currently writing an article for QEX, but I can give you more detail if you like the idea. What I am proposing is an offspring of an already proven concept. http://www.kufr.cz/~ok1iak/HAM/ATS3a-digital/index.php3 http://www.kufr.cz/~ok1iak/HAM/ATS3b/index.php3 http://www.kufr.cz/~ok1iak/HAM/WSPR/index.php3 The "commands over sound card" protocol is supported by PocketDigi http://sourceforge.net/projects/pocketdigi/ http://www.n0hr.com/PocketDigi/PocketDigi_intro.htm The firmware for the MSP430 controller of the ATS-3b is freely available. 73, Vojtech OK1IAK, AB2ZA
[digitalradio] Announce: Standalone CW/PSK31/PSK63 decoder
Hi gang. After half a year of weekend tinkering, I managed to develop firmware for a low power 16bit general purpose controller MSP430 to decode CW, PSK31 and PSK63. It has a very limited user interface, one needs to tune the radio with precision of 10Hz using just baragraph. The power consumption is extremely low <3.5mA at min 2.75V. The device is kitted by Steve Weber. Here is the manual. http://www.kufr.cz/~ok1iak/temp/decoder.pdf Steve's announce and information about kit purchase follows. Steve's ATS-4 kit provides direct paddle to PSK31 transmit function and this kit is considered an accessory to the ATS-4. 73, Vojtech OK1IAK, AB2ZA - from Steven Weber, steve.kd...@gmail.com Vojtech's CW/PSK decoder is now available - for a short time Vojtech's long awaited stand alone, low power CW/PSK decoder/reader is now available for order. I am doing the kitting and shipping for Vojtech. The instruction manual is in the files section with the name "decoder.pdf" and will only be available there, no CD will come with the kit this time, as the manual is pretty short and you all know how to solder SMT parts by now. The price for the kit is $30.00 plus $5.00 ($35.00 total) for US postage and $15.00 for DX ($45.00 USD). It will be shipped in a flat rate Priority Mail box, as I didn't think to get any small boxes to ship this in and the LCD display needs to be shipped in a box for protection. Using Priority mail for DX orders will help ensure they get it in a timely fashion, as it seems the small box used to ship the ATS-4 kits in some cases resulted in long delays at customs. (I belive there is at least one which STILL hasn't shown up!) There are only 96 kits available (we used up some of the parts in testing) and I will only be able to accept orders until Friday, the 10th. I will be heading for FDIM at Dayton shortly after that and then be gone on a 3-4 week hiking trip, so any orders after that will have to wait until I get back. Due to the short ordering window, only use pay-pal and my email address from my web page. Thanks, Steve KD1JV
[digitalradio] What is SS and what it is good for to HAMs, was: ARRL/FCC Announcement
I did not follow the whole conversation. Anyway, spread spectrum has following benefits as far as I am known: It allows more stations to use the spectrum. The trick is in spreading the signal by a sequence, which appears to be random. Many stations transmitting spread spectrum signals at various time and frequency offsets will all together resemble white noise. On the contrary, many conventional narrow band signals will approach white noise much slower. There is a classic article from Costas (of the PSK Costa's loop decoder algorithm) explaining why even DSB has theoretical benefits over SSB because it spreads the signal to higher bandwidth, which makes the total interference look more like white noise. The spreading in frequency makes the signal less sensitive to narrow band carriers, it makes it difficult to jam a signal by a single or couple of carriers. The other benefit is critical to military use. It is difficult to detect and if one does not know the spreading sequence, it is impossible to decode. Spread spectrum somehow contradicts the HAM radio philosophy. Spread spectrum to be useful mandates the software itself to identify and lock to the signal. It is impossible identify weak SS signal from white noise by ears. The operator will just enumerate the channels and the machine will do the rest. Higher amount of SS stations at the same frequency will increase background noise, so it will create an interference to let's say a CW operator. Therefore one would need to dedicate SS channels, otherwise there would be plenty of complaints from CW operators. I don't see a real benefit in running SS signal in just 2.5kHz SSB bandwidth. Olivia or MFSK will do better because they use the whole spectrum for itself, while SS on purpose leaves all the orthogonal spreading sequences to be used by other stations. For the same bandwidth, SS is designed to share frequency, classic multitone signals for best coding gain. That is a whole world of difference. SS would be very beneficial for beacon network, where all beacons share the same channel. This is what the GPS satellite network does indeed. SS may be used for single channel world wide chatting mode. One will be able to decode many signals at once with powerful computer. 73, Vojtech OK1IAK
[digitalradio] Re: Comparison of RTTY software sensitivity
> By synchronous detection, Vojtech, do you mean treating the first start bit > as the beginning of a synchronous multi-character sequence, thereby > providing some protection against "broken" start and stop bits within that > sequence? Brian K6STI referred to his decoding technique as employing a > "flywheel", which I interpreted as a means of adjusting the synchronous > timing with high-quality start bits decoded within the sequence. Dave, what I mean is to consider all edge into sync recovery. Most software I know is using pretty stable clock and fills the spaces with idle characters. The decoder needs to know how long the stop bit is, which may be estimated on the air or configured by the user. I suppose 1.5 bit length is the most common? Then you may try to search for raising/falling edge at 2x bit speed and slowly adjust the sampling point. Yes, it is some kind of "flywheel", that any synchronous decoder like PSK31 uses. 73, Vojtech OK1IAK
[digitalradio] Re: Comparison of RTTY software sensitivity
Here is another, similar chart: http://www.dxatlas.com/RttyCompare/ I was comparing MMTTY with MultiPSK and gMFSK against RTTY in white noise. Interesting observation was that MMTTY was better than MultiPSK at better than marginal SNR, but MultiPSK was slightly better than MMTTY at very low SNR. My best bet is that MMTTY is doing some kind of signal processing after detector, which fixes some errors, but makes things worse in very low SNR. Both yours and Alex's graphs show superiority of TrueRTTY and MixW. I wonder whether TrueRTTY is doing synchronous detection. This is what I plan to try when I retire, hi. 73, Vojtech OK1IAK
[digitalradio] Re: IZ8BLY's PSK63F + PSKFEC31
PSK63F is implemented in PocketDigi, source code is available. > PSK63F is in all cases better than PSK31. The only advantage of PSK31 is its > smaller bandwidth. The other benefit of PSK31 is quick turnaround. But I agree that PSK63F shall be exercised and will be very useful at marginal conditions. 73, Vojtech
[digitalradio] Re: RS ID
> 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
[digitalradio] Re: RSID numbers + New official RS ID list
> The "first list" (272 possibilities) permits to > have codings orthogonal (or almost orthogonal) in time and frequency, so not > to > mix two possible contiguous (in time or frequency) RS ID. orthogonal = "as much different as possible". For example, integrating sin(x)*cos(x) over 2pi interval will provide zero result, the sine and cosine functions are called to be orthogonal. With RSID you want to achieve, that you will not falsely decode one code as another one if shifted in time or frequency (or inverted by selecting wrong sideband). With low SNR and/or lot QRM/QRN there may be random "tones" detected, which may be falsely added to the real RSID diddle. Some of the RSID numbers were not used, because they look similar to the codes left in the table, when shifted in time or frequency. For example, binary code 111010 looks similar to 110101 after shifting one bit right. 111010 110101 73, Vojtech OK1IAK --- In digitalradio@yahoogroups.com, Warren Moxley wrote: > > Patrick, > > I am not sure I know what you are saying. > Are you saying I need two list? > > Warren - K5WGM > > > --- On Sat, 10/24/09, Patrick Lindecker wrote: > > From: Patrick Lindecker > Subject: Re: [digitalradio] Re: RSID numbers + New official RS ID list > To: digitalradio@yahoogroups.com > Date: Saturday, October 24, 2009, 10:02 AM > > > > > > > > > > > > > > > > Hello Warren, > > >I wanted this info in a spreadsheet so I made a list from you > code. > >Notice the gaps. > The "first list" (272 possibilities) permits to > have codings orthogonal (or almost orthogonal) in time and frequency, so not > to > mix two possible contiguous (in time or frequency) RS ID. > > 73 > Patrick > > - Original Message - > From: > Warren Moxley > > To: digitalradio@ yahoogroups. com > > Sent: Saturday, October 24, 2009 4:49 > PM > Subject: Re: [digitalradio] Re: RSID > numbers + New official RS ID list > > > > > > Patrick, > > I wanted this info in a spreadsheet so I > made a list from you code. > Notice the > gaps. > = = = > 1 > BPSK31 > 2 BPSK63 > 3 QPSK63 > 4 > BPSK125 > 5 QPSK125 > > 7 PSKFEC31 > 8 > PSK10 > 9 MT63-500-LG > 10 MT63-500-ST > 11 > MT63-500-VST > 12 MT63-1000-LG > 13 > MT63-1000-ST > 14 MT63-1000-VST > 15 > MT63-2000-LG > > 17 MT63-2000-ST > 18 > MT63-2000-VST > 19 PSKAM10 > 20 PSKAM31 > 21 > PSKAM50 > 22 PSK63F > 23 PSK220F > 24 > CHIP-64 > 25 CHIP-128 > 26 CW > 27 > CCW-OOK-12 > 28 CCW-OOK-24 > 29 CCW-OOK-48 > 30 > CCW-FSK-12 > 31 CCW-FSK-24 > > 33 CCW-FSK-48 > 34 > PACTOR1-FEC > 35 PACKET-300 > 36 PACKET-1200 > 37 > ASCII-7 > 38 ASCII-8 > 39 RTTY-45 > 40 > RTTY-50 > 41 RTTY-75 > 42 AMTOR FEC > 43 > THROB-1 > 44 THROB-2 > 45 THROB-4 > 46 > THROBX-1 > 47 THROBX-2 > > 49 > CONTESTIA-8- 250 > 50 CONTESTIA-16- 500 > 51 > CONTESTIA-32- 1000 > 52 CONTESTIA-8- 500 > 53 > CONTESTIA-16- 1000 > 54 CONTESTIA-4- 500 > 55 > CONTESTIA-4- 250 > 56 VOICE > 57 MFSK16 > > > 60 > MFSK8 > 61 RTTYM-8-250 > 62 RTTYM-16-500 > 63 > RTTYM-32-1000 > > 65 RTTYM-8-500 > 66 > RTTYM-16-1000 > 67 RTTYM-4-500 > 68 > RTTYM-4-250 > 69 OLIVIA-8-250 > 70 > OLIVIA-16-500 > 71 OLIVIA-32-1000 > 72 > OLIVIA-8-500 > 73 OLIVIA-16-1000 > 74 > OLIVIA-4-500 > 75 OLIVIA-4-250 > 76 PAX > 77 > PAX2 > 78 DOMINOF > 79 FAX > > 81 > SSTV > > > 84 DOMINOEX-4 > 85 DOMINOEX-5 > 86 > DOMINOEX-8 > 87 DOMINOEX-11 > 88 > DOMINOEX-16 > > 90 DOMINOEX-22 > > 92 > DOMINOEX-4-FEC > 93 DOMINOEX-5-FEC > > > > 97 > DOMINOEX-8-FEC > 98 DOMINOEX-11- FEC > 99 > DOMINOEX-16- FEC > 101 DOMINOEX-22- FEC > > > > 104 FELD > HELL > 105 PSK HELL > 106 HELL 80 > 107 FM HELL-105 > 108 FM > HELL-245 > > 110 QPSK31 > > > 113 PACKET-110 > 114 > 141A > > 116 OLIVIA-8-1000 > 117 C
[digitalradio] Re: ANNOUNCE: PocketDigi 1.0.12 released
Hi Andy. I usually implement something based on user report or on my own experience. I never used multiple sound cards myself for more than a short test. I will put sound card selection on my TODO list. > Anyone used PocketDigi on a Blackberry ? PocketDigi will only run on Windows CE >=3.0 devices, which accounts for a majority of Pocket PCs and Windows Mobile phones. 73, Vojtech OK1IAK
[digitalradio] Re: Propagation
Hi Andy. > My best visual view of grey > line propagation was in the old days of HF APRS when I set a receiving and > map on 30M. All day I was receiving joust 200-500 miles and then , all of a > sudden, 1700-3000 miles... The WSPRnet.org does exactly the kind of distance and signal strength mapping. Just run your TRX with WSPR for day or two and be prepared for nice surprise. My 800mW WSPR beacon with modest 30m dipole was heard at New Zeland from NJ, USA regularly. WSPR is really a great propagation and education tool. It will give a beginner hands on experience with HF propagation. With the signal strength reporting, it will give one a feeling on the time and power needed to do a contact in given mode. WSPR beacon is detected at minimum -29dB / 3kHz. PSK31 is readable at -13dB / 3kHz. If my beacon is heard at -25dB/3kHz, the PSK31 signal would be readable with -13-(-29)=+12dB linear amplifier, which would be about 13W compared to my 800mW beacon. 73, Vojtech OK1IAK
[digitalradio] Re: ANNOUNCE: PocketDigi 1.0.12 released
> How do I select a sound card? Using it on my PC, I am not receiving any > signals in the waterfall , probably because I have not selected a sound > source. Hi Andy. PocketDigi uses the default sound card. There is no selection. The UI is spartan as it was designed for the Pocket PC platform. The "big" windows version was written mostly as a testbed for the Pocket PC version. It is much easier to develop on the PC first and then just recompile for the Pocket PC. On the other side, the application is tiny and very CPU and memory efficient. It will provide basic communication means with most digital modes on most Windows boxes. It will run pretty well even on the first Pentium ~150MHz laptops. 73, Vojtech OK1IAK
[digitalradio] Re: Understanding soundcard basics ?
Hi Andy. I would say the sound card qualities are very similar to receiver. Noise floor Linearity Birdies and other noise I exclude timing issues, because they could most often be corrected for with software. Also I exclude stuff like bad drivers, that would cause dropouts. Now if you use narrow band receiver, you will be fine even with poor sound card, because noise floor will not be an issue. You will suffer sound card nonlinearity, if you try to receive panoramatic PSK31 with poor sound card. Noise floor may be an issue. High sound card noise floor will make SDR like SoftRock unusable, the receiver will be deaf, I have my personal experience. SDR puts biggest strain on your sound card. It sounds perverse to play with $15 SoftRock connected to $100 sound card and this is the reason why my SoftRock is stored in the basement as I did not have $100 to spare for the toy. Vojtech --- In digitalradio@yahoogroups.com, "obrienaj" wrote: > > From what I have read in the past, there is a difference between inexpensive > sound cards and the high quality ones. I recall past articles that suggest > the high quality ones can result in some very weak signals being detectable > in a waterfall, whereas cheap cards may not reproduce the signal. However, > as most of us know, even the cheap sound cards effectively render the average > ham signals, even quite weak ones. > > So, aside from the higher end ones rendering weak signals on a waterfall > better, what are measurable difference between a poor cheap one and a really > good top-of-the-line one ? Can someone explain this is plain English? > > I am aware of the "calibration/timing" issue. Although that too does not > seem to make a huge difference with many digital modes. Of the numerous > digital modes I have tried over the years, PC-ALE and JT65A in WSJT have been > the most impacted by calibration issues. I have seen WSJT not decode at all > when timing of the soundcard is not correct. Do higher end sound card have > less problems with timing/calibration than cheap ones? > > Is calibration really an issue of concern IF an application can enable a > re-calibration process ? If an application enables re-calibration, does that > only "hold" for that application or can it correct the soundcard for other > applications. > > I raise these questions out of general interest, but also because of recent > WINMOR test where the poor performance has been blamed , in part, on cheap > sound cards or sound cards not dedicated to the application. I don't know > enough to argue the point, but my suspicion is that it is really not that > sound card related. > > Andy K3UK >
[digitalradio] Re: Double Entries on Waterfall
Hi Ralph. The second or multiple received streams may be caused by a non-linearity somewhere between his computer and your computer. It may be his sound card, his TX, your RX or your sound card. Yes, I experienced it also. The "ghost" signals are of much lower amplitude though, so they are easily recognized and ignored. If I were you, I would first verify, whether you do not overdrive your sound card. Secondly I would adjust attenuator to just get some slight atmospheric noise in your receiver. This way you will maximize your receiver's dynamic range. If you still get some ghost signals, it may be a good time to upgrade your sound card. 73, Vojtech OK1IAK --- In digitalradio@yahoogroups.com, "Ralph Lambert" wrote: > > --- In digitalradio@yahoogroups.com, "Andrew O'Brien" wrote: > > > > > > > > Let me try again, Sheesh ! Can you actually decode text from the same > > > station on two different parts of the waterfall? How far apart on your > > > waterfall are these "doubles" ? > > > > > > > > > First... Sorry if I offended, it wasn't the intent... > > I never had success with WinWarbler because of my sound issues (see my > previous thread) and because I am using a laptop for digital and I also > because couldn't fit all of the DXLab applications on the screen in a way > that made sense. > > I've seen the doubling 14.070.150 & 14.070.20 (this operator was in the US) > and today I saw one that was on both sides of the waterfall 14.070.15 and > 14.072.90 (this operator was from EU) I thought to myself this is odd > sohere I am once again. > > Yes, I was able to decode the text, and as far I as could tell they were the > same text at the same time. > > The reason for the question I thought somebody had figured out a way to take > over a freq to ensure that they made all the contacts. > > So it is safe for me to assume this not a natural occurrence and I am just > being paranoid (again) > > - Ralph (AJ4GR) > > > > > > > > > > > > > > > > > > How do you know they are doubles? > > > > > > > > > > I don't, that's why I was asking the question. Sheesh! > > > > > > - Ralph (AJ4GR) > > > > > >
[digitalradio] Re: Use the *$%#ing RS ID!
Who voluteers to write an article for QST? This is exactly the publicity this tool needs. 73, Vojtech OK1IAK --- In digitalradio@yahoogroups.com, "Charles Brabham" wrote: > > Hello, Andy, > > After reading your post about RIS ID, I did a quick dogpile search on "RIS ID > Ham Radio" and nothing much turned up, just a few forum posts, etc. > > If you or somebody will write up an info article, laying out the basic > concept and including any relevant links, I'd be glad to turn it into HTML > and publish it at the USPacket.Org website, so that when somebody does a > search on RIS ID they'll get the straight poop, right off the bat. > > It would give us all a direction to point when questions come up. > > I'd write it up myself, but I'm ignorant about anything beyond the basic > concept. - It sounds like something I would be glad to support. > > 73 DE Charles Brabham, N5PVL > > n5...@... > > > - Original Message - > From: Andy obrien > To: digitalradio > Sent: Monday, July 06, 2009 7:27 PM > Subject: [digitalradio] Use the *$%#ing RS ID! > > > > > > OK folks, I am officially declaring any excuse NOT to use RIS ID as > invalid. Now that FLDIGI, MULTIPSK, and DM780 all have it... use it! > Obviously when using PS31, RTTY, and Packet, you probably do not need > it. Last night I saw several people CQing with "odd" Olivia mode > configurations, no responses . My view is that it should be standard > operating practice to CQ with RS-ID on when using anything but RTTY > and PSK31! > > Andy K3UK >
[digitalradio] Re: QRV ALE-400 ARQ chat mode -- 14074.0
Hi Skip. The DOS executable is here: http://www.cnunix.com/ftp/hamradio/tapr/software_lib/utils/7plus20.exe The source code is here: ftp://sunsite.unc.edu/pub/Linux/apps/ham/7pl217sr.tgz 7plus is available as installation package in some Linux distributions. I was maintaining 7plus installation package and other HAM applications for SuSE Linux in Prague when I was a student. There is one neat thing about 7plus. 7plus files have standard header and tail. The packet radio modems often snipped out the 7plus sections from their RX window and stored them into appropriate files. Some applications even executed the 7plus utility to decompress the data when all pieces were received. There were even programs, that extracted 7plus files from monitor. This allowed for multicasting, if the link quality was good. 73, Vojtech --- In digitalradio@yahoogroups.com, kh6ty wrote: > > That's neat, Vojtech. Is there a link to download 7plus? WRAP only > calculates a checksum for the entire file, and if it will not "unwrap", > we just resend the whole file. > > 73, Skip KH6TY > > > Vojtech Bubnik wrote: > > > > > > > so we developed the Wrap program, which sends a checksum at the end > > > of the message, and error-free reception can be verified that way. > > > > Hi Skip. > > > > >From the Packet Radio times, we have a 7plus utility, which splits a > > longer binary file to multiple parts and adds mild error detection / > > correction codes. After you receive all parts and run them through > > 7plus, if there are errors, the application will generate a "request" > > message, which will identify missing parts to be repeated. > > > > 73, Vojtech AB2ZA > > > > > > -- > *Skip KH6TY* > http://KH6TY.home.comcast.net >
[digitalradio] Re: Outdoor screen viewing?
--- In digitalradio@yahoogroups.com, "Briggs Longbothum" wrote: > > What has anyone found to be handy and effective to enable good screen viewing > outdoors, in daylight, etc?? You need either common display and shade, or common display with very strong backlight, or transreflexive display. Some PDAs and Smart Phones are equipped with transreflexive displays. They are well readable in strong sunlight. One example is my old iPaq 3630. I think generally the PDAs and Smartphones are more likely to be designed to be readable outdoors than laptops. If you need just PSK31, the display of NUE-PSK will work great. > Has anyone tried any versions of those "wide screen goggles" (I know you > might need a pc to TV adapter). This sounds like overkill to me. 73, Vojtech AB2ZA
[digitalradio] Re: QRV ALE-400 ARQ chat mode -- 14074.0
> so we developed the Wrap program, which sends a checksum at the end > of the message, and error-free reception can be verified that way. Hi Skip. >From the Packet Radio times, we have a 7plus utility, which splits a longer >binary file to multiple parts and adds mild error detection / correction >codes. After you receive all parts and run them through 7plus, if there are >errors, the application will generate a "request" message, which will identify >missing parts to be repeated. 73, Vojtech AB2ZA
[digitalradio] Re: Has anyone tried the ASuS EEE pc 901?
Hi Jaak. You could download it from the same place as PocketDigi for Pocket PC. Look for the -x86.zip suffix and just unpack and execute. 73, Vojtech --- In digitalradio@yahoogroups.com, Jaak Hohensee wrote: > > Vojtech Bubnik wrote: > > > > > > PocketDigi will run most digital modes (RTTY, PSK31, MFSK, Olivia ...) > > on any Windows desktop or laptop with 150MHz CPU. > > > Where to DL, how to install? I tried without success on XP > > Jaak > es1hj/qr > > > It is efficient enough to decode PSK31 on 75 MHz Pentium and show > > waterfall. > > 73, Vojtech OK1IAK > > > > --- In digitalradio@yahoogroups.com > > <mailto:digitalradio%40yahoogroups.com>, "Brent Gourley" > > wrote: > > > > > > I have run digipan on a 75 mHz P2 W95 notebook. Long ago. > > > > > > KE4MZ, Brent > > > Dothan, AL > > > bgrly@ > > > www.wb4zpi.org > > > > > > > > > > > > - Original Message - > > > From: "Ralph Mowery" > > > To: > <mailto:digitalradio%40yahoogroups.com>> > > > Sent: Wednesday, June 24, 2009 9:42 PM > > > Subject: Re: [digitalradio] Has anyone tried the ASuS EEE pc 901? > > > > > > > > > > > > > > > > > > > > > > --- On Mon, 6/22/09, jeffnjr484 wrote: > > > > > > > >> From: jeffnjr484 > > > >> Subject: [digitalradio] Has anyone tried the ASuS EEE pc 901? > > > >> To: digitalradio@yahoogroups.com > > <mailto:digitalradio%40yahoogroups.com> > > > >> Date: Monday, June 22, 2009, 11:24 AM > > > >> Hello, > > > >> > > > >> Has anyone used the ASUS laptop for psk31 or any digital > > > >> modes im looking at it > > > >> for some portable ops > > > >> > > http://www.amazon.com/gp/product/B001BYD178/ref=noref?ie=UTF8&s=pc > > <http://www.amazon.com/gp/product/B001BYD178/ref=noref?ie=UTF8&s=pc> > > > >> It looks like a neat computer and the price is outstanding > > > >> just wanted to know > > > >> if anyone has tried it > > > >> jeff kd4qit > > > >> > > > >> > > > >> > > > > The 901 should be just fine for the digital modes. I have the ASUS > > 1000HE > > > > which is just about the same computer except for the hard drive > > vers the > > > > solid state memory and a few extras. I have used Digipan and several > > > > other programs for psk31 with no problem. Runs mmtty fine. If you > > do not > > > > have a usb to serial port adaptor you may not be able to control > > the rig. > > > > Some of the interface units come with the adaptors for this. > > > > > > > > It does not really take much of a computer to run basic psk31. I > > have ran > > > > psk 31 with some 200 mhz desktop computers years ago. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Announce your digital presence via our Interactive Sked Pages at > > > > http://www.obriensweb.com/sked <http://www.obriensweb.com/sked> > > > > > > > > Recommended digital mode software: Winwarbler, FLDIGI, DM780, or > > Multipsk > > > > Logging Software: DXKeeper or Ham Radio Deluxe. > > > > > > > > > > > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > > > > > > > > > > > > -- > Kirjutas ja tervitab > Jaak Hohensee >
[digitalradio] Re: Has anyone tried the ASuS EEE pc 901?
PocketDigi will run most digital modes (RTTY, PSK31, MFSK, Olivia ...) on any Windows desktop or laptop with 150MHz CPU. It is efficient enough to decode PSK31 on 75 MHz Pentium and show waterfall. 73, Vojtech OK1IAK --- In digitalradio@yahoogroups.com, "Brent Gourley" wrote: > > I have run digipan on a 75 mHz P2 W95 notebook. Long ago. > > KE4MZ, Brent > Dothan, AL > bg...@... > www.wb4zpi.org > > > > - Original Message - > From: "Ralph Mowery" > To: > Sent: Wednesday, June 24, 2009 9:42 PM > Subject: Re: [digitalradio] Has anyone tried the ASuS EEE pc 901? > > > > > > > > > > --- On Mon, 6/22/09, jeffnjr484 wrote: > > > >> From: jeffnjr484 > >> Subject: [digitalradio] Has anyone tried the ASuS EEE pc 901? > >> To: digitalradio@yahoogroups.com > >> Date: Monday, June 22, 2009, 11:24 AM > >> Hello, > >> > >> Has anyone used the ASUS laptop for psk31 or any digital > >> modes im looking at it > >> for some portable ops > >> http://www.amazon.com/gp/product/B001BYD178/ref=noref?ie=UTF8&s=pc > >> It looks like a neat computer and the price is outstanding > >> just wanted to know > >> if anyone has tried it > >> jeff kd4qit > >> > >> > >> > > The 901 should be just fine for the digital modes. I have the ASUS 1000HE > > which is just about the same computer except for the hard drive vers the > > solid state memory and a few extras. I have used Digipan and several > > other programs for psk31 with no problem. Runs mmtty fine. If you do not > > have a usb to serial port adaptor you may not be able to control the rig. > > Some of the interface units come with the adaptors for this. > > > > It does not really take much of a computer to run basic psk31. I have ran > > psk 31 with some 200 mhz desktop computers years ago. > > > > > > > > > > > > > > > > > > > > Announce your digital presence via our Interactive Sked Pages at > > http://www.obriensweb.com/sked > > > > Recommended digital mode software: Winwarbler, FLDIGI, DM780, or Multipsk > > Logging Software: DXKeeper or Ham Radio Deluxe. > > > > > > > > Yahoo! Groups Links > > > > > > > > >
[digitalradio] Re: Sound Cards
Hi Skip and others. I bought the other USB sound card dongle: http://www.geeks.com/details.asp?invtid=CL-USCM2&cpc=SCH I was disappointed with it. The microphone input was noisy and A/D resolution was far lower than 16 bits. I do not remember exactly, I think it was either 10 or 12 bits. With the noise taken into account, the input resolution was probably about 8 bits. There are no decoupling capacitors on the earphone output. And I don't think that it is a switched class amplifier or bridge amplifier. The earphones are grounded to common ground. If the earphones were plugged, there was DC current flowing through the earphones. It seems the manufacturer simply saved money and space by sparing two capacitors. I dissected one and the second one is still on my shelf unused. 73, Vojtech OK1IAK --- In digitalradio@yahoogroups.com, kh6ty wrote: > > Tim, have you tried the "USB sound adapter"? The low end noise that the > standard SignaLink has is not there and you can just use VOX for PTT > switching. It is also an external soundcard. For only $7.50, you can > hardly go wrong! > > If you can handle tiny chips, there is also a PTT output that you can > bring to the outside. > > http://www.geeks.com/details.asp?invtid=HE-280B&cat=SND > > 73, Skip KH6TY > > > > > > > > Thank you Peter. I've been looking at external sound cards to use with > > a laptop for portable work. The internal unit in my laptop doesn't > > work all that well and my thinking was if I use a good quality > > external unit it can move to a new laptop when I upgrade some day. > > > > Tim, N9PUZ > > > > _ > > > > > > > > -- > *Skip KH6TY* > http://KH6TY.home.comcast.net >
[digitalradio] Re: Time to start a PSK qrp freq?
Hi Simon. The enhancement looks very interesting. How do you do that? BTW, I was trying to achieve nice CW waterfall like in Rocky, but I did not succeed. Your method looks promissing. 73, Vojtech --- In digitalradio@yahoogroups.com, "Simon \(HB9DRV\)" wrote: > > What I am seeing is PSK users climbing about 14.073 to get away from the > pack - this is what I would do. I don't see anyone using more than 50W on > PSK and a decent QRP radio such as the IC-703 shouldn't have much of a > problem, especially when using a 500Hz filter. > > The soundcard also plays a role - myself I will soon be using a microHam USB > interface III with my TS-480SAT, with my FT-950 I am using a USInterface.com > Navigator. Neither of these will be the weak link in the chain, some onboard > soundcards have poor dynamic range. > > If someone is suffering from strong signals I would want to know what radio > and soundcard he's using, also a screenshot of the waterfall can help. > > I've added something in DM780 which attempts to visually (waterfall) dig all > signals out of the noise, see these two images: > > Enhanced: http://www.ham-radio.ch/images/enhanced.jpg > > Normal: http://www.ham-radio.ch/images/normal.jpg > > In this example I've turned up the enhancement up to the max., obviously the > user can decide what level to use. > > Simon Brown, HB9DRV > www.ham-radio-deluxe.com > > - Original Message - > From: "frankk2ncc" > > > >A good concept. Looking though the web searches, there's some feedback to > >that point. However, where you suggest would put you up with some other > >offenders, particularly RTTY. I don't think it matters where you go, > >you'll still get stomped on if your QRP. >
[digitalradio] Re: Contestia & RTTYM
Hi Simon. Why don't you use MultiPSK or PocketDigi to test Contestia and RTTYM against? You could reuse PocketDigi's source code also. 73, Vojtech --- In digitalradio@yahoogroups.com, "Simon \(HB9DRV\)" wrote: > > Is there anyone out there who uses both DM780 & MixW who could record wave > files using DM780 where the wave files contain Contestia and RTTYM > trasmissions? You'll need to couple the programs using something like VAC. > Ideally one file per mode with a reasonable long text. > > I need the waves files to be sure I implement Contestia and RTTYM correctly. > I don't have mixW and don't use it less i get accussed of plagiarism and > lawyers start hunting me (yes, it has happened before). > > Simon HB9DRV > www.ham-radio-deluxe.com www.sdr-radio.com >
[digitalradio] Re: The next big thing - Using Swarm Intelligence
> On the other hand I use free community software such a DotNetNuke where > community collaboration has really worked I was a big proponent when I was a student. Now with more than 10 years in the industry writing customer specific software I realize how unrealistic is to want every piece of software to be free. Open source is a good model for products, that target vast number of users, so there will be large number of talented programmers in the target group able to participate and there will be some among them willing to participate and cooperate. If the target group is small like in the case of messaging digital modes for HF, the development will be either commercial or one man show at best as the reality has proven. And the target group for digital messaging is vastly smaller than of contesting or casual rag chewing. If Simon would release his DM780 source code (I know it is difficult because he is using some 3rd party commercial libraries), I bet there will be couple of programmers trying to tinker with it and probably there will be some doing contributing minor improvements. The same applies for the fldigi as it targets the second most HAM used operating system today. With pocketdigi I cannot expect much contribution even if I provided source code, because its target group is much smaller notwithstanding the fact, that the PDAs are often replaced by the tiny cheap diskless PCs. Actually, there seems to be a single contribution on the way for PocketDigi - one French sailor is fine tuning Amtor / NavTex. So there will be open source codec for flDigi and DM780, hi. 73, Vojtech
[digitalradio] Re: Mode of the Day? RS ID on SdR bandwidth
Hi Simon. I have one pledge. Would you please integrate the ATS-3b interface into your digital modes software? ATS-3b is a transceiver fitting into Altoids tin, which supports generating of BPSK and MFSK signals with its DDS. TX is controlled with special protocol over sound card. It should not be difficult to integrate it into your software, it would only make your TX code a bit less readable. The code is available in PocketDigi. http://www.kufr.cz/~ok1iak/HAM/ATS3a-digital/index.php3 I am asking for it because right now only PocketDigi supports this interface. Although PocketDigi runs on desktop, it was developed primarily for Pocket PC and it is very rudimentary. Also I hope (maybe blindly) that the concept of DDS generated digital modes will be adapted by other QRP kits one day. With the class-D PA and circuit simplicity it should be tempting to design a digital modes transceiver for battery operation, for example for the EMCOM folks. Thanks, Vojtech --- In digitalradio@yahoogroups.com, "Vojtech Bubnik" wrote: > > Hi Patrick and Simon. > > My code is derived from Patrick's, only I heavily optimized it to be executed > on a less powerful fixed point arithmetics CPU. I am obsessed with > optimization to increase battery life of the Pocket PC device. > > I am refering to PocketDigi source code, misc/rsid.c. I believe fldigi used > my source code as a starting point. > > rsid_search function receives samples @ 11025 and calculates 1024 point real > FFT each time 1024 new samples are received. Therefore the FFT intervals > overlap by one half. The sound card runs at 8 kSamples per second, but I have > a resampler running outside of the rsid code to resample to 11025. Also the > resampler takes care of the sound card clock correction. I have another > resampler running for clock correction from 8ksamples to 8ksamples, but this > one is only executed if clock adjustment is different from zero to save some > battery time. Also resampling with fixed point arithmetics add some error. > > The main speed up of Patrick's search routine is done by "hashing". In case > of RSID we are happy enough that it is possible to setup reverse lookup > tables, which have no duplicate hits. The tables are setup in rsid_init. > Encoded RSID code consists of 15 nibbles. Patrick decided to only accept a > code as valid if it has zero or one error. I therefore prepared two reverse > lookup tables from encoded RSID code consisting from 15 nibbles to the mode > identifier index, which fits into single byte. Each of the reverse lookup > tables have 256 entries, some of them may be empty - they lead to invalid > RSID code. The first table is indexed by first and second nibble of encoded > RSID, the other table with third and fourth nibble of encoded RSID. The idea > behind it is that if there is a single bit error in the first two nibbles, > there will be no error in the third and fourth nibble. After the two tables > are resolved, the received code hamming distance is verified as in Patrick's > original source code. My optimization consists therefore mainly in saving > some 100 calls of Hamming distance calculation by using two table lookups, > gaining probably speedup of about 50x. > > Another optimization is in CalculateBuckets(), which calculates maximum of 16 > successive tones. It uses result of previous sweep in most cases. This > probably speeds up the function about 4x. Not that significant if compared to > the hashing trick, but after the hashing was implemented, even this little > optimization becomes useful. I believe now the RSID decoding time depends > mostly on the real FFT routine. > > My encoder generates phase coherent MFSK signal @ 8000, no resampling to > 11025 is necessary. TX is done in main/trx.c, mainly in trx_txstate(), see > case with TRX_STATE_TXRSID_TONE0 to 14. > > 73, Vojtech > > --- In digitalradio@yahoogroups.com, "Patrick Lindecker" wrote: > > > > Simon, > > > > >Why must the sampling frequency be 11025? > > because the Fourier is done with 2048 samples at 11025 samples/sec. At > > 8000, the number of samples would not be a power of 2 and this Fourier > > could not be a FFT but a standard digital Fourier (DFT) which takes times > > to do. So the simplest way is to base all on 11025. > > > > For more details, read the "RS_ID_English.doc" file in > > http://f6cte.free.fr/PAPERS.ZIP > > > > 73 > > Patrick > > - Original Message - > > From: Simon (HB9DRV) > > To: digitalradio@yahoogroups.com > > Sent: Thursday, April 16, 2009 10:54 PM > > Subject: Re: [digitalradio] Mode of the Day? RS ID on SdR band
[digitalradio] Re: Mode of the Day? RS ID on SdR bandwidth
Hi Patrick and Simon. My code is derived from Patrick's, only I heavily optimized it to be executed on a less powerful fixed point arithmetics CPU. I am obsessed with optimization to increase battery life of the Pocket PC device. I am refering to PocketDigi source code, misc/rsid.c. I believe fldigi used my source code as a starting point. rsid_search function receives samples @ 11025 and calculates 1024 point real FFT each time 1024 new samples are received. Therefore the FFT intervals overlap by one half. The sound card runs at 8 kSamples per second, but I have a resampler running outside of the rsid code to resample to 11025. Also the resampler takes care of the sound card clock correction. I have another resampler running for clock correction from 8ksamples to 8ksamples, but this one is only executed if clock adjustment is different from zero to save some battery time. Also resampling with fixed point arithmetics add some error. The main speed up of Patrick's search routine is done by "hashing". In case of RSID we are happy enough that it is possible to setup reverse lookup tables, which have no duplicate hits. The tables are setup in rsid_init. Encoded RSID code consists of 15 nibbles. Patrick decided to only accept a code as valid if it has zero or one error. I therefore prepared two reverse lookup tables from encoded RSID code consisting from 15 nibbles to the mode identifier index, which fits into single byte. Each of the reverse lookup tables have 256 entries, some of them may be empty - they lead to invalid RSID code. The first table is indexed by first and second nibble of encoded RSID, the other table with third and fourth nibble of encoded RSID. The idea behind it is that if there is a single bit error in the first two nibbles, there will be no error in the third and fourth nibble. After the two tables are resolved, the received code hamming distance is verified as in Patrick's original source code. My optimization consists therefore mainly in saving some 100 calls of Hamming distance calculation by using two table lookups, gaining probably speedup of about 50x. Another optimization is in CalculateBuckets(), which calculates maximum of 16 successive tones. It uses result of previous sweep in most cases. This probably speeds up the function about 4x. Not that significant if compared to the hashing trick, but after the hashing was implemented, even this little optimization becomes useful. I believe now the RSID decoding time depends mostly on the real FFT routine. My encoder generates phase coherent MFSK signal @ 8000, no resampling to 11025 is necessary. TX is done in main/trx.c, mainly in trx_txstate(), see case with TRX_STATE_TXRSID_TONE0 to 14. 73, Vojtech --- In digitalradio@yahoogroups.com, "Patrick Lindecker" wrote: > > Simon, > > >Why must the sampling frequency be 11025? > because the Fourier is done with 2048 samples at 11025 samples/sec. At 8000, > the number of samples would not be a power of 2 and this Fourier could not be > a FFT but a standard digital Fourier (DFT) which takes times to do. So the > simplest way is to base all on 11025. > > For more details, read the "RS_ID_English.doc" file in > http://f6cte.free.fr/PAPERS.ZIP > > 73 > Patrick > - Original Message - > From: Simon (HB9DRV) > To: digitalradio@yahoogroups.com > Sent: Thursday, April 16, 2009 10:54 PM > Subject: Re: [digitalradio] Mode of the Day? RS ID on SdR bandwidth > > > > > > Hi, > > Why must the sampling frequency be 11025? > > Simon Brown, HB9DRV > www.ham-radio-deluxe.com > - Original Message - > From: Patrick Lindecker > > No problem, but I program in Pascal not in C...(Votjech did a C source). > The sampling frequency must be 11025, but it is not a problem to work at 8000. >
[digitalradio] Re: Bad PSK31 Signal
Hi Simon and gang. Seems a simple CW keying circuit with linear up/down ramp and 180 grades phase flipping would make a much better job. http://www.kufr.cz/~ok1iak/temp/psk31-trapezoidal-envelope.pdf This simple circuit could do it after one capacitor is replaced with higher value: http://kd1jv.qrpradio.com/ compare to overdriven SSB transmitter. http://www.kufr.cz/~ok1iak/temp/psk31-overdriven-flat.pdf 73, Vojtech --- In digitalradio@yahoogroups.com, "Simon \(HB9DRV\)" wrote: > > Please look at: > http://www.ham-radio.ch/images/HRD-AudioMonitor-2009-04-14%20114504.jpg > > 10W from a TS-140S. > > Simon Brown, HB9DRV > www.ham-radio-deluxe.com >
[digitalradio] Re: Pocket Digi
> By the way is PocketDigi still being developed? Just hoped there would > be an update someday soon :) Hi Sholto. I am doing some improvements, but very slowly. Actually I have the DXCC database and calculation of bearing/distance ready for about a year already, I just waited to get more new features accumulated before I do another release. I worked on hardware improvements of the ATS-3b transceiver. Now I need to update ATS-3b firmware and then I will probably return to PocketDigi development. I need to be more on air to be motivated again to improve PocketDigi. 73, Vojtech --- In digitalradio@yahoogroups.com, Sholto Fisher wrote: > > Hi Vojtech, > > I know Pat's page says that but this iPaq definitely only has gnd & > stereo out. I also picked up a 1945 and it is identical. > > By the way is PocketDigi still being developed? Just hoped there would > be an update someday soon :) > > 73 Sholto. > > > > > Vojtech Bubnik wrote: > > > > > > Hi Sholto. > > > > Check Pat's page: > > http://www.n0hr. com/PocketDigi/ PocketDigi_ Tigertronics_ Interface. > > htm <http://www.n0hr.com/PocketDigi/PocketDigi_Tigertronics_Interface.htm> > > > > He states that your device has 4 contact earphone jack, the added ring > > probably connects to microphone input. You could either buy an Y cable > > or build it yourself. Mouser stocks the 3.5mm 4 pole jack at #171-7435-EX. > > > > 73, Vojtech OK1IAK > > > > --- In digitalradio@ yahoogroups. com > > <mailto:digitalradio%40yahoogroups.com>, Sholto Fisher wrote: > > > > > > I use Pocket Digi on my iPaq 1940 pda and it works FB but I was > > > wondering if anyone knew a pda device/smartphone which has audio input & > > > output available on a headphone jack? My iPaq only has output so for > > > input I have to acoustically couple the sig which is not optimal. > > > > > > 73 > > > > > > Sholto > > > K7TMG > > > > > > > >
[digitalradio] Re: Pocket Digi
Hi Sholto. Check Pat's page: http://www.n0hr.com/PocketDigi/PocketDigi_Tigertronics_Interface.htm He states that your device has 4 contact earphone jack, the added ring probably connects to microphone input. You could either buy an Y cable or build it yourself. Mouser stocks the 3.5mm 4 pole jack at #171-7435-EX. 73, Vojtech OK1IAK --- In digitalradio@yahoogroups.com, Sholto Fisher wrote: > > I use Pocket Digi on my iPaq 1940 pda and it works FB but I was > wondering if anyone knew a pda device/smartphone which has audio input & > output available on a headphone jack? My iPaq only has output so for > input I have to acoustically couple the sig which is not optimal. > > 73 > > Sholto > K7TMG >
[digitalradio] Re: on another note
Hi Patrick and others. > I don't think it would be technically very difficult to do something equivalent to P3 with sound cards. I think that it would even possible to do much better with, for example, multi-users protocol. I completely agree. > The problem is the time necessary to do this. An amateur can work (with pleasure and passion of course), let's say a day per week, when a company can make work a small team 5 days a week. Much less than one day per week if one has toddler or two to take care of. I admire your endurance in developing a complex free HAM software. > Now an amateur project must be short in time (several months at a maximum) as it is done for fun. Working on the same project during years seems very difficult (and surely boring) for amateurs. Very true. If the project is too complex, it will simply become obsoleted by a commercial product before it is finished. The same thinking applies to development of hardware as I learned during my tinkering with ATS-3b. Patrick, I have a proposal for one low hanging fruit project. How about to receive RTTY in a synchronous way? I believe most SW really generate precise synchronous RTTY, where the only variable is the unknown stop bit length (mostly 1.5?). If the stop bit length is being estimated or selected from menu, one could receive RTTY synchronously and greatly increase sensitivity of this legacy but often used mode. 73, Vojtech OK1IAK
[digitalradio] Re: NBEMS QST article/digital weak signal FM
> As more people try using digital modes on 2 meter FM, the overall best > performing mode will automatically surface, but for the longest range on > digital modes (not counting CW), it is really necessary to use SSB, and in > that case, we have found that MFSK16 is just too critical for tuning to be > used with transceivers without a TCXO. Skip, how about to try MFSK16 with RSID? The RSID solves the intial tuning on key down. Once the signal is tuned, AFC shall track it. 73, Vojtech
[digitalradio] Re: NBEMS QST article/digital weak signal FM
Hi Tony. I suppose the reason is that we are comparing MFSK16/DominoEX over FM versus MFSK16/DominoEX over SSB. I believe they are just different animals. SSB only shifts signals in frequency. FM does much more complex (in mathematical sense) transformation. Skip is doing interesting pioneering work. Digital modulation over common voice FM transceiver will have different noise and distortion properties than SSB. It will be influenced by noise properties of FM, preemphasis/deemphasis, how FM is modulated (pulling VFO inside the phase loop?) etc. Pulling varactor inside the phase loop will distort low frequencies (phase loop acts against the modulation), therefore baseband modulation is difficult. It brings back the memories of my teenage packet radio obsession. At that time the modulation modes were limited mainly by circuit complexity and there was no DSP. Common handhelds were modulated with BELL202 1200Bd two tone synchronous modulation. 9k6 enabled transceivers allowed direct modulation of the VFO varactor by bypassing all the microphone circuit, preemphasis and clipping. I suppose Skip's target is the first group of transceivers, where the modulation/demodulation amplitude and phase response is unknown. Skip, it would be interesting, if you could investigate, which modulation bandwidths and at which center audio frequency the common FM transceivers work best with common HF weak signal digital modes. Keep the good work. Someone able to do the math? 73, Vojtech OK1IAK > White noise tests show DominioEX-4 to be a bit more sensitive than MFSK16, > but it doesn't seem to handle HF distortion nearly as well. > > I was surprised that it did better than MFSK16 with multipath and was > wondering if you thought the better throughput was due to MFSK16 tuning > issues rather than actual robustness? > > Tony - KHMU >
[digitalradio] Re: Recent MFSK16 DX
> In a simple shoot out between olivia 250 x8 and msfk16 , olivia > stopped decoding whilst mfsk was still at 100% ... thought that was > not supposed to happen ? Hi Graham. I am certainly not surprised and it confirms my Gaussian noise tests. Olivia trades sensitivity for automatic tuning. MFSK16's convolution coding provides for high sensitivity, but does not give sharp enough indicator, whether the data is valid. Basically the Hammond distance of the code is too low to give reliable indicator. Olivia uses Welsh block coding, which provides good data validity indicator, but has not as high coding gain as convolution codes. For explanation of coding gain, see the excellent article from g3ruh http://www.amsat.org/amsat/articles/g3ruh/105.html I believe the perfect weak signal mode for HAM radio is yet to be designed with easy tuning of Olivia and high sensitivity of MFSK16, combining both convolution and block codes. Maybe overlying MFSK16 with Reed-Solomon block code and running multiple MFSK16 decoders with half tone spacing will do the trick. 73, Vojtech OK1IAK
[digitalradio] Re: ALE400 and 141a - talk about JNOS ...
Hi Maiko. > I'm not sure what mode I would want to use it for though. I even > considered using JNOS as an IP bridge using the MultiPSK modem to > transport RAW IP (more or less) frames over HF, as one example > of what was on my mind. I played with http over ax.25 slow 1200bd line. I wrote a simple sw package using Linux ax.25 kernel stack. One installed a http proxy on his computer, which initiated ax.25 connection to a server, queried for a page, the other side compressed it with gzip, sent over ax.25 channel, the http proxy decompressed and fed to the browser. It worked remarkably well for text only pages, but the SW was not debugged enough to be published. Anyway, the sources are here: http://www.kufr.cz/~ok1iak/download/ham/axw3.tar.gz >From my experience, routing IP over any other slow connected low quality link does not work well. The overhead of layering two complex connected protocols one over another is too big for slow links. Their acknowledge mechanism will add protocol delays in case of failure, one protocol's packet repetition will interfere with the other one's. Even running TCP over some slow unacknowledged link like ax.25 uproto will not work well, because the TCP connection is initiated at the end nodes, which have the parameters set up for much faster links. If they adjust, it will take a looong time, effectively becoming unusable. Application gateway is a way to go for HAM radio IMHO, not packet gateway. 73, Vojtech OK1IAK
[digitalradio] Re: AX.25 modem as an infrastructure?
Hi Misko. I strongly believe before going to actually implement something one shall explore existing systems first and if it is possible, try to simulate a new system using the existing one. I propose that you and your friends try to set up a flexnet system using fixed links at single frequency. You may try to add and remove a link and see how fast the change will be redistributed around the other nodes using shared frequency and very low bandwidth channel and how much of the shared bandwidth will be used just for protocol overhead. When you setup your test, try to make sure only two transmitters will hear each other. I believe the probability of packet clashes will be so high, that the network will not work. 73, Vojtech OK1IAK
[digitalradio] Re: AX.25 modem as an infrastructure?
Hi Misko. I used to play with AX.25 a lot when I was a teenager. You have two major problems when designing the kind of ad hoc network you are proposing: hidden transmitters and protocol overhead. With 1200Bd shared bandwidth you do not have much wiggle room to cope with either of them. With your ad-hoc approach you would either broadcast data to all nodes in the network (APRS approach), or broadcast routing tables (FlexNet approach) or broadcast request to connect (I don't know any such AX.25 system). Would you be more specific about your approach? Into which category it falls? Flexnet was probably the best AX.25 system designed with working auto router, but still it took some time before the routing tables were updated after a station connected / disconnected. And it was using dedicated links between nodes, so there was no hidden transmitter problem. 73, Vojtech OK1IAK
[digitalradio] Re: mftty
Hi Norbert. I do not want to discourage you from your experiments, but I would like to point out, that there are already two tone chat modes designed for amateur use on HF, namely Throb and ThrobX. DTMF as well as ThrobX encode each single character into two simultaneous tones. Throb has a single exception, idle character is encoded as single tone. DTMF does not shape amplitude, Throb/ThrobX does. DTMF is much wider than Throb or ThrobX. I believe DTMF was designed for cheap inexact tone decoders and not fully harmonic encoders and transmission paths, the tones are picked so their third intermix product is not exactly aligned with other DTMF tones. If used on HF, one does not want the IMD product fall outside of the useful signal. On telephone line it does not matter and some nonlinearity may be even useful to boost SNR. On HF I don't believe big tone spacing will bring much benefit when compared with ThrobX. 73, Vojtech OK1IAK --- In digitalradio@yahoogroups.com, "Norbert Pieper" wrote: > > Hello Siggi and Group, > > i'm very glad to see that you were able to use MFTTy with some > success. > So far i have learned that "tune finder" is needed. > And a Hlepfile in a more readable format? > > I will add a graphical, FFT-Based, "tune finder" This might take a > week or two. I will let you know when done. > > Please send me your additional suggestions, i will collect and > considder them as my little available time allows... step by step. > > 73 > 55 > de > Norbert > > > > --- In digitalradio@yahoogroups.com, "Siegfried Jackstien" > wrote: > > > > dear norbert > > thanks for the "second edition" of your software > > i will try it out on my system and can send you my comments about > > best 73´s de dg9bfc > > sigi > > - Original Message - > > From: Norbert Pieper > > To: digitalradio@yahoogroups.com > > Sent: Saturday, December 13, 2008 3:15 PM > > Subject: [digitalradio] Re: mftty > > > > > > Hello to the Group!! > > > > I'm new here and have some goddies... > > > > I freshly released an update of MF Tele Type V 2.0.088 > > http://www.polar-electric.com/MFTT/ > > > > And yes it is possible to run MFTT under Vista > > Instructions: > > Launch program directly from it's Program folder location for > > example > > "c:\Program Files\HamRadioSoftware\MFTeleType\MFteletype.exe" > > > > In the properties table one must set: > > > > XP Servicepack2 ( right click on the MFteletype.exe file to > access > > the properties tab and select XP Service pack 2) this step need > be > > done only one time. > > > > Execute as Administrator (each time one runs the program, it is > > necessary to right click the .exe file and select to run it as > > Administrator. ) > > > > Whish you lots of fun with MFTT! > > Any feedback is welcome. > > > > 73 > > 55 > > de > > Norbert > > >
[digitalradio] Re: Olivia mode comparisons, testers needed.
I still believe the decoder may be improved in two ways: 1) Better frequency and time resolution of the decoder. In worst case Pawel's decoder will be 1/4 of frequency and time spacing off. While his code is efficient for initial locking, it may lock more precise after initial sync. I believe this is the explanation why Patrick's decoder is slightly better. 2) Decoding lag. After decoder is locked, there is no need to look up in time 1/2 of symbol spacing for better lock. 73, Vojtech OK1IAK --- In digitalradio@yahoogroups.com, "Patrick Lindecker" <[EMAIL PROTECTED]> wrote: > > Hello Andy, > > The Multipsk code is not better than the Pawel's design. If I had to rewrite the code, I would prefer to use the Pawel's design because it is simpler. > Simply when I wrote it, I was used to do this way (as with MFSK16, PSK31...) and moreover, I had doubts about the precision of a double-estimation by symbol. 10 estimations per symbol seemed to me much better, but of course, it would have be necessary to load much the CPU, so I forgot it. > But I was wrong, because under a good S/N, this precision (double-estimation by symbol) is not necessary and under a bad S/N, it all cases this precision is homogeneous with the precision of symbol estimation. > > Note: it is reminded that, under noise, the quick degradation of decoding is due to : > * the loss of symbol synchronization, > * the imprecision of the symbol estimation. > This can be seen in an "eye" diagram. > > 73 > Patrick > > - Original Message - > From: Andrew O'Brien > To: digitalradio@yahoogroups.com > Sent: Sunday, November 23, 2008 6:08 PM > Subject: Re: [digitalradio] Re: Olivia mode comparisons, testers needed. > > > So does this mean that Patrick has IMPROVED on Pawel's design and the "true" implementation within DM780 is not as effective, or is DM780 slower but better at decoding ? > > Andy > > > > > On Sat, Nov 22, 2008 at 4:34 PM, Patrick Lindecker <[EMAIL PROTECTED]> > wrote: > > > Hello Votjech, > > >I believe the difference between Patrick's MultiPSK and Pawel's > >original Olivia code is in the way how the sync time is adjusted after > >the initial sync is reached. Partick's code locks in time and only > Yes it is as you described (you are perspicacious!). The symbol synchronization is done as in MFSK16, or other mode with a non-linearity and a PLL to follow slight variations. > > However, I use the complete Pawel strategy for RS ID. > > > > synchronization and for decoding very weak signal, additionaly > > introduced 1 second lag in case of Olivia1000/32 is annoying. > > I don't think there is some issue for weak signal. > I tried here comparing Mixw, Multipsk and OliviaAid with a very noisy transmission: the decodings are more or less equivalent. > > The results are the following (with a signal at -13 dB of S/N Gaussian which is the limit for Olivia 32-1000 decoding): > * OliviaAid: 120 characters decoded, > * Mixw: 164 characters decoded, > * Multipsk: 208 characters decoded. > > However, I tested on Gaussian noise, when real conditions could be very different from a Gaussian noise (QSB was not simulated for example) and so the results could be different... > > 73 > > Patrick > > > - Original Message - > From: "Vojtech Bubnik" <[EMAIL PROTECTED]> > To: > Sent: Saturday, November 22, 2008 4:14 PM > Subject: [digitalradio] Re: Olivia mode comparisons, testers needed. > > > > Hi Andy. > > > > Let's say one works with Olivia 1000/32. Olivia sends/receives 7bit > > ASCII letters. Each 7 bit letter is coded by Walch-Hadamard > > transformation into 2^(7-1)=64 bits. One of 32 tones modulation codes > > 32=2^5 combinations, which equals to 5 binary bits. Olivia is > > spreading 5 7bit letters over 64 MFSK32 tones. It takes 64/31.25=2.048 > > seconds to transmit one block of 5 letters. I hope this explains why > > the received letters appear in groups of five and why there is a > > considerable lag, which cannot be lower than 2 seconds for any decoder. > > > > Olivia receiver searches for the Walch-Hadamard coded blocks in time > > and space. Pawel Jalocha's code is running matrix of decoders spaced > > by one half of Olivia tone spacing in frequency and one half of tone > > spacing in time. He is calculating signal level (or quality, > > correlation or whatever one wants to name it) of each of the dec
[digitalradio] Re: Olivia mode comparisons, testers needed.
Hi Andy. Let's say one works with Olivia 1000/32. Olivia sends/receives 7bit ASCII letters. Each 7 bit letter is coded by Walch-Hadamard transformation into 2^(7-1)=64 bits. One of 32 tones modulation codes 32=2^5 combinations, which equals to 5 binary bits. Olivia is spreading 5 7bit letters over 64 MFSK32 tones. It takes 64/31.25=2.048 seconds to transmit one block of 5 letters. I hope this explains why the received letters appear in groups of five and why there is a considerable lag, which cannot be lower than 2 seconds for any decoder. Olivia receiver searches for the Walch-Hadamard coded blocks in time and space. Pawel Jalocha's code is running matrix of decoders spaced by one half of Olivia tone spacing in frequency and one half of tone spacing in time. He is calculating signal level (or quality, correlation or whatever one wants to name it) of each of the decoder in the matrix to check, whether and/or where a valid Olivia block was received. I believe the difference between Patrick's MultiPSK and Pawel's original Olivia code is in the way how the sync time is adjusted after the initial sync is reached. Partick's code locks in time and only slightly adjusts the sync time to cope with differences in RX/TX sound card clock callibration the same way his or any other MFSK16 decoder works. Pawel's code is always looking up one half of block time after the expected sync time. While Pawel's strategy is good for initial synchronization and for decoding very weak signal, additionaly introduced 1 second lag in case of Olivia1000/32 is annoying. I believe Pawel's code may be improved to decrease time lag in case the decoder is already locked to a strong signal. Also if a strong correlation is detected, one does not need to wait another 1 second for even stronger signal, because this is highly improbable. I believe Patrick's MFSK is doing both. Also if the signal is very strong, then one may break into a middle of a block and the block will be detected correctly with the prerequisity that the decoder will be flushed at the time one changes frequency either on waterfall or by tuning knob. I don't think any Olivia decoder is flushed at tuning change. It sounds like a challenge for my PocketDigi code, but don't tell my wife I have a new project :-) 73, Vojtech OK1IAK --- In digitalradio@yahoogroups.com, "Andrew O'Brien" <[EMAIL PROTECTED]> wrote: > > Folks, when Simon was first adding Olivia to DM780 he studied Pawel > Jalocha's coding and consulted with him about the correct implementation. > The lag noticed in DM780 is reportedly as the Pawel Jalocha intended. What > I am looking for is people to get on the air with Olivia and see if the > applications that may have less lag , have any noticeable decoding > degradation. Since I know Olivia in MixW and Multipsk work well, I am > wondering if the "proper" implimentation of Olivia in DM780 is worth the > delay and issues this causes during a QSO (those not knowing about the lag > think we are not coming back to them and start a transmission again ) > > Andy > > On Thu, Nov 20, 2008 at 3:18 AM, Simon Brown (KNS) <[EMAIL PROTECTED]>wrote: > > > The lag is in the software - it's part of the design for the error > > correction. Where error correction is part of the design then *in general* > > with Ham modes you have to wait a while before text is decoding is the > > error > > correction is applied. The lag is not caused by CPU load. > > > > To really understand this it's best to analyse the Olivia design although > > this can be rough for the brain :-) > > > > > > Simon Brown, HB9DRV > > www.ham-radio-deluxe.com > > > > - Original Message - > > From: "captcurt2000" <[EMAIL PROTECTED] > > > > > > Sooo. a 500Mhhz machine running at 20% is going to perform the > > > integrations and decoding same delay as a 2 Ghz machine running at 20%?? > > > > > > That seems counter intuitive to me.. > > > > > > I'm sure you're right but I don't understand how that can be. > > > > > > I thought the load information talked about resources not speed of > > > execution. > > > > > > Help me understand.. > > > > > > > > > > -- > Andy K3UK >
[digitalradio] Re: SignaLink USB Mods
--- In digitalradio@yahoogroups.com, "Tom Tcimpidis" <[EMAIL PROTECTED]> wrote: > > One thing I did with the Signalink on my 746Pro was insert an 18K resistor > in series with the TX audio right at the radio connector. This allowed me > to raise the audio level from the SignaLink and improved my transmit S/N > noticeably. I would do exactly the same. One needs to use the dynamic range of cheap electronics wisely. 73, Vojtech OK1IAK
[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* >
[digitalradio] Re: Sound card question
Hi John. > 1. I noticed that although most PSK31 signals I receive are showing > the two phase positions as displayed on the scope at 180 degrees, > some are consistently at less angle than that, typically down to > about 135 degrees. When I say consistently I mean it is obviously not > just a momentary shift due to propagation as one can see with DX or > QRMed signals. Is this related to the difference in calibration > between the sound cards? Yes > 2. In the case of PSK31 how much does mis-calibration really affects > the reception? Does it result in a simple an increase percentage of > mis-decoded characters when propagation/QRM creates unwanted phase > shifts? In case of PSK31 it depends on the implementation of the decoder algorithm. Uncalibrated clock will cause phase shift to be different from 180 grades, which adds some uncertainity to decoded bit value. But uncalibrated clock will also negatively influence decoder ability to bit synchronize. I remember optimizing PocketDigi PSK31 decoder for best SNR. One of my optimizations was decreasing speed of PSK31 decoder clock synchronization. One does not want a single noise spike to have much influence. I was very surprised, when I found that my decoder did not work at all when the sound card clock was 1% off. > 3. Which modes are the most / least sensitive to sound cards > calibration differences? My guest is that in the least category we > should find the psk and ifsk (e.g. Domino) modes and in the most > sensitive category MFSK modes. Is that a correct assesment? Least sensitive will be CW and RTTY, which are asynchronous modes. Narrow spaced multitone modes (MFSK, Olivia, Contestia, Throb, Domino) will have problems if the tone scale is stretched or shrinked against the decoder bins caused by sound card clock error. Also the same applies here as at 2). Ability to bit synchronize if the sound card clock is off depends on the implementation of the decoder algorithm and is usually a compromise between SNR ability, time to synchronize and sensitivity to clock difference between modulator and demodulator. 73, Vojtech OK1IAK
[digitalradio] Re: 10M WSPR propagation study
> I am proposing that digital radio enthusiasts place their > transceivers on 10M WSPR when they are not using their radio for other > purposes. It does not need to be a full time activity, just when you > radio is not doing anything else. I would propose that all signals > transmitted be less than 5 watts. I thought about extending the ATS-3b firmware to beacon in WSPT format. DDS VFO lends itself to a MFSK modulation very easily. I thought of modifying the original WSJT software to export the beacon diddle as a sequence of tone indices, which would be loaded into ATS-3b keyer memory. A simple complete TX-only 5W beacon may be build based on the ATS-3b schematic for couple of bucks. One of many items on my "like to do" list. What a wonderful world would it be if all my time wasted with nonconstructive arguing with unwilling / non capable people was substituted by happy homebrewing. http://kd1jv.qrpradio.com/ATS3B/ats3b.HTM 73, Vojtech OK1IAK
[digitalradio] Re: Crest factor in Pactor
Hi Patrick. > The first mode of Pactor 3, with 2 carriers (in BPSK) specifies a crest factor of 1.9 dB (ratio of 1.55). > Pactor 2 specifies a crest factor of 1.45 (in ratio)...1.6 dB > > Meanwhile, Pactor 2 applies a root raised cosine window which gives for a one carrier only, a crest factor of about 1.4 /1.45. I wonder whether they reference their two tone crest factor to a single PSK carrier? > Now in Pactor 2, with two carriers sent in the same time, mecanically the crest carrier must be increased to 1.6+3=4.6 dB if no overloading is accepted (and it would be curious to apply a cosine window to afterwards overload the signal...). How about to shift one carrier in time by a half the symbol period and always shape the carrier even if there is no phase change? You will reduce crest factor by this simple scheme. 73, Vojtech
[digitalradio] Re: New Hams and New Digital Technology
Contestia & RTTYM are implemented in PocketDigi also. 73, Vojtech OK1IAK, AB2ZA
[digitalradio] Re: USB soundcard for use with laptop
> At least from what I've seen in the market recently, > some of the cheap USB sound devices do not have > real 48kHz sampling, and they are quite sub-standard > compared to the internal sound device system found > on the average laptop. I bought a cheap USB sound card from geeks.com recently. It has mic preamp always on, which makes it really noisy for digital modes reception. The resolution is not 16bit, but 14bit (the higher 2 bits always zero) and the noise level degrades it to about 8 or 10 bits of real resolution. The sound card does not have output decoupling capacitors! It has no artificial ground for speaker output. I do not believe it is a switched amplifier. Most probably the caps simply did not fit and were too expensive, so earphones are DC linked to the AF PA. 73, Vojtech OK1IAK, AB2ZA
[digitalradio] Re: Multiple Digital Modes: Time to get rid of most ?
Hi Rud. > The decoding delay is minimal and probably not even noticeable, even in chat > mode. The decoding delay will not be an issue in chat mode. But it is annoying for someone interesting in DXes or just high rate of QSOs. It will take too long to just decode call sign during CQ to find out whether one is interested to make QSO. This is one of the reasons CW is so popular. Trained operator is able to decode call sign darn fast. I have to improve myself in CW reception. I was never able to cross the boundary of counting dots and dashes. > The delay in a chat is waiting for a buffer to fill so the FEC packet can be > constructed. In non-FEC mode characters are sent as typed. So for a 20 > character message it requires the time for 20 keystrokes, calculation of the > FEC and then the transmission of the 20 characters plus FEC characters. The delay depends on FEC and interleaving. > It might be interesting to try the following: > 6. After the FEC is received and decoded the receiver displays any corrected > characters in the appropriate place on the display. This was proposed by Phill Karn in MFSK16 list some months ago. You could do it if you do do not have interleaving and use systematic code. With modes like MFSK16 you may only slightly improve decoding delay by using shorter Viterbi decoder. But the delay caused by interleaving and convolutional code is not avoidable. 73, Vojtech OK1IAK
[digitalradio] Re: Multiple Digital Modes: Time to get rid of most ?
> >>>A new protocol with all of PSK31's current virtues augmented by > error correction and the ability to convey modest-sized files in real- > time would initiate a similar transition, I suspect. BTW, PSK63F has error correction, but I never heard it on air. FEC will always introduce decoding delay. 73, Vojtech OK1IAK
[digitalradio] Re: ANNOUNCE: PocketDigi 1.0.11 released - JT65
Hi Patrick. > Why do you think to propose JT65 to your program. It would be quite nice to be able to do far QSOs with a Pocket PC and a small mobile QRP station. I am not convinced that unmodified JT65 is a good idea on HF as the tone spacing is 2.69 Hz. It must be sensitive to doppler, polar flutter, multipath etc. I do not say that it will not work as the amount of redundancy in this mode is overwhelming, but increasing tone spacing will improve it on HF. It would be interesting to run it through a ionspheric simulator and play with tone spacing. I will consider adding JT65 to PocketDigi, but currently I am investigating, whether it would be possible to use speech recognition methods for decoding morse code. I also thought about implementing your 400Hz ALE, but I was intimidated by the DoD specification. 73, Vojtech OK1IAK
[digitalradio] Re: PSKmail
> It would be nice to have the pskmail functionality in a "re-usable" form. > The code is complicated enough to need deep involvement to understand. > It's not possible to "quick-hack" it into C. We need the help of the > author ! There is a C implementation of flARQ. It uses gtk UI toolkit and there is a port of gtk to Windows. I already tried to compile it on Windows and connect it to PocketDigi, but there is some work needed, as threading and communication between flARQ and flDigi are not directly portable to Windows. AFAIK pskmail slightly extends protocol, that flARQ implements. 73, Vojtech OK1IAK
[digitalradio] Re: Technical Question: FDMDV / QPSK in PSK31
Yes, my note about bpsk/qpsk was nonsense. > My understanding of theory is that baud equals the spread between tones in > an OFDM or 2* baud in basic multi-tone signal. As someone noted, it is not ODFM. > That does not fit with a 50 baud and 75 Hz separation. Compromise on total signal width and intersymbol interference. Vojtech
[digitalradio] Re: Technical Question: FDMDV
--- In digitalradio@yahoogroups.com, "Rud Merriam" <[EMAIL PROTECTED]> wrote: > > The statement about it being "50 baud, RRC filtered..." confuses me. > > My understanding of theory is that baud equals the spread between tones in > an OFDM or 2* baud in basic multi-tone signal. That does not fit with a 50 > baud and 75 Hz separation. > > What am I missing? It is QPSK, not BPSK. 73, Vojtech
[digitalradio] Re: digital voice within 100 Hz bandwidth
> Books that have been done in the past did not have narrow bandwidth > as their main objective. Look at the LPC-10 codec. You could try it by downloading internet telephony software from speakfreely.org. The codec was developed with the low bandwidth in mind and its intelligibility is on the threshold what I would accept. If IVOX is able to squeeze LPC-10 to 1200bps with the same intelligibility, than it is great. The proposal that you gave will certainly not work. You describe a system, that computes spectrum and compares it to a library of spectra, one by one. It may work for some vowels, but it will certainly not work for the other phonemes. The task is much more difficult than you think. The fricatives - d, t, f, s etc are hard to detect. The sound is quite complex and spectrum of a single phoneme changes in time. The sound starts with quiet pause, then explosion, then some transient of the explosion. The hidden Markov classifier is a kind of probabilistic network, is often used on spectra and is a good system for detection of phonemes. As I already wrote, if you get the consonants wrong, your system will mumble. Even for vowels, you would have to keep more spectra for a single phoneme in the lookup table, sampled for different pitch. You don't want to learn to speak with a constant pitch. Phoneme detection is described in every voice recognition text book. Writing papers about phoneme detection for HAM radio is reinventing the wheel. 73, Vojtech OK1IAK
[digitalradio] Re: Testing Digital Codes at Bit Level
Hi Rud. I do not know any program, that introduces errors into bit stream for protocol tuning purposes. For tuning the decoders in PocketDigi, I used Moe's WSCGen, which generates test streams of various levels of AWGN. http://www.moetronix.com/ae4jy/projects.htm It is not valid to simulate AWGN in bit stream by flipping bits. All the advanced decoders use "soft" bits technique, that works with fuzzy bits. For example, MFSK16 decoder utilizing Viterbi decoder implemented by Phil Karn KA9Q and used by gMFSK, fldigi and PocketDigi reads bits quantized to 8 bits, 0 signalizing 100% zero, 255 siganlizing 100% one and 127 dont't know. Noise may influence not only data stream, but also its synchronization in time and frequency (AFC). At the end, one needs to evaluate the whole decoder chain at once. One phase error in differential system (psk31, domino) caused by noise may introduce two successive bit errors. One error in FSK system will introduce only one bit error. > Fading: is it valid to simulate fading by removing some bits in the data > stream? It depends on the coding and synchronization. If the code is synchronous and sync lock is slow, it may survive the fading gap. Then you will get a correct number of bits, which will contain rubbish. An asynchronous decoder like RTTY will soon be lost, throwing away whole 6-bit symbols. 73, Vojtech
[digitalradio] Re: ALE400 - Narrow band ALE mode now available
--- In digitalradio@yahoogroups.com, "Brian A" <[EMAIL PROTECTED]> wrote: > 1) Using a 200 Hz filter instead of 400 or 500 Hz filter gives a 3db > S/N ratio improvment-- PSK or RTTY. It's guaranteed. It is not. Using narrower filter will reduce total noise and out of channel QRM, lowering dynamic range requirements for MF, AF and A/D stages. If the chain has enough dynamic range, it does not matter, which filter you use. Each software PSK31 decoder contains narrow DSP filter just after A/D What really matters is S/N after this digital filter, which is independent of MF filter bandwidth. > In other words, all the extra baggage (bandwidth) is generally just > extra weight with no robust benefit. There are physical laws telling that one needs less energy to transport the same information, if he increases channel bandwidth. 73, Vojtech OK1IAK
[digitalradio] Re: Sub Channel DQPSK
> Would the phase distortion that can corrupt a PSK signal occur the same on a > M-PSK signal? Phase and frequency modulation are two sides of the same coin. There is a baseband transformation to translate from phase to frequency modulation and vice versa - integration / derivation. Integrate baseband signal for phase modulator to get baseband for frequency modulator, derive baseband signal for frequency modulator to get baseband signal for phase modulator. The same phase distortion rendering PSK signal unreadable shows as a Doppler shift making the signal leaking into a neighbor frequency bins. Generally, there will be some inter symbol interference, but MFSK will still work, if the bins are not too narrow. PSK as well as MFSK will be affected by multipath, it will create another type of inter symbol interference - time overlap. DominoEX with its incremental MFSK tries to cope with it, but there is a price for that. I am not convinced yet that the incremental MFSK is the best thing. > If the phase distortion affects all the sub channels then doing differential > PSK among the sub channels would work where symbol to symbol DxPSK would not > work. It is rather not the case. Polar flutter is frequency dependent. It seems you are jumping on the train very fast. I hope you will help me to make PocketDigi better, because my time for PocketDigi will be shortened as I am slowly getting busy with the Father project, hi. 73, Vojtech OK1IAK
[digitalradio] Re: PSK under ionospheric flutter, was: QEX Article on HF Digital Propagation
> Up to PSK31, you can see this phenomenon. But if you increase the speed (PSK63), you decrease the sensitivity to Doppler but also increase (with 3 dB) the minimum S/N. All is a question of compromise. Yes, my point was that adding convolutional encoder, coding gain could somehow eliminate the 3db S/N loss of double bandwidth. > For comparison of modes, I think it would be, ideally, interesting to normalize to the same text throughput so to be able to consider all the parameters of the performance, as for example, the degree of redundancy introduced by the mode (example MFSK16 or PSK63F: 2, Olivia: about 9). This because if, for example, MFSK16 would be transmitted at the same throughput as Olivia 32/1000, its minimum S/N would be 3 dB better that the present S/N (-16,5 dB instead of -13.5 dB). Thanks for that note. In my opinion Olivia trades easy tuning against decreased speed and S/N capability if compared to MFSK16. 73, Vojtech OK1IAK
[digitalradio] Re: QEX Article on HF Digital Propagation
> PSK31 failed, bad copy even under good SNR, with 3 ms multipath and 10 Hz > Doppler. It did not do well with 2 ms multipath and 1 Hz Doppler. > > Since Pactor uses PSK I wondered if it would similarly fail as shown by the > PSK31 results. I suspect that it handles Doppler better through frequency > tracking algorithms. PSK31 bandwidth is much lower than of PSK100 that Pactor 2/3 utilizes. PSK100 will lock to a signal 100/31 times far mistuned than PSK31. Symbol length of PSK31 is 32msec, symbol length of PSK100 is 10msec. I would say that PSK31 will be oblivious to 2ms multipath, but I suppose the phase difference of both reflections will not be stable, causing phase modulation of the summed multipath signal, which PSK100 with convolutional code will be able to handle. 73, Vojtech OK1IAK
[digitalradio] PSK under ionospheric flutter, was: QEX Article on HF Digital Propagation
> Why do the reports about Pactor indicate it is more robust than the QEX > article would indicate? I did not read the QEX article, but I hope I learned something about PSK modulation with regard to ionospheric flutter over the years I am developing PocketDigi. 1) PSK is very efficient in white noise. 2) Ionospheric flutter modulates reflected signal. If the digital modulation is slower or comparable to the modulation caused by ionospheric flutter, the signal will not be intelligible. 3) Coding gain is your friend. Trade bandwidth for improved coding gain. It works, if the raw channel S/N is higher than some threshold, see the graph on the following page and read the whole article. http://www.qsl.net/n9zia/a105/index.html So if a slow PSK signal is reflected by fluttering ionosphere, it will be distorted. If a fast PSK signal is reflected by the same ionosphere, the distortion will be less severe, but one would need to increase power to keep the wider signal readable. The solution to beat ionospheric flutter is to combine higher modulation speed and coding. Pactor 3 raw modulation speed is 100Bd. In worst conditions, effective data rate will be reduced by a convolutional encoder to 50Bd. Pactor improves the reliability further by memory ARQ. Pactor will really work even in a bad ionospheric flutter. There are less elaborate PSK modes than Pactor 2/3 used by HAMs designed to beat ionospheric flutter. PSK63F is a mode derived from PSK63 and MFSK16. It uses binary PSK modulation of raw 63 bits per second, but it is coded by MFSK16 varicode and MFSK16 convolutional coder, decreasing effective data rate to 31 bits per second. If comparing PSK31 against PSK63F in white Gaussian noise, there will be a S/N threshold, under which PSK31 will produce less errors than PSK63F. Above this threshold, PSK63F will produce less errors than PSK31 for the price of doubled bandwidth and turnaround delay caused by convolutional encoder/decoder. If comparing the two modes under ionospheric flutter, PSK63F will work under much more severe flutter than PSK31 independent of S/N. I think Patrick has a similar mode in MultiPSK, which limits further the character table, making the mode work with even lower S/N. 73, Vojtech OK1IAK
[digitalradio] Re: Dev: Real to I/Q
> How do I change from a real signal to quadrature? Look into gMFSK sources, search for Hilbert transformation. Basically, one filters the input signal through two low pass filters, one results in real, the other in imaginatory component. > Also, do I remember that after the conversion the sampling rate is 1/2 the > original sampling rate? Not exactly. If you convert a real signal into complex signal by Hilbert transformation and run FFT, you will find no power in negative frequencies. If you set the I component zero and run FFT on the real signal (no Hilbert transformation done), you will find the power spectrum is mirrored around Y axis, only the I component has opposite signum for negative frequencies. Because negative frequencies convey no power after you do Hilbert transformation, one could shift the whole spectrum by half bandwidth left, low pass filter at half the bandwidth and throw away every second sample. Now the complex signal conveys the same amount of information in the same amount of coeffitients as the original real signal. 73, Vojtech OK1IAK
[digitalradio] Re: 30 meter PSK
> What is the best frequency for PSK31 work on 30 meters? I Europe, it is around 10.140. 73, Vojtech OK1IAK
[digitalradio] Re: The decline of Olivia and DominoEX
Hello Patrick. Thanks for your explanation. Do I understand your S/N figures well? Let's say I am using a 100 watts transceiver. If transmitting > * MT63 à 10 bauds: - 5 dB and 100 wpm, 1000 Hz bandwidth, crest factor 0.1 then I will be actually able to send energy equivalent only to 10 watts CW. If transmitting > * Contestia "16-1K": "Fast" 16 tones, bandwidth=1000 Hz, speed=62.5 bauds, 78.2 wpm, lowest S/N =-9 dB, crest factor 0.76 then I will be actually able to send energy equivalent to 76 watts CW. Then I am losing another 10 * log10(76/10) = 8.8dB and I may say, that with the same 100W transceiver MT63 will perform 12.8dB worse at 100 wpm than Contestia at 78.2 wpm? It sounds pretty bad for MT63. I think there is another issue with ODFM of high number of tones. It is highly sensitive to linearity of the whole transmitting and receiving chain. If not linear, the tones will mix together, which will further decrease sensitivity. In my opinion, MT63 was a useful experiment, that has shown a dead way. 73, Vojtech OK1IAK --- In digitalradio@yahoogroups.com, "Patrick Lindecker" <[EMAIL PROTECTED]> wrote: > > Hello Votjech, > > Yes you are right the crest factor in MT63 is very low (mean power/ crest power = 0.1 (OFDM general problem) for 0.76 in Olivia... > > Other problems: due to the big number of carriers (64) you need a good calibration of the sound card. Otherwise, you decode nothing. > The minimum S/N is not very good either and the latency time is big. > > If Olivia is too slow, another better option is to transmit in Contestia. For about S/N, it is only about 1 dB under Olivia but the speed is twice. > > Example: > * MT63 à 10 bauds: - 5 dB and 100 wpm, 1000 Hz bandwidth > * Contestia "16-1K": "Fast" 16 tones, bandwidth=1000 Hz, speed=62.5 bauds, 78.2 wpm, lowest S/N =-9 dB, > No problem of crest factor (0.76), small latency time and no problem of sound card calibration. > It's available in Mixw, Multipsk and perhaps Fldigi. > > 73 > Patrick > > > - Original Message - > From: Vojtech Bubnik > To: digitalradio@yahoogroups.com > Sent: Friday, September 14, 2007 12:45 PM > Subject: [digitalradio] Re: The decline of Olivia and DominoEX > > > > Question - what's so special about MT63 - where / when is it used? > > From my point of view, MT63 has high number of carriers, which implies > low crest factor - the effective transmitted power will be much lower > than of single tone mode like Olivia, if you make sure PA is not > overdriven by peaks where the amplitude maxima of multiple carriers meet. > > Some argue that the mode is fast, but are not there Olivia submodes > with the same throughput? > > 73, Vojtech OK1IAK >
[digitalradio] Re: Best digital modes for portable QRP
> I'm very much a newcomer to digital modes, so please pardon this > question. I'm interested in designing a QRP rig that uses digital > modes for portable operation in the field, much like the KX-1 and ATS > do for CW. Other that PSK31, which digital modes are best suited for > this type of operation? Hello Mike. Look at the AT_Sprint group at yahoogroups. Look into files for manual for the ATS-3b transceiver kit. The little TRX is able to work not only CW, but PSK31/63, RTTYM, MFSK16, Olivia, Contestia and RTTYM (250Hz wide variants due to narrow receive filter). All you need is a Pocket PC device and two audio cables. If you are interested, hurry up to place your order. I am not sure how much kits will Steve sell this time, but the first 100 is sold out. BTW, KX1 hardware is able to work digital modes as the ATS-3b, only its firmware would need to be extended. The ATS-3b still needs Pocket PC to work digital modes. What is missing is a stand alone digital qrp transceiver with the keyboard and display built in, but I am not sure whether it makes sense to design it. The price of used Pocket PC is very low, probably lower than price of display, keyboard, some controller and custom PCB. In my opinion, PSK31, MFSK16 or Olivia 8/250 are all very good QRP modes. 73, Vojtech OK1IAK
[digitalradio] Re: The decline of Olivia and DominoEX
> Question - what's so special about MT63 - where / when is it used? >From my point of view, MT63 has high number of carriers, which implies low crest factor - the effective transmitted power will be much lower than of single tone mode like Olivia, if you make sure PA is not overdriven by peaks where the amplitude maxima of multiple carriers meet. Some argue that the mode is fast, but are not there Olivia submodes with the same throughput? 73, Vojtech OK1IAK
[digitalradio] Re: Soundcard Calibration
> Doesn't this assume an accurate system clock? I think I see a class in gMFSK > / fldidgi to compare input <=> output but for calibration we need an > accurate source. If your system time is 1 second off every day, system clock precision is 1 / (24*60*60) = 12 ppm. My feeling is that this is good enough. 73, Vojtech OK1IAK
[digitalradio] Re: Soundcard Calibration
--- In digitalradio@yahoogroups.com, "Simon Brown" <[EMAIL PROTECTED]> wrote: > > Somewhere I saw a solution for calibrating a soundcard (not using WWV). Can anyone help with this please - I want to write a DD to do this then add the code to a program of mine. > > Why? Because I'm thinking about MT63 - looks interesting but the soundcard accuracy is important. > > Simon Brown, HB9DRV > I think Patrick in his MultiPSK has some form of auto calibration. I suppose he measures with the system clock how long it takes to feed some extended number of sound bits through the system. To implement it is on my list for PocketDigi too. 73, Vojtech OK1IAK
[digitalradio] Sound card ARQ protocol, was: The decline of Olivia and DominoEX
> > With Pactor 2 and 3 they get a type of diversity gain by changing the > > order of which tones are swapped back and forth. This is specified in > > their description of the P3 protocol, but I don't fully understand this > > and maybe this is not easy to implement. Let me describe what I learned from the documents published about Pactor. For memory ARQ to work, the frame frequency and time position and frame length must be known with a lot higher probability than the frame content. Also frame acknowledgment has to be performed with patterns of high hamming distance. If those conditions are met, the frame may be received and accumulated with the previous copies to reduce noise and QRM. To detect frame frequency and start time, special long "diddle" aka header with high hamming distance is used. Frame length is known implicitly. If a frame length has to be switched, both parties negotiate it by patterns with a high hamming distance, which reduces repetitions. The polarity of FSK signal by Pactor I and order of PSK tones by Pactor II is detected by the particular diddle aka header. With each frame repetition, polarity of the frame including header is reversed. Hamming distance between non inverted and inverted header is high to be sure with which polarity the frame is sent. Reversing tones of Pactor I will effectively null single tone carriers. Pactor II/III changes order of tones. Which permutations are chosen is not published, but the switching is controlled by the header for sure. HF utilizes HDLC frames, that start and end with single byte flag (0110) and all frame data are secured with CRC32. Not only data frames, but also the control frames have the same structure. If a single bit of either data or control frame is lost, the whole frame has to be retransmitted. The frame delimiter has too low hamming distance to enable memory ARQ. Frame acknowledges are equally weak as the data frames, which reduces the ability to work with weak signals. pskmail implements a protocol described by Paul Schmidt K9PS in December 2004. The protocol is similar to AX.25, only simplified (does not support shared channel, only one connection is allowed) and supporting selective ARQ, which is the biggest plus of pskmail against HF packet. Both data and control frames start with single byte frame delimiter and are secured by CRC32. I am thinking of writing a Pactor like memory ARQ modem. There is quite a lot information published about how Pactor I/II/III modems work. There is not enough detail known to write a compatible modem, but there is enough known to write something of similar performance. The problem of PC pactor like modem is system latence. I would like to try to extend the Pactor like protocol to negotiate number of frames per round. The frame length and number of frames per round would be fixed and negotiated with high hamming distance commands. This way the memory ARQ would be possible. I will see whether I will find some time for it this Winter. 73, Vojtech OK1IAK
[digitalradio] Re: The decline of Olivia and DominoEX
Hi Patrick. > I was astonished (and a bit disappointed) not to find more that one dB. I think it's due to the particular IFK modulation: when you do one error on a symbol, the following symbol will be also in error (as in PSK31). So it's a bit more complicated for the Viterbi decoder to find the good suite of symbols. Do you use hard or soft viterbi for DominoEX? Plus one decibel would indicate hard decoder. Does your QPSK31 decoder use soft or hard viterbi decoding? gMFSK and supposedly fldigi use hard viterbi decoder. 73, Vojtech OK1IAK
[digitalradio] Re: The decline of Olivia and DominoEX
Hello Rick. First of all, I would like to comment on FEC and S/N. Look at the article from G3RUH http://www.amsat.org/amsat/articles/g3ruh/105.html The graph http://www.amsat.org/amsat/articles/g3ruh/105/fig01.gif explains a lot. FEC gives you an extra coding gain, only if the raw signal S/N is higher than some threshold. If the raw signal S/N drops below some threshold, you will be better off not using FEC, because FEC will only add errors. Now I would like to compare pskmail with pactor. While pskmail is a better HF packet radio, pactor is much more elaborate. Frames have fixed length, which allows whole frame interleaving and memory ARQ. Interleaving allows spreading burst errors along the whole frame. Memory ARQ allows to accumulate energy of each bit over more frames. Even if there is no chance to receive the frame under the current S/N, it is possible to accumulate it couple of times to improve on S/N. There is another neat feature of pactor, it alternates FSK or PSK tones to add frequency diversity. I think the holy grail of sound card ARQ mode would use all the knowledge and experience gained from Pactor development. This include FEC, interleaving, fixed frame length, memory ARQ, tones alternation. It is not that dificult to implement, one needs just a bit of experience and a huge amount of time to write and tune it. 73, Vojtech OK1IAK
[digitalradio] ATS-3b CW+digital modes transceiver
Hi gang. Steve KD1JV is selling his new ATS-3b altoids tin transceiver. http://kd1jv.qrpradio.com/ He already sold the first hundred, so hurry up. The previous kits only supported CW. The current one does support modulation of various digital modes (PSK31, RTTY, MFSK16, Olivia etc.) directly on the DDS. Receive is done as usual with the earphone to mic link. TX control is quite unusual. There are serial commands modulated by the sound card output, which are decoded by a hamcom like decoder. To make sure that the signal has zero DC, serial commands are layered over Manchester modulation. The decoder is connected into the paddle socket. The only software able to talk to ATS-3b currently is PocketDigi. With Pocket PC, it is the tiny digital modes companion for backpackers and travelers. It is really fun to operate PSK31 from the peak with an equipment all fitting into a small sandwich box. 73, Vojtech OK1IAK
[digitalradio] Re: A.L.E., VHS and Betamax
> i have tried to run the livecd version ... but it wont run on any of my > 3 PC's. One deosent start up kde .. one seems too slow ... one doesent > recognize the 3 soundcards ... 2 pc's run ubuntu livecd fine, but not > the mandriva version. Hi Cesco. Did you try the vmplayer image? In my opinion the vmplayer will virtualize any sound card that is working on Windows for that live Linux. http://www.mannindustries.net/n5ale/ 73, Vojtech OK1IAK
[digitalradio] Re: RTTY Configurations
Hi Simon. I only allowed the HAM subtype of RTTY in PocketDigi mostly because of my time lack to port everything. The other reason is to keep the UI simple, which is probably the reason of your question. I asked the same question about used submodes as you couple of months ago here at this list. The only requests I got are from the yachters for allowing reception of DWD (Deutche Wetterdienst) broadcasts. http://www.dwd.de/de/wir/Geschaeftsfelder/Seeschifffahrt/Sendeplaene/broadcast_rtty_1prog.pdf http://www.dwd.de/de/wir/Geschaeftsfelder/Seeschifffahrt/Sendeplaene/broadcast_rtty_2prog.pdf The others are perfectly content with the just one submode. Hope it helps. 73, Vojtech OK1IAK
[digitalradio] Re: Straight talk on JT65a
Hi Leigh. The callsigns are source encoded into 28 bits, the grid in 15 bits. This gives 71 bits total for 2 callsigns and a grid. If the same information is exchanged by 6 bit letters of Contestia, 94 bits will be nescessary. That gives coding gain of 10*log(94/71)=1.21dB supposing the same baud speed but lower bandwidth. MFSK16 uses convolutional codes with viterbi decoder, Olivia uses Fast Hadamard Fransformation. The Reed Solomon block code that JT65 utilizes is a bit better than the two others. What is the coding gain against say Olivia? Maybe other 2dB? I would estimate the total coding gain difference of JT65 against Contestia abt. 3dB for the same symbol rate, bandwidth and tone separation. The tone separation of JT65a is 2.69Hz! This is very little considering multipath and ionospheric doppler shift. Is this mode really good for HF? Tone spacing of MFSK16 is 15.625Hz, of MFSK8 7.8125Hz. 73, Vojtech OK1IAK
[digitalradio] Re: Reed Solomon Identifier
Hi Patrick. > >you send a heavily FEC protected keyword in the desired mode. > >you do a parallel decode of all modes, de-FEC all and look which one > >matches the the codeword ? > Yes it is. But it is not only done for one frequency, it is done for all frequencies in the band. I played with MultiPSK and listened to the generated RS sequence. In my opinion it is always the same modulation. According to my ears and spectrogram it seems to be some kind of MFSK modulation, always the same number of tones and symbol speed. Please correct me, but I think there is a misunderstanding on the list. I suppose that the RS ID is very similar to Olivia, there are three differences though and I thing we have discussed it by personal e-mails. - Olivia uses Hadamard/Welsh transformation, RS uses Reed Solomon block code - Olivia is decoded parallel on a constraned band, RS is decoded parallel on the whole sound card spectrum. The channel separation is half tone. - RS code sends just one block with the mode ID. Olivia and RS decode both a lot of channels in parallel (at least the original Olivia code from Pawel Jalocha does that) and it selects the one, which gives highest correlation. This automatically gives the answer for other party frequency. I received the RS code from Patrick, but I did not add it to PocketDigi yet. I am busy now with firmware programming of ATS-3A, I hope to teach it to modulate the single tone modes by programming its DDS. It will be the ultimate portable digital set, hi. 73, Vojtech OK1IAK
[digitalradio] Re: Digital Master 780
> The real hard work has been done by W1HJK, not me. > > Simon Brown, HB9DRV Simon, I think it is fair to give credits to Tomi Manninen OH2BNS and others, http://gmfsk.connect.fi/credits.html fldigi is in a lot of aspects gMFSK reformated to C++ and using other GUI toolkit. 73, Vojtech OK1IAK
[digitalradio] Re: MPSK vs OFDM vs MFSK for HF High Speed Data
The other problem is linearity of the whole chain. The subcarriers get mixed not only in the PA, but in the receiver, sound card etc., which may be interpreted as increased noise on the decoder side. The average YaeComWood was not designed with this in mind. Voice SSB modulation is roughly similar to three carriers. So using multimulticarrier soundmodem with a YaeComWood + 1kW PA will only heat your ham shack without other useful effect. 73, Vojtech OK1IAK --- In digitalradio@yahoogroups.com, "Patrick Lindecker" <[EMAIL PROTECTED]> wrote: > > Hello to all, > > For me, the main problem, for Hams, of the multi-carriers modulation (OFDM...) is that the power is drastically limited (if you want to, legitimally, keep linear): > > If you have two carriers in parallel, the mean power/max power ratio is equal to 1/2 > If you have three carriers in parallel, the mean power/max power ratio is equal to 1/3 > > when n becomes big, the ratio tends to 1/square(n) (the carriers phases being independant, with application of the "big numbers law") > For example, for MT63 where you have 64 carriers in parallel, the ratio is 1/8. You transmit only 12.5 watts with a 100 watts maximum XCVR.
[digitalradio] Re: FNpsk
--- In digitalradio@yahoogroups.com, "Leigh L Klotz, Jr." <[EMAIL PROTECTED]> wrote: > > Vojtect OK1AK's PocketDigi may be the answer here, in the x86 version. > Especially if the cntrol gets done over TCP. > Leigh/WA5ZNU There is a file interface built in the desktop build of PocketDigi similar to the one that gMFSK implements. 73, Vojtech OK1IAK
[digitalradio] RTTY modes, which are helpful
Hi gang. Until now I only allowed the standard HAM RTTY 45Bd 170Hz mode in PocketDigi. I was asked to add the SYNOP 50Bd 450Hz mode for receiving Deutsche Wetterdienst. Most of the RTTY programs allow to select huge amount of baud speed, shifts and coding combinations. I find this only confusing. I may provide a configuration screen with all this parameters, but I would like to keep the basic UI as simple as possible. What are the other configurations that are used by HAMs or may be useful to listen to? Thanks and VY 73, Vojtech OK1IAK
[digitalradio] Re: Implementing Contestia/RTTYM, could use some advice
Joe, I have derived both Contestia and RTTYM from Pawel's code. You may look at the sources at http://pocketdigi.sourceforge.net Try to revert the bits before they are fed to the baudot decoder. 73, Vojtech OK1IAK --- In digitalradio@yahoogroups.com, "Patrick Lindecker" <[EMAIL PROTECTED]> wrote: > > Hello Joe, > > What is sure is that there is no other differences that the ones I gave in the "RX/TX modes selection and their descriptions" chapter, so modifications on: > * Block size (symbols) > * Scrambling pseudo-random sequence > * Scrambling shift (in number of bits of sequence right rotation) > * Characters set > > Try first to change from Olivia to Contestia. It is the simplest, as RTTYM adds a switch management, contrary to RTTYM. > > Then try in reception generating Contestia, without noise. You must decode it. Then adjust the different parameters of your code to decode low S/N Contestia signals. > > 73 > Patrick > > > > > > > > > - Original Message - > From: Joe Veldhuis > To: digitalradio@yahoogroups.com > Sent: Wednesday, September 27, 2006 6:38 PM > Subject: Re: [digitalradio] Re: Implementing Contestia/RTTYM, could use some advice > > > Patrick only gave an outline of the differences between Olivia and the > derivative modes. What I am looking for is some pointers on the actual > task of modifying the templates to implement those differences. > > I tried implementing RTTYM by changing the "BitsPerCharacter" and > scrambling code/shift parameters in Pawel Jalocha's reference code (and > then passing the output through a Baudot>ASCII routine), but that was > apparantly not enough, since I don't get any output from the demodulator. > > -Joe, KD8ATU > > jhaynesatalumni wrote: > > I haven't looked yet, but you might look in the MultiPSK documentation, > > since Patrick recently implemented those modes in his program and may > > have written them up. > > > > > [Non-text portions of this message have been removed] >
[digitalradio] Re: Channel Equalization, was: best mode to use for weak signal
Hi Patrick. Thanks for the info. I hope it was useful to the othes too. That's the reason I discuss it on the list. Pawel's input processor does basically the following. - Splits input stream to chunks that half overlap - Applies a window to the chunks. - Computes FFT - Averages each FFT bin energy - Equalizes the bins by the averaged bin energies. - Converts back to time by IFFT - Applies a window to the time signal and overlaps the equalized time chunks - Now the time stream is expected to be amplitude limited and amplitude peaks will be cut by a clipper. I think this last step shall resemble burst removal > In HF there would be no interest as the channel transfer function moves all times and too quickly. I believe it. > Moreover it will need some impulse in input so to determine the transfer function with output and input, which is not expected. I do not think that phase delay equalization is needed for MFSK modes. A simple frequency amplitude equalization is what I meant. I think that it may make sense to "callibrate" FFT decoder by a white noise ran through the RX. That would equalize against the RX filters. But I expect that most of the HAMs woud never use it. > Note: Pawel code uses FFT, Multipsk (and surely Mixw) use a bank of matched filters so as not to be obliged to handle only one frequency. I am not sure I understand this statement. Pawel's code runs FFT two times faster than the symbol speed and with double spaced bins than frequency spacing of Olivia symbols. That generates 4 symbol streams. The FFT window is matched against the Olivia symbol envelope. The issue is that the symbol time and frequency will be 1/4 symbol frequency and 1/4 symbol time off in worst case. On the other side it will synchronize to the other side very fast. Do You mean You actually do the AFC exactly and You synchronize the symbols as in the case of MFSK16? My code uses the Pawel's method. The issue with FFT computed by fixed point arithmetics is that it is far less exact than the matched FIR filters. Although it is good enough for waterfall, it may not be good enough for the decoder. I had to rewrite the SFFT filters of gMFSK's MFSK16 to simple FIR filter bank because of numerical problems on fixed point ALU. I tried to generate Olivia to the speakers by MultiPsk and receive it with PocketDigi by the internal mic. If I whissle somewhere in the middle of the olivia stream spectrum, the decoding is totally disrupted. I will try the same test with gMFSK yet, which uses Pawel's code with channel equalization and I expect that the channel equalization may remove the constant carrier and push the data through. I expect the same will hold for any MFSK code like MFSK16 or Throb. > >running on my 200MHz StrongArm PocketPC with channel equalization Sorry, I meant without channel equalization. 73, Vojtech OK1IAK
[digitalradio] Re: Implementing Contestia/RTTYM, could use some advice
Hi Joe. I have to confirm what Parick wrote. I am working on Olivia/Contestia/RTTYM for PocketDigi and after doing what Patrick described I was able to send/receiver contestia. I am using Pawel's code, but I removed a lot of dead code before I started to understand it. I am affraid you would not want to use my code directly because it uses fixed point arithmetics, which is not as precise as the original floating point code. 73 and GL, Vojtech OK1IAK --- In digitalradio@yahoogroups.com, "Patrick Lindecker" <[EMAIL PROTECTED]> wrote: > > Hello Joe, > > What is sure is that there is no other differences that the ones I gave in the "RX/TX modes selection and their descriptions" chapter, so modifications on: > * Block size (symbols) > * Scrambling pseudo-random sequence > * Scrambling shift (in number of bits of sequence right rotation) > * Characters set > > Try first to change from Olivia to Contestia. It is the simplest, as RTTYM adds a switch management, contrary to RTTYM. > > Then try in reception generating Contestia, without noise. You must decode it. Then adjust the different parameters of your code to decode low S/N Contestia signals. > > 73 > Patrick > > > > > > > > > - Original Message - > From: Joe Veldhuis > To: digitalradio@yahoogroups.com > Sent: Wednesday, September 27, 2006 6:38 PM > Subject: Re: [digitalradio] Re: Implementing Contestia/RTTYM, could use some advice > > > Patrick only gave an outline of the differences between Olivia and the > derivative modes. What I am looking for is some pointers on the actual > task of modifying the templates to implement those differences. > > I tried implementing RTTYM by changing the "BitsPerCharacter" and > scrambling code/shift parameters in Pawel Jalocha's reference code (and > then passing the output through a Baudot>ASCII routine), but that was > apparantly not enough, since I don't get any output from the demodulator. > > -Joe, KD8ATU > > jhaynesatalumni wrote: > > I haven't looked yet, but you might look in the MultiPSK documentation, > > since Patrick recently implemented those modes in his program and may > > have written them up. > > > > > [Non-text portions of this message have been removed] >
[digitalradio] Channel Equalization, was: best mode to use for weak signal
Hi Patrick. I studied the Olivia reference implementation from Pawel Jalocha. His code contains input processor doing channel equalization and burst removal in a way I do not understand well yet. I have a question on you as a digital modes guru: - Does MultiPsk utilize channel equalization for Olivia/Contestia/RTTYM? - Does MultiPsk utilize channel equalization for other MFSK modes like MFSK16/8, Throb/ThrobX or even old plain RTTY? - Do you find the channel equalization feature useful? I have a basic Olivia and Contestia based on Pawel reference code running on my 200MHz StrongArm PocketPC with channel equalization removed. My concern is power consumption of the device if I enable channel equalization. Thanks and VY 73, Vojtech OK1IAK --- In digitalradio@yahoogroups.com, "Patrick Lindecker" <[EMAIL PROTECTED]> wrote: > > Hello Rick, > > >If often wonder if a mode that has a very wide ability to print even if > >not tuned in well has to have some tradeoffs in robustness compared with > >critical to tune modes. Anyone have specific information about that? > The ability of DominoEx to be tuned very easily is that the modulation is an IFK one and not a MFSK one. It means that you measure a difference of frequency not a frequency in absolute as in MFSK. The good point it is easy to tune (no absolute reference of frequency) but the bad point is that when you do an error, the second symbol is also in error...you double the error (it's a bit like in PSK31, which one measures a difference of phase: if you do a error on one symbol, the next symbol will be also in error). > > >Can anyone say with some degree of certainly what modes you think will > >get through on the low bands with high QRN levels? > I think Olivia must be good but Contestia is more close to ideal as twice quicker than Olivia with a minimum S/N just 1 or 1.5 dB superior to Olivia. > > 73 > Patrick > > > > - Original Message - > From: KV9U > To: digitalradio@yahoogroups.com > Sent: Friday, December 01, 2006 7:49 PM > Subject: Re: [digitalradio] best mode to use for weak signal HF work and other mode discussions > > > Brett, > > There are several sound card modes commonly used in addition to the most > popular PSK31 and 45 baud RTTY That would be MFSK16, Olivia, Hell, and > Throb/ThrobX. Although there are others, I rarely, if ever hear them. I > no longer seem to hear any MT-63 and the CHIP modes came and went quickly. > > I wanted to do more experimenting with DominoEX and last night I got to > work some 160 meter NVIS. We started out on MFSK16 but I have been > having a lot of problems with this mode as of late and maybe it is > because my soundcard is not calibrated correctly, but I find that I have > to use about 10 to 20 Hz offset RIT in order to print the other station. > MFSK16 really does require extremely accurate tuning of perhaps 4 Hz or > so. My rig is an ICOM 756 Pro 2 which is supposed to have very good > stability at 0.5 ppm. > > The other station and I tried some PSK31 for a short time when I lost > him on MFSK16 and was just able to get him to try DominoEX at 11 baud. > His signal was close to the noise although it was not that noisy on 160 > since we are in the winter season. The print was very poor at 11 baud, > so we dropped to 8 baud and things got better. Even at 8 baud, the speed > of transmission is still faster than MFSK16. We had a CW station come up > about 50 Hz below us and when that station was transmitting, it > drastically affected the print of the DEX mode, even at 8 wpm. The one > thing that DEX has going for it is that it is less critical to tune in. > > If often wonder if a mode that has a very wide ability to print even if > not tuned in well has to have some tradeoffs in robustness compared with > critical to tune modes. Anyone have specific information about that? > > We probably should have tried even slower speeds because later on I had > great difficulty copying him and took lots of hits. He is running Linux > so did not have the FEC version of DEX. My experience in the past was > that the Viterbi coding helps a great deal in good printing, even at 11 > baud, but of course your speed drops by all of 50% so you are just a bit > slower at 11 baud/FEC than you would be with MFSK16. > > It would be interesting to hear of other station's experience with DEX > and DEX/FEC and various speeds with and without FEC, particularly with > the lower baud rates on low band NVIS type operation. > > One of the things that I have to accept is that almost none of these > modes will work very well on the lower bands with high QRN le
[digitalradio] Re: MFSK16 tuning improvement, was:best mode to use for weak signal HF work and
Hi Patrick. Thanks for an answer. > It works on Olivia because this mode uses a transform (Walsh Hadamard), an interleaving and a pseudo-random function: so within a pack of bits defined in time and in frequency there is a very strong correlation and outside the correlation decreases rapidly. This permits to define the best band of frequencies (maximum correlation). This seems to explain the meaning of the pseudorandom sequence in Olivia to me. I am working on port of Olivia to PocketDigi, which means to rewrite everything to fixed point arithmetics again. I wonder if my old iPaq 3630 will be fast enough. > This does not exist in MFSK16 where a convolution code is used (so there is no such correlation). Moreover, the S/N measure is too much imprecise, the selection would be almost random on weak signals. As far as I know there is a metrics returned by the viterbi decoder. I still wonder what happens if the metrics is averaged in every channel and after a while the best channel is selected. You have more experience than me to guess, but I hoped you love experiments and will give it a try :-) > If you use RS ID (RX and TX), the tuning is automatic. I would like to add the RS ID feature to PocketDigi someday. This would mean to rewrite the algorithm to fixed point and optimize and I would need your source code or at least good description of the algorithm. Would that be possible, please? 73, Vojtech OK1IAK
[digitalradio] MFSK16 tuning improvement, was:best mode to use for weak signal HF work and othe
Hi Patrick. I wonder whether it would make sense to improve MFSK16 to be more easy to use. The idea is to decode multiple streams in parallel as it is done in Olivia and pick the one with the best S/N. It seems to me that Olivia is only that much popular because it is a lot easier to tune than MFSK16. 73 and GL, Vojtech OK1IAK --- In digitalradio@yahoogroups.com, "Patrick Lindecker" <[EMAIL PROTECTED]> wrote: > > Hello Rick, > > >If often wonder if a mode that has a very wide ability to print even if > >not tuned in well has to have some tradeoffs in robustness compared with > >critical to tune modes. Anyone have specific information about that? > The ability of DominoEx to be tuned very easily is that the modulation is an IFK one and not a MFSK one. It means that you measure a difference of frequency not a frequency in absolute as in MFSK. The good point it is easy to tune (no absolute reference of frequency) but the bad point is that when you do an error, the second symbol is also in error...you double the error (it's a bit like in PSK31, which one measures a difference of phase: if you do a error on one symbol, the next symbol will be also in error). > > >Can anyone say with some degree of certainly what modes you think will > >get through on the low bands with high QRN levels? > I think Olivia must be good but Contestia is more close to ideal as twice quicker than Olivia with a minimum S/N just 1 or 1.5 dB superior to Olivia. > > 73 > Patrick > > > > - Original Message - > From: KV9U > To: digitalradio@yahoogroups.com > Sent: Friday, December 01, 2006 7:49 PM > Subject: Re: [digitalradio] best mode to use for weak signal HF work and other mode discussions > > > Brett, > > There are several sound card modes commonly used in addition to the most > popular PSK31 and 45 baud RTTY That would be MFSK16, Olivia, Hell, and > Throb/ThrobX. Although there are others, I rarely, if ever hear them. I > no longer seem to hear any MT-63 and the CHIP modes came and went quickly. > > I wanted to do more experimenting with DominoEX and last night I got to > work some 160 meter NVIS. We started out on MFSK16 but I have been > having a lot of problems with this mode as of late and maybe it is > because my soundcard is not calibrated correctly, but I find that I have > to use about 10 to 20 Hz offset RIT in order to print the other station. > MFSK16 really does require extremely accurate tuning of perhaps 4 Hz or > so. My rig is an ICOM 756 Pro 2 which is supposed to have very good > stability at 0.5 ppm. > > The other station and I tried some PSK31 for a short time when I lost > him on MFSK16 and was just able to get him to try DominoEX at 11 baud. > His signal was close to the noise although it was not that noisy on 160 > since we are in the winter season. The print was very poor at 11 baud, > so we dropped to 8 baud and things got better. Even at 8 baud, the speed > of transmission is still faster than MFSK16. We had a CW station come up > about 50 Hz below us and when that station was transmitting, it > drastically affected the print of the DEX mode, even at 8 wpm. The one > thing that DEX has going for it is that it is less critical to tune in. > > If often wonder if a mode that has a very wide ability to print even if > not tuned in well has to have some tradeoffs in robustness compared with > critical to tune modes. Anyone have specific information about that? > > We probably should have tried even slower speeds because later on I had > great difficulty copying him and took lots of hits. He is running Linux > so did not have the FEC version of DEX. My experience in the past was > that the Viterbi coding helps a great deal in good printing, even at 11 > baud, but of course your speed drops by all of 50% so you are just a bit > slower at 11 baud/FEC than you would be with MFSK16. > > It would be interesting to hear of other station's experience with DEX > and DEX/FEC and various speeds with and without FEC, particularly with > the lower baud rates on low band NVIS type operation. > > One of the things that I have to accept is that almost none of these > modes will work very well on the lower bands with high QRN levels from > summer static. > > Can anyone say with some degree of certainly what modes you think will > get through on the low bands with high QRN levels? > > 73, > > Rick, KV9U > > Brett Owen Rees VK2TMG wrote: > > > All, > > > > I find that I normally use PSK31 - as that is what most other stations > > use > > and is popular. But,
[digitalradio] New digital mode proposal for CW transceivers
Hi gang. I am thinking of learning my SW+40 to talk digitally. I know of only two digital modes that may be exercised on this TRX without any hardware modification: morse and feld hell. The third possibility would be RTTY, but it would need to modify the TRX slightly. Although it may be done on SW+, the VFO pulling will be more dificult on direct conversion rigs, where the frequency shift is dependent on the frequency. The most used digital mode is still morse. The problem with computer decoded morse is that it is usually asynchronous and speed varies. Computers have great dificulty to decode morse signal under bad conditions. I know there have been some synchronous CW experiments, but the SCW mode was not widely accepted, mostly because PSK decoder may decode -3dB weaker signal. But how about modifying PSK31 software modem to send CW modulated signal? As far as my DSP knowledge goes it will be about 3dB worse than PSK31, but the signal will be wider than of PSK31. Never mind, it will be intended for QRP operation. PSK31 symbol speed is too fast for NVIS. PSK31 is hurt baddly by polar flutter. The new CW modulated mode will probably be not too much affected by polar flutter. Am I right? The speed of BPSK31 is about 40WPM. It makes sense to go down to 16 symbols per second to make the mode better for NVIS and still be usable. Or use the same symbol speed 31 and add simple FEC, for example from QPSK31, 2dB will be gained. How about that? Does it make sense to create another mode? 73, Vojtech OK1IAK Need a Digital mode QSO? Connect to Telnet://cluster.dynalias.org Other areas of interest: The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/ DigiPol: http://groups.yahoo.com/group/Digipol (band plan policy discussion) Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/digitalradio/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/digitalradio/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
