On Thu, Aug 13, 2009 at 2:08 PM, Broncus<[email protected]> wrote:
> I going to start with this setup once the trip is done; > N7FMH-9,WIDE1-1,WIDE2-1. For now, once I am out of > the range of my PNRDVL fill-in, it won't be an issue. That would be a good way to ensure that you are using the same path for both the timed, and SmartBeacon enabled units. You still will have issues out of your control like time differences between when the different trackers beacon. You might loose some packets due to collisions etc. >> > I thought it would be interesting to collect data from a 'timed' >> > tracked and overlay it on a SmartBeaconing track. > >> I don't think it would really prove a lot. The HT (going through the T2) >> would be basically a 40W tracker with fixed timing. > > The use is really for showing someone on a Powerpoint slide the effects > of timed versus smart timing for the purpose of the network benefits. > Not everyone is easily convinced that Smartbeaconing is good. > Some will run timed just because it requires no thinking. By having > -7 and -9 running at the same time, the data reflects the same route > and travel time. And, the beacons are easily counted. If you are going to do this, please don't just analyze the packets over the duration of the route travelled. I have been at war with Bob Bruninga for many years working to get it out of his mind that SmartBeaconing is designed to increase the number of packets sent by a tracker. SmartBeaconing actually reduces the number of packets, and the packets that are sent are of more importance than those sent via timed beacons as they are at significant points along the track. If you compare a timed beacon unit (3 minute interval?) against a properly set up SmartBeacon unit (1 min at >60, 30 min at <5, and normal corner pegging values) over the course of a couple hours, with a "normal" trip of 1/2 hour duration in that time, you will probably find the SmartBeacon unit will send fewer packets. The track left by the SmartBeacon unit will also do a better job of describing the path taken by the tracked unit. If you extend that to where people leave their tracker on 24 hours a day, the SmartBeacon unit wins hands down. If however you only analyze the difference between the two over a twisty course that lasts 30 minutes, the SmartBeacon unit will send more packets. The SmartBeacon settings that are promoted as "normal" or generic are designed to create a decent depiction of where you have been, and also to allow those driving towards each other at highways speeds to notice each other before they are past each other. The concept was to have the beacon rate decrease automatically when the mobile station stopped moving, and to report significant events such as large distances moved, or significant course changes in a timely manor. It gives you an output that would be similar to what you would give for directions to someone coming to visit your house. You wouldn't say, if you are at the corner of Wye Road, and Sherwood Drive, in 3 minutes you'll be on Brentwood Boulevard, and then 3 minutes later you'll be at my house. Better directions would be from Wye Road and Sherwood Drive, continue east. Turn left onto Brentwood Boulevard, then turn right onto Lark Ave. Next turn left on Falcon Drive, and then again left onto Curlew Crescent. The first is what you get from timed beacons, whereas the latter is closer to what you get from SmartBeaconing, although in the real world with minimum turn time set to keep from making too much noise, I don't quite report all those corners as they are pretty close together. One caveat: Preemptive digipeating will use a path that is not next in line, jumping past the paths in front of it. It will be marked as used, and the paths in front will never get used. If you use a path such as WIDE1-1,WIDE2-1,MYCAR and have your vehicle set to preemptive digipeat on MYCAR, it will be handled by the car, but will look like this after. WIDE1-1,WIDE2-1,MYCAR* where the asterisk (*) represents the has been digipeated bit. Any subsequent digipeater fill-in or mountaintop will only look for a path that is after the has been digipeated bit. One other observation from down your way... ever though about building WIDE digipeaters rather than a bunch of fill-in digipeaters? Fill in digis are to boost the signal into the WIDEs from areas where low powered trackers don't get heard. You should still be able to hear the WIDE digipeaters in that area so that APRS is a bi-directional communications medium. >From what I can see you have a bunch of fill-in digipeaters, but the closest WIDE digi is 30 kms away. Can you hear N1EXT-5 reliably in your area? Not only do you want your tracker to be heard from where you area, but you need to be able to hear other people as well. If you send an APRS message to me, it goes through PNRDVL to an i-gate, and then to me a couple thousand miles away. If I send a reply, will your local i-gate be able to get that message back to me? (It should be sending just locally, or possibly 1 hop depending upon the density of i-gates in the area) Since the i-gate is a fixed station with reasonable antenna, it should not be using WIDE1-1. That means you need to be able to hear the i-gate or a WIDE digi to get my message. What about co-locating a WIDE digi with the 147.33 repeater? James VE6SRV
