[aprssig] Local Repeater Displays on Mobiles
Robert Bruninga bruninga at usna.eduThu Jan 25 14:53:58 UTC 2007
- Previous message: [aprssig] Local Repeater Displays on Mobiles
- Next message: [aprssig] DIGIpeater - Network performance
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> ... To program for the least common denominator, IMO, > leaves a lot to be desired. You get all the info by > looking up on the D7/D700 where it is easy to see > the -R I have no problem at all with an object 146.940-R. Though I wouldn't use it, since if it is 146.940, I can already tell that it is a voice repeater. And by leaving off the "R", then for those GPS displays that show only 6 characters on their maps, then at least they show 6.940- instead of .940-R. I just don't see that the -R gives anything. >(Bob, if you are doing lookups while you are in motion > behind the wheel, you are spending way too much > time with your eyes off of the road). If the object name is the freq, as I propose, then one does not have to do any "lookup". I have the control head mounted on the dashboard above the steering wheel where it is even easier to glance at than the car's instrument cluster. And since the frequency 146.940 of the OBJect repeater shows up on the display without me having to push any buttons, then it is hands free too. Your proposed method of having voice repeaters send out just anther callsign with an -R on the end and requiring the driver to push a button to see what the frequency is, I would say is more distracting to the driver and lacks any ergonomics considering the mobile traveler's needs. > I find it interesting that Bob has been a big proponent > of IRLP, EchoLink, and Winlink objects to use the SSID > or the first two letters of the object name as a visual > identifier that it is that type of object, yet he doesn't > like that idea for voice repeaters. Yes, what I am proposing now is completely consistent with those receommendations. That is, that the *info* needed by the travler (in this case the node number) shows up in the OBJECT name, so that it shows on the front panel of the radio hands-free. We recommended putting the ER or IP in front of the object name so that when it was truncated on a 6 character GPS map, then the more important node number would still show on the map. Thus we get ER-123456 for ECHOlink and IRLP-8080 for IRLP and these show on the worst-case-6-byte GPS map as 123456 and P-8080. These are easy to distinguish at a glance from an object "146.940-" But for this voice repeater application, I don't see that much value in focusing so hard on trying to get the digits to show on the GPS map. What we are after here is not that, but the hands-free, heads-up-display on the front panel of the radio without pushing any buttons to show the traveler the receommended voice repeater for where he is right now. > Bob's refusal to say "OK" to adding ,TCPIP* to the third- > party path is odd too: it takes care of APRS-IS being a > factor in this discussion with minimal effort. But your email made two recommendations: 1) put in TCPIP* so the APRS-IS would ignore these packets 2) you wanted to be able to see recommended repeaters in an area remotely via the APRS-IS. You cannot have it both ways. So I took your suggestions and modified my propossal for voice repeaters so that 1) yes we could see them on the APRS-IS if desired and by 2) using the 9th character to make them all unique, so that they could be individualy viewed from anywhere. This then necessitated not blocking them from the APRS-IS by adding TCPIP*, since you cannot have it both ways. > APRS-IS is not going to start handling certain objects > based on their names or symbols in certain ways out of > the millions of packets sent each day. Why not? They already do. The APRS-IS and all clients are already required to parse out the object name and the SENDERS call for every object, since attribution of an object is required in the spec. Only a few lines of code change can logically combine these fields to make all such objects unique. > Yes, propagation in the DFW area where these objects can > collide is almost a daily issue. It must be nice for Bob > to live in an isolated area where he can pass down his > pronouncements with a "I don't care if it doesn't work > for you 'cuz we don't have that problem here" attitude. Don't make a quote out of your own opinion and imply that I said it. I would never say that. And besides it is unfounded anyway... for several reasons. 1) I live in probably the highest density of APRS and voice repeaters on the planet, over 100 voice repeaters and I just checked 50 digipeaters heard on RF. So I think it is representative of the worst case scenario.. SO my area on the eastern deaboard is probably a pretty good test bed. 2) With our population density, we have multiple 146.94 repeaters every 50 to 100 miles or so and yet we don't think that a 146.94 object transmitted DIRECT from 100 miles away is going to cause a problem to our locals. 3) Yes we have tropo sometimes and we sometimes hear multiple 146.94 repeaters in our area, but then it is doubtful that an adjacent 146.94 repeater is also the #1 APRS recommended repeater in the next eastern seeaboard city. Thus, there will not be that many 146.94 objects competing during tropo with ours. 4) OK, say there is a string of 146.94 recommended traverlrs repeters and during band openings these objects do come in. So what. What shows on the radio's display is still just 146.94- which is all that the traveler needs to see anyway. 5) In an area such as you claim as DFW, then if multiple 146.94 repeaters are all the receommended travelr repeaters and you want to distinguish them, then surely the APRS digipeater sysops who are putting these objects in the digipeaeters can agree on a unique -X byte to make them unique. Say, 146.94-D for the Dallas one, 146.94-F for the FortWorth one, and so forth... In any case, these recommended voice repeater frequencies showing up on the front panel hands-free, are far more valuable to the driver than seeing W5XYZ-R and W5APC-R, both of which the operator has to push a button just to see what frequency they are on. So it still seems to me that the best object name should be 146.940- and even the "-" is optional and also any of the 36 additional "-X" options can be used to make the repeaters unique in areas where tropo may be a problem. Bob, WB4APR > > -----Original Message----- > > From: Ron > > Posted At: Wednesday, January 24, 2007 6:30 PM > > Subject: RE: [aprssig] Local Repeater Displays on Mobiles > > > > Thanks for more input Pete. I like the callsign-R but > > I was considering some other angles too. Not only how > > it displays on my D7, but also how it appears on my > > GPS (Fortrex201). > > With callsign-R the '-R' is truncated on the GPS which > > is not so bad but the use of the rptr freq really > > shows up better than just another callsign on the > > little screen. > > > > I don't think you meant that the RNGxxxx was actually > > decoded as much as it was easy to compare that range > > 'number' to the next screen which shows the actual > > direction and distance to the object. > > In my case I added the 'km' to the number to indicate > > km. > > _______________________________________________ > aprssig mailing list > aprssig at lists.tapr.org > https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig >
- Previous message: [aprssig] Local Repeater Displays on Mobiles
- Next message: [aprssig] DIGIpeater - Network performance
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the aprssig mailing list
