[digitalradio] Re: Using CTSS on a digipeater?
Let me thow out a couple more issues about this problem: 1) The Digi would be located on a hill over 10,000ft high, in an area prone to immense RF inference. Because of its height and the nature of digital signals, I'm concerned that a KPC+ would be overwhelmed hearing multiple signals from hundreds of miles away that might make the TNC unavailable, just when it needs to be available exclusively for ECOM. 2) The purpose of the Digi is specically for RACES traffic and needs to pass ECOM traffic from mobile command posts back to the EOC, for both large and small events. There are other circuts available for non-RACES traffic, so I'm not really concerned that other hams would be excluded from this one Digi. The goal would be to provide the County with a high point that doesn't currently exist. From a technical stand point, I would be concerned if a CTSS tone would be counter productive to the radio reponding quick enough for reliable packet communications. I was also concerned about packet collisions that could be caused by the TNC not hearing all packet traffic on the frequency. I guess the best solution would be choose a packet frequency thats used very rarely by other groups and leave the Digi as a open machine. Thanks. --- In digitalradio@yahoogroups.com, Bob Donnell kd...@... wrote: I'm with Vince on a number of points. If there's really a serious emergency, that will benefit from packet radio, chances are that the hobbiest hams are not going to be on the air, unless it's in support of your goals. I think it's far better to have the local community exercising your digipeater for you, so you know if it fails. If you're truly insistent on having the ability to lock out stations, it'd be better to do a couple of things to achieve that: 1) Use a TNC that allows performing over-the-air settings modifications 2) When an event happens, and you determine that the level of emcomm traffic vs. regular user traffic requires it, set up a beacon that frequently (every minute or two) informs all users that the digipeater has been configured for emcomm operations, and create a buddy list of stations that are allowed to connect and digipeat via the digipeater, and implement it. Another alternative that can be done remotely is to change the MYDIGI setting to respond to something else, but that's only a short-term fix, since anyone that's monitoring can see the digipeater callsign. Perhaps the most important thing, is if the operation is of a limited period, remember to set operations back to normal operations before shutting operations down, or when the emcomm traffic volume is reduced enough to support normal operations. From a technical perspective, using CTCSS as an operational modifier is a poor solution, for the reason Vince mentioned, and additionally, depending on the TNC and radio combination, having the the CTCSS tone present at the input to the TNC may cause it to make more reception errors than if it's not present. Also, anything that delays the digipeater (especially) from being able to tell that the channel is busy, and that to wait for the channel to clear before transmitting, is going to kill performance and require many more retries than leaving the digipeater open. Hope that helps! 73, Bob, KD7NM -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On Behalf Of Terry Breitenfeldt Sent: Sunday, February 22, 2009 11:37 PM To: digitalradio@yahoogroups.com Subject: [digitalradio] Using CTSS on a digipeater? If I wanted to setup a closed Digipreater on 145.09 Mhz on a high mountain peak, so that I could limit activity to only ECOM traffic, would the use of a CTSS tone decode be a viable option? Would a CTSS tone interfere with Packet operations? 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
[digitalradio] Re: on another note
Hi Patrick and others. I don't think it would be technically very difficult to do something equivalent to P3 with sound cards. I think that it would even possible to do much better with, for example, multi-users protocol. I completely agree. The problem is the time necessary to do this. An amateur can work (with pleasure and passion of course), let's say a day per week, when a company can make work a small team 5 days a week. Much less than one day per week if one has toddler or two to take care of. I admire your endurance in developing a complex free HAM software. Now an amateur project must be short in time (several months at a maximum) as it is done for fun. Working on the same project during years seems very difficult (and surely boring) for amateurs. Very true. If the project is too complex, it will simply become obsoleted by a commercial product before it is finished. The same thinking applies to development of hardware as I learned during my tinkering with ATS-3b. Patrick, I have a proposal for one low hanging fruit project. How about to receive RTTY in a synchronous way? I believe most SW really generate precise synchronous RTTY, where the only variable is the unknown stop bit length (mostly 1.5?). If the stop bit length is being estimated or selected from menu, one could receive RTTY synchronously and greatly increase sensitivity of this legacy but often used mode. 73, Vojtech OK1IAK
Re: [digitalradio] The Basics On WINMOR
Hard to respond as you did not indicate what you found confusing. There is no question that WINMOR, if reasonably successful, will cause an increase use of Winlink 2000, maybe even more than they might prefer, HI. And it will also impact sales of SCS to a certain extent. As Patrick pointed out, there is no technical reason that sound card modes could not improve over Pactor 2 and 3. Maybe he is too optimistic right now, but in the long term 73, Rick, KV9U John Becker, WØJAB wrote: Rick I'm a bit confused over your long post. But I can say that he has said that it's not a replacement for P2 or P3 or ever will be. John
[digitalradio] Re: on another note
--- In digitalradio@yahoogroups.com, Vojtech Bubnik bubn...@... wrote: Patrick, I have a proposal for one low hanging fruit project. How about to receive RTTY in a synchronous way? I believe most SW really generate precise synchronous RTTY, where the only variable is the unknown stop bit length (mostly 1.5?). If the stop bit length is being estimated or selected from menu, one could receive RTTY synchronously and greatly increase sensitivity of this legacy but often used mode. It's been done, in the K6STI RITTY software some years ago. Not that it couldn't be done again. K6STI was selling his software and pulled it off the market when users began stealing it. Also it was basically DOS software, and that may have been a necessity considering the timing vagaries of multitasking operating systems. There was for a time an implementation of Pactor-I in RTTY, later taken out. What K6STI did was something I had been dreaming about ever since the vacuum tube and heavy metal days of RTTY, so I was tickled pink that he did it. I had a few arguments with him about the dynamics of the digital flywheel as he called it; but he's the expert and I'm not. As things turned out it did not greatly increase the sensitivity - it was good for a db or two and that was about all. One neat thing he did, that I wish other RTTY software writers would do, was to output cleaned-up Baudot while receiving, so that one could drive a TTY machine from it, using his software as sort of the ultimate T.U. Jim W6JVE
RE: [digitalradio] Re: Using CTSS on a digipeater?
Your situation is creating for you a huge hidden transmitter problem. Is there anything that says you can't do either of these things: 1) Use a directional antenna - reduce the signal strength from the far-away mountains. Using down-tilt to both better illuminate the valleys close to the digi, and at the same time, reduce the strength of signals on the horizon, by tilting enough to put them well down the main lobe. 2) Move the antenna or digipeater site to a lower location, perhaps where you can gain some benefit from putting the mountain between the digipeater antenna and the most likely interferers 3) Use a different band entirely. It's usually easier to find underutilized frequencies to use for packet, on 222 and 420-450 MHz. A thought associated with hidden transmitters, that we've had huge success with here, but is more complicated, and that's to get a repeater allocation and put up a repeater dedicate for packet communications. This has a number of benefits: 1) No hidden transmitters - at all. Collisions are pretty much non-existant. 2) Everyone connects to everyone direct. No digipeating needed, which instantly doubles your throughput. 3) All fixed operations can use beam antennas for packet because they don't need to be able to hear or talk in multiple directions. Additionally, using beams usually means that if multipath is a problem, you can usually find a direction to point the beam to eliminate the multipath. Movable resources can be equipped with a beam, which can be set up if multipath at that site is a problem. 4) If you don't provide any services on the repeater, like a public BBS, node, or DX Cluster, chances are the repeater won't see a lot of use, meaning it'll be available. The biggest down side is that a repeater is more complicated than a digipeater. There are more pieces to go wrong. But the repeater doesn't need a fancy controller. In fact, using the TNC DCD indicator line (with a KPC 3x set for software DCD) or any other TNC with True DCD, provides the COR line to key the transmitter. Further, the TNC can act as the repeater ID'er - just to send an ID packet every 10 minutes. That has been confirmed to constitute a legal same-mode ID, when the repeater is intended for packet use. If that's an interesting option, I can provide more details. We've had a number of packet repeaters over the years, one of which has been on the air since 1985 or so. The others were on 9600 baud, which is a can of worms I don't recommend, because so few radios that claim to be 9600 baud ready really are not. 73, Bob, KD7NM -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On Behalf Of Terry Breitenfeldt Sent: Tuesday, February 24, 2009 8:00 PM To: digitalradio@yahoogroups.com Subject: [digitalradio] Re: Using CTSS on a digipeater? Let me thow out a couple more issues about this problem: 1) The Digi would be located on a hill over 10,000ft high, in an area prone to immense RF inference. Because of its height and the nature of digital signals, I'm concerned that a KPC+ would be overwhelmed hearing multiple signals from hundreds of miles away that might make the TNC unavailable, just when it needs to be available exclusively for ECOM. 2) The purpose of the Digi is specically for RACES traffic and needs to pass ECOM traffic from mobile command posts back to the EOC, for both large and small events. There are other circuts available for non-RACES traffic, so I'm not really concerned that other hams would be excluded from this one Digi. The goal would be to provide the County with a high point that doesn't currently exist. From a technical stand point, I would be concerned if a CTSS tone would be counter productive to the radio reponding quick enough for reliable packet communications. I was also concerned about packet collisions that could be caused by the TNC not hearing all packet traffic on the frequency. I guess the best solution would be choose a packet frequency thats used very rarely by other groups and leave the Digi as a open machine. Thanks. --- In digitalradio@yahoogroups.com, Bob Donnell kd...@... wrote: I'm with Vince on a number of points. If there's really a serious emergency, that will benefit from packet radio, chances are that the hobbiest hams are not going to be on the air, unless it's in support of your goals. I think it's far better to have the local community exercising your digipeater for you, so you know if it fails. If you're truly insistent on having the ability to lock out stations, it'd be better to do a couple of things to achieve that: 1) Use a TNC that allows performing over-the-air settings modifications 2) When an event happens, and you determine that the level of emcomm traffic vs. regular user traffic requires it, set up a beacon that frequently (every minute or two) informs all users that the digipeater has been configured for
Re: [digitalradio] on another note
Hello John, RFSM8000 has come as close as anything so far, but it's weakness was operating well under poor conditions (read normally poor these days) As far as I know, RFSM8000 uses a protocol close to 110A. This protocol is fine as it permits a great dynamic of data speed and moreover it has an excellent Mean power/Peak power ratio, very close to 1. However, it has a problem as the symbol rate being equal to 2400 bauds, it is required an equalization (indispensable above 100 bauds). This equalization is efficient only for good (or not too bad) signal to noise ratio (with too much noise, the equalizer does not converge or lead to false solutions). The other solution is to be at 100 bauds or less and to multiply the number of carriers (as in MT63). However, in that case the Mean power/Peak power ratio is not good (as in MT63) and it can be a problem if for example, you are limited to 10 watts (to keep linear) with a 100 watts transceiver. To be able to have a very good S/N ratio (as good as the one supposed for P3), it is necessary to have a sequence of symbols (carrying the specific transmission parameters) at slow speed that can be recognized easily without error (i.e with a strong autocorrelation function) as for the RS ID. Once recognized, all is more simple as this sequence acts as a pivot: you can add your message at a given speed, repeat it if necessary (an ARQ memory is of course indispensable), increase or decrease the speed according to the ionospheric conditions... 73 Patrick - Original Message - From: John Bradley To: digitalradio@yahoogroups.com Cc: multi...@yahoogroups.com Sent: Tuesday, February 24, 2009 11:48 PM Subject: RE: [digitalradio] on another note I don't think it would be technically very difficult to do something equivalent to P3 with sound cards. I think that it would even possible to do much better with, for example, multi-users protocol. RFSM8000 has come as close as anything so far, but it's weakness was operating well under poor conditions (read normally poor these days) The problem is the time necessary to do this. An amateur can work (with pleasure and passion of course), let's say a day per week, when a company can make work a small team 5 days a week. Now an amateur project must be short in time (several months at a maximum) as it is done for fun. Working on the same project during years seems very difficult (and surely boring) for amateurs. No kidding.. it is amazing and very appreciated with what you and other software authors have done, and is especially important when it is done as a hobby. Another point is that the number of Hams really interested in ARQ modes is very weak... I can't answer that , outside of the fact there are a pile of winlink users. Think you might underestimate the number of folks interested in ARQ soundcard modes, and maybe this is an opportunity for Andy to do a survey on his website? Note: have tests on the minimum S/N versus the data rate done, for pactot P2 and P3? (as it is difficult to trust commercial data) don't know, but think so . but my ear tells me it works better than OLIVIA, which is about the top of the heap right now. I cannot hear the other station and yet the connect runs at fast speed. John VE5MU
Re: [digitalradio] Re: on another note
Hello Votjech and Jim, TKS for the information. I suppose the difference must be the same as between CW (not coherent) and CCW (coherent) so a gain of several dB on the S/N. A synchronous RTTY under Windows is possible with a standard symbol synchronization (with or without a PLL which can be seen as the digital flywheel). However, the stop bit (1.5 symbols) complicates all as it is not an integer multiple of the symbol length. Now, RTTY must be supposed to be asynchronous to be compatible with all RTTY apparatus and programs. Let's work on more modern modes... 73 Patrick - Original Message - From: jhaynesatalumni jhhay...@earthlink.net To: digitalradio@yahoogroups.com Sent: Wednesday, February 25, 2009 5:54 PM Subject: [digitalradio] Re: on another note --- In digitalradio@yahoogroups.com, Vojtech Bubnik bubn...@... wrote: Patrick, I have a proposal for one low hanging fruit project. How about to receive RTTY in a synchronous way? I believe most SW really generate precise synchronous RTTY, where the only variable is the unknown stop bit length (mostly 1.5?). If the stop bit length is being estimated or selected from menu, one could receive RTTY synchronously and greatly increase sensitivity of this legacy but often used mode. It's been done, in the K6STI RITTY software some years ago. Not that it couldn't be done again. K6STI was selling his software and pulled it off the market when users began stealing it. Also it was basically DOS software, and that may have been a necessity considering the timing vagaries of multitasking operating systems. There was for a time an implementation of Pactor-I in RTTY, later taken out. What K6STI did was something I had been dreaming about ever since the vacuum tube and heavy metal days of RTTY, so I was tickled pink that he did it. I had a few arguments with him about the dynamics of the digital flywheel as he called it; but he's the expert and I'm not. As things turned out it did not greatly increase the sensitivity - it was good for a db or two and that was about all. One neat thing he did, that I wish other RTTY software writers would do, was to output cleaned-up Baudot while receiving, so that one could drive a TTY machine from it, using his software as sort of the ultimate T.U. Jim W6JVE 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
[digitalradio] Re: Using CTSS on a digipeater?
--- In digitalradio@yahoogroups.com, Terry Breitenfeldt tabreitenfe...@... wrote: Let me thow out a couple more issues about this problem: 1) The Digi would be located on a hill over 10,000ft high, in an area prone to immense RF inference. Because of its height and the nature of digital signals, I'm concerned that a KPC+ would be overwhelmed hearing multiple signals from hundreds of miles away that might make the TNC unavailable, just when it needs to be available exclusively for ECOM. Even if a closed group were technologically possible, even inside a closed group you can still have massive hidden transmitter problems causing thruput problems. So if ham X 50 miles N can't hear the transmissions of ham Y 50 miles south, then the LAN will break down if ham X and ham Y both try to access the same digi. All the stations on the network will need hundreds of miles of range not just the digipeater. You may want to look at what the folks in WI and MI and MN (and probably many other locations) have done. Now if you installed multiple directional antennas and radios pointing to distinct metro areas on distinct frequencies, that culd work quite well. So antenna 1 pointing to metro area #1 where everyone in metro area #1 can hear each other while using off the shelf mobiles could work. Use nodes instead of digis and link them together. 73 de Vince N9NFB
Re: [digitalradio] Re: Newbie looking for a bbs packet radio
Hello Hugo, You can use Kiss commands from your program. Some programs (considered as modems) support these commands through serial port (physical or virtual) as AGWPE, Mixw (I think) or Multipsk. In the last test version of this one, I added TCP/IP Kiss commands (contact me in direct for details if you need). 73 Patrick - Original Message - From: Hugo Correa Sena To: digitalradio@yahoogroups.com Sent: Wednesday, February 25, 2009 2:37 PM Subject: Re: [digitalradio] Re: Newbie looking for a bbs packet radio Thanks Andy for fast aswer. I take a lok in those very interesting programs. My first plan is use some graphic and dedicade program. Somethink like butons of connect, open a graphic menu window, make fews commands just clicking mouse buttons. Somethink easy to start, you know? Later I´ll but more hard tasks in BBS. 2009/2/24 Andrew O'Brien k3uka...@gmail.com Hugo, Your English is good! Did you try PSKMAIL? That may help, or perhaps Multipsk's packet functions. Andy K3UK --- In digitalradio@yahoogroups.com, Hugo Correa Sena pp8hs...@... wrote: Dear friends, I´d like some help in a simple (not to me, HI) project. I´d like to try of putting in the air a station BBS packet radio (I think that´s the name) just to send/recieve personal messenger, little files and general messenger (like QTC). Later I´ll connect in others net The big objective of this project is start interesting in Amateur radio of digital modes in VHF. As not activitie, I´d like to start with programs to emulate tnc and baycom modems (like as mixW does, I supose). Supose again that this project is divided in two poles: server and user. So my ask for you is some programs (I´ll appreciate graphics programs) to use on this task. Thanks for help and sorry for bad english -- Hugo Sena PP8HS PX8C1546 http://pp8hs.110mb.com -- Hugo Sena PP8HS PX8C1546 http://pp8hs.110mb.com
[digitalradio] Re: on another note
--- In digitalradio@yahoogroups.com, Patrick Lindecker f6...@... wrote: A synchronous RTTY under Windows is possible with a standard symbol synchronization (with or without a PLL which can be seen as the digital flywheel). However, the stop bit (1.5 symbols) complicates all as it is not an integer multiple of the symbol length. Now, RTTY must be supposed to be asynchronous to be compatible with all RTTY apparatus and programs. Let's work on more modern modes... I did some work earlier with compatible synchronous RTTY using 7.00 unit start-stop code, to make it easier to synchronize. Even mechanical TTY machines can easily receive 7.00 unit code. I built a transmitting converter that would send the 7.00 unit code, and insert fill characters (LTRS or FIGS) if there was no input character available when one was called for. Another ham was working on the receiver - I don't know if he ever got it working. Then years later K6STI did his digital flywheel and he said it didn't matter that the character length was not an integral multiple of the bit length so long as the character length was constant. Which required transmitting diddle. But I fully agree about more modern modes. Last night I was copying a couple of RTTY stations, pretty good copy except for QSB, and one of them was using 1KW and the other using 500W. And back in the glory days of RTTY we were all trying to run that kind of power. I have a big TMC kilowatt transmitter gathering dust out with all the TTY machines. There is an amusing explanation for why TTY uses a 7.42 unit code (in the U.S.) but I'll forbear to tell it unless someone asks. Jim W6JVE
RE: [digitalradio] Re: on another note
I'm asking. :) Bob, W5XR. _ From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On Behalf Of jhaynesatalumni Sent: Wednesday, February 25, 2009 8:26 PM To: digitalradio@yahoogroups.com Subject: [digitalradio] Re: on another note --- In digitalradio@ mailto:digitalradio%40yahoogroups.com yahoogroups.com, Patrick Lindecker f6...@... wrote: A synchronous RTTY under Windows is possible with a standard symbol synchronization (with or without a PLL which can be seen as the digital flywheel). However, the stop bit (1.5 symbols) complicates all as it is not an integer multiple of the symbol length. Now, RTTY must be supposed to be asynchronous to be compatible with all RTTY apparatus and programs. Let's work on more modern modes... I did some work earlier with compatible synchronous RTTY using 7.00 unit start-stop code, to make it easier to synchronize. Even mechanical TTY machines can easily receive 7.00 unit code. I built a transmitting converter that would send the 7.00 unit code, and insert fill characters (LTRS or FIGS) if there was no input character available when one was called for. Another ham was working on the receiver - I don't know if he ever got it working. Then years later K6STI did his digital flywheel and he said it didn't matter that the character length was not an integral multiple of the bit length so long as the character length was constant. Which required transmitting diddle. But I fully agree about more modern modes. Last night I was copying a couple of RTTY stations, pretty good copy except for QSB, and one of them was using 1KW and the other using 500W. And back in the glory days of RTTY we were all trying to run that kind of power. I have a big TMC kilowatt transmitter gathering dust out with all the TTY machines. There is an amusing explanation for why TTY uses a 7.42 unit code (in the U.S.) but I'll forbear to tell it unless someone asks. Jim W6JVE
