Re: [digitalradio] FCC - Spread Spectrum NPRM
El 18/03/2010 18:11, KH6TY escribió: Extensive tests on 70cm using ROS 16 baud spread spectrum have been disappointing. ROS appears to be unable to survive the Doppler shift and Doppler induced flutter so prevalent on that band. The hope was that ROS 16 baud would make traditional communications possible that were difficult on SSB phone because of the Doppler shift and flutter. However, the tests show that Olivia 32-1000, in half the bandwidth, and Olivia 16-500, produce print when ROS only prints garbage. This, together with the fact that both stations must be within 400 Hz of each other before even trying to communicate, instead of being able to tune with the mouse as is possible with Olivia, makes it very difficult to achieve a QSO on 70cm using ROS. Olivia has therefore proven to be much more successful than ROS on UHF. I was also dissapointed on HF. To me, ROS is an incomplete solution that stands no comparison to other beter designed protocols already in use. FHSS per se is not a miraculous solution. Even when having some processing gain, is not enough to stand and recover from the real world path impairments. Tests using the ROS 1 baud variation will be made next, but the slow speed of that mode is more suited to EME communications than normal QSO's. In two weeks of monitoring ROS 16 baud on 20m, there has been only one observed case where the S/N was under where Olivia 32-1000 can decode, so even on HF, there does not appear to be any justification for using such a wide mode, even if spread spectrum were permitted on HF in the US. Just use Olivia or MFSK16 instead when band conditions are poor. The new narrow band ROS modes were not tested, since a mode to do better than Olivia is what is needed, and the spread spectrum mode of ROS held the best hope. As it stands, only CW is better than Olivia under the worst conditions, and only when copying by ear, but CW is only a little better than Olivia 16-500. We have also found that the more narrow Olivia modes (i.e. 500 Hz wide) are also too greatly disturbed by Doppler to be useful either. Perhaps what is needed is a variant with wider tones/bins, modulated at a higher speed, so path perturbations have a lesser effect. Have you tried higher bandwidth and less tones ? Maybe you can find a better compromise (it will always be a compromise, I believe) that way. If anyone is within 200 miles of FM02, has 100 watts and an antenna gain of 17 dBi or greater, and would like to try ROS 16 baud on UHF, I am available to do that. I promised to post the results of our attempts to use ROS on UHF on this reflector, and this is what we have found. So, it looks like Olivia is currently still the best digital mode to use on UHF, VHF, or HF for normal (not EME) digital QSO's. Skip, please do tell us. I am particularly quite curious about the results of your tests. 73, Jose, CO2JA
Re: [digitalradio] Re: Question for experts
El 10/03/2010 7:57, g4ilo escribió: What does ROS gain by using SS over another mode that carries the same amount of data at the same speed using the same bandwidth and the same number of tones but uses an entirely predictable method of modulation? Processing gain. Signals correlated with the hopping sequence add up, non correlated signals do not add up. It does not mean that SS is not a predictable modulation method, you just need to know the key, in the USA, the key must be one of a few specific codes, and if you don't have the key, security by obscurity applies. 73, Jose, CO2JA
Re: [digitalradio] Re: Question for experts
El 10/03/2010 10:51, KH6TY escribió: Jose, If you were going to design a mode that filled 2200 Hz, but did not use SS, and was as sensitive as possible in that bandwidth, how would you do it? Tough question. I believe that on HF the best solution so far is Pactor-III It would have to be highly resistant to fast Doppler shift also, but minimum S/N would be the most important parameter, as it would be used at UHF. So far, Olivia 16-500 seems to be the best compromise between minimum S/N and Doppler shift survival at UHF. The more narrow Olivia modes, even though more sensitive, do not decode as well if there is noticeable fast Doppler shift, and sometimes, not at all. As you add more tones the bin width reduces. The only hope I see is using wide bins to accomodate Doppler, and perhaps, more tones, but that is not possible with 3 kHz radios. Perhaps it is a task for some SDR. I believe wider modes are not a problem in UHF. It may take more CPU power, and higher powered radios for simultaneous tones. DominoEx is completely destroyed by the Doppler shift Doppler is parasitic noise to DominoEx... and MFSK16 is not tolerant enough to drift to be usable at UHF. MT63-2000 covers 2000 Hz, has highly redundant FEC, but the minimum S/N is only -2 dB, so that is not an alternative. Both seem to have been designed for HF, and MT63 seems to require a single ray dominant path. At times it works well, but I have not had luck with MT63, overall. MT63 has many carriers and narrow bins, not good for multipath with doppler. What I am looking for is a mode that will copy under the visible and audible noise on UHF during deep fades, but survives fast Doppler shift. Olivia 16-500 makes it down to the noise, but not under, during deep fades. CW by ear is just slightly better than Olivia 16-500, and the note is very raspy sounding - much like Aurora communications. But CW requires well trained operators... There is a paper by Tim Giles about multitone modems for high latitude HF paths (PhD publication in Sweden) and he avoided sending in contiguous bins in wide Doppler spread conditions, and reassigned contiguous bins on the side to have a wider hat to catch the path shifted tones. That sacrifices thruput, but nevertheless, it is worthless to push nature. In that case, it is better to become its ally, and to me, wider spaced tones and reusing contiguous bins seems a good idea. I read it a long time ago and maybe I am not remembering all details, but it was interesting enough so I haven't lost the big picture. The 3 kHz channel limit on HF is a straitjacket that might be avoided on VHF - UHF if clear frequencies are available and you need speed. Another observation - most stations I copy on ROS 16 are reading a metric of -12 dB or greater. Only once have I copied a station (using 1 baud ROS) that was measuring a metric under -25 dB. Is the ROS metric supposed to correlate with the path S/N? I ask this because even the weakest ROS tones at 1 baud are still visible on the waterfall, whereas weak Olivia 32-1000 signals with a -12 dB minimum S/N stop decoding just about the time the tones become hard to see in the noise, but still can be heard faintly. It is a long way from even -25 dB S/N to -12 dB S/N, so I would expect if the metric is just another way to say S/N, I would not be able to see the tones, yet I can, and not only on the ROS waterfall, but on the DigiPan waterfall as well. I really don't know what does METRIC mean in the ROS case, Skip. I really did not pay much attention to it, as most times there was packet or pactor QRM, being ROS so wide. What caught my attention is how bad it performs under QRM, having seen Olivia 500-16 under similar conditions unaffected. I believe I know the reasons, as you may as well know, but won't elaborate further about it on this list. 73, Jose, CO2JA
Re: [digitalradio] Re: Question for experts
El 09/03/2010 17:11, rein...@ix.netcom.com escribió: Hello Jose, Multiple Frequency Shift Keying, OK, but you really did not answer my question, I think. Suppose I replaced the modulation device with a filtered piano ( no harmonics ) a microphone. I am serious, trying to find out the question we can't address here any longer. I used a x-tal oscillator. Limited my BW to some 300 Hz 73 Rein W6SZ Rein I failed to see the twist and I still do not see what you are after. I took My Way (MP3), played on the piano by Richard Claydermann, and processed it with Audacity, mixing it to mono, resampling to 11025 Hz, saved it as wav, and played it back thru both Spectran and HDWinrad, one at a time, both very steeply filtered, and what you hear are pings, tingling noises with a very slight trace of musicality. There are also some harmonics of the lower frequencies that bleed thru the filter, since their spectrum falls in the selected bandpass. Can you give any further hints? You might reproduce that yourself, without spending a lot of money and waiting for your filter to be made. 73, Jose, CO2JA
Re: [digitalradio] Re: Question for experts
El 09/03/2010 21:15, rein...@ix.netcom.com escribió: Sorry Ralph, I did not read the header. 3 Rein W6SZ -Original Message- From: Ralph Moweryku...@yahoo.com Sent: Mar 10, 2010 12:25 AM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Re: Question for experts If you are doing what I think, you have just built a complicated CW transmitter. Start with a crystal oscillator, go to a ballanced modulator and then filter out one sideband. This is similar to how cw is often generated in a SSB transceiver. Well, actually FSK or ASK of two tones is hard to tell from each other on the air. A friend built such a modem, I contributed a couple of ideas, using ASK with TTL logic to key a solid state laser from a crystal derived clock. The optical link worked flawlessly. What you see as result of using your example are random frequency and amplitude tones in the spectral display, sometimes simulteneously, sometimes, not. So, what? 73, Jose, CO2JA
Re: [digitalradio] Re: JT65A harmonics
El 06/03/2010 14:53, Rein A escribió: Hello Jose, I always set the sound card volume, the modulation, that when changing the volume setting, the output of the transmitter will follow in a linear fashion. This is very important in particular for WSPR and WSPR-QSO modes. 73 Rein W6SZ I do likewise. My homebrew interface has no variable adjustments at all, and I do all the settings in the computer. I use a professional (even when small) 600:1 transformer, backwards, so it acts as an attenuator, towards the radio mic input. I use a small pot core ferrite transformer as 1:1 ratio isolator, loaded with 1200 ohms and 2.2 nF to get the least overshoot in the square wave edges. Even when I am going to send mostly sinewaves (band pass, 300 to 2700 Hz audio), it gives a measure of received bandpass flatness. That is the radio to PC channel. I noticed a slight hiss/harshness in the highs reduction in the PC speakers when the transformer stopped ringing. I listen thru my 2.1 speaker set, which sounds better. I use a 4N26 optoisolator with a red LED in series (visual PTT indicator) shunted by a reverse connected 1N4007 that was at hand, to protect the LED and optocoupler, and a series resistor I believe is a 2.2 K resistor (do not remember clearly now). All the paths are isolated, but the PC and radio PSU are connected to ground, a couple of rods and a big old truck radiator buried in the garden.My metal desk is also tied to ground, which allows me to work with static sensitive components with total confidence. I have done eventual envelope checks with my oscilloscope (a -40 dB tap in the SWR probe), to make sure there is no envelope clipping at normal levels. I also check routinely the tx level when I change bands. I built a PEP (peak holding) SWR indicator, and always look for a slight decay in the output while setting the soundcard output. It assures me there is no clipping in the chain from the soundcard to the antenna. I usually do that with the TUNE button of MultiPSK. 73, Jose, CO2JA
Re: [digitalradio] Re: ARRL/FCC Announcement about ROS
El 06/03/2010 19:44, iv3nwv escribió: Jose, if you are referring to me I'm not saying that theoretically it is correct to use as much bandwidth as possible. This is a conclusion you have drawn on your own. Using a 100 kHz bandwith to communicate information at a rate of 1 bit/s could by sure approach any channel capacity, but the spectral efficiency of such a communication channel would be quite questionable. Let this option to NASA deep space communications. What we need are modes which are both power AND bandwidth efficient. I think that the term spread spectrum here is misleading. What's the difference between a communication system which uses a FEC code with a very low rate, say R=0.01 (one information bit per one hundreds symbols), and a communication system which hops or spreads the modulating signal on an equivalent bandwidth? In my opinion: NONE. Both systems are using a bandwidth which is one hundreds time the bandwidth which would be used by an uncoded system. The problem is not whether a system is spread spectrum or not. The problem is how much it is bandwidth efficient. Everyone knows that an ortoghonal signalling system approaches the (AWGN) channel capacity. The legitimate question is if the whole 20 m band should be used to achieve such a result to communicate information at 3 bit/s. For what I know ROS has a really poor bandwidth efficience nor it copes with MUI (multiuser interference) issues. I do not doubt that it can achieve an exciting performance under the power efficiency point of view, but that's not all. We are called to develop systems which are efficient also in respect to bandwidth. The spread spectrum story is just a bad motivation used against true concerns. 73s Nico, IV3NWV Nico, Excuse me if I misunderstood it. I believe it is theoretically correct, but not always practical nor possible. For one, I agree that it is incorrect to run over a whole crowded band like 20 meters. You have a point too nobody had made me to stop and think about. FEC or UWB in whatever way, carried to the extremes, are two sides of the same coin. On crowded spectrum, efficiency certainly counts. Nevertheless, it is a complex issue, because I also believe that unprotected systems, like packet has traditionally been is also a waste of bandwidth when a single lost bit sends, say, 255 bytes to trash. As usual, the solution may hardly be on the extremes. 73, Jose, CO2JA
Re: [digitalradio] Re: IF someone PURPOSELY has tried to mislead me
El 05/03/2010 13:15, g4ilo escribió: Someone really should try to find out whether_this_ Jose has a call. Because if he isn't a licensed ham he hasn't much to lose by any trouble he causes. I did try, but failed. But if he has a call, why does he keep it a secret? Julian, G4ILO No, that is no secret, he has no callsign. 73, Jose A. Amador, CO2JA --- Date: Wed, 24 Feb 2010 09:59:50 + (GMT) From: jose alberto nieto ros nietoro...@yahoo.es Subject: Re: [digitalradio] Re: Consensus? Is ROS Legal in US?` To: Jose A. Amador ama...@electrica.cujae.edu.cu In-Reply-To: 4b848deb.9080...@electrica.cujae.edu.cu MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=0-1835158209-1267005590=:11831 X-RCPT-TO: ama...@electrica.cujae.edu.cu Status: U X-UIDL: 520590980 --0-1835158209-1267005590=:11831 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Soy Ingenerio de Telecomunicaciones pero no soy radioaficionado ni trabajo en ninguna Universidad.
Re: [digitalradio] Re: ARRL/FCC Announcement about ROS
El 06/03/2010 4:49, rein...@ix.netcom.com escribió: I thought, that there has to be a direct specific connection between the transmitter and the receiver on how to retrieve the info from the spread spectrum. ( SS for dummies ) This makes it useful for the militairy, for who it was originally designed and in the case of cell phones, for instance, the code recovery algorithm is programmmed in the system, not secret, I assume, but still hard to figure. I thought cell phones run over 1,5 Mhz wide spreading. Is this true? I for one have never thought or learned much about SS. ( 75 yrs and retired and I am sure some will say you know what ) 3000 Hz info band - 1.5 10 e+6,Hz ? Anyway what is so frustrating to me here, is that I do not see a straight definition of SS written in a published book that I can cross reference. Carlson, Bruce, Communications Systems, Chapter 15 Spread Spectrum Systems, p 671, Mc Graw Hill 2002 I have the ARRL SS source book, and there, all I can find is that SS spreads the info band width between 10 and 100 times. Also I thought if one looks with a Spectrum Analyzer,( I have never done that, ) to a SS signal, is is hard to see the side bands. Signals so weak and so random, perhaps semi- that one can have a large number of those side bands from different transmitters overlapping without causing problems in the communication process. It should be that way. But ROS has insignificant spreading when compared to what has become publicly known about SS (i.e., 802.11). Just a INCREASED noise level, that would seriously be a problem for EME, for instance, it would cover up the natural background or with other words, increase the noise temperature, Now here you have a few simple concepts, it is crazy talk yes or no? Please feel free to tell your views with a basis, where I can look it up myself. I asked before for a peer reviewed paper SS for laypersons or dummies I do only WSJT on HF and on EME as group member, please someone explain to me why WSJT is, what? JT65A is MFSK with a heavy block coding scheme and high redundancy. It is NOT spread spectrum. It appears to be legal? Yes, it is NOT SS and occupies some 170 Hz. It is WELL DOCUMENTED by Dr. Joseph Taylor, K1JT, a Nobel Prize Laureate and Princeton Professor. What is the difference between JT65C and ROS when it relates to the SPREAD Spectrum properties, Apples and oranges. ROS does not quite reach the level of sophistication of WSJT, within the bounds allowed to hams in the US. WSJT has a smart and efficient info packing scheme that makes it pretty much an all or nothing system. ROS, produces a lot of errors, if the signal strenght goes down after the start, but that is not a SS issue, Certainly not. ROS is a baby compared to JT65 robustness. Please explain to me and perhaps quite a few others what SS is, other than that is Wide Im my own mind the width has not really too much to do with it? True or false. Ideally, SS should be of infinite bandwidth, which is not viable in practice. As you reduce it to a practical, allowable level, its magic properties lose strenght, be it direct sequence or frequency hopping. Theoretically, FH should have a very small dwell time, but then again, to contain at least 90% of the spread message sidebands in a 3 kHz bandwidth makes it not undescernible from noise. All straight layman's questions, so who answers them, most of us like to learn and understand a little. 73 Rein W6SZ 73, Jose, CO2JA
Re: [digitalradio] Re: ARRL/FCC Announcement about ROS
I agree with Nino, theoretically it is correct to use as much bandwidth as possible, 3 kHz in the ROS case, but due to the small spreading, the ROS signal does not have a negligble level compared to others on the channel, so it is a halfbreed, it has spread spectrum characteristics, but does not quite behave like the pure definition. ROS still had problems in version 1.6.3 and it is easy to notice that it works in a free channel, but does not stand burst errors (in fact, errors long as a packet or pactor frame length) and its ability to copy crumbles. That does not happen, at least so noticeably, with JT65 or Olivia. 73, Jose, CO2JA El 05/03/2010 20:22, iv3nwv escribió: Julian, thanks for your comments. Yes, laws are laws. Also the Hammurabi rule If a man puts out the eye of an equal, his eye shall be put out was a law but I don't think that it would be of great help in our modern society. I agree with you that simulations should be performed prior to any other on air experiment. I think that this is already a common practice nowadays or at least that nobody interested in a serious development would omit to perform it today. I also agree that amateur bands are not just an experimenter's playground but this implicitly means that they are not exclusive to communicators. If I were an experimenter I would like to see acknowledged my right to make my experiments somewhere in our bands. I would have no interest interfering other users activity, I would just need a portion of the spectrum where me or other amateurs on the other side of the Atlantic Ocean were not considered criminals just because we are validating a model on the field. I don't agree that we should use modes which have already been invented and stop looking for new ones. Research and development in communications and in information theory are everything but dead. Turbo codes were submitted to the attention of the research community just fiftheen years ago, when many had already missed the hope that the Shannon channel capacity could be really approached. Should Berrou, Glavieux and Thitimajshima have made more use of what had been already invented instead of experimenting what had not be done yet? And what about those who dedicated their time inventing new efficient algorithms to decode LDPC (or Gallager's) codes, as David MacKay did few years later? Koetter (unfortunately passed away at a still young age), one of the two researchers who found an algebraic soft decision method to decode better than before the Reed-Solomon codes, as those used in Joe's JT65, published his work in 2003 or so. Should we have stopped our alternatives to knowledge and technologies available in 2002? I don't think so. We should better keep up with news and new modes. Nico, IV3NWV
Re: [digitalradio] The cost of digital mode interfaces
El 06/03/2010 8:34, Andy obrien escribió: I was helping a ham get set-up for digital modes recently and turned to the issue of interfaces for digital modes. I researched the price for a Rigblaster Pro and was shocked that they sell for $299. My friend settled for another interface that cost $69, new. I was wondering about interfaces and wondering about whether the era of high priced interfaces might be coming to an end. I'm not talking about the ones that have extra features like electronic CW keying, high end soundcards , etc etc. I'm thinking that a device that has connectors, isolation circuits, pots, and a good solid enclosure, should be in the under $100 range. I know you can build your own for $20 or so, It is nice to see that many low price options exist nowadays. Andy K3UK Mine is built using scrounged components, mostly. 1) A good quality japanese professional audio 10 k : 600 ohms transformer. Connected as step down, it doubles as an attenuator. Loaded with a 600 ohms resistor in the secondary. 2) Several 1:1 transformers. The last one I am using is ferrite pot core recovered from a dead modem, loaded with 1200 ohms and 2.2 nF in series gives insignificant square wave ringing on the edges when tested with audio generator / oscilloscope. 3) A 4N26 optocoupler with a red LED is series and a 2.2 k resistor. Also has a reverse bias protection shunt diode (1N4007 that was at hand) over the LED + optocoupler diode string. All contained in a small plastic box, from a discarded battery charger. I only paid for the new all metal stereo miniplugs that go to the PC soundcard. In use for at least a couple of years already. 73, Jose, CO2JA
Re: [digitalradio] What is SS? Senor Ros is not an honest person !
On Sat, Mar 6, 2010 at 9:12 AM, Arnaldo Coro acoro33...@yahoo.com wrote: So, amigos at digital radio , my advise , and that's what I am going to do, is to alert ROS users of the possibility that the author of the software may even be attempting to use it for other purposes that are not related to amateur radio... Yep, the dark side may be lurking. Ham transceivers are not used only by hams, so it may as well apply... Jose, CO2JA
Re: [digitalradio] A question about spread spectrum
El 06/03/2010 9:01, KH6TY escribió: The other possible problem is wide-spreading spread spectrum. There was a failed attempt about 5 years ago by the ARRL HSMM (High Speed Multi-Media) proponents to allow spread spectrum on the HF bands with the argument that the signal is spread so widely, each carrier appears at any given frequency only a short time, so it would not significantly interfere with other users of the frequency, and could, for example, be allowed to cover the entire 20m band. However, that assumes only one FHSS signal at a time. I think if you put on many at one time, in the resulting aggregate, there could be continuous interference over the entire width of the spectrum spread, since the spreading is pseudorandom. You can see what happens when just more than one ROS user tries to use the same frequency. They interfere with each other. That is affectively a limit with CDMA cellphones. Even when using different codes, they are not 100% orthogonal and the result is a degradation of SNR. It requires a multiplicity of non overlapping cells and automatic power control to be viable. Using a single coding sequence, access method such as those used in packet to share the channel should be enforced as well. Not a simple matter, as the hidden station is a concrete fact. 73, Jose, CO2JA
Re: [digitalradio] JT65A harmonics
El 06/03/2010 11:28, g4ilo escribió: I was listening down around 14.077, just above some slow FSK mode which I think is JT65A. The JT65A was tuned quite low pitched in my receiver, and I could clearly see images of it over to the right. Judging by the spacing of the image tones I was seeing an audio third harmonic of the original signal. The image tones were clearly visible and would have been copyiable in their own right if not for the 3x spacing. My transceiver is a K3 and the signal was just an S9 so overload or intermod are unlikely to be the issue, but to make sure the images weren't being generated this end I tuned in some strong RTTY and found no harmonic images of the signal. Has anyone else seen this? Aren't the tones supposed to be generated at such a frequency that any harmonics are cut off by the SSB filter? Julian, G4ILO I have not seen that particular case. But the radio should be driven at a reasonable lever where harmonics or unnaceptable IMD products are not created. A SDR, becoming so common nowadays, cannot rely on the filtering of hardware radios. Jose, CO2JA
Re: [digitalradio] JT65A harmonics
No, and sorry if I misled anyone. I do have both WSJT and MultiPSK, I nowadays use MultiPSK mostly for HF, but I have actually not come across such a case particularly with JT65. Of course it has been more than usual for some particular ops on 14070, but in spite of the apparent simplicity, even PSK31 is not plug and play stuff like a key and a CW transmitter used to be in the past, it takes a bit of knowledge to get an SSB transceiver with a clean soundcard mode signal on the air. 73, Jose, CO2JA PS: There is more I would like to do than the available free time allows lately for me. --- El 06/03/2010 12:20, rein...@ix.netcom.com escribió: Hello Jose, This was clearly a case of overloading, most likely on the transmitter side, over driving perhaps the sound card or the transmitter being over loaded by the sound card's signal. The K3 is too good a receiver, but it is part of your receiving chain. Properly running WSJT should not show it and as a full time WSJT operator, I have rarely seen it, recently at least, It is of course not my business, but I am surprised that you have no WSJT capabilities, it seems. 73 Rein W6SZ -Original Message- From: Jose A. Amadorama...@electrica.cujae.edu.cu Sent: Mar 6, 2010 8:54 AM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] JT65A harmonics El 06/03/2010 11:28, g4ilo escribió: I was listening down around 14.077, just above some slow FSK mode which I think is JT65A. The JT65A was tuned quite low pitched in my receiver, and I could clearly see images of it over to the right. Judging by the spacing of the image tones I was seeing an audio third harmonic of the original signal. The image tones were clearly visible and would have been copyiable in their own right if not for the 3x spacing. My transceiver is a K3 and the signal was just an S9 so overload or intermod are unlikely to be the issue, but to make sure the images weren't being generated this end I tuned in some strong RTTY and found no harmonic images of the signal. Has anyone else seen this? Aren't the tones supposed to be generated at such a frequency that any harmonics are cut off by the SSB filter? Julian, G4ILO I have not seen that particular case. But the radio should be driven at a reasonable lever where harmonics or unnaceptable IMD products are not created. A SDR, becoming so common nowadays, cannot rely on the filtering of hardware radios. Jose, CO2JA
Re: [digitalradio] ROS carrier pattern when idle
No, I have not, because Olivia is usually found in different frequencies than those where packet activity is found on this side of planet Earth, and in general, packet sysops and Olivia users know their way around and do not step over others toes. Very seldom I have experienced Olivia to Olivia QRM, I have heard the other's tones showing up near to the frequency I have been using, it has shown up on the waterfall but it did no impairment to reception. I have to add that I only have copied one side of the other's QSO, so it is quite likely that he did not hear my correspondent either. Nothing to create fuss about. El 26/02/2010 18:06, jose alberto nieto ros escribió: have you tested what happen if Olivia is tx over other Olivia? or over packet?
Re: [digitalradio] Re: GTOR- has anyone tried this?
I used: System Info for Windows v1.67 (Build 626) --- March 17, 2007 Freeware Version -- Copyright © 2004-2007 Gabriel Topala to determine which is the device number. In my case, receive card (Audigy 2) is device 9 and transmit card (AC-97) is card 1. In my case, setting 0 in my configuration blocked the GTOR program. I am still to connect to someone... 73, Jose, CO2JA --- El 23/02/2010 15:37, Steinar Aanesland escribió: Hi I think 0 is the default sound card . 1 is the next etc. 73 de LA5VNA Steinar On 23.02.2010 21:29, graham787 wrote: ??? running win-xp-pro with out board usb sound as well as mother board sound .. how do I select usb card .. can only see number box , sound seems to come from main sound card ..how can you work out what 'number' a sound card is ?? comport tx is fine Tnx - G .. --- In digitalradio@yahoogroups.com, obrienajk3uka...@... wrote: It works , Sholto. I am able to get PTT working and generate tones. Anyone for G-Tor? Andy K3UK --- In digitalradio@yahoogroups.com, obrienajk3ukandy@ wrote: Interesting. The about info reveals Mixw 2003. I also found this G-TOR (Golay -TOR) is an FSK mode that offers a fast transfer rate compared to Pactor. It incorporates a data inter-leaving system that assists in minimizing the effects of atmospheric noise and has the ability to fix garbled data. G-tor tries to perform all transmissions at 300 baud but drops to 200 baud if difficulties are encountered and finally to 100 baud. (The protocol that brought back those good photos of Saturn and Jupiter from the Voyager space shots was devised by M.Golay and now adapted for ham radio use.) G-tor is found in only one manufacture's TNC and is rarely used today. --- In digitalradio@yahoogroups.com, sholtofishsholto@ wrote: Came across this the other day: http://db0lj.prgm.org/boxfiles/software/Gtor.zip Looks like it's a sound card implementation of G-TOR?? Seems to have a butterfly icon so something to do with MixW?? Does it work? Try Hamspots, PSKreporter, and K3UK Sked Page http://www.obriensweb.com/skedpskr4.html Suggesting calling frequencies: Modes500Hz 3583,7073,14073,18103, 21073,24923, 28123 . Wider modes e.g. Olivia 32/1000, ROS16, ALE: 14109.7088. Yahoo! Groups Links -- MSc. Ing. Jose Angel Amador Fundora Profesor Auxiliar Departamento de Telecomunicaciones Facultad de Ingenieria Electrica, CUJAE Calle 114 #11901 e/ 119 y 127 Marianao 19390, Ciudad de la Habana, Cuba Tel: (53 7) 266-3445 Email: amador at electrica.cujae.edu.cu
Re: [digitalradio] Curious sound card modes question -
Nothing is altered. In a SSB transmitter, amplitudes are scaled (usually UP) and frequencies just shifted. So, if audio tones change frequency, RF tones do likewise. 73, Jose, CO2JA --- El 22/02/2010 18:04, John escribió: So as to not continue growing the ROS legality discussion even further, I would like to ask a fairly simple question. How will the modulation be determined from any SSB transmitter when the source of the modulation is via the microphone audio input of that transmitter? Simply stated, how would any digital mode create anything other than some form of FSK simply by inputting a tone at the microphone input? Regardless of the software being used to generate the tone(s), at any given time there is nothing more than the absence or presence of a tone at the audio input of the transmitter. This is true of HRD's DM780, MixW modes, MMSSTV, or many other sound card driven software packages. They all have one thing in common, they generate a sequence of tones which is then processed by the very same transmitter in the very same way. The maximum output bandwidth is supposed to be somewhat limited in the bandpass of the transmitter circuitry (which is NOT being altered). Again, NO transmitter circuitry is being altered in any way that I am aware of. With this discussion, how do we arbitrarily change the transmitter output definitions? I am truly asking because that is a concept beyond my feeble mind. I really do not know. To me, regardless of the source of the modulation itself, the modulation still remains an offset of the carrier frequency by the frequency of the input tone. To me, the discussion of particular FCC designators for any of these modes is rather moot, unless there is some method to tie the two together. To simply start an argument about a particular FCC rule, without showing the correlation to the subject is somewhat like arguing the color of orange peels in an apple pie instruction sheet. They simply don't necessarily relate. Both may have valid points about their own arguments, but the tow simply do not go together. Am I missing something besides a few marbles now? My head is spinning from all these rules being bandied about, that may have no application here at all. John KE5HAM
Re: [digitalradio] A closer look at ROS]]
ROS is one voice channel wide, it seems to have been conceived for a 3 kHz wide voice channel, as usual with SSB radios. Its width is comparable with accepted modes like MT63 or Olivia xx:2000. It is not an automated mode, it is meant for keyboarding. Its spectrum spreading is hardly the way WiFi works, nor the hopping mode of some HF tactical radios. It is not the way spread spectrum is defined in my paper bound 1986 ARRL Handbook or Operating Manual. There is nothing secret with it as far as I have seen, if you have the public program. I have not seen the specs, but I have watched it in a loopback connection using Spectran. I have the pictures stored in my HD. Limits in nowadays technology are more complex, or fuzzier, perhaps. But ROS is neither wider than a voice channel nor an automated mode. Of course, it is ALWAYS a 3 kHz wide channel, and should be accomodated accordingly, say, like Olivia xx:2000. And I agree that in legalese, the wording is extremely important. A badly worded claim may do more damage than obtaining meager benefits. 73, Jose, CO2JA
Re: [digitalradio] Puppy Linux anyone ?
I installed both the Puppy and Knoppix versions and did very well from hard disk, as far as you can go with a Live CD. Particularly, Knoppix worked very well with Wine and Windows software. It was a nice experience. 73, Jose, CO2JA -- Rein Couperus escribió: Russell, As soon as fldigi-3.13 is released i will make a new puppy iso... Rein PA0R Thanks Alen, I might do the same thing, I;m also looking how ot update programs within puppy linux, it would be smaller than a CD. Thanks Russell NC5O -- MSc.Jose Angel Amador Fundora Profesor Auxiliar Departamento de Telecomunicaciones Facultad de Ingeniería Electrica, CUJAE Calle 114 #11901 e/ 119 y 127 Marianao 19390, Ciudad de la Habana, Cuba Tel:(53 7) 266-3445 Email: ama...@electrica.cujae.edu.cu Participe en Universidad 2010, del 8 al 12 de febrero de 2010 La Habana, Cuba http://www.universidad2010.cu - SEGUNDO SEMINARIO INTERNACIONAL LEGADO Y DIVERSIDAD. ARQUITECTURA Y URBANISMO. El rescate de los valores urbanos y arquitectónicos en tiempos de globalización Colegio de San Gerónimo, La Habana Vieja, noviembre 24-27, 2009 - Suggested frequencies for calling CQ with experimental digital modes = 3584,10147, 14074 USB on your dial plus 1000Hz on waterfall. Announce your digital presence via our Interactive Sked Pages at http://www.obriensweb.com/sked Yahoo! Groups Links * 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: digitalradio-dig...@yahoogroups.com digitalradio-fullfeatu...@yahoogroups.com * To unsubscribe from this group, send an email to: digitalradio-unsubscr...@yahoogroups.com * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: [digitalradio] Nominations for 2009 Digitalradio Awards needed
I also agree. Please count my vote for Patrick. Jose, CO2JA --- Warren Moxley escribió: Patrick is the greatest! I 2nd that nomination. --- On *Sun, 12/6/09, Ian Wade G3NRW /g3...@yahoo.co.uk/* wrote: From: Ian Wade G3NRW g3...@yahoo.co.uk Subject: Re: [digitalradio] Nominations for 2009 Digitalradio Awards needed To: digitalradio@yahoogroups.com Date: Sunday, December 6, 2009, 11:02 AM From: Andy obrien k3uka...@gmail. com /mc/compose?to=k3ukandy%40gmail.com Date: Sun, 6 Dec 2009 Time: 11:11:22 It is that time again, as we approach our 10th January in existence it is time to seek you nominations for the Annual Digitalradio Awards. [Snip] My vote goes to Patrick -- his innovations and responsiveness to user requests are a shining example of the true amateur spirit. -- 73 Ian, G3NRW
Re: [digitalradio] Is there a convention for stereo phone plugs?
Look for The Hardware Book, by Joakim Ögren in http://www.hardwarebook.net/. It is a manual for many connectors, cables and buses, including PC's and home audio and video. And yes, there is a standard, the tip is the left channel. 73, José, CO2JA --- Chris Robinson escribió: Tip is generally left side audio so as to conform and work when placed in a mono jack. ring is right and body is ground. As for a convention, not sure I know they have them for Trekkies, that is one stereotype! Have a nice weekend and hope that helps. On Fri, Nov 27, 2009 at 4:14 PM, jhaynesatalumni jhhay...@earthlink.net mailto:jhhay...@earthlink.net wrote: I've never known if there is a standard for whether tip or ring is left or right channel. And is left or right normally used for the computer DSP radio software?
Re: [digitalradio] RSID numbers
I have not used MixW in a long time and my memories might be a bit innacurate, but in MixW you set the basic modulation and choose the arguments in a cascading menu. Say, you choose RTTY, and in the modem configuration you choose shift and speed. On PSK you may choose the signalling speed, and so on.I believe Same with Olivia, choosing BW and tones. I believe FLdigi is equally capable of doing so, but I have used it ocassionally as it is distributed, off the box. I am afraid that to cover all bases you must use a modulation code with additional arguments, as a limited nunbers pool may not be able to describe all variants. It has a cost, a longer RSID which is likely to be not welcome. A solution I would like is not mess with what works and assign a longer code for rarer, not yet described modes.Of course, it would require a new RSID protocol version. Just a suggestion. 73 Jose, CO2JA --- Rein Couperus escribió: I have the patches for fldigi ready, only waiting forthe numbers... 73, Rein PA0R -Ursprüngliche Nachricht- Von: Patrick Lindecker f6...@free.fr Gesendet: 22.10.09 20:16:40 An: digitalradio@yahoogroups.com Betreff: Re: [digitalradio] RSID numbers Hello Rein, BPSK500, BPSK1000, QPSK500 and QPSK1000? Are these modes on Fldigi or DM780? If so, there were no demand for these modes, so no RS ID numbers given. It can't be given RS ID numbers if the modes don't exist in any of the softs able to decode RS ID. 73 Patrick - Original Message - From: Rein Couperus r...@couperus.com To: digitalradio@yahoogroups.com Cc: linux-...@yahoogroups.com Sent: Thursday, October 22, 2009 5:31 PM Subject: [digitalradio] RSID numbers What are the RSID numbers for BPSK500, BPSK1000, QPSK500 and QPSK1000? Does anybody know? 73, Rein PA0R -- http://pa0r.blogspirit.com Participe en Universidad 2010, del 8 al 12 de febrero de 2010 La Habana, Cuba http://www.universidad2010.cu - SEGUNDO SEMINARIO INTERNACIONAL LEGADO Y DIVERSIDAD. ARQUITECTURA Y URBANISMO. El rescate de los valores urbanos y arquitectónicos en tiempos de globalización Colegio de San Gerónimo, La Habana Vieja, noviembre 24-27, 2009 - 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 * 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:digitalradio-dig...@yahoogroups.com mailto:digitalradio-fullfeatu...@yahoogroups.com * To unsubscribe from this group, send an email to: digitalradio-unsubscr...@yahoogroups.com * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: [digitalradio] QRV RFSM-8000 tonight
I called and beaconed using v. 0.536 on 7077.0 KHz USB and nothing happened. Jose, CO2JA obrienaj escribió: I will be operating RFSM-8000 tonight around to 0200 probably around 7077 or 14077 depending on conditions. I will beacon occasionally and try to remember the baud rate limitation that USA ham have to follow. Hopefully I can test a few transfers with someone. Andy K3UK Participe en Universidad 2010, del 8 al 12 de febrero de 2010 La Habana, Cuba http://www.universidad2010.cu - SEGUNDO SEMINARIO INTERNACIONAL LEGADO Y DIVERSIDAD. ARQUITECTURA Y URBANISMO. El rescate de los valores urbanos y arquitectónicos en tiempos de globalización Colegio de San Gerónimo, La Habana Vieja, noviembre 24-27, 2009 -
Re: [digitalradio] pse help id this mode
Marco, I usually run MultiPSK 4.14 for JT65, so, just press the proper button (JT65), select JT65A, left click on the sync tone (the extreme left limit of the signal on the waterfall). Besides, your computer must be synchronized to UTC somehow (from the Internet, a GPS, or a radio standard like WWV, WWVB. CHU, DCF77,etc).I use CHU with Clock, tuning 14670 or 7850 kHz, it is the best of them by far from here. 73, Jose, CO2JA --- Marco IK1ODO escribió: At 22.22 06/09/2009, you wrote: Usually JT65A can be found there. It can be decoded using the WSJT software, by K1JT. Dave thanks to all - I will give it a try. 73 - Marco IK1ODO __ Información de ESET NOD32 Antivirus, versión de la base de firmas de virus 3832 (20090206) __ ESET NOD32 Antivirus ha comprobado este mensaje. http://www.eset.com Participe en Universidad 2010, del 8 al 12 de febrero de 2010 La Habana, Cuba http://www.universidad2010.cu - SEGUNDO SEMINARIO INTERNACIONAL LEGADO Y DIVERSIDAD. ARQUITECTURA Y URBANISMO. El rescate de los valores urbanos y arquitectónicos en tiempos de globalización Colegio de San Gerónimo, La Habana Vieja, noviembre 24-27, 2009 -
Re: [digitalradio] Talking JT65A via Multipsk
I do that a lot, particularly when I put that screen on the background to do something else on the computer. Very useful !! Jose, CO2JA --- Andrew O'Brien escribió: Just a reminder, with Multipsk and in JT65 modes, try clicking on the VOCALIZATION button. With that pressed (and your speakers on) when your software decodes 14:447 -09 1 +0244 CQ VA6SZ DO33 D=2757 Km (1713 mil.) Az=308° The CQ VA6SZ DO33 part will be spoken aloud ... you can be in the next room and find out who is calling. My shack is quite active today. Multipsk just announced VA6SZ calling and Joe DX in Spotcollector is letting me know via voice announcement Malta is on 17M RTTY. __ Información de ESET NOD32 Antivirus, versión de la base de firmas de virus 3832 (20090206) __ ESET NOD32 Antivirus ha comprobado este mensaje. http://www.eset.com Participe en Universidad 2010, del 8 al 12 de febrero de 2010 La Habana, Cuba http://www.universidad2010.cu - SEGUNDO SEMINARIO INTERNACIONAL LEGADO Y DIVERSIDAD. ARQUITECTURA Y URBANISMO. El rescate de los valores urbanos y arquitectónicos en tiempos de globalización Colegio de San Gerónimo, La Habana Vieja, noviembre 24-27, 2009 -
Re: [digitalradio] WINMOR
Warren Moxley escribió: I don't think he knew it was not ready for prime time since he has a real Pactor III TNC. It still looks to me that your are pretty much stuck without this piece of hardware if you really need to do WinLink via HF. It looks to me that WinLink is great for guys at sea who can afford the hardware, but I don't see it for hams guys on limited funds. Even when it depends on the willingness of Winlink operators to allow Pactor I, (at least for emergencies, usually they do not, being slower and not so robust as P 2 or P3) some old hardware like a a PK-232 or a KAM could be useful. And of course, an HF radio, a proper antenna (possibly a humble dipole will be OK) and a source of power for your radio, computer and TNC. You need Airmail as e-mail client. 73, Jose, CO2JA __ Información de ESET NOD32 Antivirus, versión de la base de firmas de virus 3832 (20090206) __ ESET NOD32 Antivirus ha comprobado este mensaje. http://www.eset.com Participe en Universidad 2010, del 8 al 12 de febrero de 2010 La Habana, Cuba http://www.universidad2010.cu - SEGUNDO SEMINARIO INTERNACIONAL LEGADO Y DIVERSIDAD. ARQUITECTURA Y URBANISMO. El rescate de los valores urbanos y arquitectónicos en tiempos de globalización Colegio de San Gerónimo, La Habana Vieja, noviembre 24-27, 2009 -
Re: [digitalradio] flarq compatible modes
Dave, Is the beacon interval OK? Wouldn't it better be 30 MINUTES? I wonder, because I used to run beacons every 10 minutes on packet. Less than that could be considered antisocial by some people... :-( 73, Jose, CO2JA --- David Freese escribió: for example: MT63-500 requires flarq be set up with: Wait time 30 seconds Timeout 300 seconds Tx delay 500 msec Beacon interval 30 seconds on both ends. Watch the flowers grow :-) Probably the most important thing for persons trying the flarq / fldigi suite to know is that they should not use DominoEX-FEC or Olivia as the transport layer. These modes suppress the transmission of the required control codes for the flarq data stream. 73, Dave, W1HKJ __ Información de ESET NOD32 Antivirus, versión de la base de firmas de virus 3832 (20090206) __ ESET NOD32 Antivirus ha comprobado este mensaje. http://www.eset.com Participe en Universidad 2010, del 8 al 12 de febrero de 2010 La Habana, Cuba http://www.universidad2010.cu - SEGUNDO SEMINARIO INTERNACIONAL LEGADO Y DIVERSIDAD. ARQUITECTURA Y URBANISMO. El rescate de los valores urbanos y arquitectónicos en tiempos de globalización Colegio de San Gerónimo, La Habana Vieja, noviembre 24-27, 2009 -
Re: [digitalradio] Re: Soliciting suggestions
Just one more comment, being on agreement with the previous postings... on a linear transponder (as a SSB transceiver becomes usually on HF between your antenna and your soundcard) just rock the transceiver's dial to make the tones fall in the proper place in the spectrum. FLdigi has a sweetspot setting that MIGHT help to set the baseband start at 1500 Hz (I am not sure because I have not used it). On FM (F2D), it is something else, as you must make the baseband tones coincide.Simon just hit the nail once again. 73, Jose, CO2JA --- Simon (HB9DRV) escribió: - Original Message - From: kh6ty kh...@comcast.net The standard for MT63 is to start at 500 Hz. Fldigi follows the accepted standard. Anyone wishing to use fldigi and flarq together on MT63 will have to follow the standard and only use MT63-1000 or MT63-2000 as other versions have too much latency for flarq Being more exact - Pawel, the designer of MT63 specifically set the lower frequency to 500Hz. fldigi and DM780 use Pawel's code, it is not a trivial task to work out how to allow a different starting frequency. As Skip says, the MT63 standard is to start at 500Hz. I think MARS have decided to use some other default but it's really their problem. Simon Brown, HB9DRV www.ham-radio-deluxe.com __ Información de ESET NOD32 Antivirus, versión de la base de firmas de virus 3832 (20090206) __ ESET NOD32 Antivirus ha comprobado este mensaje. http://www.eset.com Participe en Universidad 2010, del 8 al 12 de febrero de 2010 La Habana, Cuba http://www.universidad2010.cu - SEGUNDO SEMINARIO INTERNACIONAL LEGADO Y DIVERSIDAD. ARQUITECTURA Y URBANISMO. El rescate de los valores urbanos y arquitectónicos en tiempos de globalización Colegio de San Gerónimo, La Habana Vieja, noviembre 24-27, 2009 -
Re: [digitalradio] Re: More RSID - PLEASE!
The difference here is that a helper signal has been added, same as with SSTV, but which is only sent at the start of the transmission. That is essentially different from the raw, bare signal with no ID. A new situation, to be fair. 73, Jose, CO2JA Simon (HB9DRV) escribió: FWIW SSTV has been using VIS (slightly similar) for ~ 10 years or so, maybe more. Simon Brown, HB9DRV www.ham-radio-deluxe.com http://www.ham-radio-deluxe.com - Original Message - *From:* Charles Brabham mailto:n5...@uspacket.org ** This is interesting in light of all the claims by WinLink and ALE aficianados that that comprehensive signal-detection is 'impossible'. __ Información de ESET NOD32 Antivirus, versión de la base de firmas de virus 3832 (20090206) __ ESET NOD32 Antivirus ha comprobado este mensaje. http://www.eset.com Participe en Universidad 2010, del 8 al 12 de febrero de 2010 La Habana, Cuba http://www.universidad2010.cu - SEGUNDO SEMINARIO INTERNACIONAL LEGADO Y DIVERSIDAD. ARQUITECTURA Y URBANISMO. El rescate de los valores urbanos y arquitectónicos en tiempos de globalización Colegio de San Gerónimo, La Habana Vieja, noviembre 24-27, 2009 -
Re: [digitalradio] Need help with PSK-31 and my antenna tuner
It all shows a severe electromagnetic incompatibility in your shack. Check if all goes OK with dummy load, both at the HF radio and at the tuner output. If all goes OK with a dummy load, then you may have RF feedback (bad) into your power line, that feeds all the faulty equipment. It is quite normal that an efficient antenna induces RF in all wires parallel to it, and that includes the power line. To attempt to solve that you should use a low pass filter. That filter should have an inductor input so it effectively DIMINISHES the parasitically originated circulating RF current. I have had to resort to ferrites in many cables, when running 100 watts or more in RTTY, packet and SSB. I have had susceptible mice and keyboards, that have needed special treatment with extra filtering. Just isolate the origin and work step by step, evaluating the results and attempting to find sensible solutions. A single solution may or may not be possible.More often than not, multiple steps will be required, as RF may be induced in every wire in the neighborhood. . 73 GL, Jose, CO2JA --- doug_tara2005 escribió: Hi, I'm having a little problem with my antenna tuner when transmitting PSK-31 above 30 watts. I have a IC-706MKIIG with a MFJ-945E. Both are on their own power supply and well grounded. When I transmit PSK-31, it locks up my IC-2820H (D-STAR) radio (unable to transmit DV, analog or control the radio). My IC-2820H is on a different power supply and also grounded. The radios and tuner are about 3-4 feet apart from each other. Additionally, I use to have a KPC-9612 and it also locked up from time to time and had to do a hard reset. I didn't think anything was at fault and have sold my KPC-9612, but the PSK-31/auto tuner could have also been locking it up. Does anyone else have this problem? Can anyone give me good advise about my setup? --73 de Doug (N1OBU) Participe en Universidad 2010, del 8 al 12 de febrero de 2010 La Habana, Cuba http://www.universidad2010.cu - SEGUNDO SEMINARIO INTERNACIONAL LEGADO Y DIVERSIDAD. ARQUITECTURA Y URBANISMO. El rescate de los valores urbanos y arquitectónicos en tiempos de globalización Colegio de San Gerónimo, La Habana Vieja, noviembre 24-27, 2009 -
Re: [digitalradio] Digital modes and old husband's tales
It seems that the wheel has to be rediscovered periodically. For me, the solution is to use a PEP wattmeter and always run the output power slightly below the clipping level, where the meter needle advances no more. This point may be different on different bands. Just identify the clipping level and back off a bit, if there are no other distortion contributions and your system is linear to the clipping point. With ALC, it all depends on its particular design, and avoiding ALC action avoids the distortion introduced by fast attack fast decay ALC. As with receivers, what is needed is a fast attack slow decay ALC, no nonlinearities between the transmitting and receiving soundcards and peak reading capable meters, if you run digital modes with an envelope. I built a peak detector for my output meter and now I can measure either peak or average power, at will. As simple as that. 73, Jose, CO2JA Andrew O'Brien escribió: The replies to Ralph's question about audio levels appear to be sound advice and certainly in keeping with what has been advised since sound card digital modes burst upon the scene. I wonder how accurate it is though?I have seen a few serious hams argue that no ALC is not really the case, that some ALC can be OK. I have also seen mention that the no ALC issue applies to some modes (like PSK) but not to others like (JT65A). I also wonder about the half-power advice that some advise. With my homebrewed interface, I could never get much above 40 watts before some ALC began to show. When I switched to a commerical interface with good isolation (Microkeyer by Microham) I can almost always get 100 watts output without any ALC action. I have not received any negative reports about my signal . If I run 100 watts SSB for phone contacts, why would I not want to do the same for digital modes assuming the signal was clean ? . Yes, I would agree I should not run 100 watts if communication was possible with less power, but I don't think a brief PSK CQ at 100 watts is going to do much more harm to my finals than a 3 minute ragchew at 50 watts, phone . Right ? Comments ? -- Andy K3UK Participe en Universidad 2010, del 8 al 12 de febrero de 2010 La Habana, Cuba http://www.universidad2010.cu - SEGUNDO SEMINARIO INTERNACIONAL LEGADO Y DIVERSIDAD. ARQUITECTURA Y URBANISMO. El rescate de los valores urbanos y arquitectónicos en tiempos de globalización Colegio de San Gerónimo, La Habana Vieja, noviembre 24-27, 2009 -
Re: [digitalradio] Possible Purchase
For many reasons I built my own and I feel it is foolish not to use an optocoupler when you already use two transformers. I am not happy with less than that. I use soundcard input and output with stereo miniplugs and serial port keying with a DB9 female connector. I use another female DB9 for audio I/O, wired to the same standard as Kantronics TNC's, so my old TNC cables are still useful. All using scrounged material, and does work acceptably well. I have included fixed attenuators in the newer cables to suit the radio, so the interface is the simplest. Of course, I understand all the explained reasons, but in my case, homebrewing is the easy way out. 73, Jose, CO2JA. Tim N9PUZ escribió: If you do not have to have an external sound card the various interfaces that use your computers internal sound card are much less expensive. With some, such as the Rascal GLX you switch cables to use them with different transceivers. There are many other choices, I just happen to be familiar with that one. Tim, N9PUZ Participe en Universidad 2010, del 8 al 12 de febrero de 2010 La Habana, Cuba http://www.universidad2010.cu - SEGUNDO SEMINARIO INTERNACIONAL LEGADO Y DIVERSIDAD. ARQUITECTURA Y URBANISMO. El rescate de los valores urbanos y arquitectónicos en tiempos de globalización Colegio de San Gerónimo, La Habana Vieja, noviembre 24-27, 2009 -
Re: [digitalradio] . . . the other digital mode
Isn't hand sent Morse Code a jittery PAM / PWM combo? A computer can generate a less jittery code. But machine reception is something else. PAM is the simplest, but the worst to decode reliably digital modulation in the presence of noise and interference, which are the rule at least on HF. 73, Jose, CO2JA --- J. Moen wrote: Having learned CW in 1959 and computer programming in 1968, I take your point. In the broadest sense, CW is binary. It is true most digital modes have fairly precise timing, whereas CW, especially sent with a straight key, can be quite the opposite. I have been doing my best to stay away from use of PC programs that generate CW, as well as those that can decode it. I realize that's a loosing battle. DXers and Contesters are moving to these programs for obvious reasons. In everyday Ham language, usually digital modes mean a computer program is generating the transmitted information and another one is decoding it on the other end. So I would exclude traditional CW from my personal list of digital modes for that reason. But in fact, since computer generated and decoded CW is now possible, it really should be included in the list of digital modes, shouldn't it? Jim - K6XZ - Original Message - *From:* Siegfried Jackstien mailto:siegfried.jackst...@freenet.de *To:* digitalradio@yahoogroups.com mailto:digitalradio@yahoogroups.com *Sent:* Monday, June 01, 2009 2:45 PM *Subject:* Re: [digitalradio] . . . the other digital mode cw is digital on off on off or dit dah dit dah . sound there sound away ... so where is the analog compound??? - Original Message - *From:* S.J. mailto:felineveterinar...@yahoo.com *To:* digitalradio@yahoogroups.com mailto:digitalradio@yahoogroups.com *Sent:* Monday, June 01, 2009 5:15 PM *Subject:* [digitalradio] . . . the other digital mode CW is an Analog Mode . . . 73, Sherm KB9Q VI Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética 9 - 12 de Junio 2009, Palacio de las Convenciones ...Por una cultura energética sustentable www.ciercuba.com
Re: [digitalradio] PSK-ARQ versus ALE-400
I wonder what kind of investment is required. It has as many points as possible in common with sound card modes and only requires MultiPSK as terminal program. If I am not asking for a comparison between apples and oranges (I am not entirely convinced right now... 8-) ), maybe Tony could devise some measurements to compare them. 73, Jose, CO2JA --- Andy obrien wrote: While I have seen how well ALE 400 works, I am not convinced that it is worth the effort to invest in activity due to the lack of other hams using the mode. While ALE400 make sense to me, I can't see hams, en masse , switching to it. I still think that a better option would be the increased development of NBEMS PSK and MFSK with ARQ as implemented in FLDIGI. While perhaps not as robust as ALE 400 FAE , it is far more likely to be used by hams if there is more publicity about NBEMS. Andy K3UK VI Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética 9 - 12 de Junio 2009, Palacio de las Convenciones ...Por una cultura energética sustentable www.ciercuba.com
Re: [digitalradio] Re: PACTERM 98
Not necessarily so if the disk is damaged. gkar2000 wrote: The easiest thing might be to borrow a USB floppy drive and install it from there. Mike kc9doa --- In digitalradio@yahoogroups.com, Casey Bell jc130b_...@... wrote: I have a registered copy of PACTERM 98, I'm not trying to 'bootleg' a copy. I have the program on 4 3 1/2 disks and tried to copy to a CD, my computer doesn't have a floppy drive. Disk 1 copied OK, but I'm unable to copy Disk 2. I'd like to get a copy of the program on a CD if anyone can do this for me. The contractor is unable to do it, they no longer stock it. Casey Bell/KQ4YI South Daytona, FL VI Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética 9 - 12 de Junio 2009, Palacio de las Convenciones ...Por una cultura energética sustentable www.ciercuba.com
Re: [digitalradio] Re: Ready for Q15X25 packet test ...
Exactly. With the prevailing bad propagation (and maybe the increased noise levels around my QTH) it is rare lately that P III can go into fourth gear or higher... And I did not have good luck with Q15X25. It was more tha five years ago, and I blamed my old computer... 73, Jose, CO2JA Rick W wrote: Maybe others who have experience with P modes can give us some idea how often it needs to drop to lower levels. When that happens, it would seems reasonable that Q15X25 would not be possible to use. 73, Rick, KV9U VI Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética 9 - 12 de Junio 2009, Palacio de las Convenciones ...Por una cultura energética sustentable www.ciercuba.com 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 * 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:digitalradio-dig...@yahoogroups.com mailto:digitalradio-fullfeatu...@yahoogroups.com * To unsubscribe from this group, send an email to: digitalradio-unsubscr...@yahoogroups.com * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: [digitalradio] Re: Cartoon Charcters
To send a smiling face 8-) , you just send a number eight, followed by a dash and a closing parenthesis sign. The roots are in the newsgroups mails, more than 15 years ago, before anyone had the idea to translate the literal signs (emoticons) into yellow smiling faces and such (seems those came with the generalized use of Win95 and GUI's)... some software is parsing those signs into yellow little faces. The keyboard chatter is so flat that someone had the idea to add some salt and pepper to it, and express feelings in a compact way (happiness, sadness, anger, etc) 73, Jose, CO2JA Andrew O'Brien wrote: --- In digitalradio@yahoogroups.com, John Netro n9...@... wrote: I am talking about this kind of faces Same thing. Someone sends :) with PSK31 and your software substitutes a smiley face. Check your PSK31 sofware's folders and you will see all the icons in a folder. Andy VI Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética 9 - 12 de Junio 2009, Palacio de las Convenciones ...Por una cultura energética sustentable www.ciercuba.com
Re: [digitalradio] TAK-Tenna
I would advise you to check http://www.antennex.com for some past articles about the TakTenna. 73, Jose, CO2JA --- Larry Kebel wrote: I was reading up on the TAK-Tenna and found that it might just be the antenna I am looking for. Check out www.Tak-Tenna.com But, all the info I get is that the radiating wire should be put in a circular configuration. Would there be any problem if I pulled the wire tight and make it into a diamond (square) shape? The same length wire, of course. That would make the structure a lot stronger for transporting. Please let me have your thoughts on this. Larry KB0ZP VI Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética 9 - 12 de Junio 2009, Palacio de las Convenciones ...Por una cultura energética sustentable www.ciercuba.com
Re: [digitalradio] The usual OS Flame war thread....
Per wrote: Hi, I know, I've not always kept my mouth shut either but it never leads to any good in the end. As we are hams we should have an antenna flame war instead ;-) (I like verticals ;-)) 73 de Per, sm0rwo Agreed 8-) 73, Jose, CO2JA Linux User # 91155 http://counter.li.org VI Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética 9 - 12 de Junio 2009, Palacio de las Convenciones ...Por una cultura energética sustentable www.ciercuba.com
Re: [digitalradio] Newbie question
deadgoose38 wrote: Hear a digital signal -- maybe 8+ tones. Starts with a low one, then shifts to series of single ones at a higher frequency, then returns to the base tone. What am I listening to? JT65 Will DM780 decode it? No, that I know. If not, what? WSJT, MultiPSK 73, Jose, CO2JA VI Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética 9 - 12 de Junio 2009, Palacio de las Convenciones ...Por una cultura energética sustentable www.ciercuba.com
Re: [digitalradio] Re: Bandwidth v Shift in RTTY ?
Not exactly. You must add the upper and lower keying sidebands spacing to the upper and lower tones to get an aproximate idea of the occupied bandwidth. The sidebands lie at half the signalling speed around the carriers, and the keying harmonics, whose level and width depends on the modulation index, which is quite large with 1 kHz shift. The Carson Rule gives an approximate answer. The exact answer could be found by Fourier analysis. A simple way to get an answer may be using PSpice or LTSpice, for those willing to use a simulation package. The simplistic answer is at least 1300 Hz: 150 + 1000 + 150, disregarding higher order sidebands. With such a large shift to keying rate, the occupied bandwidth will be larger than the simplistic, on the fky answer. Maybe some people won't bother with Fourier analysis, Bessel coefficients, simulation software or even simple math and just mimic it with MixW and a loopback to some PC based spectrum analyzer. I would use Spectran. Spectrum Lab should be OK too. The carriers should be as high as possible to avoid the lower sideband spectrum foldover. For those that would like to give it a try with a radio, I would use a SDR and not a transceiver with an IF crystal filter to find a true answer. Beware of nonlinearities that might broaden the signal. It would be interesting to read about some practical replies to that question. 73, Jose, CO2JA --- Dave Bernstein wrote: In n-ary FSK, if all tones in the ensemble have identical maximum magnitudes, then isn't it true that the maximum bandwidth will be identical that of binary (2-tone) FSK with a shift whose value is difference in frequency between the highest and lowest tones in the ensemble? VI Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética 9 - 12 de Junio 2009, Palacio de las Convenciones ...Por una cultura energética sustentable www.ciercuba.com
Re: [digitalradio] Re: illinoisdigitalham?
Some members of another group I am a member too felt harrassed and sent a protest. Sometimes we got too many announcements and no real news, so it became tiresome. Most mails were pdf's with large detailed images, which was quite a burden for slow modems. 73, Jose, CO2JA --- Andrew O'Brien wrote: I am guessing that it was taken down due to violation of Yahoo rules. Several people have written to me privately complaining about what they perceived as violations. I refrained from doing anything because the group was in some sense a competitor to my digitalradio group. Competition is good, so I did not want to do anything that would imply I am biased . The issues raised were related to multiple cross posting and frequent solicitations to join the Illinois group, often after they had asked for the solicitations to stop. The owner made some good contributions here but seemed to get a bit lost at times, a few times items I posted here were later re-posted as new items by this person. Since the Illinois group was activated and undertook major PR efforts, postings to this group dropped about 40%. Perhaps we will see some increased use here. Andy K3UK Owner -Digitalradio -- In digitalradio@yahoogroups.com, WD8ARZ wd8...@... wrote: My last one from them was: - Original Message - From: Jerry - N9LYA Sent: Saturday, February 07, 2009 3:18 PM Subject: [illinoisdigitalham] HARDS NEWSLETTER Not showing as a listing anymore either. Maybe a name change? 73 from Bill - WD8ARZ - Original Message - From: expeditionradio expeditionra...@... To: digitalradio@yahoogroups.com Sent: Wednesday, February 18, 2009 8:54 PM Subject: [digitalradio] illinoisdigitalham? Anyone know what happened to illinoisdigitalham? Bonnie KQ6XA Announce your digital presence via our Interactive Sked Page at http://www.obriensweb.com/sked Recommended software: Winwarbler, FLDIGI, DM780, or Multipsk Yahoo! Groups Links VI Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética 9 - 12 de Junio 2009, Palacio de las Convenciones ...Por una cultura energética sustentable www.ciercuba.com
Re: [digitalradio] The perfect mode
That's not me ! I wanted to stress the point that we have two seemingly different needs: one for keyboarding, which is OK with a smaller character set, and a full 8 bit word mode for data, that could be used instead of the old packet modems. As usual, each one might carry a different name or designation. I should do my homework and find some time to read the specs of the existent modes and identify which are the already 8 bit capable ones... so far I have not... I might be speaking a bit off base without this certainty. 73, Jose, CO2JA --- Andrew O'Brien wrote: --- In digitalradio@yahoogroups.com, Vojtech Bubnik bubn...@... wrote: 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 Maybe overlying MFSK16 with Reed-Solomon block code and running multiple MFSK16 decoders with half tone spacing will do the trick. There we go, who do we have aboard that might try coding the above ? Andy K3UK VI Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética 9 - 12 de Junio 2009, Palacio de las Convenciones ...Por una cultura energética sustentable www.ciercuba.com
Re: [digitalradio] new -a few questions.
m3hxe wrote: Hi may I bother you with some questions.I would like to try psk31 and plan to buy a kit interface soon. My problem is this,I am restricted to 10 watts output due to licence conditions and use a Trio ts-130s. I use an alc mod to reduce the power output to 10 watts by applying voltage into the socket on the back of the rig. When I use ssb the alc meter gos end stop due to this mod.I have read that I should reduce the transmit level on the psk interface so that the alc doesn't move. You *MUST* keep the whole chain (audio input to antenna) linear. Think that the mic gain is the audio gain in a receiver and the ALC is the AGC, with order reversed. You must be careful not to overload the transmitter input, first, and then, not overload the final amplifier. Should I remove this mod then plug in a dummyload so that I can adjust the transmit level to the required alc settings? What does that mean? I see nothing wrong using ALC *IF* the ALC time constant is *MUCH LONGER* than the period of envelope variation. Also, acknowledging that the ALC control range is finite and not too large. Ideally, transmitters should have hang ALC, with short attack and long decay time, but that isn't actually the general case, so it becomes simpler to advise not to run ALC. What happens is that short ALC time constants distort the envelope with a quick gain pumping reaction (it gives a certain speech processing gain, that comes precisely from the near clipping action on the TS-520, as an example, when you pull the Processor control). So, in short, running ALC in datamodes becomes bad with many transceivers, A short ALC time constant may act as a sort of syllabic compressor, acceptable for voice but undesirable for data. I, for one, used it a *LOT* on SSB. That provides you with a denser signal that gives you a few dB's gain to work DX easier. Peak power remains the same, but you make a louder noise in the band. Also when I put the alc mod back in the alc reading will go endstop again will this upset the transmit level? I dont think that it will as I would have set the transtmit level without it and I have not had any bad audio reports useing SSB. I hope that this all makes sence! Many thanks for your help-Simon (M3HXE). Simon, the simple answer is a PSKMETER. The perhaps more costly option is an oscilloscope to monitor the output, like those that the Yaesu and Kenwood radios of the 70's and 80's had included in their equipment lines and actually watch the envelope and not allow any envelope distortion, no matter what you do and how do you ride your gain settings up and down. When I am in doubt, I use my old Cossor 110 connected to a tap in my homebrew SWR meter to watch a sample of the RF that goes to the antenna. The tap is a simple 40 dB L attenuator connected to a BNC female connector in the RF sampler box. 73, Jose, CO2JA VI Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética 9 - 12 de Junio 2009, Palacio de las Convenciones ...Por una cultura energética sustentable www.ciercuba.com
Re: [digitalradio] Re: MFTTY On Air Sensitivity
Norbert, I am taking the license of answering before Tony does, so look for the Pathsim docs (AE4JY). There is another german program, IONOS, which is another HF path simulator. I have just played with them, but actually done nothing serious enough. 73, Jose, CO2JA --- Norbert Pieper wrote: i would like to learn more about HF path simulator. Is there any material on the web i can study? BR Norbert VI Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética 9 - 12 de Junio 2009, Palacio de las Convenciones ...Por una cultura energética sustentable www.ciercuba.com
Re: [digitalradio] Windows Vista for digital mode soundcard applications ?
W6IDS wrote: The only other issue I did have was a lack of backward compatibility with PK-232 software, XPwin, that I used on an older XP computer before it crashed three months ago, or so. I found a program that helped with XP and some DOS programs, but I don't know if it would work OK in Vista: DOSBox. You could Google for it and find out if it may help. 73, Jose, CO2JA VI Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética 9 - 12 de Junio 2009, Palacio de las Convenciones ...Por una cultura energética sustentable www.ciercuba.com
Re: [digitalradio] ALE400 and 141a messaging
Based on what I know, for SMTP, JNOS may be an option at less than 300 baud, i.e., 100-110 baud or PAX, using MultiPSK as soundcard modem. I have not tested any of it yet. I have had no time and possibilities to test it so far. JNOS can use FBB compression or LZW compressed SMTP on any of its radio ports using KISS protocol to connect to a TNC. I ran both FBB and JNOS simultaneously for several years sharing the same TNC under MSDOS and Linux, and HF mail using compressed FBB protocol or LZW compressed SMTP worked, even when painfully slow, at 300 baud on a shared forwarding frequency. Even FTP worked (I do not remember if it could be compressed as well) on HF. It is not theoretical. JNOS networking works on HF with the known 300 baud weaknesses. How well does it work really matters when nothing else is available? Certainly, that may be an option in an unconnected scenario. I have also read some papers (which are not recent ones) mentioning the possibility of using JNOS for armed forces communications. I believe it should be tried out. Configuring JNOS is not easy, it is command line oriented and learning its options is a steep process not suited for the faint of heart, because along its history, it has been developed and maintained by people familiar with Unix, networking and text mode consoles in a spartan command line environment. Working options may be saved in a configuration file that it reads at the start up. One almost miraculous option it has is the maxwait parameter. It limits the usual TCPIP exponential backoff to a value of your choice (not arbitrary, it basically depends on the signalling speed and channel reliability or congestion), indispensable when running TCPIP on a radio link and not on a high speed, less noisy, wired environment. Other TCPIP implementations fail without this kludge, particularly, on HF radio. Even Linux with its native TCPIP stack is subject to fail as well. JNOS packet stack is better crafted than the Linux AX.25 support. Alan is right, maybe a kludge between an AX.25 stack and other modes could be devised, but it is not simple. If other sound card modes work at the same speed, why wouldn't PAX or slow packet work? APRS has been tested so far with slower than 300 baud speeds and has worked, even with the nowadays prevalent bad HF propagation. Frugality in message content is *INDISPENSABLE*. Compression is your friend. In a bandwidth limited radio channel, concise, short, text messages are preferable to more voluminous file formats (.doc, .xls, .bmp, etc). If that is not acceptable, then, who needs that should procure a wideband VSAT link. 73, Jose, CO2JA --- John Bradley wrote: What would be our non VHF options? John VE5MU VI Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética 9 - 12 de Junio 2009, Palacio de las Convenciones ...Por una cultura energética sustentable www.ciercuba.com
Re: [digitalradio] ALE400 and 141a messaging
Alan Barrow wrote: Yes, I understand it works. FBB works OK on HF because once you are logged in, it's not that interactive. But you still have 2-3 turnarounds before you send the initial message, etc. FBB protocol has a feature I find very valuable: the Z-modem style resume. JNOS had not achieved that until 1.11g or so... about the last I used seriously. Buried inside the P3 WL2K pactor transfers is a basic F6FBB chat login. Yes, I have been able to login to WL2K from FBB using P2 or P3. Typically 5-10 seconds to link, get logged in, and sync prior to really transferring the messages. Again, it works, lot's of messaging sent this way. But a bit wasteful. Why are you logging in when the system already knows who is sending it via your callsign? And you just sent the password in the clear on hf, so why bother? Login's are wasteful on HF. Lot's of analysis discussion in this area as well. That is interesting. I had (and lost) an archive collection of the early decisions in packet and BBS's. I learned a lot from that (and have forgotten many fine details as well). Real answer is a public/private key system. Anything else is wasted time bandwidth. Adds no security, and reduces reliability. I used the JNOS MD5 challenge/response logins. Otherwise, it was false security with clear passwords flying on the air. I am not too familiar with the public/private key systems. SMTP over HF is much less efficient reliable because it has many, many turnarounds. It is true. But JNOS LZW compressed SMTP fared fairly well in comparison. It's designed for a lan with infinite signal to noise ratio. :-) short packets, many turnarounds. With more overhead in the TCP/IP header than in the data sent. So in the commercial military systems, you see TCP/IP spoofing. Eat, then recreate the IP headers on the opposite end. Same for SMTP. I have never seen that in the ham world. Sounds interesting. (just like the trailblazer modems did with UUCP in the old unix days) I lived that... So how do you deal with this using the tools you have? With BBSLink we use an FBB command structure, but compress the initiation of sending the message into a single file transfer. IE: the command, user ID, etc is prepended to the message and processed by bbslink. So no login chat over the air, retries, etc. With HF, you only get so many seconds of decent S/N at times. You don't want to waste half of your window getting logged in using a system oriented for interactive users. Certainly. But there is a catch. I have *SUFFERED* receiving a queue where the most important mail is not the one I get first. A tricky condition that may prove nasty in an emergency. Perhaps it could be handy to be offered a set of headers/message sizes to choose. Routinely, it should not be necessary, but could be invoked if needed. Something to think about. I am not too familiar with WL2K beyond being a user. If the message is short enough, it's a single send, then ack back from the receiving system. Longer messages do have an ack before the next frame is sent, etc. DBM is not perfect, but works, and is a true WW standard. (for as much as that means... F6FBB is also a defacto standard but there are very many implementation differences in login specifics, etc when talking to them programatically.) We'd like to see other protocols like FAE, etc leveragable as well. So could you make JNOS/MSYS work over HF with a kiss modem? Most likely. Is that the best way? I think we can do better if we apply ourselves work together. JNOS is certainly a useful tool in the mix. I have had a good experience with FBB and JNOS and feel that the networking part worked in a fairly decent way. I used MSYS very little and liked FBB a lot, I felt it led the race in the early 90's. I am aware that the limit was not the networking part, but some sublayers in layer 1. I did quite a bit of FBB forwarding using my PTC-II and it worked wonderfully, with the same radio and using a lot less power. At least 10 times better on the average, thruput-wise. Maybe there is some room for improvement left, but nevertheless, I don't feel that the wheel has to be reinvented. Maybe just use more suitable tires, or better roller bearings, but reusing what has been proven to work. If the best known is not affordable, don't quit, and use another acceptable alternative. The worst is havin no comms at all. I dared to answer John because if networking and HF are an important terms in the equation I would rather use what I know that somehow works and not wait until a perfect solution shows up. It will eventually show up. Fortunately for us, there are people that strive to find better solutions for working systems. The best is, as far as I know, a SCS pactor controller. But slow packet or PAX could be workable solutions for HF. Would other modes capable of passing a full ASCII alphabet (8 bit words) work instead of a modem whistling
Re: [digitalradio] SOFTWARE?
Maybe one of the latest versions of Hamcom, or Mix 2.19 or 2.21 could be configured to make your boxes run with a PC and PC software. I did some 12 years ago, using a KPC 2 as dumb modem and homebrew FSK modems (TU's) on my old 386 and 486's using the serial and parallel ports. Don't ask me about the specifics right now, as it has been a long time to remember it all in detail. Just browse the help and docs of Hamcom and the old DOS Mix, and your boxes manuals I had particularly good results with a homebrew dual AM demodulator for FSK using some ideas borrowed from the KAM modem and the AN-93. I ran AMTOR and PACTOR using TERMAN 93 and packet using BPQAX25. Filter's alignment and a suitably good post demodulator low pass filter are certainly important. So your equipment may be out of fashion but not useless if it is still in good working shape. But it will be hard to find anyone on AMTOR or plain old pactor in the HF bands, and packet is quite scarce too. 73 HNY, Jose, CO2JA --- Siegfried Jackstien wrote: you can get an old pc for free sometimes ... just hold your eyes open commodore c64 ... yes it is really old gear happy2009 dg9bfc - Original Message - *From:* Michael Mihailovic mailto:vk...@bigpond.com *To:* digitalradio@yahoogroups.com mailto:digitalradio@yahoogroups.com *Sent:* Saturday, January 03, 2009 10:13 PM *Subject:* [digitalradio] SOFTWARE? Hello All. I have an old MFJ-1229 which i would like to get going again as well as a Kantronics UTU interface i used to run the mfj with MBA-TOR prog on my C64 Commodore does anyone know or have a copy of MBA-TOR or can suggest something to get these units running the UTU has never been run please dont laugh i know it's old hat gear but its all i have. Regards 73's Mike VK2OZ. VI Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética 9 - 12 de Junio 2009, Palacio de las Convenciones ...Por una cultura energética sustentable www.ciercuba.com
Re: [digitalradio] PSK distortion effects theory
kf4hou wrote: This is only a theory , but i like to have some input on this. I have noticed on using bpsk31 some stations can be very wide at times. I can give them a report they are wide and they also tell me I am wide. but the next day they look clean to me and they have not touched anything Why is that I asked my self. And speaking about the type of stations that even have imd meters. And what IMD levels are acceptable to them? -30 dB? My theory is this you know how you get ghosting on analog TV caused my multipathing, and how someone can sound if they are multipathing into a repeater were they sound very distorted like they are off freq some? Well could you not have some of the same effects on bpsk31 on hf, mf ? Especially in the cases where you have a local station on the lower bands where you have ground wave and sky wave meeting slightly different in time and like on HF bands where you can have multipathing or selective fading would you not have some type of distortion added to signals? Any such distortion would be LINEAR distortion, which would modify the waveform or alter the frequency response, but should not create any further nonlinear distortion. Also I can not grip on the idea of phase distortion as well, can someone break that down to me? For a complex waveform to retain its shape, phase shift shall be linear with frequency. If the harmonics are not phase shifted proportionally, the waveshape will not be preserved. But it does not add any distortion products, new frequencies are not created Seems like to me also I have noticed that QPSK does not have this problem as much as well, Why is that? I know nothing that protects QPSK in such a way. But an amplifier with crossover distortion will perform worse with zero crossing signals. OQPSK on satellite links takes adventage of such a fact. I also understand about people having over driven audio as well and lousy soundcards , but seems like some days people's audio are awful in general and the next day, in general most people look fairly well. I also understand the noise floor vs. signal strength and hide some of the bad audio effects out there as well. Of course. Depending on the background noise levels, one day you may only see the head and other days get to see the shoulders or even the chest But I have seen quite a few cases of distorted signals coming from people that are running no ALC if distortion is created before the final stages (even the transceiver's audio input may be overloaded, or low quality transformers overdriven into saturation), running no ALC will not clean it. Actually, it will faithfully preserve the distortion of the signals you inject to the balanced modulator(s). Shaped envelope signals like PSK31 or simultaneous multitone modems MUST have LINEAR amplifier chains from the soundcard D/A to the antenna. If that is not accomplished, new frequencies and a broader spectrum (spectral regrowth) will show up. 73, Jose, CO2JA VI Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética 9 - 12 de Junio 2009, Palacio de las Convenciones ...Por una cultura energética sustentable www.ciercuba.com
Re: [digitalradio] Signalink USB Problems
Seemingly you are experiencing clipping/distortion/overload from a too high audio input, judging the fact that you are getting strong harmonics in the passband. 73 HNY, Jose, CO2JA --- n4hra wrote: I am having a problem with a new Signalink USB depending on how strong a station is I get multl signal on the waterfalls from the same station. it does not matter what PSK software I am running. I did not have this issue when I was running a home brew Rascal SET-UP: RIG: Kenwood TS-2000,OS: Vista Any Idea? Thank you Lew N4HRA VI Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética 9 - 12 de Junio 2009, Palacio de las Convenciones ...Por una cultura energética sustentable www.ciercuba.com
Re: [digitalradio] Re: Specification of Frequency for Net Announcement
Jose A. Amador wrote: Pactor 3 MUST be USB. To remain compatible. If EVERYBODY used LSB, there would not be any problems, of course. Just a thought after I reread this from the list... Jose, CO2JA VI Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética 9 - 12 de Junio 2009, Palacio de las Convenciones ...Por una cultura energética sustentable www.ciercuba.com
Re: [digitalradio] Re: Specification of Frequency for Net Announcement
I use USB for RTTY, and reverse in the terminal program. That keeps mark and space in the right relative places. 73, Jose, CO2JA John Becker, WØJAB wrote: At 02:23 PM 12/30/2008, JONATHAN WALLEN wrote in part: All data modes should be in USB. True except for RTTY. VI Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética 9 - 12 de Junio 2009, Palacio de las Convenciones ...Por una cultura energética sustentable www.ciercuba.com
Re: [digitalradio] Re: Specification of Frequency for Net Announcement
Due to its baseband coding, it does not matter what sideband you use in packet. It is only relevant to published dial frequencies when tuning some spectrum chunk. I did use USB for many years with the only consequence that dial frequencies were different. Same happens with Pactor or Pactor II. Pactor 3 MUST be USB. Frequencies will be different to published ones for people that use different modem tones (2025/2225, 2000/2200, 1650/1850, etc) even on the same sideband. 73 HNY Jose, CO2JA --- Charles Brabham wrote: Most HF Packet is LSB as well. General statements will often get you into trouble, unless very well researched. 73 DE Charles, N5PVL - Original Message - *From:* John Becker, WØJAB mailto:w0...@big-river.net *To:* digitalradio@yahoogroups.com mailto:digitalradio@yahoogroups.com *Sent:* Tuesday, December 30, 2008 6:56 PM *Subject:* Re: [digitalradio] Re: Specification of Frequency for Net Announcement At 02:23 PM 12/30/2008, JONATHAN WALLEN wrote in part: All data modes should be in USB. True except for RTTY. Announce your digital presence via our Interactive Sked Page at http://www.obriensweb.com/sked VI Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética 9 - 12 de Junio 2009, Palacio de las Convenciones ...Por una cultura energética sustentable www.ciercuba.com
Re: [digitalradio] Broken PC question
Andrew O'Brien wrote: Please excuse the non-radio question... We have a PC that just stopped working, looking for some possible ideas. The PC (a desk top) was knocked over by a frustrated teenager , when plugged back in the power light comes back on but nothing is seen by the monitor , no Windows attempting to boot or anything, no beep codes. The fans are going, I do not see the HD LED light up, and after a few seconds at boot-up, I hear a slight click like the HD is trying without success. If the HD has gone kaput, would I not get some indication from the PC rather than just nothing at all ? Andy K3UK Andy, It usualy pays to take a peek inside. First, I would check the PSU output voltages and make sure they are within the allowable margins, usually +/- 5%. If it passes the test, I would remove anything that is pluggable (a damaged disk may impede booting), reseat the memories and make sure the speaker works. If the motherboard does not have onboard video, plug in the video card and attach a display. You should also check if the microprocessor is seated correctly on its socket. A crab with no legs is deaf 8-) With no drives, you should see some video and the boot process stopping at the point it has no bootable system disk. The speaker is important to check beep codes. For my use, I usually disable the beautiful boot screen and enable all the memory, disk and devices checks to be seen. If it does not show any signs of life, and it was a working computer, you may have a broken line somewhere. Nowadays motherboards have a small switching converters to derive the core voltages from, and you must have a working PSU plus a working core voltage converter. I have seen some motherboards fail by this reason, specially some AOpen boards with cheapo electrolytic capacitors. Those capacitors SHALL NOT be unsoldered (those are multilayer boards), but rather, opened to access the leads and solder a new capacitor to them. Tin wave soldering may have weak spots and a MOSFET pin may not be making contact after the shock. What else? It still may have some dizzy or angry electrons inside thar refuse to go with the herd... Good luck ! Jose, CO2JA VI Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética 9 - 12 de Junio 2009, Palacio de las Convenciones ...Por una cultura energética sustentable www.ciercuba.com
Re: [digitalradio] RE:Packet radio with sound card
Rick, You have a point. I did not stop to think about the possibility of multicast fills. 73, Jose, CO2JA -- Rick W wrote: Hi Jose, The advantage of using manual ARQ fills after the transmission of the data, is that it can be used as a one to many transmission. If any stations did not receive the data perfectly, they can send a request to repair defective portions. This is not possible with a handshaking type connection. Ideally, you would be able to do it either way. The main advantage of Pactor, Clover II and Gtor were the ability to make some changes in the speed and modulation in order to more closely match the path conditions. SCAMP could do this within a narrow limit, but it was not capable of working down to the weak signal level that the developer had expected, which was around zero dB SNR. Instead, it was closer to perhaps ~ +8 dB and needed to have a slower (more robust) mode to compete at all with Pactor. It is hard to believe that 4 years have gone by since we started beta testing SCAMP, but better something late than never. In the meantime, no one else was able to come up with an adaptive mode suitable for amateur use, so this could be the next big thing ... 73, Rick, KV9U Jose A. Amador wrote: I can understand that procedure in sake of simplicity, but hardly an efficient one. Obviously, ARQ should be automatic. VI Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética 9 - 12 de Junio 2009, Palacio de las Convenciones ...Por una cultura energética sustentable www.ciercuba.com
Re: [digitalradio] RE:Packet radio with sound card
Rick W wrote: SCAMP had no problem at all with the switching times from the testing I did. As a former Amtor and Pactor user from years earlier, it proved to me that my concerns about switching were unwarranted. Cold switching (no RF until contacts are closed, or opened while RF is flowing) should be harmless. My 600 W output homebrew linear can handle 40 wpm full break in using a current driven, run of the mill Potter and Brumfield 12 V 3P2T relay. But other replacement relays may be not as easy to find. Then along comes RFSM2400 with its frequent switching back and forth to maintain a link, even with no data flow, and you realize that computers can switch in a few tens of milliseconds, even with non-real time operating systems. Try toggling the PTT control with a typical multimode program and see how fast you can switch back and forth. It is not all that slow. I am skeptical about the wear and tear issue. My first experiences with AMTOR were frightening... but proved harmless to my gear. Many rigs have QSK capabilities to allow switching between TX and RX many times per second. Even at 60 wpm with CW! So twice per second for older technology such as Amtor would not be that difficult to handle and new technology with less than one cycle per a few seconds, hardly noticeable. Although RFSM (MIL-STD 188-110A) can not be used in the HF RTTY/Data U.S. bands due to the high baud rate, other MIL-STD parallel tone modems could, even though it is not something that common. One of the methods would be to use some of the SCAMP technology and leverage it with the newer non RFDT modulation of SSTV/data such as QAM QAM is as far as you can go without losing appreciable robustness. and do it with on the fly ARQ instead of manually after the completion of the transmission as it is done now with most of these programs. I can understand that procedure in sake of simplicity, but hardly an efficient one. Obviously, ARQ should be automatic. From my understanding that is what Winmor effectively does, plus it will have the necessary adaptive technology for ramping speeds up and down for conditions. This is something that any new, successful messaging system MUST have to succeed. That is what SCS boxes have done for a long time. The big question for the future is how open Winmor will be so that other adaptations can be made for BBS and peer to peer connections, particularly if you want something that can meet the needs of public service/emergency communication. Some sort of input is necessary, as MultiPSK can be used as modem for KISS streams. I have not enough details about Winmor to understand what it packs and what it misses. E-mail can be helpful, but peer connections are vital, and BBS of great value in order to time shift. If there was a BBS system that could use low/no cost sound card adaptive modes for HF and/or VHF, I think it would be popular. I think likewise. I personally would be one of the first to support such a system. This is currently a large hole in what we need since the packet systems have mostly been discontinued. The key is to have at least a local BBS system that can work over a moderate distance of perhaps 30 to 50 miles on VHF (or more) and up to a few hundred miles on HF. ...in order to regain what has been lost. BBS's here, beyond allowing local contacts, also allowed to access the worldwide packet network, which was a window to the ham world. 73, Jose, CO2JA
[digitalradio] Programs for soundcard packet, 9600 baud ?
I would like to receive suggestions about what may be available for G3RUH encoded 9600 baud packet, using Windows XP and Linux. I would like to try the digital amateur satellites sometime and I have no 9600 baud TNC available. In general, I would appreciate pointers for sound card packet software that may be useful to access the amateur satellites. I really am in need of an update of what's cooking nowadays. 73, Jose, CO2JA AMSAT-NA LM1209
Re: [digitalradio] Programs for soundcard packet, 9600 baud ?
Thank you, Toby. Yes, that can be an option. 73, Jose, CO2JA --- Toby Burnett wrote: I've used winpack and AGWPE sound card driver with success before on my local BBS nodes. Not sure if this is what your after. Works quite well. Now unfortunately I'm not in range of my nearest Node :( Also received packet from the iss with this ok. I've not got any real good VHF antenna,s at the moment but give it a try. Toby
Re: [digitalradio] Christmas and Happy New Year 2009
Quite possibly! But at this date, with the Summer Solstice so close, who is going to blame him? I see nothing wrong in having a few COOOLD beers while tanning on the beach ... 8-) Hector, muchas cosas buenas para tí y los tuyos, 73, Jose, CO2JA --- John Gleichweit wrote: Feliz Navidad y Feliz Año Nuevo! I guess you're taking an extended vacation? -- John Smokey Behr Gleichweit FF1/EMT, CCNA, MCSE IPN-CAL023 N6FOG UP Fresno Sub MP183.5 ECV1852 List Owner x10, Moderator x9 CA-OES 51-507 http://smokeybehr.blogspot.com http://www.myspace.com/smokeybehr *From:* Hector Cabrera lu6...@gmail.com *To:* DIGITAL RADIO digitalradio@yahoogroups.com *Sent:* Monday, December 8, 2008 1:29:31 PM *Subject:* [digitalradio] Christmas and Happy New Year 2009 Merry Christmas and Happy New Year 2009 Héctor C.Cabrera LU6DEZ _ Announce your digital presence via our Interactive Sked Page at http://www.obriensweb.com/sked
Re: [digitalradio] Re: Odd noise in receiver
It might be a switching PSU on standby mode. I know one TV set that cycles in a similar way (producing some 'reverse TVI), even when the numbers are not the same, it starts, charges the main capacitor, goes into standby and restarts when its voltage diminishes under a certain threshold. 73, Jose, CO2JA Dave 'Doc' Corio wrote: Thanks for the info, Bruce. I didn't have a chance to record it or measure it accurately before it disappeared Friday evening some time. As to if it's time synced, I would have to guess that it is. It was extremely close to 10 seconds on and 5 seconds off, and the number of pulses was 55 during the on period. Granted, timing it with a stopwatch is not exactly precise, but it was close enough that I'm reasonably certain it's timed somehow. The simple fact that it stopped Friday night leads me to believe it's some type of commercial activity. I've had the rig on a lot this weekend, and haven't heard it once. It also stopped before I could log exactly where it was. If I'm lucky, it's gone, never to return. I doubt it, however. If it comes back, I'll get a recording of it and post it. If you have a recording of yours, please send it to me! May not help, but it sure couldn't hurt! Tnx es 73 Dave KB3MOW Bruce Sawtelle wrote: Hi Dave, I have a similar type noise in our neighborhood. By doing some DF'ing, we've pinned it down to a neighbor's house, but haven't been successful yet in gaining their confidence to let us explore beyond their front door. Can here it on VHF when we're at their front porch. Is it time synced, i.e. is the accuracy such that it's being derived from a 60Hz/Xtal time base. In my case, it's not. It comes on for APPROX 12 seconds and goes off for APPROX 3 seconds, but if I listen to it over a few minutes, it will drift up or down. Also, I noticed I can hear it at ~ 16.7KHz offsets, which makes me think it could be PC video related. Not sure if it could be switching power supply related, I thought most of them were 100's Khz. Actually, It had been across the full 20M band last year when we were DF'ing, but now it's discrete. I have a wav file I can send you if that would help. Fortunately, it's been down to S2-3 as of late. It also seems to be tied to colder weather (thermostat control??). BTW, the neighbor is 300-400 feet away in a suburban area (70' x 120' lots) . W5AHC is another ham in the neighborhood and he's ~100 fett closer and hears it as well. Hope this helps. Let me know what it ends up being. tnx es 73 Bruce - W3NJ
Re: [digitalradio] Re: identify this mode?
Well, I have not tried MP3 saving and decoding, since I KNOW it supresses redundancies for the ear as a way to achieve LOSSY compression. Avoiding it makes sense to me, as MP3 mangles the spectrum with its algorithm. But, as you say, it may not be entirely the case. While experimenting with DRM, I have only seen wav files distributed for demonstration from several sites. Also, demo files for SDR tests are also wav files. Wav files may be zipped for saving/distribution without losing a single bit. So it seems that it is not OK for OFDM, SDR demodulation or saving accurate spectrum samples, but maybe some simpler spectra or less stringent applications may not actually suffer (should I add much??) from MP3 compression. I am almost sure that RTTY might likely pass the MP3 test with flying colors, but I am not so sure with multicarrier modes (Olivia may be one example) That makes something to test with some free time and determine what are the actual effects for different uses and modulations. Variants are many, and I would expect a range of results, from little or no impairments, to entirely useless. It makes me curious, and who knows if there are others interested in doing their own tests and publishing the results. 73, Jose, CO2JA - Tooner wrote: --- In digitalradio@yahoogroups.com, Jose A. Amador [EMAIL PROTECTED] wrote: That's OK for aural reference, but a .wav cilp is required for decoding. Jose, I gave thought to what you said and it makes sense. The 'aural reference' and screenshot is good, but the ability to decode is even better. I was concerned that I wouldn't get that ability, but before I committed to the concern, I decided to test the theory. I recorded several HF digital modes and saved them as MP3 files, set at 128Kbps/48000Hz/Mono. I could have added my own phasing, sine characteristics, modulations, base frequency, etc. But it's untouched audio, straight from the rig. Upon playback, I've been able to decode every MP3 I've made. Is there any specific modes that you were referring to? Maybe I missed it. f, k2ncc Announce your digital presence via our Interactive Sked Page at http://www.obriensweb.com/sked Yahoo! Groups Links
Re: [digitalradio] Re: Odd signal 14171
I am copying it some 20 dB out of the noise here in Havana at 21:55 UTC on 14173 center. It has 8 threads, plus some other two that show up on the side, at much lower intensity, possibly IMD products, as their amplitude seems to track the larger peaks excursions. The tones are 875, 900, 925, 975, 1025, 1075, 1100, 1125 Hz, with my radio on 14172.0, USB. The smaller tones on the side are 825 and 1175 Hz. It looks like periodic bursts on a PC oscilloscope. I observed the spectrum using Spectran. The sound has a slight resemblance to RTTY, but using just how it sounds to evaluate it is misleading. I would believe it is some sort of PSK, with noticeable ionospheric Doppler and fading affecting the tones, some 2 Hz and 10 dB. 73, Jose, CO2JA --- Fred VE3FAL wrote: The signal is back and is strong again today at 16:35z on Sunday. It does sound like RTTY, but unable to copy any of it... I have made a recording if anyone would like a copy. Fred VE3FAL -Original Message- From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of marc Sent: Sunday, October 26, 2008 8:50 AM To: digitalradio@yahoogroups.com Subject: [digitalradio] Re: Odd signal 14171 And it is loud and clear in EU too: 9+10dB So an European Signal? Marc, PD4U
Re: [digitalradio] Re: Odd signal 14171
Might be coming from Europe. I was hearing an EI station stirring up a pileup one kHz up. The EI station was keeping this signal out of his USB passband, so I assume it was a QRM source for him ... 8-) So, this signal coming from beyond the skip zone in EI. 73, Jose, CO2JA --- Andrew O'Brien wrote: --- In digitalradio@yahoogroups.com, marc [EMAIL PROTECTED] wrote: And it is loud and clear in EU too: 9+10dB So an European Signal? Marc, PD4U Very loud here today too
Re: [digitalradio] Contestia 1K vs MT63?
Tony wrote: Patrick, I get the same minimum SNR for Contestia but can squeeze -8db out of MT63 when using DM780 and IZ8BLY. Yesterday I had no luck with DM780 while monitoring Tony's QSO's on 14106. Of course, I have not calibrated DM780, so that is no surprise. Propagation was not good, but MultiPSK did fairly well. The threshold difference shows on-air as well as under controlled conditions and so it would seem that the best way to get the most out of MT63 is to use software that decodes deeper into the noise. No doubt... The 10-to-1 peak-to-average power ratio is an excellent point and it's obvious that Contestia will put more RF into the air on average. There's no doubt in my mind that the Contestia 16-1K will do better most of the time. I have doubts on this department. If the peak amplitudes are the same, as may be happening with the audio tests, the decoding on those conditions should be equally valid. Of course, Vojtech points out that MT63 is more sensitive to distortions which are pretty common with some not so careful operators. Fast attack slow decay ALC could have a chance of correcting some of the overloads after the transmit IF, but the rest of the chain, from the audio input to the IF should receive proper audio levels. I have seen rebel cases of distorted PSK-31 when people closes the mic gain and distortion remains... because the early stages of the transceiver are already overloaded, and I had a real bad luck when explaining that to the other operator. People should know their way around... On the other hand, it does not seem to recover from the complete drop-outs that occur during deep fading or with lightning static the way MT63 does. I was browsing my references this afternoon (local) and I I decided not to send a reply, since it seemed that Vojtech had a good point and was not worth arguing about it. Nevertheless, I wonder how the degradating effect of -30 to -20 dB IMD, the usually accepted values when adding that to the channel noise. Even more when I read that Contestia was devised with a flat envelope on mind (nonlinearity does not affect it) and uses about the same Walsh-Hadamard code. But it _might_ mean, conversely, that Contestia is more power greedy, an important consideration for emergency operation. I've tested this theory by removing short 1-to-3 second segments of the signal at random intervals and the mode continues to print despite the missing 'chunks'. As you say, this could be due to the difference in modulation speeds. Is there an alternative mode that I can test that might have similar characteristics? I did not find any details on my references, but seemingly interleaving is done both in the time and frequency domains, so there is more chance for MT63 to get the message thru, specially with long interleave. On the other hand, if someone pulls the carpet (heavy doppler) there is a risk that MT63 will fail strepitously with bits falling on the wrong bins while a mode with less, wider frequency bins (like Contestia or Olivia) will really shine. I had really a low esteem for MT-63, but it had been hard to make a MT-63 QSO before Tony started the present tests campaign. It just happens that each mode should be used according to its most promiment strengths. I still have low steem for Chip-64... 8-) 73, Jose, CO2JA
Re: [digitalradio] Re: ASCII ?
jhaynesatalumni wrote: I guess some people thought it was a Big Deal, but there were lots of reasons why it didn't go anywhere. I'd say the overriding one is that with 60 wpm Baudot RTTY the bit length is 22 milliseconds. With 100 wpm ASCII 110 baud the bit length is 9 milliseconds. That means 2.4 times the bandwidth, and correspondingly more noise sensitivity. Maybe for VHF local work it wouldn't matter; but for HF that's a big penalty. And we were already running 500 watts or so to get good copy on RTTY. One very important reason is (I)nter (S)ymbol (I)nterference, or ISI, when one delayed (by multipath) symbol steps on the following one, confusing the demodulator and creating lots of garbage. A long symbol may allow reflections to die and the demodulator to output some meaningful data, but a shorter one also has smaller probabilities of hitting the nail on the head. The idea of longer symbols crafted for multipath environments is exploited in OFDM systems, together with some measure of FEC, if not using also ARQ, to assure the correct reception of data, whatever the message content may be. 73, Jose, CO2JA
Re: [digitalradio] ASCII ?
John Becker, WØJAB wrote: Still a lot of machines out there still working after all these years. Gee it would be so nice if the software writers would do the same. John, W0JAB John, It is the ongoing fashion, nothing else. Life cycles are shorter nowadays. There are many old american cars from the fifties running in Havana streets, and even a few Model T Fords too, that tourists love to see. They were built to last. Modern operating systems are short cycle mutants. Quite often, the change is introduced seeking for profits, and nothing else. I am not against changes for better, but there was a GM - Microsoft controversy that ended with a caustic reply from the GM's President that explained it too well. 73, Jose, CO2JA
Re: [digitalradio] Re: CSS releases EmComm Ops Radio Software for Packet Radio
It may have been that you were awake while Snow White slept... 73, Jose, CO2JA -- Andrew O'Brien wrote: Is my brain dead? I may be missing the point of this product, I read the manual and it says PSK31 is a new mode and it references 20 year old concepts . Seems like a step backwards to me. Andy
Re: [digitalradio] Re: ASCII ?
Well, what I meant (I don't remember the exact quote right now) is that the steering wheel and the pedals remain in the same place and react in a similar way, you don't have to learn anything basically new. Highways don't need to be modified, either... Jose, CO2JA Tom Tcimpidis wrote: The CEO of GM once said that “What is good for GM is good for the country.” *From:* digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] *On Behalf Of *jhaynesatalumni *Sent:* Thursday, October 02, 2008 8:47 AM *To:* digitalradio@yahoogroups.com *Subject:* [digitalradio] Re: ASCII ? --- In digitalradio@yahoogroups.com mailto:digitalradio%40yahoogroups.com, Jose A. Amador [EMAIL PROTECTED] wrote: but there was a GM - Microsoft controversy that ended with a caustic reply from the GM's President that explained it too well. That's interesting, because I think it was GM that is generally credited with inventing planned obsolescence and the annual model change. Announce your digital presence via our Interactive Sked Page at http://www.obriensweb.com/sked 30M digital activity at http://www.projectsandparts.com/30m Recommended software : DM780, Multipsk, FLDIGI, Winwarbler ,MMVARI. Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/digitalradio/ * Your email settings: Individual Email | Traditional * To change settings online go to: http://groups.yahoo.com/group/digitalradio/join (Yahoo! ID required) * To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: [digitalradio] Pactor III licensing...
[EMAIL PROTECTED] wrote: I have a KAM XL and a fully tricked out PK232. can either of them be licensed for Pactor III? what is the cost of upgrading to II and to III? thanks chas k5dam No, it is only for the SCS made boxes. For license details, check http://www.scs-ptc.com 73, Jose, CO2JA
Re: [digitalradio] MT63 freq ?
Rick W wrote: I don't know enough about ionospheric disturbances to know if you can only have Doppler (such as polar flutter) without having multipath at the same time. The only way that comes to my mind that you can get rid of multipath is by just receiving a single ray. To achieve it, a working frequency for a given path geometry between two stations might be chosen for a limited period. That is tricky and sadly, not practical, being a moving target. The practical solution is to use the Optimum Working Frequency, conventionally 85% of the MUF, but that might allow some multipath to propagate. When you must reach more than one station, at different distances, you certainly must allow multipath to exist as well. I seems reasonable that you might have one or the other, but most times (as you have tested) you have some of each. The boundaries between ionospheric regions are always shaky, and contracting or expanding around the planet, so, most of the time, some Doppler, even slight and slow, is unavoidable. 73, Jose, CO2JA
Re: [digitalradio] KISS feature of Multipsk (test version)
Patrick Lindecker wrote: Hello to all, The KISS feature is available in a test version. A next new test version (proposed in the Multipsk reflector) will improve this feature tested through UI-VIEW for instance. There won't be any licence necessary for this feature, so it will be open to any Ham able to interface or to program a Packet protocol (responder, small BBS...). The available Packet modes of Multipsk are 1200, 300 and 110 bauds AFSK. If anyone is interested for a PAX/PAX2 Kiss interface, tell me (it needs to understand first the Pax protocol...). 73 Patrick Patrick, Based on K2MO's findings, I believe that extending the KISS interface to PAX could be useful, if possible, as there is some 10 dB adventage with PAX vs. Bell 103. 73, Jose, CO2JA
Re: [digitalradio] VOX not for ARQ modes
Seems we are reaching the age of the crippled PC. For a desktop there should still be a chance of adding a serial port PCI card. I have never used the parport for PTT so far, and it seems I never will... USB is adequate for most common PC jobs, but not for interfacing radios without some _special_ interface. And of course, managing RTS seems to be the most adequate way of applying PTT to a radio. All other ways (VOX, CAT, etc) seem to introduce too much latency in an ARQ link. VOX may be OK just for keyboarding, which may be the the solution for most users, but hardly is a one size fits all solution. 73, Jose, CO2JA --- expeditionradio wrote: Peter OZ1PIF/5Q2M wrote: Either you have to add an external USB- RS232 [...] or resort to the VOX solution. Hi Peter, For ARQ or handshaking modes, VOX is simply way too slow. Signalink will not work. Not an option. Let's crunch the numbers: 1. Really fast VOX with 25milliSecond PTT delay. 2. Add 12mSec to 30mSec transmitter 90% power ramp-up. 3. Total delay = 37mSec to 55mSec! Now, let's take a typical example of a slow ARQ or handshaking mode running at 125 baud (symbols/second) It transmits one symbol every 8 milliseconds. In 37mSec, you have missed 4 symbols. In 55mSec, you have missed 7 symbols. Each time you miss some symbols, this creates more errors that need to be corrected somehow. So, each transmission with a VOX system, you create errors... and each ARQ transmission is trying to fix the previous transmission's error, and the previous errors in the transmissions before that... a vicious cycle :) The other issue is VOX release delay. The longer it is, the more the receive decoder will miss symbols. VOX is totally wrong for ARQ modes. I'm surprised that Signalink doesn't offer any RTS keying, it would be so easy to add to their interface. They are really shooting themselves in the foot with their design choice. A lot of hams are buying these Signalink and other VOX interfaces, and they don't realize what they are missing by doing so. Of course, Signalink doesn't tell them, (the truth would be bad for business). 73 Bonnie VR2/KQ6XA
Re: [digitalradio] Re: signalink sL+
Off list. Don't want to spill gasoline on the fire. Does your Signalink use a COM port at all? My interface is homebrew, and uses one COM port to derive PTT from. Packet is tolerant of losing part of the flag bits, maybe pactor too, but AMTOR does not tolerate delays at all. It has been years that I do not make an AMTOR QSO. 73, Jose, CO2JA Sholto Fisher wrote: Bonnie and all, I use the SignalLink SL-1+ (older version, not USB) for ARQ modes successfully. I use MultiPSK and the ARQ modes I have tested and had working are: ALE 141A, ALE400, Pax/Pax2 and Packet. As there is no sound card Pactor (or AMTOR) ARQ there is no way to see if it works but I think it probably wouldn't and almost definitely not on AMTOR. But with ALE400 you have a better mode than Pactor-1 anyhow. 73 Sholto.
Re: [digitalradio] Path Simulator Test - PSK FEC31
SNR in a 3 kHz BW has become a gauging standard. Even when a PSK decoder may see a PSK31 signal some 16 dB better on a 63 Hz bandwidth. Even when the actual signal is much narrower and the decoder uses a matching bandwidth, which allows a better SNR to the demodulator, it is useful to have a standard to compare, which matches the radios in general use nowadays. Stating different measuring bandwidths for different modes would obscure the results if you want to make such a comparison. A PSK31, detectable at -10 dB on a 3 kHz BW may ideally be a +6dB signal on a 63 Hz BW, assuming equal noise density in the whole 3 kHz passband. Apples remain apples, oranges remain oranges, and you can weigh them with the same scale. 73, Jose, CO2JA --- Tony wrote: Mark, If the SNR is negative, how is it that you can copy any signal? The path simulator adds Gaussian white noise to the input signal to simulate a signal-to-noise ratio through a 3KHz band pass filter. If the SNR is less than 0, it's below the noise level. The signal is still there, it's just weaker than the noise. Tony, K2MO - Original Message - From: Mark Miller [EMAIL PROTECTED] To: digitalradio@yahoogroups.com; digitalradio@yahoogroups.com Sent: Thursday, August 21, 2008 5:42 AM Subject: Re: [digitalradio] Path Simulator Test - PSK FEC31 If the SNR is negative, how is it that you can copy any signal? 73, Mark N5RFX At 02:36 AM 8/21/2008, Tony wrote: __ Sensitivity Test - Direct Path (no ionospheric disturbance) Minimum SNR for error-free copy Contestia 500/32-15db DominoEX-4 ..-15db F Announce your digital presence via our Interactive Sked Page at http://www.obriensweb.com/sked Check our other Yahoo Groups http://groups.yahoo.com/group/dxlist/ http://groups.yahoo.com/group/contesting http://groups.yahoo.com/group/themixwgroup Yahoo! Groups Links -- MSc. Ing. Jose Angel Amador Fundora Profesor Auxiliar Departamento de Telecomunicaciones Facultad de Ingenieria Electrica, CUJAE Calle 114 #11901 e/ 119 y 127 Marianao 19390, Ciudad de la Habana, Cuba Tel: (53 7) 266-3445 Email: amador at electrica.cujae.edu.cu
Re: [digitalradio] AX.25 vs Something New
As I understood in a quick reading, this is aiming at keeping the modem and adding intelligent redundancy, specially for beacons and telemetry. The older equipment just receives some more harmless digital rubbish, and could even receive the same packets with no improvements. Interesting, anyway, because they also report improvements. It has a merit, it keeps compatibility with the deployed equipment base. Also, that they make the improvements in a borderline sublayer, placed on the lower region of layer 2. The effect could be similar to doing it on top of layer 1... But my appreciation is that this still falls short for HF. My idea was not to mess with the protocol, but aim at what I perceive is even weaker, the HF modem. Would a hybrid, FX.25 / more suitable modem combo be worthwhile to investigate? Jose, CO2JA Chuck Mayfield - AA5J wrote: Several modems on that link claim fx.25 compatibility; TNC-X comes to mind, but they all seem to have been developed for VHF/UHF use, so YMMV on HF. Chuck AA5J
Re: [digitalradio] AX.25 vs Something New
Rud Merriam wrote: I suggest anyone interested in this topic start by reading http://citeseer.ist.psu.edu/cache/papers/cs/2504/http:zSzzSzpeople.qualcomm. com/karnz/papers/newlinkpaper.pdf/karn94toward.pdf by Phil Karn KA9Q. If anyone does not recognize his name or call then research him because he is an icon in amateur packet and digital communications. One of the experts. Just to tease the article starts by saying that AX.25 is widely recognized as far from optimal. There are some additional articles by Phil and others that address the issues with AX.25, including the hidden transmitter problem. OK, I will try to get this or the other links. I only have mail at home, and I am on holidays. Of course I know about Phil Karn. I have been an AMSAT-NA Life Member for 28 years and a licensed ham for 36 years. I am also aware that AX.25 is far from optimal, but so far it works. Tearing it all down and redoing or substituting looks scary at the present perspective. It would trash most TNC's and packet software in developed and developing countries, those that do not have the Internet as available as tap water. Would that be fruitful? You mention protocol layers. Which model do you want to use for discussion, OSI or the Internet model? Perhaps not a big question since layers 1 2 are the same but once we start moving up the stack they differ. I have been speaking about the seven layer OSI model. It is the relevant one for AX.25. I quote for reference: This protocol conforms to International Standards Organization (ISO) Information Standards (IS) 3309, 4335 and 7809 High-level Data Link Control (HDLC) and uses terminology found in these documents. It also follows the principles of Consultative Committee in International Telegraph and Telephone (CCITT) Recommendation Q.920 and Q.921 (LAP-D) in the use of multiple links, distinguished by the address field, on a single shared channel. Parameter negotiation was extracted from ISO IS 8885. The data-link service definitions were extracted from ISO IS 8886. I was referring to digipeating with respect to routing. Routing messages is the big problem with a ham network because the connectivity is totally dynamic and the issues with hams changing locations. Overall routing is a layer 3 protocol problem. Well, if packet radio is in the sad status it is nowadays, it would be even harder, if not impossible, to add such capabilities just by the hams effort. It does not seem realistic to me now. Your perspective on the use of AX.25 hardware probably differs from mine. There is little of it in use in the US except for Winlink 2000 VHF/UHF links. Providing gateways and bridges to existing networks is problem to address. We certainly have different perspectives. For me, HF was the way to achieve BBS connectivity and forwarding at large distances. HF forwarding has lost critical mass, and I doubt if it will ever recover it without a sound improvement. Whatever the causes may be, the BBS forwarding network is virtually inexistent, all has gone to WL2K and that is only for email style exchanges, using hard to get controller boxes, and far from the style and content of the old BBS network. That was a way of getting news relevant to hams, DXpeditions, operating events and plain ham to ham contact all around the world. It was important to many hams without email and Internet connectivity here. Packet was window to the world, accesible from your own equipment, that did not require fees or permissions other than an appropiate ham license. This situation is still widely prevailing. The possibility of better modems and a change of paradigm back to HF packet radio (or a suitable substitute) gives me a slight hope that some of the large network that once existed might be regained. First things first, I feel that an reconfigurable modem, or at least, a more suitable one is a priority. If a better protocol ever gets developed to substitute AX.25, it could use it. With the protocol in use, or another, we still have the same modem problem standing as a quarter of a century ago. 73, Jose, CO2JA
Re: [digitalradio] Re: Has anyone looked into FPGA-based digitalmodes?
Graham wrote: I really do not understand Graham's proposal: a narrow band spread spectrum system? I really need some more clarification about this.*** Ok may be a bit like calling a steam train a iron horse, dose the same thing but a little differently Spread spectrum : may not be quite the intended system, more like a frequency agile system within a constrained pass band, where data packet are transmitted, by say psk31 type modulation, on random channels within the pass band – collision avoidance with multi users, and short data bursts Now I see. Frequency hopping spread spectrum. Those channels are not really random, but pseudo-random. I foresee two problems: 1) Coordination. The necessary codes should be defined. Netting those transmissions is not trivial, calibration issues are important and not all radios are calibrated equally. A heavy task for CAT, indeed. I am not sure it can be done well enough, or without special radios. 2) Administrative. It will be hard to convince communications administrations to let run systems they cannot monitor easily or reliably. PSK31 is not suitable per se, it is not thought for reliable transfers but for casual keyboarding. Emphasis is on quick responsiveness, because features that increase reliability of transfers also increase latency, which is felt as undesirable by many keyboarders. Count me in, I react differently if I want to chat with few erroneous characters that do not obliterate the meaning or if I want to transfer a file reliably. AX25 : merely as comparison to existing mode's of operation, some kind of watered down system that would allow routing via other stations, mail boxes that sort of thing, ok the data rate wont be too high, but just a novel system using the pc as a intelligent modem. could transmit command/route packets and data packets to keep things short Actually, it is not only AX.25, but using the BBS Interface Specification Working Draft 11/28/93 Is there any newer? I have not seen any other, newer or improved. FBB modified some aspects of it, specially regarding compressed transfers, but this is the basic protocol as I understand. I also keep the FBB protocol docs on a backup CD. The FBB and JNOS sources could be a good guide for someone interested in the tiny details. FBB does it better, with Z-modem style transfers that resume the file transfer where the link is cut. That also reduces the spectral footprint. If you views the system on a waterfall display, you would see, what looked like random vary length , short psk31 (type) signals appearing simulations'ly with in the system band with on say fixed channels with the odd collision and extended gaps …. Depending on usage why not start to double up on the cannel usage to give a fec function under good conditions A waterfall would be a good thing. It was particularly hard to net in, even with a well calibrated radio without being able to really watch the spectrum using a TNC with no tuning indicator. Summarizing, I believe this is too complex and creates more problems than solutions. That is my personal perception. What I feel is needed is something based on the established technology (AX.25, BBS Spec) with a new modem more suitable for HF than the old Bell 103 modem. I see divided opinions, many prefer the shared frequency concept. This is not without problems. Bad or uncoordinated parameters, hidden stations, collisions, all reduce the transfer efficiency. I still remember that 14095 could be quite messy at times. I participated on a net where one station was the hub and clearinghouse, all had to be coordinated with the net manager, and it worked rather well. Something similar to frequency hopping but not exactly so were the procedures used by the AMTOR/Pactor mailboxes, scanning several channels per band, and using one for the entire connection period. What does this has to do with FPGA based data modes? At the end, we still need a better HF modem than the Bell 103. One step at a time, I would love to see a better, open source, low cost mousetrap implemented for reliable transfers. I feel important to note and take adventage of what strategies are proven to work, and not reinvent the wheel. Exact bit to bit compatibility to say, pactor, is not as important as a good robust modem, negotiable signaling speed and coding adapted to HF propagation, among other aspects. Adaptive equalization might be used advantageously in a modem. Maybe some good ideas could be taken from Q15X25, with care, of course, because it also left a not satisfied wish list. It is not necessarily as simple as stating such a wish list, but there should be some intellectual property modules that actually do some of the above, in modules, to simplify the programming tasks ahead. 73, Jose, CO2JA Announce your digital presence via our Interactive Sked Page at
Re: [digitalradio] Re: Has anyone looked into FPGA-based digitalmodes?
My experience has been that the weakest point on HF packet were a too feeble modem, losing frames with just one erroneous bit and bad, aggressive parameters. There were other reasons, like stations not zero beat on each other, hidden stations, etc, nothing to do with the protocol. I have been a BBS sysop since 1992. I am proposing what I know that worked, is well documented and discussed by teams of experts, based on standards that may be incomplete, or not fit to the purpose. I am not sure if working from the gropund up is going to be viable. Maybe I am a bit conservative but creating a new wheel may never make it roll. Very likely, that was the reason for using a modified version of X.25, even when I know no firm details about this choice. I have seen discussions about all this in a QRZ disk I gave to a friend many years ago and never returned. I cannot remember many details right now. He finally quit packet and hamming... It would be interesting to learn in detail which are the reasons you state that make AX.25 unsuitable. I finally dug and found some of my old documents. I am not proposing to tack some FEC to AX.25, because AX.25 is Layer 2, and modems belong to layer 1. What I am proposing is not to touch AX.25, but rather, to make the transfers closer to the environment that X.25 expects. A more reliable modem can certainly help to get closer to that goal. Going from simple to complex (even when reworking the modem may not be too simple), I would start from what I know is wrong, the modem. When you refer to message routing, what do you mean? Specifying the other end of the link, or specifying digipeaters? Digipeaters are wrong, inefficient, but may be useful if used conservatively, with care, maybe one, and not more than two seems to be in the acceptable ballpark. I have used even internally in the same PC to link two different BBS programs, or more. Nodes are preferable, if they can be found and used. Why is routing wrong, from your point of view? What would substitute routing to reach the destination? I am not entrenched, but very curious, I know I do not have all the answers, and an open discussion, some brainstorming, may clarify ideas. DAMA could provide a solution to collisions, but I don't see how DAMA would work on HF, because to keep control, routes must be stable, and HF isn't. And DAMA does not allow TCPIP but on connected mode, and I prefer to use TCPIP in datagram mode. Something else is the amount of equipment out there that uses AX.25, and trashing all that may be the final death shot. That's the reason to strive for compatibility, because many TNC's had disconnect headers to use different modems and there is a lot of work done that would be uncertain to be repeated, among them, the support for AX.25 in the Linux kernel. I believe that we would need very compelling reasons to trash AX.25. 73, Jose, CO2JA --- Rud Merriam wrote: Again, AX.25 is not suitable for many reason so a new standard is needed. It is based on X.25 that assumes a reliable link which is obviously not the case with RF. Simply tacking some kind of FEC onto AX.25 will not suffice. AX.25 includes message routing which is inappropriate for that level of protocol. The URL in my signature is a place for assembling information about all of this. It has been around for awhile but nobody has taken me up on the offer to contribute. I will get back to actively working on this material but a broken arm last spring side tracked me, along with summer family visit commitments. Rud Merriam K5RUD ARES AEC Montgomery County, TX http://TheHamNetwork.net -Original Message- From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Jose A. Amador Sent: Wednesday, August 06, 2008 1:54 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Re: Has anyone looked into FPGA-based digitalmodes? What I feel is needed is something based on the established technology (AX.25, BBS Spec) with a new modem more suitable for HF than the old Bell 103 modem. 73, Jose, CO2JA
Re: [digitalradio] Re: Has anyone looked into FPGA-based digitalmodes?
Paul L Schmidt, K9PS wrote: I've got to agree with Jose here. AX.25 works pretty well on VHF, but falls apart on HF. But AX.25 is a link-layer protocol, not the whole suite of stuff that got crammed into a TNC. AX.25 may have been derived from the X.25 landline protocol, but using the obsolete landline modem under it is the real problem. Tacking some kind of FEC onto the current 300-baud FSK modem that is generally used in the TNC's implementation (but has little to do with AX.25 other than being a common physical layer to hook it to) is a bit of an oversimplification. Nevertheless, even that works pretty well. If you could ever check how well CHU modulation works for setting the PC time, one minute after another, using the same Bell 103 tones. I am using Patrick's CLOCK program. I find WWVB less reliable, and WWV a lot less. I do not have Internet access here, and that is what I nowadays use to keep my PC on UTC time, set my wristwatch and other clocks around the house. But no, don't stop just tacking FEC on the old modem, if there is a better approach, please go ahead. But using a carefully designed FEC layer on top of a more appropriate baseband signal -- then hooking it up to the AX.25 link layer and whatever else goes on top of that -- that sounds like a quite reasonable approach. Setting reasonable goals usually gets the work done. In fact, putting ALL of the TNC (soft Z80, I/O ports, as well as a re-designed physical layer) into an FPGA, then running the existing TNC firmware on the soft CPU, sounds quite workable. A drop-in replacement TNC for BBS, etc. operation -- which could support both new and old modems. Looks the same to me. Rud Merriam wrote: Again, AX.25 is not suitable for many reason so a new standard is needed. It is based on X.25 that assumes a reliable link which is obviously not the case with RF. Simply tacking some kind of FEC onto AX.25 will not suffice. But putting an appropriate type of FEC to make the link reliable enough should suffice. Maybe viterbi-encoded data with a Reed-Solomon code on top of it (such as is used in satellite links). Certainly. I have witnessed a slower signaling speed Pactor link to beat 10:1 my older packet links, with a lot less power, heat and energy expense. AX.25 includes message routing which is inappropriate for that level of protocol. Which doesn't have to be used. The connect to xyz via abc and def was more of a hack to get by until something better came along. One shouldn't be digipeating on HF, anyway. Use it for point-to-point and that's it. I would not sweep that away. It allowed me to run a DXCluster for some time, along with a node, a FBB BBS and a JNOS BBS. I did digipeat one hop within the PC from DXNET to reach JNOS and make the telnet link to the cluster on the Internet. I used DXNET on a very resource limited 486 and it worked very well, it was a reasonably quick hack in a moment I did not have the time or resources to run a more complex DX Cluster on Linux. One digipeated hop within the PC is lightning fast. Using digipeaters on the air is something else. I rather not abuse of digipeating, but it can be the only way to reach a well located node during an emergency. Treat that as a knife or a gun, and use it only for very compelling situations. 73, Jose, CO2JA
Re: [digitalradio] Re: Has anyone looked into FPGA-based digitalmodes?
I have been playing with what has been available around, and the past august, I devoted quite a bit of time to receive DRM. It is not easy, in spite of the high powers the broadcasters use, and the more succesful ones are the less greedy ones. I had far better results with RNZI and its 17 kbps mono signals than with the BBC or Deutsche Welle with pseudo stereo, EPG, etc, needing more than 20 kbps on a 10 kHz channel. I had quite a bit of trouble to succeed until I found that the noise figure at the input of my soundcard was not good enough due to current noise. I just added an output amplifier to my IF converter to have low output impedance and higher output level, to reduce the noise due to a high equivalent impedance Thevenin source out of the CMOS switches and to swamp any voltage noise without overdriving the soundcard input. I got more than 10 dB improvement that way. DRM signals around here are not too strong, and I got heavy multipath problems from Sackville and Montsinery, sometimes with comparable strength components that cannot be disregarded. The more complex the constellation is, the less robust it will be. The smaller payload results seems consistent with the results of FDMDV vs WinDRM on the ham bands. Nowadays solutions have been worked out to allow switching speeds on a digital link. One that both the chinese digital TV standard, DMBT, and DRM use is to have a time multiplexed fast access channel using 4QAM which tells how the main service channel is modulated. I believe that DVB works that way as well, I have to recheck my references. I have a gut feeling thet we should not use anything more complex than 16QAM for the main channel of ham stuff, taking the powers we may use into consideration. This should not be surprising. It is the same general idea as using the MFSK Reed-Solomon preamble mode indicator that MultiPSK and others now use. I have told about what others have done on LOS links on VHF/UHF, but maybe on HF PSK or QAM are not the only ways to go, and some other modulations might be useful sometimes as well, that is something to sort out. Something to be weighed is potential traffic capabilities vs real traffic performance. HF packet had a higher than usable transfer rate at times, and every repeat takes a 1/(n+1) toll on transfer capability, one retry halves it, two retries may equal a 100 baud link, and so on. So, why tolerate retries, if an acceptable FEC and signalling rate can be found? Minimizing retries optimizes the spectral footprint. Why is Olivia so robust? Because of a well thought FEC. The same applies to Pactor II/III. I believe that developing a usable speed change algorithm is going to be the trickiest part of it, being HF propagation the way it is. Nevertheless, even when there are no detailed specs of the latest pactor solutions, we have enough hints to compare what works on pactor and is missing on other solutions. Even a non complete copy of Pactor, just mimicking the known strategies may work. But it looks to be the way to go. Phone modems did it first, and pactor proved it can be done succesfully on HF as well. Certainly, it is no piece of cake, but anything less than that will certainly be less than optimal. About SCS stuff, it is not cheap, but it is neither too unfair to charge for some really good intellectual property that actually does work. Even when the soundcard seems the way to go, I would not discard a priori a hardware solution as the one being proposed. It has the beauty of distributed processing, and is not tied by operating system constraints. Something to be learned from SCS as well, flashable firmware. It is very easy to distribute and install firmware updates for DSP modems. It eludes the technological jail of non reconfigurable systems, and extends the value of such solutions. Getting new modes, or improvements of former ones is really easy that way. Something that has been nearly forgotten is the YAM modem, a FPGA FSK modem originated in the 90's, which required its RAM to be loaded first to configure it when started, loadad from the same serial port it got data from during oparation. There were 1200 and 9600 baud alternatives from the same device, loadable at boot time. Flash or RAM FPGA's could be good, flexible alternatives with versatility in mind. 73, Jose, CO2JA Rick W. wrote: Very good points, Jose, Some of us had very high hopes for Q15X25 but never heard much about it after it was tested, some years ago, even though some of us asked repeatedly for information. It has taken a few years to hear bits and pieces, but it seems that it just was not robust enough. I was not aware that Kantronics included this mode in any of their products. Can anyone here tell us more about this or any success (or not) that they had? I can see that this mode is really very similar to Pactor 3 at the higher speed levels since it uses QPSK and 15 tones. The baud
Re: [digitalradio] Re: Has anyone looked into FPGA-based digitalmodes?
There are multiple examples of reconfigurable devices that might prove viable and not too costly. I am certainly not advocating against sound card modes, or for high cost hardware. For me, hardware might prove harder to get than software, but I just won't allow that fact to blind me. Don't lose sight that quite a few of the present sound card modes appeared from previous work in hardware (PSK31, JT44, etc). Let them work. And I am also in favor of open source solutions. 73, Jose, CO2JA Linux User 91155 http://counter.li.org --- Jeff Moore wrote: $1000 modems are not going to be viable! Not if you want widespread usage. Stick with open-source non-hardware based solutions. Jeff -- KE7ACY
Re: [digitalradio] Re: Has anyone looked into FPGA-based digitalmodes?
, Patrick Lindecker [EMAIL PROTECTED] wrote: Hello all, For my small experience about ARQ modes, it seems to me that: * a modern ARQ system does not really need a synchronous scheme as in Pactor (with obligation to permanently exchange frames). It must be asynchronous as Packet, Pax or ARQ FAE, at least to be able to share the frequency (collisions must be managed), * I don't think a powerful coding is really necessary. I think a ratio of 1/2 (one information byte received for two bytes transmitted) is sufficient (as in ARQ FAE or ALE DBM). Big block codings as in JT65 or Olivia with ratio of 1/5 or less would be exagerated and will decrease drastically the characters throughput. I don't think convolutional codings are conveneint for ARQ modes as you must introduce a relatively big delay before deciding what was the received characters. These codings are more convenient for continuous modes (as in PSK63F), * an ARQ memory is absolutly necessary. You can forget coding but you can't forget this tool. It is equivalent to a repetition coding and it permits to reduce drastically the number of retries, * if you have an ARQ memory the minimum S/N is not given by the message itself but by the possibility to detect the frame. If you detect the frame, you will be sure to decode it (directly or through one or two retries). This means that you could do a system very quick and also sensitive in the same time (if you accept the number of necessary retries). Practically, the minimum S/N will be determined by the speed of transmission of the frame prefix (in ARQ FAE , for 50 bauds the minimum S/N is about -13 dB. This means that for 500 bauds it would be -3 dB and for 5 bauds it would be -23 dB). The speed prefix transmission must be independant from the message speed transmission, * if I would want to do a very quick ARQ mode (but I'm on very slow modes at the moment), I will prefer a THROBX modulation (a choice of 2 carriers over n) than an OFDM, this because the maximum power transmitted is very low if you want to keep linear (1/sqrt(n) if n is very big). A configuration with a mean power/peak power below 1/3 is not a good configuration. I would switch from a non coded transmission (good conditions) to a coded transmission (bad conditions) according to ionospheric conditions (as determined on frames reception). A predetermined (i.e known) sequence as in 110A to determine the channel transfert function would be perhaps interesting. * I think MFSK modulations are better than PSK modulations. * Doing a very quick ARQ mode is not very fun... Doing a system able to permit exchange between several Hams would be much more fun. 73 Patrick Announce your digital presence via our Interactive Sked Page at http://www.obriensweb.com/sked Check our other Yahoo Groups http://groups.yahoo.com/group/dxlist/ http://groups.yahoo.com/group/contesting http://groups.yahoo.com/group/themixwgroup Yahoo! Groups Links Announce your digital presence via our Interactive Sked Page at http://www.obriensweb.com/sked Check our other Yahoo Groups http://groups.yahoo.com/group/dxlist/ http://groups.yahoo.com/group/contesting http://groups.yahoo.com/group/themixwgroup Yahoo! Groups Links -- MSc. Ing. Jose Angel Amador Fundora Profesor Auxiliar Departamento de Telecomunicaciones Facultad de Ingenieria Electrica, CUJAE Calle 114 #11901 e/ 119 y 127 Marianao 19390, Ciudad de la Habana, Cuba Tel: (53 7) 266-3445 Email: amador at electrica.cujae.edu.cu
Re: [digitalradio] Re: Has anyone looked into FPGA-based digitalmodes?
suitable substitute. It is made by SCS, yes, and requires a PTC to plug it in. Period. Nowadays I cannot accept anymore that a raw 300 baud modem is the solution, and many quitters, sadly, seem to corroborate this lately. Convolutional coding is used not only by space communications, but by Pactor II and III, and by WSPR, and it _*does work well on HF*_ Block codes and interleaving are used by many professional protocols, like DRM, DVB-T, DVB-S, DMBT, and actually, not in vain. Enhanced ATSC uses two layers of Reed-Solomon coding, so, why leave those signs pass as unseen ? The best seem to be LDPC and turbo codes, but there might be some patent issues with them, of which I am not sure right now. So, I was happy using Pactor-II to do BBS forwarding in HF, of course, on different frequencies to the mainstream forwarding ones, and it did work well for the links to the US, Europe and Africa, sometimes with as low power as 25 watts (PEP) on a dipole or a vertical antenna for twenty meters. It was the alternative for me, and I am glad I used it. It meant a 10:1 spectral footprint improvement. Something else is the mess the forwarding routes have become, but that is a different topic. 73, Jose, CO2JA --- Charles Brabham wrote: PACTOR, being an ARQ mode is incapable of sharing a frequency with more than one other station. That, along with the extreme bandwidth and lack of effective signal detection makes PACTOR unsuitable for digital HF networks on anything but a very limited scale. - A few afficianados can play around with it, but in that case as the network grows, more and more participants cop out and use the internet band-aid to cover up for the mode's basic lack of suitability for HF networking. Or they do like WinLink and run roughshod over their fellow hams, operating what amounts to a QRM mill that takes up more and more spectrum as the network grows. HF Packet, warts and all, is currently the only digital mode that a serious HF network can be built upon. The secret to this performance edge is AX25, which allows multiple stations to share a single frequency. The more reasonable bandwith there is also a positive factor that appeals to responsible amateurs who know how to play well with others. They call this spectral efficiency and if your mode of choice does not have it, best to keep it for keyboard use and leave the networking to the networkers. It is fashionable to diss Packet radio and AX25 - but none of the detractors have been able to demonstrate anything that does HF Packet's job any better... In fact, nobody has come up with anything yet that even works as well. Performance talks, and fashionable PC attitudes walk when actual networkers look at the available digital modes. That's the way it is... Maybe someday there will be an actual improvement over AX25 and Packet for HF networking. When this happens, I'll be one of the first to put the new system on the air and into actual use. BUT I have witnessed and been part of several efforts to improve upon AX25 and Packet over the last couple of decades, and what has been found in every case so far is that it is awfully easy to sit around and diss AX25 Packet for HF networking, but not so easy to come up with something that actually works as well, much less any better. If there was anything actually better out there, the HF digital network would already be using it and AX25 Packet would only be found on the VHF/UHF bands. But there isn't, so... 73 DE Charles Brabham, N5PVL [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] - Original Message - *From:* Jose A. Amador mailto:[EMAIL PROTECTED] *To:* digitalradio@yahoogroups.com mailto:digitalradio@yahoogroups.com *Sent:* Sunday, August 03, 2008 9:16 PM *Subject:* Re: [digitalradio] Re: Has anyone looked into FPGA-based digitalmodes? I believe that both the AX.25 and the BBS model are OK, but that the packet channel coding is a disaster in the sense that a single erroneous bit trashes a frame. That fires up the retries chain that are so detrimental to the link capacity, and may sever it as well. Pactor does a _LOT_ better, as it is able to use frames with errors that would be useless on packet using different FEC mechanisms. Source compression may help as well, as FBB and WL2K do. If the signalling speed can be made to match the channel and the protocol yield capabilities under a certain level of errors, a huge relative improvement can be achieved. That is the big adventage of WL2K, the use of Pactor II and its better channel coding. The rest is much alike the old BBS system, reworked. I believe that something that achieves similar results to those stated above will certainly be a step ahead. 73, Jose, CO2JA
Re: [digitalradio] Re: Has anyone looked into FPGA-based digital modes?
I believe that both the AX.25 and the BBS model are OK, but that the packet channel coding is a disaster in the sense that a single erroneous bit trashes a frame. That fires up the retries chain that are so detrimental to the link capacity, and may sever it as well. Pactor does a _LOT_ better, as it is able to use frames with errors that would be useless on packet using different FEC mechanisms. Source compression may help as well, as FBB and WL2K do. If the signalling speed can be made to match the channel and the protocol yield capabilities under a certain level of errors, a huge relative improvement can be achieved. That is the big adventage of WL2K, the use of Pactor II and its better channel coding. The rest is much alike the old BBS system, reworked. I believe that something that achieves similar results to those stated above will certainly be a step ahead. 73, Jose, CO2JA --- Bill McLaughlin wrote: To echo what Rick stated, FAE400 is an extremely useful ARQ mode that has a lot of potential; robust yet reasonably narrow. Works very well, just a shame so few use it. NBEMS is also a good ARQ suite, but a lot slower when using HF friendly modes. No sure the lock-up time using MFSK16 has been resolved but the new FLDIGI had the mode THOR, an incremental shift keying mode similar to DominoEX. Not sure if that will be implemented into NBEMS, although it certainly has that potential, especially as it retains DominoEx's tolerance to frequency accuracy. The ax25 packet structure was fine; problem was/is that ax25 at 300 Baud on HF, unless near MUF, is a less then optimum speed choice. It actually works fairly well at 110 Baud but it is slow. I think there are many good protocols out there, but not many want to experiment. 73, Bill N9DSJ
Re: [digitalradio] Diagnosing issues with dropped PC
Andrew O'Brien wrote: Please excuse the non-ham question but hopefully folks here will have an idea or two. One of my household PCs (not the ham PC thankfully) was dropped during a move to another room. Out spilled the memory cards, wireless PCI card, and the CPU heatsink fan. After reinstalling I get the PC to briefly boot up and then it shuts it's self down. The shutdown is too quick to get a any beep codes, the first couple of attempts I heard a European siren-type noise for a few seconds. Anyone here have any guesses what the issue would be? Andy, I would check the memories for integrity, perhaps in another compatible computer. Also, I would check the beep codes to understand what the siren means. I wonder about CPU overheating but the fan snapped nicely back in to place and the fan appears to work fine. Any chance the bang to the PC would cause the CPU heatsink to lose a seal with the CPU? I have not taken the CPU heatsink off yet, it looks firmly in place and apart from some dust in the heatsink fins, it looks OK. Make sure it is firmly seated. What it takes is thermal grease, like any semiconductor device attached to a heat sink. My P4 came with a square of something like chewing gum which is thermal compound and goes between the microprocessor and the heatsink. I have always judged a good thermal contact by the stickyness of the heatsink. If you have to pull it with a bit of force after the locks are released, there is a good contact. The thermal compound fills the small voids in the mating surfaces and when you pull it, it creates a bit of vacuum. You should have some temperature indication on a setup tab. Check that the core temperature is not excessive. On the most recent attempt I took one of the memory sticks out and the PC boot-up lasted long enough to tell me that the firmware had detected a change in memory configuration. That is certainly a positive sign. Then I briefly got the flashed message about pressing a F -Key if I wanted to access the BIOS. Then it closed down. I am taking that as a sign the hardrive was briefly accessed. That looks like overheating. Make sure the CPU is making good contact to the heat sink. Leave just one memory stick to boot. You could even test it with no disk, the boot process would stop when it finds no bootable device, and should not shut down by itself. Check the performance of the motherboard with a diagnostic program, like Aida32 or Everest. There may be some loose contact due to the impact. Check memory sockets with a previously checked good memory. The impact may have damaged a printed circuit board line and make a good memory lok bad. If the memory modules pass the test, plug all in their places and make sure all are well seated. I am wondering if one would get similar symptoms if the power supply was somehow damaged during the fall ? There is a possibility. Check the voltages in the corresponding setup tab, or with a digital VOM. You should have stable +5 and +12V on the disks power connector. 5 volts should be OK between 4.75 and 5.25 V, but usually the error will be much less, from 4.9 to 5.1 V 73, Jose, CO2JA
Re: [digitalradio] Olivia mode performance
If I am allowed to summarize, if you don't own a PTC, at least give Olivia a try 8-) Impressive indeed, Tony. 73, Jose, CO2JA --- Tony wrote: All, Certainly is remarkable the way Olivia mode performs under adverse conditions. Was having trouble decoding VK2PN in PSK31 mode due to the unstable conditions at the time (selective fading / multi-path). Switching to Olivia 500/16 fixed the problem. Copy went from marginal to perfect (see captured text below). We certainly are lucky as digital ops to have a variety of modes to choose from. Whether it's rag-chewing or dxing, it's nice to have the ability to switch to suit conditions. Tony, K2MO Kings Park, NY __ *e2MO de VKPN VA2PN pse kn o e¬ i * VK2PN DE K2MO Thanks for the call, your 449 449 New York. Name is Tony Tony. Hw cpy? VK2PN de K2MO K *Hi An ponm r coming back o me, Your ttport : 559 55y naie is : atrick Patri Hr the QTH is : Sdney Syacey Locator: QF56pe BF56pe You ate not as tong as the previous sttnon ot the bxd is closing by now.h s Funny propagation we get lo ely e.. very stong sils and then iuddel th and loses a 7 all sigs are gone tHow do yoe mopy? BTU vethe , K2 iO V - t Dn t tCnte h Ot * OK Patrick, thanks for the 559 report and ok on your QTH in Sydney. Yes, your not very strong here; do you have any other modes? Can you do Olivia Olivia or MFSK16 MFSK16? KKK *t i t- aTMO de VK2PN OKitns... the bead st b cloaidng... and yeis I can work livia... Woulfyo want to QSY a bidt or soay re on this requenc ?? e So BTU Anthony, K2MO ie VK2Pe c * OK yes we QSY QSY 14072 14072 14072 and 500hz 8 tone 500hz 8 tone is that OK? * Laae r/t-K2MO de VbPN roger QSY 1400ei and K usiog th i%o0 Hz width... fine Obtde vk2piy now Eel90k,)|teG t\j_[1$Wc?fSh * /(SWITCH TO OLIVIA) / VK2PN DE K2MO PSE KKK *v K2MO de VK2PN roger roger Anthony... Yes the olivia is much more robust than the psk hi hi I love Olivia too but there is not as many stations around on this mode. Still I think, I've tried them all and love the Pactor the most. But that is even more rare hi hi Sow is the copy? BTU Anthony, K2MO de VK2PN k * RRR Olivia makes quite a difference, throughput 100%. I'm running 20 watts to a 5 element Monoband Yagi by M2 up 18 meters. VK2PN de K2MO K *eK2MO de VK2PN OH yes. You are right, big diffetence this is 100% copy and OK a bit slower, but who cares... *
Re: [digitalradio] dumb terminal software for packet
Even when I have been away from packet for some time after being a sysop for some twelve years, I have the feeling, but still not the certainty that having MultiPSK to serve as a transparent dumb modem also would be a good thing. Creating a good packet terminal is not trivial, I used FBB for years since version 5.13 and I don't see the need to duplicate the job that Jean Paul Roubelat did. Maybe it still would accept improvements, but I don't see much room for that. It is a job well done and hard to improve when all bases seem well covered. I used pure packet for some six years using BPQ or the Linux AX.25 engine, until I began using a PTC-II and after seeing what it does I just quit HF packet, Pactor II being better by far, just by having a more reliable transfer mechanism than classic packet. I was using FBB, as JNOS 1.11 did not handle the PTC back then. MultiPSK has a suite of modes that could still be useful and unique on HF, and particularly, I like PAX for that, and maybe ALE 400 as modulation / ARQ scheme could be useful too. Maybe others with a full alphabet (required for compressed forwarding) could be useful. I really have not though much about the tiny details. I am not sure about the situation beyond my area, but I certainly do miss HF BBS's, as I had a fruitful and nice experience after all those years. Maybe I need some people to excuse me, but I never liked AGW, perhaps I never did understand it well. I never used extra features of MixW, more interested in its sound card modes, but they never meant an obstacle either. I did use TeraTerm 2.3 and did like it too. I don't know if others could agree with me, I am aware it is not too easy to do, but maybe Patrick could do some research into making it available as a dumb terminal using TCP/IP, KISS or host mode. Just daydreaming by now, but, who knows? I am already used to get nice surprises from MultiPSK. 73, Jose, CO2JA --- Patrick Lindecker wrote: Hello, Multipsk can also be used for a sound-card terminal for Packet (with many other possibilities). But you can also use AGW Packet engine (and of course Mixw). 73 Patrick
Re: [digitalradio] DV Equalizer
Tony, I am using VE3NEA's Voice Shaper for SSB, with good results. I have not used it for DV. I am using a cheap earphone / mic combo, also a good performer. I do not know the Romac EQ, and I doubt I'll try it if it is time limited. 73, Jose, CO2JA --- Tony wrote: All, Does anyone know of a good audio EQ program similar to the Romac 10 band EQ? Need one that can use different sound cards for mic / speaker input / outputs. An open source program would be ideal. The Romac 30 hour trial we're using to experiment with digital voice is about to run out. Thanks Tony - K2MO
Re: [digitalradio] Re: How to -- FDMDV Digital Voice Over HF
Leslie Elliott wrote: Hi - New to FDMDV. I am trying to set up my rig for the mode, and can receive OK, but so far my set-up won't let me transmit. I'm using a FT-920 and a Signalink SL 1+ connected to the data port on the 920. I am using a outboard SoundBlaster USB soundcard, connected to the audio in and out of the Signalink. This set-up works FB for all the other digital modes, but since this mode requires 2 soundcards, I'm having trouble seeing how I can use this for DV. I have a non-USB computer mike, and if I connect it to the computers onboard soundcard, how does that audio get to the outboard USB soundcard ? Maybe I need to get a USB computer Mike? No, go to the setup and choose the inputs and outputs for each card. I am using one onboard soundcard and another PCI one. Anyone using this set-up, please let me know how you are connected. I've tried using the on-board soundcard as soundcard 1, and the USB soundcard as soundcard 2, per the directions given, but that doesn't work. Thanks for any help. I'm getting old (72) and my brain doesn't work as good as it might have at an earlier age! LOL KCØPTO Les 73, Jose, CO2JA Announce your digital presence via our Interactive Sked Page at http://www.obriensweb.com/sked Check our other Yahoo Groups http://groups.yahoo.com/group/dxlist/ http://groups.yahoo.com/group/contesting http://groups.yahoo.com/group/themixwgroup Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/digitalradio/ * Your email settings: Individual Email | Traditional * To change settings online go to: http://groups.yahoo.com/group/digitalradio/join (Yahoo! ID required) * To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: [digitalradio] Re: How to choose Olivia tone/bandwidth parameters -- an idea
No, not at all. Just watching the waterfall. I do not remember the little details. Patrick has replied as well, and you can look for them at http://f6cte.free.fr/PAPERS.ZIP, download the ZIP file and extract RS_ID_English.DOC. 73, Jose, CO2JA Paul wrote: Jose, But does that mean you need to be listening in Hell mode? Or does it display on the waterfall regardless of the chosen mode? Paul
Re: [digitalradio] How to choose Olivia tone/bandwidth parameters -- an idea
Interesting, but I believe it has already been done in MultiPSK with the RS ID codes sent in MFSK in the preamble. They seem to work well. I have used Video ID's and maybe your proposal is a bit more compact and readable that the usual video ID's. It should be tested out. I believe tha making Olivia more popular is a good thing. Just some more food for thought. 73, Jose, CO2JA I am crossposting this to the Olivia and MultiPSK groups from the digitalradio group. Seems an interesting point in favor of Olivia. --- Ian Wade wrote: Here is an idea that Olivia developers might care to consider. People often remark that it's difficult to set up the right parameters when receiving Olivia signals. There are potentially eight possible tone settings to choose from (2, 4, 8, 16, 32, 64, 128 and 256 tones) and five possible bandwidths (125, 250, 500, 1000 and 2000 Hz) -- a total of 40 possible combinations -- making it almost impossible to choose the right combination before the signal disappears. Out of these 40 possible tone/bandwidth combinations, there are probably up to 8 that are in popular use: 4/250, 4/500, 8/250, 8/500, 8/1000, 16/500, 16/1000 and 32/1000. Even so, narrowing the choice down to these 8 still takes too long. What is needed is a simple way of indicating which combination is in use at the start of transmission. This is where we can make use of the capability to display text characters in the waterfall. If we allocate a code for each tone/bandwidth combination, and display that code as text in the waterfall immediately before transmitting the Olivia signal, it will be possible to set up the correct parameters very quickly, in time to decode the signal. A possible coding scheme could be as in the table below. The most popular combinations are indicated with asterisks. Each code is preceded by the letters OL- (for Olivia), to identify the mode. So, for an 8/500 signal, you would see the characters OL-12 in the waterfall before the Olivia signal starts. OL-CodeTones / Bandwidth OL-00 2 125 OL-01 2 250 OL-02 2 500 OL-03 2 1000 OL-04 2 2000 OL-05 4 125 OL-06 4 250 *** OL-07 4 500 *** OL-08 4 1000 OL-09 4 2000 OL-10 8 125 OL-11 8 250 *** OL-12 8 500 *** OL-13 8 1000 *** OL-14 8 2000 OL-1516 125 OL-1616 250 OL-1716 500 *** OL-1816 1000 *** OL-1916 2000 OL-2032 125 OL-2132 250 OL-2232 500 OL-2332 1000 *** OL-2432 2000 OL-2564 125 OL-2664 250 OL-2764 500 OL-2864 1000 OL-2964 2000 OL-30 128 125 OL-31 128 250 OL-32 128 500 OL-33 128 1000 OL-34 128 2000 OL-35 256 125 OL-36 256 250 OL-37 256 500 OL-38 256 1000 OL-39 256 2000 This idea could even be extended to other modes, substituting a different code in place of OL. I believe that Olivia is greatly under-utilized because of the difficulty in choosing the correct tone/bandwidth parameters when receiving a signal. Being able to select the parameters quickly by reading the code in the waterfall should go a long way to promoting more Olivia activity. Comments anyone?
Re: [digitalradio] How to choose Olivia tone/bandwidth parameters -- an idea
Clever...simple and evident. There is a common russian phrase that applies kratka sistra talanta, conciseness is the sister of talent. 73, Jose, CO2JA --- Simon Brown wrote: You see the bandwidth already - so why not just OL + number of tones? I don't think users will like a lookup table. Simon Brown, HB9DRV -- From: Ian Wade [EMAIL PROTECTED] Here is an idea that Olivia developers might care to consider. Announce your digital presence via our Interactive Sked Page at http://www.obriensweb.com/sked Check our other Yahoo Groups http://groups.yahoo.com/group/dxlist/ http://groups.yahoo.com/group/contesting http://groups.yahoo.com/group/themixwgroup Yahoo! Groups Links -- MSc. Ing. Jose Angel Amador Fundora Profesor Auxiliar Departamento de Telecomunicaciones Facultad de Ingenieria Electrica, CUJAE Calle 114 #11901 e/ 119 y 127 Marianao 19390, Ciudad de la Habana, Cuba Tel: (53 7) 266-3445 Email: amador at electrica.cujae.edu.cu
Re: [digitalradio] Re: CW - last resort?
Even when I have nothing against DV, people have to recognize that it is not a QRP activity. I see quite a few signals I can never decode because they do not exceed the threshold. FDMDV is not PSK31. 73, Jose, CO2JA --- Jim Dear wrote: Amen, and hopefully someday soon, come into the 21st century by instituting digital voice, as well as the other digital modes currently used. Pax, Jim Dear W5LOG NNN0RKQ
Re: [digitalradio] Re: How to choose Olivia tone/bandwidth parameters -- an idea
Paul, Some programs are capable of sending a Video ID using Hell, so, you can read the ID as a text preamble from the waterfall. MultiPSK also does send a RS ID using some codes sent as an MFSK preamble. FDMDV now does use the RS ID too, to help zero beating on the spectrum center. 73, Jose, CO2JA -- Paul wrote: I think I missed the memo on how to ...display that code as text... Are you suggesting calling CQ in a different digital mode than Qlivia, then switching over? If the listener can read the (Olivia) Text then they are already reading at the proper BW/Tone?? 73, Paul If we allocate a code for each tone/bandwidth combination, and display that code as text in the waterfall immediately before transmitting the Olivia signal, it will
[digitalradio] Re: [olivia] Re: MultiPSK 4.8 doesn't decode all that great on Olivia
garylinnrobinson wrote: I didn't do my comparison's on MixW and Olivia Aid - I did them with DM780 and just recently FLDigi on a separate computer but same sound feed from transceiver since FLDigi is on Linux. Same results. You can say it's just Gary but I don't believe it. And it is doesn't apply to PSK or RTTY they work abt the same on all the progs. If I have to own a special computer or special soundcard or do some special soundcard alignment that I haven't already done - too many hoops for the regular user let alone a guy who has worked in the computer industry as a tech and programmer as I have. There are several factors to consider in order to achieve a fair relative evaluation, and I am sure you know with your claimed background. First, with the data you have at hand could you achieve a quantitative evaluation? As Lord Kelvin stated a long time ago, in science and engineering you actually need numbers to avoid fuzziness. To dissipate doubts, it could be useful if you could also provide your data sets for independent evaluation. Second, are your two computers identical? Same sound card, processor, speed, memory, you certainly wouldn't need to be told all the factors to weigh. Third, as I understand, the AC97 timing syndrome only happens on Windows. On Linux and Unix derivatives, queues, semaphores, etc, have different priorities, and so far, Linux fares better with run of the mill soundcards and associated delays, even when that does not make differences insignificant, for many reasons, not related exclusively to timing. Signal levels, distortion, noise, A/D and D/A converters linearity, Hamming distances of different modulation formats, FEC, data interleaving are also important factors and certainly have an influence on received BER. Something that would be quite peculiar, if proven true, is that all modes show exactly the same problems. It seems important to sort out this particular allegged behavior with valid data to substantiate it. Linux certainly could give an edge to FLDigi, which is, in fact, also a good performer. It might be interesting to evaluate also GMFSK or other available programs, for sake of completeness. I feel that the last paragraph of your posting above is particularly unfair. In many aspects of life, there exist well known price/performance tradeoffs, be clothing, cars, CPU's, soundcards, just to mention a few well known and some relevant ones. When the multimode boxes were predominant, there were designs and brands that were undoubtedly superior to others. I believe that it is a formidable feat to achieve a similar perforance between dedicated boxes with single tasking processors and computers with multiple running tasks on a multitasking or task switching environment like Windows, at the cost it gets achieved. I have not made any well documented comparisons myself previously, and I am using an average card for receiving, an Audigy 2, which is not a Delta, an EMU, or a higher cost cousin, but neither an AC97. So far, I have not found substantial differences between MultiPSK and MixW, before I began using MultiPSK almost exclusively when versions 4.xx appeared. My soundcard does not require a noticeably different setting from its default. Nevertheless, hardware differences may be so many among users, and behaviors under different OS versions that an independent developer cannot evaluate all possible influences without the beta testers and users feedback. Other programs I also use corroborate such a situation. I believe that all users could certainly gain with a fair evaluation that unveils problems that a developer alone cannot certainly find. 73, Jose, CO2JA
[digitalradio] Any good, free programs for a PK-232?
A friend of mine (CO2DC) got a bare, used DSP-2232 and was asking for free programs to run it. I have never owned a PK-232. Could anyone on the list suggest something to pass to my friend ? 73, Jose, CO2JA
Re: [digitalradio] USB - RS232 adapter for Vista 64bit?
Is that Linux or plain old Solaris? Does Wine work with it? 73, Jose, CO2JA --- Rick wrote: Incidentally, I burned an ISO from the new OpenSolaris Live and that seemed much better than Linux variants in terms of image quality. Even could handle my high end HP tower with Nvidia chipset. But then again, the problem is that I could not run my ham software, which is something I am really not willing to give up. 73, Rick, KV9U
Re: [digitalradio] Any good, free programs for a PK-232?
I guess that RTTY, AMTOR, etc. That's up to my friend, I will pass this to him. 73 thanks, Jose, CO2JA --- Dave AA6YQ wrote: That depends on what you’re interested in doing with your PK-232. WinWarbler supports your PK-232’s CW and RTTY modes. You can run RTTY with the MMTTY soundcard engine and your PK-232 simultaneously, providing either diversity decoding or the ability to decode a RTTY DX station and its pileup simultaneously. WinWarbler is free, and available via www.dxlabsuite.com http://www.dxlabsuite.com 73, Dave, AA6YQ Announce your digital presence via our Interactive Sked Page at http://www.obriensweb.com/sked Check our other Yahoo Groups http://groups.yahoo.com/group/dxlist/ http://groups.yahoo.com/group/contesting http://groups.yahoo.com/group/themixwgroup 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/
