Re: [digitalradio] More on FCC contacts
Hello Rein As I have told you before , there is something fishy going. Lets forget about this ros/josh thing and go back to modes like olivia, ale400 and jt65. Ros/josh gives me creeps. la5vna Steinar On 07.03.2010 02:32, Rein A wrote: Hello All, I found this on the VHF reflecor in the US: by Bill Pasternak WA6ITF. WA6ITF is or was publishing an Amateur Radio Newsline and had contacts in the agency due too his present ot previos work ( Radio TV broadcasting ) In thr past I havebeen in contact with him about translating German amatuer radio news items. 73 Rein W6SZ (...)
Re: [digitalradio] Beta testing PSKmail 1.0
windoze ?? Is it a linux clone ? la5vna S On 07.03.2010 10:44, Rein Couperus wrote: Beta tests are under way for PSKmail 1.0 == This new release takes PSKmail to its next logical step. The PSKmail 1.0 digital communication system is largely mode-independent. Both uplink- and downlink modes are separately adapted to fit he channel conditions in such a way that efficient use of the channel is guaranteed. In the PSKmail client/server system, the server controls timing and Rx/Tx modes. To enable this, fldigi has been extended by VK2ETA to report avarage Signal to Noise ratio values and Mode changes during a session. The PSKmail protocol was extended to carry SNR values and mode indexes. Using this information the server can control the modes so that on both sides of the communications link the number of ARQ repeats is kept within certain limits. The system uses PSK500, PSK500R, PSK250, MFSK32, THOR22, MFSK16 and THOR8, and a mode is shifted up and down the table when appropriate. Intelligent RSID control == The PSKmail server also controls the RSID function on client and server. When idle, the server usesRxID. As soon as a session is established, the server closes RxID and uses TxID to make sure theclient is listening in the right mode. This is only necessary when a mode change is involved, so normally no time is lost on unnecessary RSID frames... Limiting repeats to loose less time... As soon as more than one ARQ repeat is necessary the server degrades the mode by one step, to make sure the client gets the next one correct. The server constantly monitors the channel quality both ways, and also uses ARQ success to decide on mode upgrades. Using this system allows fast and flexible response to QRM like ALE sounding or Pactor connect requests trying to take over the channel while a session is in progress. The system just waits until the ordeal is over and carries on with the session... Using new Fldigi-3.20 = PSKmail 1.0 only works with Fldigi-3.20, which has the new support features for PSKmail built in. A client upgrade to jPSKmail 0.4.9.9 (beta) is also necessary, and the server version with the new goodies built in is pskmail_server-1.0 (at the moment alpha2). The new client beta is available for experimenting and beta testing on http://hermes.esrac.ele.tue.nl/pskmail , SM0RWO has provided installers for windoze, Linux and Mac. The server test software runs on PI4TUE, SM0RWO and IS0GRB-3 on 10147.0 kHz (center frequency). The new server image can be found on http://hermes.esrac.ele.tue.nl/pskmail/alpha Fldigi-3.20 can be found on http://www.w1hkj.com/beta New parameter for fldigi === To use PSKmail 1.0 a new parameter has to be set in fldigi-Configure-Misc-Pskmail: Set 'Report ARQ frames average S/N'. Set both the initial server and client modes to the PSK500R default to start with. If a connect is not possible you could try MFSK32 or MFSK16 to call the server. Once the session is established, both modes will change to fit channel conditions... After beta testing, the client will get version jPSKmail 0.5, commemorating the first PSKmail email exchange between KH6TY and PA0R, from a parking lot near le Havre, France, now 5 years ago!! I hope you have as much fun testing this as I had... 73, Rein PA0R
Re: [digitalradio] Beta testing PSKmail 1.0
java runs even on windoze the server needs a proper OS. :) Rein PA0R windoze ?? Is it a linux clone ? la5vna S
[digitalradio] Re: Beta testing PSKmail 1.0
Hopefully people took time to read this announcement, it represents a major advancement. Of course, now I am interested in some mode-independent application for when not passing mail. The PSK500, PSK500R, PSK250, MFSK32, THOR22, MFSK16 and THOR8 shifting looks like a good method Andy K3UK --- In digitalradio@yahoogroups.com, Rein Couperus r...@... wrote: Beta tests are under way for PSKmail 1.0 == This new release takes PSKmail to its next logical step. The PSKmail 1.0 digital communication system is largely mode-independent. Both uplink- and downlink modes are separately adapted to fit he channel conditions in such a way that efficient use of the channel is guaranteed. In the PSKmail client/server system, the server controls timing and Rx/Tx modes. To enable this, fldigi has been extended by VK2ETA to report avarage Signal to Noise ratio values and Mode changes during a session. The PSKmail protocol was extended to carry SNR values and mode indexes. Using this information the server can control the modes so that on both sides of the communications link the number of ARQ repeats is kept within certain limits. The system uses PSK500, PSK500R, PSK250, MFSK32, THOR22, MFSK16 and THOR8, and a mode is shifted up and down the table when appropriate. Intelligent RSID control == The PSKmail server also controls the RSID function on client and server. When idle, the server usesRxID. As soon as a session is established, the server closes RxID and uses TxID to make sure theclient is listening in the right mode. This is only necessary when a mode change is involved, so normally no time is lost on unnecessary RSID frames... Limiting repeats to loose less time... As soon as more than one ARQ repeat is necessary the server degrades the mode by one step, to make sure the client gets the next one correct. The server constantly monitors the channel quality both ways, and also uses ARQ success to decide on mode upgrades. Using this system allows fast and flexible response to QRM like ALE sounding or Pactor connect requests trying to take over the channel while a session is in progress. The system just waits until the ordeal is over and carries on with the session... Using new Fldigi-3.20 = PSKmail 1.0 only works with Fldigi-3.20, which has the new support features for PSKmail built in. A client upgrade to jPSKmail 0.4.9.9 (beta) is also necessary, and the server version with the new goodies built in is pskmail_server-1.0 (at the moment alpha2). The new client beta is available for experimenting and beta testing on http://hermes.esrac.ele.tue.nl/pskmail , SM0RWO has provided installers for windoze, Linux and Mac. The server test software runs on PI4TUE, SM0RWO and IS0GRB-3 on 10147.0 kHz (center frequency). The new server image can be found on http://hermes.esrac.ele.tue.nl/pskmail/alpha Fldigi-3.20 can be found on http://www.w1hkj.com/beta New parameter for fldigi === To use PSKmail 1.0 a new parameter has to be set in fldigi-Configure-Misc-Pskmail: Set 'Report ARQ frames average S/N'. Set both the initial server and client modes to the PSK500R default to start with. If a connect is not possible you could try MFSK32 or MFSK16 to call the server. Once the session is established, both modes will change to fit channel conditions... After beta testing, the client will get version jPSKmail 0.5, commemorating the first PSKmail email exchange between KH6TY and PA0R, from a parking lot near le Havre, France, now 5 years ago!! I hope you have as much fun testing this as I had... 73, Rein PA0R -- http://pa0r.blogspirit.com
Re: [digitalradio] Beta testing PSKmail 1.0
On Sun, Mar 7, 2010 at 5:08 AM, Rein Couperus r...@couperus.com wrote: java runs even on windoze the server needs a proper OS. :) Rein PA0R Nice way to put it :) Andy K3UK
[digitalradio] What is SS and what it is good for to HAMs, was: ARRL/FCC Announcement
I did not follow the whole conversation. Anyway, spread spectrum has following benefits as far as I am known: It allows more stations to use the spectrum. The trick is in spreading the signal by a sequence, which appears to be random. Many stations transmitting spread spectrum signals at various time and frequency offsets will all together resemble white noise. On the contrary, many conventional narrow band signals will approach white noise much slower. There is a classic article from Costas (of the PSK Costa's loop decoder algorithm) explaining why even DSB has theoretical benefits over SSB because it spreads the signal to higher bandwidth, which makes the total interference look more like white noise. The spreading in frequency makes the signal less sensitive to narrow band carriers, it makes it difficult to jam a signal by a single or couple of carriers. The other benefit is critical to military use. It is difficult to detect and if one does not know the spreading sequence, it is impossible to decode. Spread spectrum somehow contradicts the HAM radio philosophy. Spread spectrum to be useful mandates the software itself to identify and lock to the signal. It is impossible identify weak SS signal from white noise by ears. The operator will just enumerate the channels and the machine will do the rest. Higher amount of SS stations at the same frequency will increase background noise, so it will create an interference to let's say a CW operator. Therefore one would need to dedicate SS channels, otherwise there would be plenty of complaints from CW operators. I don't see a real benefit in running SS signal in just 2.5kHz SSB bandwidth. Olivia or MFSK will do better because they use the whole spectrum for itself, while SS on purpose leaves all the orthogonal spreading sequences to be used by other stations. For the same bandwidth, SS is designed to share frequency, classic multitone signals for best coding gain. That is a whole world of difference. SS would be very beneficial for beacon network, where all beacons share the same channel. This is what the GPS satellite network does indeed. SS may be used for single channel world wide chatting mode. One will be able to decode many signals at once with powerful computer. 73, Vojtech OK1IAK
[digitalradio] ALE400 Experiment-Development of Standard Calling Mode: NAN NETWORK
Hello Andy and all, For about the Split mode. There is an option in the Trancseiver window. About Multipsk and ALE refer to the Tony's paper, below. 73 Patrick Multipsk ALE-400 ARQ FAE A Quick Start Guide by Anthony Bombardiere, K2MO Patrick Lindecker, F6CTE is the author of the digital mode software Multipsk. His program includes a variety standard sound card modes as well as a few that he created himself. One that stands out from the crowd is called ALE400 ARQ FAE. As the name implies, it was developed for Automatic Link Establishment; a mode which is used to automatically select the best link between two stations by scanning and signaling specific channels within the HF spectrum. Although intended for Automatic Link Establishment, a small group of us started experimenting with Patrick's ALE-400 ARQ FAE using it as a stand-alone keyboard chat-mode. What we found was a robust mode with good sensitivity, combined with a specialized ARQ that allows it to run error-free. So how does it work? With conventional keyboard modes such as RTTY or PSK31, the receiving station must wait until the other station un-keys before he or she gets a chance to respond. In the interim, the band can change causing a loss of data during a lengthy key-down. The sending station would have no idea since there's no way to know, but with ALE-400 ARQ, there's a second text window that monitors outgoing throughput letting the sending station know if the message is getting through. The ALE-400 ARQ FAE mode operates more like a pseudo full-duplex system where each station types at the same time while the mode automatically exchanges data in 6-to-7 second intervals. The data is sent at approximately 80 words-per-minute during a bilateral exchange and 60 words-per-minute one-way. The advantages over conentional chat-modes are pretty obvious; one is that there is no need to wait for the other station to un-key in order to change the subject or inject a quick comment since the change-over happens in a matter of few seonds. The other advantage is that because the exchange takes place so often, it gives the ARQ a chance to check for errors that may occur as the band changes. The ARQ is responsible for keeping the text error-free. The Soft ARQ Memory developed by Patrick works to reduce the number of repeats and improve throughput. The FAE or Fast Acknowledgement Exchange allows the process to happen quickly. Patrick explains how this Soft ARQ Memory works: Soft ARQ memory is used to limit the number of retries due to noise (each erroneous frame is used to determine the original frame). This ARQ memory begins to work only in case of two received erroneous frames. The general principle of ARQ memory is to average erroneous frames which leads to increasing the S/N ratio. Consequently, the averaged frame is better than each of both received frames. For example, if both of the erroneous frames has one error, averaging two frames will lead to a gain of 3 dB in S/N ratio and, with a great probability, will have an averaged frame without error. In general, it is sufficient to average two and, more rarely three frames. Patrick, Lindecker, F6CTE Another unique feature about ALE-400 is the ability to send mail to the Multipsk Mailbox while in chat mode with another station. The station sending the mail message will still be able to see incoming text from the other party so one-way keyboarding is still possible during the mail transfer; two-way keyboarding resumes once the message transfer is completed. Patrick's ALE-400 ARQ FAE has all the features of the standard ALE (Automatic Link Establishment) software including sounding, messaging and link quality analysis. At approximately 400Hz bandwidth, ALE-400 is also spectrum-friendly running 50 baud with a carrier spacing of 50Hz. A word about RSID One of the most useful features for digital mode operation is the RSID or Reed Solomon Identifier. Developed by Patrick Lindecker, this short MFSK identifier is sent automatically before the start of a digital mode transmission and is then decoded by other stations letting them know which mode is in use. Multipsk will automatically switch to the correct mode once the RSID transmission is detected within the receivers pass band. What RSID does is take the guess work out of trying to figure out which mode is being transmitted. Many sound very much alike so they are not easily identified by sight and sound. In addition to a long list of familiar sound card modes, Multipsk includes some not-so-familiar like PAX, PSK10 and a narrow-band MFSK mode called VOICE named for it's ability to vocalize or spell-out incoming text through the sound cards speakers I've complied a Quick Start Guide that should hopefully get you up and running with Multipsk and the ALE-400 FAE-ARQ chat-mode. Special thanks to Patrick Lindecker (F6CTE). 73, Tony -K2MO
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] Fabricating FCC approval
LA5VNA Steinar wrote: This has taken a whole new turn for me. I don't like this at all. I don't like it either, including the threats of legal action and the call for an ARRL official to resign (not that there isn't a good argument about a double standard here in the US, but this is not the time to make that argument). But I am a glass is half full type person. While I haven't taken the time to read everything carefully, and I'm travelling now and don't have time to access all the posts, I'm guessing Jose's interaction with the FCC agent was along the lines of each US amateur radio operator must determine what a mode is, and if it is legal and Jose took that to mean, or chose to take that to mean, that if a Ham read the new website and concluded it was a non SS digital mode, it would be legal. If that's true, and there's no way to know for sure, it's not quite the same as fabricating something, but it was likely not reporting FCC's full message, and it's understandable why FCC would ask ARRL to communicate the correction, trusting them not to twist the meaning of the message. In any case, it is time to move on. To amateurs worldwide, I hope you experiment with this new mode. If I were you, I'd try to forgot this sordid episode, and try to learn what's good about ROS, and suggest improvements as you see fit. Enjoy. I wish I could join you. Jim - K6JM Original Message Subject: [digitalradio] Fabricating FCC approval From: Steinar Aanesland saa...@broadpark.no Date: Fri, March 05, 2010 6:01 am To: * Digitalradio digitalradio@yahoogroups.com Hi all I the past days there has been a fair and square discussion about SS and FCC rules. Maybe some is more Catholic than the pope when it comes to arguing for the FCC rules, but that we have to tolerate . Then a question about credibility comes into issue. It is no longer a question about SS and FCC rules, but IF there was a FABRICATED FCC approval on the web page, then the situation is MUCH more serious. This has taken a whole new turn for me. I don't like this at all. LA5VNA Steinar On 05.03.2010 04:33, Dave AA6YQ wrote: You are in denial, Jose. Anyone here can call (877) 480-3201, ask for Dawn (agent 3820), and hear first-hand that you distorted her response. Since her conversation with you was recorded, there is no doubt about what she told you. Until someone un-does the damage you've done by characterizing ROS as spread spectrum and then fabricating FCC approval on your web page, ROS cannot be used by US amateurs on HF bands. 73, Dave, AA6YQ
Re: [digitalradio] Beta testing PSKmail 1.0
Well.. la5vna On 07.03.2010 14:34, Andy obrien wrote: On Sun, Mar 7, 2010 at 5:08 AM, Rein Couperus r...@couperus.com wrote: java runs even on windoze the server needs a proper OS. :) Rein PA0R Nice way to put it :) Andy K3UK
[digitalradio] Re: What is SS and what it is good for to HAMs, was: ARRL/FCC Announcement
Vojtech I think you will find that SS could make monitoring the bands more difficult as SS rings bells of the cryptographic sort in odd places .. and as these bell ringers are still trying to decode enigma and ultra intercepts from ww2 ... meetings in forests and the like ring any bells ? (tnx)... perhaps it would be too much to handle ... On the other hand .. yes your right multi channel occupancy and sub noise level communications are quite possible .. but hams with such ability .. why, can hear the clanging of the bells from here ! ... I think psk31 and mfsk suffered a similar cold reception from this side of the pond , but that was more of an embarrassment that hams had better station's with more bells and whistles(piccolo?) G .. --- In digitalradio@yahoogroups.com, Vojtech bubn...@... wrote: I did not follow the whole conversation. Anyway, spread spectrum has following benefits as far as I am known: It allows more stations to use the spectrum. The trick is in spreading the signal by a sequence, which appears to be random. Many stations transmitting spread spectrum signals at various time and frequency offsets will all together resemble white noise. On the contrary, many conventional narrow band signals will approach white noise much slower. There is a classic article from Costas (of the PSK Costa's loop decoder algorithm) explaining why even DSB has theoretical benefits over SSB because it spreads the signal to higher bandwidth, which makes the total interference look more like white noise. The spreading in frequency makes the signal less sensitive to narrow band carriers, it makes it difficult to jam a signal by a single or couple of carriers. The other benefit is critical to military use. It is difficult to detect and if one does not know the spreading sequence, it is impossible to decode. Spread spectrum somehow contradicts the HAM radio philosophy. Spread spectrum to be useful mandates the software itself to identify and lock to the signal. It is impossible identify weak SS signal from white noise by ears. The operator will just enumerate the channels and the machine will do the rest. Higher amount of SS stations at the same frequency will increase background noise, so it will create an interference to let's say a CW operator. Therefore one would need to dedicate SS channels, otherwise there would be plenty of complaints from CW operators. I don't see a real benefit in running SS signal in just 2.5kHz SSB bandwidth. Olivia or MFSK will do better because they use the whole spectrum for itself, while SS on purpose leaves all the orthogonal spreading sequences to be used by other stations. For the same bandwidth, SS is designed to share frequency, classic multitone signals for best coding gain. That is a whole world of difference. SS would be very beneficial for beacon network, where all beacons share the same channel. This is what the GPS satellite network does indeed. SS may be used for single channel world wide chatting mode. One will be able to decode many signals at once with powerful computer. 73, Vojtech OK1IAK
Re: [digitalradio] Re: What is SS and what it is good for to HAMs, was: ARRL/FCC Announcement
The FCC has addressed the cryptographic aspects of spread spectrum. Only certain relatively short PN codes are permitted for spread spectrum operation in the currently authorized bands. It is relatively trivial to cycle through those codes and receive the signal. The downside is that the technology is constrained in the degree of spectral efficiency possible. graham787 wrote: Vojtech I think you will find that SS could make monitoring the bands more difficult as SS rings bells of the cryptographic sort in odd places .. and as these bell ringers are still trying to decode enigma and ultra intercepts from ww2 ... meetings in forests and the like ring any bells ? (tnx)... perhaps it would be too much to handle ... On the other hand .. yes your right multi channel occupancy and sub noise level communications are quite possible .. but hams with such ability .. why, can hear the clanging of the bells from here ! ... I think psk31 and mfsk suffered a similar cold reception from this side of the pond , but that was more of an embarrassment that hams had better station's with more bells and whistles(piccolo?) G .. --- In digitalradio@yahoogroups.com, Vojtech bubn...@... wrote: I did not follow the whole conversation. Anyway, spread spectrum has following benefits as far as I am known: It allows more stations to use the spectrum. The trick is in spreading the signal by a sequence, which appears to be random. Many stations transmitting spread spectrum signals at various time and frequency offsets will all together resemble white noise. On the contrary, many conventional narrow band signals will approach white noise much slower. There is a classic article from Costas (of the PSK Costa's loop decoder algorithm) explaining why even DSB has theoretical benefits over SSB because it spreads the signal to higher bandwidth, which makes the total interference look more like white noise. The spreading in frequency makes the signal less sensitive to narrow band carriers, it makes it difficult to jam a signal by a single or couple of carriers. The other benefit is critical to military use. It is difficult to detect and if one does not know the spreading sequence, it is impossible to decode. Spread spectrum somehow contradicts the HAM radio philosophy. Spread spectrum to be useful mandates the software itself to identify and lock to the signal. It is impossible identify weak SS signal from white noise by ears. The operator will just enumerate the channels and the machine will do the rest. Higher amount of SS stations at the same frequency will increase background noise, so it will create an interference to let's say a CW operator. Therefore one would need to dedicate SS channels, otherwise there would be plenty of complaints from CW operators. I don't see a real benefit in running SS signal in just 2.5kHz SSB bandwidth. Olivia or MFSK will do better because they use the whole spectrum for itself, while SS on purpose leaves all the orthogonal spreading sequences to be used by other stations. For the same bandwidth, SS is designed to share frequency, classic multitone signals for best coding gain. That is a whole world of difference. SS would be very beneficial for beacon network, where all beacons share the same channel. This is what the GPS satellite network does indeed. SS may be used for single channel world wide chatting mode. One will be able to decode many signals at once with powerful computer. 73, Vojtech OK1IAK
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
