Re: [digitalradio] Re: Getting serious about ALE for non-encomm digital hamming
Hello, > One way would do it. To use an analogy, you ring the phone and the > operator decides if he wants to pick up. With RSID, Call OK I see the analogy. > By the way, is there currently a mechanism for monitoring the 3KHz > passband for a certain Call ID and only alarming on that? Yes there are several options (monitoring, automatic spot...). The covered bandwidth can be 2.5, 3.3, 4.3 or 44 KHz on a SdR. I have modified a bit the Call ID source to integrate a small "message ID" (possibility to send small messages (9 characters max) readable on the waterfall). 73 Patrick - Original Message - From: "aa777888athotmaildotcom" To: Sent: Monday, November 23, 2009 12:51 PM Subject: [digitalradio] Re: Getting serious about ALE for non-encomm digital hamming > > > --- In digitalradio@yahoogroups.com, "Patrick Lindecker" > wrote: >> >> Hello, >> >> > Once an effective, simple and robust SELCAL standard is developed >> > (again >> > IMHO it should be a logical extension of the >existing RSID and Call ID >> > standards) it could eventually be parlayed into a more modern and >> > effective variant of ALE. By using >> RR for the nice SELCAL idea. I'm not sure it would be very easy if you >> need >> a symetrical acknowledgment. If it is only a one way transmission without >> any double acknowledgment it is much more easy. RS ID and CALL ID are >> public >> sources. So... > > One way would do it. To use an analogy, you ring the phone and the > operator decides if he wants to pick up. With RSID, Call ID and SELCAL > combined the called station would know he's being called, who's calling > and on what mode and freq. Just like RSID, allow the alert to be ignored > or allow the alert to cause the station to be put on the right mode and > freq. Just like RSID the operator answers manually. > > By the way, is there currently a mechanism for monitoring the 3KHz > passband for a certain Call ID and only alarming on that? > > > > > > > Suggested frequencies for calling CQ with experimental digital modes = > 3584,10147, 14074 USB on your dial plus 1000Hz on waterfall. > > Announce your digital presence via our Interactive Sked Pages at > http://www.obriensweb.com/sked > Yahoo! Groups Links > > > >
Re: [digitalradio] Re: Getting serious about ALE for non-encomm digital hamming
Hello, > Once an effective, simple and robust SELCAL standard is developed (again > IMHO it should be a logical extension of the >existing RSID and Call ID > standards) it could eventually be parlayed into a more modern and > effective variant of ALE. By using RR for the nice SELCAL idea. I'm not sure it would be very easy if you need a symetrical acknowledgment. If it is only a one way transmission without any double acknowledgment it is much more easy. RS ID and CALL ID are public sources. So... 73 Patrick - Original Message - From: "aa777888athotmaildotcom" To: Sent: Sunday, November 22, 2009 4:18 AM Subject: [digitalradio] Re: Getting serious about ALE for non-encomm digital hamming > I've gave PCALE a very good try. As implemented it suffers from several > problems: > > 1. It is equipment specific and intensive. You either need an SGC tuner > set up for bypass-on-receive (the only brand I am aware of that has this > capability) or a special antenna that is resonant and efficient on each > band you plan to scan. You can also set up RF switching to bypass the > tuner on receive but that becomes even more complex. There was a computer > controlled tuner on the market that could be controlled by MARS-ALE but > MARS-ALE is not available to mere mortals and the tuner itself was buggy > and is now out of production. > > 2. The link margins necessary for the calling waveform are pretty > substantial. Those used to the relatively robust nature of RSID or any of > the other common digital modes will be sorely disappointed. Even Winmor, > while better than ALE, requires substantially better conditions for > success. > > 3. The software itself is relatively complex to setup and operate. I'm > sure Andy will argue to the contrary :-) However IMHO it's significantly > more involved than just firing up Fldigi and banging away at some Olivia > or PSK. > > 4. The widely shared nature of the ham bands makes collisions inevitable > given the automation inherent in ALE (automation that is the whole point, > in fact) and the limitations of even the best busy channel detection > algorithm. This issue tends to generate a lot of hate and discontent. > However this ought to be the least worrisome issue. With an appropriate > band plan (which already exists for PCALE) the carnage can be limited to > just the ALE calling channels and anyone who wants to use ALE should be > expected to sign up for a certain amount of interference and not be > whining about it as long as it stays on the calling freq's. > > In lieu of full-blown ALE consider the following idea: > > I'm no software engineer and beggars can't be choosers, so forgive me for > making the following related suggestion (Patrick already laid into me on > this once!) Consider that RSID is great for identifying the mode and that > Call ID is great for identifying who is calling. Both use signaling > standards and waveforms that are very simple and robust. But what is > missing is an equivalent SELCAL (selective calling) signaling standard > using waveforms and formats similar to RSID and Call ID. Imagine you > wanted to find somebody monitoring the 3KHz of USB spectrum at 14070KHz > dial freq. You could find a clear spot in the waterfall and transmit the > SELCAL which contains the call sign of the station you wish to reach. At > the receiving station the SELCAL enabled software would function in the > same manner as that currently done for RSID, i.e. detect the call, > display/sound a notification and provide automation for tuning and > answering under operator control. > > Once an effective, simple and robust SELCAL standard is developed (again > IMHO it should be a logical extension of the existing RSID and Call ID > standards) it could eventually be parlayed into a more modern and > effective variant of ALE. By using time synchronized band scanning and > transmission (similar to WSPR et al) probability of intercept can be > substantially improved. Neither the SELCAL or time synchronization > represent new technology and both derive from proven, similar > implementations. So if one were to make a SELCAL on 80M, for example, once > the spot on the waterfall was chosen by the operator (because we can't > rely on unreliable busy-channel detection technology) the SELCAL > transmission would occur at say for instance 10 seconds past the minute. > Synchronized scanning would put all stations on 80M at 10-15 seconds past > the minute, 40M at 15-20 seconds, and so on. > > The last piece would be to perfect busy channel detection and automate the > selection of empty places on the waterfall, but this part of the puzzle is > useless with SELCAL (very useful by itself) and synchronized > scanning/transmission. And once this last part was perfected we are back > to requiring special tuner/antenna solutions. > > > > > > > > Suggested frequencies for calling CQ with experim
Re: [digitalradio] Re: Getting serious about ALE for non-encomm digital hamming
"This is not really correct with PC-ALE and a modern receiver that has a internal antenna tuner. I have used PC-ALE with a TS2000 and an Icom 746 Pro and the tuner in both rigs memorizes settings for each transmission" How fast does the rig need to scan? philw de ka1gmn
Re: [digitalradio] Re: Getting serious about ALE for non-encomm digital hamming
On Sat, Nov 21, 2009 at 10:18 PM, aa777888athotmaildotcom wrote: > > > > I've gave PCALE a very good try. As implemented it suffers from several > problems: > > 1. It is equipment specific and intensive. You either need an SGC tuner set > up for bypass-on-receive (the only brand I am aware of that has this > capability) or a special antenna that is resonant and >efficient on each band > you plan to scan. You can also set up RF switching to bypass the tuner on > receive but that becomes even more complex. There was a computer controlled > tuner on the market >that could be controlled by MARS-ALE but MARS-ALE is not > available to mere mortals and the tuner itself was buggy and is now out of > production. This is not really correct with PC-ALE and a modern receiver that has a internal antenna tuner. I have used PC-ALE with a TS2000 and an Icom 746 Pro and the tuner in both rigs memorizes settings for each frequency fast enough so that a match is achieved before an ALE transmission. So, with my basic home brewed antennas (a 60M loop and a 20M ground plan vertical) I can macth 80-10M and use PC-ALE (or Multipsk) fully. > > 2. The link margins necessary for the calling waveform are pretty > substantial. Those used to the relatively robust nature of RSID or any of the > other common digital modes will be sorely disappointed. >Even Winmor, while > better than ALE, requires substantially better conditions for success. > > 3. The software itself is relatively complex to setup and operate. I'm sure > Andy will argue to the contrary :-) However IMHO it's significantly more > involved than just firing up Fldigi and banging away at >some Olivia or PSK. You are correct, I'll argue to the contrary. It is easier that FLdigi to set up EXCEPT the terminology used in the program is not familiar to many of us and contributes to confusion. The quick guide to setting it up that is on the hflink web site can help an ham be up and running in 2 minutes. > > 4. The widely shared nature of the ham bands makes collisions inevitable > given the automation inherent in ALE (automation that is the whole point, in > fact) and the limitations of even the best busy >channel detection algorithm. > This issue tends to generate a lot of hate and discontent. However this ought > to be the least worrisome issue. With an appropriate band plan (which already > exists for >PCALE) the carnage can be limited to just the ALE calling > channels and anyone who wants to use ALE should be expected to sign up for a > certain amount of interference and not be whining about it >as long as it > stays on the calling freq's. > I agree. > In lieu of full-blown ALE consider the following idea: > > I'm no software engineer and beggars can't be choosers, so forgive me for > making the following related suggestion (Patrick already laid into me on this > once!) Consider that RSID is great for identifying the mode and that Call ID > is great for identifying who is calling. Both use signaling standards and > waveforms that are very simple and robust. But what is missing is an > equivalent SELCAL (selective calling) signaling standard using waveforms and > formats similar to RSID and Call ID. Imagine you wanted to find somebody > monitoring the 3KHz of USB spectrum at 14070KHz dial freq. You could find a > clear spot in the waterfall and transmit the SELCAL which contains the call > sign of the station you wish to reach. At the receiving station the SELCAL > enabled software would function in the same manner as that currently done for > RSID, i.e. detect the call, display/sound a notification and provide > automation for tuning and answering under operator control. > > Once an effective, simple and robust SELCAL standard is developed (again IMHO > it should be a logical extension of the existing RSID and Call ID standards) > it could eventually be parlayed into a more modern and effective variant of > ALE. By using time synchronized band scanning and transmission (similar to > WSPR et al) probability of intercept can be substantially improved. Neither > the SELCAL or time synchronization represent new technology and both derive > from proven, similar implementations. So if one were to make a SELCAL on 80M, > for example, once the spot on the waterfall was chosen by the operator > (because we can't rely on unreliable busy-channel detection technology) the > SELCAL transmission would occur at say for instance 10 seconds past the > minute. Synchronized scanning would put all stations on 80M at 10-15 seconds > past the minute, 40M at 15-20 seconds, and so on. > > The last piece would be to perfect busy channel detection and automate the > selection of empty places on the waterfall, but this part of the puzzle is > useless with SELCAL (very useful by itself) and synchronized > scanning/transmission. And once this last part was perfected we are back to > requiring special tuner/antenna solutions. > Sound lik
