[aprssig] objects sent from a client (was Re: UIDIGI Setup)
Keith VE7GDH ve7gdh at rac.caThu Nov 5 17:37:32 UTC 2009
- Previous message: [aprssig] UIDIGI Setup
- Next message: [aprssig] UIDIGI Setup
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Bob WB4APR wrote... > Just to clarify. That's not the point. Ed isn't going to like this, but I did change the subject line. > The point is for "info type" objects generated by "software > driven" programs [at non-digi-locations]. The reasons these > local info frequency objects are best generated at the digi are: In my case, they are one and the same place. On the other hand some stations generating an object could be so far down in a hole that they wouldn't be heard at all unless they went through a digi. > 1) Only the digi can hear the channel and avoid colliding with > users That could be re-worded to either "sometimes only the digi" or even "often only the digi"... it's a bit misleading to make a blanket statement and say "only the digi" can hear the channel. I'm not on a mountain-top, but I am on a ridge about 165M ASL. I can hear one mountain-top digi over 200 km away, and a few others not much short of that, but that's because they are quite high. However, there's mostly just water (and a few other islands) between me and there, and I can hear a lot of traffic from the mainland and in other directions. While I have mountains to the west and mountains to the east, there's a lot that I can hear in between. Perhaps my location is somewhat unique, but it can't be completely unique. > 2) Only the digi can generate these packets direct over the > coverage area Correct, a digi can send a packet direct that can be heard over it's coverage area. However, another station sending a packet with one hop via that digi will have the same coverage, but it will take up two time slots and stations very close to the originating station will hear two copies. However, in the case of an IRLP APRS object, the information will be accurate and far more useless than a "here I am" kind of beacon without conveying any other information. You could even look at is two opportunities for mobile stations to hear the change in status of an IRLP node, giving them a better chance of having the most up-to-date information. > 3) Home generated objects have to use 1 hop which collide with > other users Collisions are a part of APRS, but "home" stations don't necessarily have to use any path at all. It's up to the operator to set the path which could be direct or not. Obviously, if they are normally using any path at all, they need to consider whether they are the right station to generate any kind of information object. > 4) Home objects usually use the station's set path, usually 2 hops Usually, but not always. I think that more people would listen to your suggestions if you weren't so rigid with blanket statements. At least you used the world "usually" above instead of "always". > 5) Anything beyond the local digi is SPAM and MISSINFORMATION I would agree with the SPAM part in most cases, but it wouldn't be misinformation. It would just be propagating it where it wasn't needed. Umm... isn't MISSINFORMATION kind of like a hookers bulletin board? What a difference one "s" makes - hi! > Result is that the QRM and collision potential of these objects > is 16 times greater when generated at a home station than at > the digi. And all those unwanted copies are in areas where the > object is useless SPAM. (A 2 hop path where most digis can hear > 4 others = 16 dupes. You are talking about objects going out with multiple hops. Yes, a clue-less person could easily do that. Perhaps I put more faith in my fellow ham, and perhaps you have seen more examples of people "doing it wrong". > Compared to ONE packet that is guaranteed not to collide with > anything). You and I know that isn't guaranteed, but a packet sent from a high digi would have less chance of collisions because it at least listens before it transmits. There will always be perfect doubles though. >> If you don't have a digi at your disposal and UI-View is >> the right tool and in the right place, then why not? > > If your area is remote from all other traffic, then of course, > it is ok to generate these at home, but PLEASE limit them to 1 > hop. The SPAM issue trumps all else. I hate seeing a frequency > object and then QSY to find *that it is 3 counties away that I > cannot use*. I'm anything but remote, but I just use one hop. To be honest, the discussion has made me start thinking about changing my IGate over to direct with no path, but I would probably want to upgrade from the current quarter wave to a half wave or something along those lines first. >> In my opinion, a digi is not the right tool >> to generate an object for an IRLP or EchoIRLP node. > > Maybe slightly better wording here would be.. > > " the IRLP or Echolink node itself is the far better > " place to generate these objects if you can afford > " the extra radio and TNC.... In my opinion that would be a waste of an extra radio and TNC. In my case, my IRLP node, IGate and digi are all at the same location. With different antennas, coverage is different, but my IGate is exactly the right thing to beacon my IRLP object to RF. As mentioned above, if I upgrade the IGate antenna, I would very likely change the path to direct instead of one hop. I would never degrade the IRLP object by having something that doesn't know the status generate the object. It all comes down to knowing what you are doing. A car or gun or fighter jet in the wrong hands can be dangerous. An APRS client is exactly the same way. You need to know how to use it. As I look around me, I can see zillions of things that could be used improperly. Used correctly, they do what they are supposed to do. I'm not saying that an APRS client is the right tool to do everything with, but it isn't necessarily the wrong tool just because it isn't a digi. 73 es cul - Keith VE7GDH -- "I may be lost, but I know exactly where I am!"
- Previous message: [aprssig] UIDIGI Setup
- Next message: [aprssig] UIDIGI Setup
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the aprssig mailing list
