On Wed, 20 May 2009 19:05:20 -0700, "J. Moen" <[email protected]> said: > Nate WY0X wrote: "having an IP Gateway up WAY up high at the super wide > area Digi site is going to change the Denver APRS "landscape" a bit, but > I'll > leave that to the Digi owner to discuss with folks, etc... should be a > GOOD thing..." > > In the APRS world, Bruninga has recommended that the APRS digipeater > architecture works better if each one has limited range and you have more > of them scattered about. The simplex digipeater can handle only so many > beacons a minute, and the ones with really tall antennas can get > overloaded, causing lots more collisions.
Yeah, I leave that to the APRS local "management", such as it is. They've had high mountain digis and mess around with calling them "WIDE" and all those other things on Packet I stopped paying attention to back in the early 90's with IP Packet activity in the area died off. That was really the only interesting thing in Packet to me by that point in time, but I know others are really into it. > Of course, I haven't looked at recent statistics. I suppose over time, > some of those APRS beacons could get shifted to DStar. I think you're asking if it's a good idea to bring ALL the local APRS traffic over to the D-STAR side? I don't think so... but I guess it *can* be done... not saying it's "smart". What MIGHT work well on a multi-repeater D-STAR "stack" is setting local policy that a particular MODULE is where that type of thing goes on, and keep the other modules "quieter"... for example, one could gateway stuff from APRS to D-STAR only on module C, while local users would be encouraged to chit-chat and use the system regularly on Module B. This would be easier to do if the "all call" D-Plus feature for a stack wasn't broken right now... so folks could "find" each other more easily than callsign routing from B to C to see if their "data crazed buddy with his car PC and mobile tracking software" was listening over there. Also if folks were careful to always key up on whatever module they were on at least once, I believe the local Gateway now caches that info, even if it differs from the Trust Server (I swear I saw that announcement go by a while back, but haven't tested it) so calling the person by callsign to find them would work locally on the stack too. Lots of moving parts... kinda too complex for most to really "go there"... but gateway of DPRS to APRS where the APRS "channel" isn't really a mixed-use channel, seems like a great addition to any local area from the D-STAR Gateways that have the gear handy in the same location to do it. > I have a question. On the email list of a local DStar repeater, it was > pointed out that: > > One thing to keep in mind is if you are sending this positioning > information automatically, you may be colliding with another user > attempting to be making a voice transmission. As we know, the R2D2 > affect happens when a doubling takes place and I just want to make sure > everyone understands the outcome of sending GPS data in an automatic > mode. We must also keep in mind, that if you have your radio set to a > memory channel that connects your transmission to another System through > the Worldwide Gateway your GPS data is also being sent to the distant > node. With our low local usage levels right now, we have a number of us that just get on the B module with D-RATS on a whim, and really don't get any complaints. But as usage in the area goes up, I'm sure we'll have to set some policy about where/when heavy low-speed data use should be done on the stack, etc... and as others have mentioned, people need to be acutely aware if a module is D-Plus linked somewhere... a bunch of data transmissions with no voice in that mode will drive a whole lot of people crazy on a Reflector... unless you key up once in a while on voice and explain what's going on. People who haven't turned the beeps off in the rigs after each transmission are at the greatest risk for SERIOUSLY being annoyed. Personally, I can't decide if I want the beeps or not. I do wish the protocol's next version would have what someone else called the "automated transmission" bit... if data from the serial port or the rig's own GPS settings caused the transmission, set the "automated" bit. If it was a user keying a real PTT button, leave it off. That would make it SIMPLE for the receiving radio to behave differently upon reception of either sort. I also wish Icom would separate the "busy channel lock-out" function into two settings, one for DV mode and one for FM. On an FM repeater with a long transmitter tail, it's annoying to have it turned on. On DV mode, it's NICE to have it on... you run less risk of "stepping on" either another voice or a silent data transmission if you're not watching the head of the rig. But I run with the feature turned OFF, because all my "analog club's" repeaters other than one, have long TX tails and leave the CTCSS active during the tail. The one I modified to do in-band linking has the CTCSS of the repeater follow user input, and that's MUCH cleaner with the busy-channel-lockout feature, but many hams just aren't used to that kind of a repeater setup on FM analog yet. > He recommended stationary radios beacon every 12 hours, and mobile radios > send their position only on PTT, not automatically. > > This makes sense to me, but I'm curious how other parts of the country > feel about it. Around here, it wouldn't make MUCH difference unless a QSO was going on. It would be even NICER if the auto-position features in the Icom rigs had an "intelligent back-off" timer set of settings where if the frequency is busy, they slow down, if desired. Kinda like Kenwood's feature where if you're turning/changing direction, etc.. the APRS transmissions speed up... but otherwise they run slower in a straight-line type of travel. The rigs definitely need to be "smarter" in the future about GPS coordinate broadcasts... there's a number of good/bad ways to implement that. But generally, for today's "dumb" implementation -- I'd say you really don't want folks auto-broadcasting location info very often. It'll be bound to annoy *someone* who takes themselves and their ham hobby so seriously that they can't ever reach over and hit that special key that fixes EVERYTHING in Ham Radio, labeled "Power" or "OFF". :-) :-) :-) Nate WY0X > > Jim - K6XZ > > ----- Original Message ----- > From: Nate Duehr > To: Discussion of D-RATS > Cc: [email protected] > Sent: Wednesday, May 20, 2009 5:48 PM > Subject: [DSTAR_DIGITAL] Re: [drats_users] Dprs question > > > On Wed, 20 May 2009 07:36:15 -0400, "Adam Karsin" <[email protected]> > said: > > > First thanks to everyone! It works, no fancy software (like I had been > > told > > in the past) just hook radio to GPS, set a few settings in the radio and > > *poof* *presto* there is a little icon of me on the web!! Ok, it's early, > > I > > entertain easily! > > You have me laughing because that was MY first experience with it > too... > and I set up the darn Gateway! (I didn't know all that add-on stuff > included a "it just works" copy of javaAPRSd running on the Gateway > that > would send all the right "stuff" to the world. LOL! > > > So for about the 2 hours I was driving around I have realized something, > > _bring extra batteries_. 15 minutes into running errands yesterday the > > GPS > > batteries died, and shortly after that the battery on the 91AD followed > > suit. > > Same thing happened here too... I quickly realized that I have EITHER a > serial cable for my venerable old Garmin GPS V, *OR* a power cable, but > not one of the "dual" cables. Oops. Something to order... eventually. > Rechargeable AA batteries are playing "cover" in the mean-time. > > One of the posts on the Gateway admin's list a while back talked about > how to drive a separate TNC/radio with the SAME copy of javaAPRSd from > the D-STAR Gateway machine, to create an APRS/IP Gateway on "that side" > of things. > > With the repeater being at a REALLY high mountain-top site and there is > already an APRS DIGI up there, radio/antenna/etc... already up there, > and owned by one of the tech crew members of the D-STAR group... all we > have to do is run a cable to the TNC, reconfigure things a bit... and > voila... APRS/IP Gateway. > > Then we can also gateway the DPRS from the D-STAR side to the RF side > on > APRS and back and forth if we want to, without having to hunt down the > current IP Gateway operators, necessarily. > > (Obviously having an IP Gateway up WAY up high at the super wide area > Digi site is going to change the Denver APRS "landscape" a bit, but > I'll > leave that to the Digi owner to discuss with folks, etc... should be a > GOOD thing... but hey, we have solid IP access up there... why not? > Save a few hops and some air-time... just about everything in the city > can get there direct.) > > So... anyway... that'll be much later this summer, if we even get 'er > done. We're all swamped with more pressing projects right now. But > it's a cool thing to do up there. > > Have fun with DPRS! > > Nate WY0X > -- > Nate Duehr > [email protected] > . > > > > [Non-text portions of this message have been removed] > -- Nate Duehr [email protected]
