Re: [Xastir] Local Info, repeaters and object.log
On Tue, Aug 19, 2008 at 10:41 AM, Kelly Martin-AB9RF [EMAIL PROTECTED] wrote: Hmm... it's an interesting idea. Currently the splat analysis is raster data, but I think there is some way to have it calculate vector data. Might be easier to run the raster analysis through a line tracer. I'd love to see this done with radar data too. Getting vector data out of splat would be best done by generating a .plo file, which is just a huge litany of points (they're actually generated along each azimuth line going outward) with the corresponding path loss. Building contour lines from that data ought not to be terribly hard. .plo files are freaking large, though (4 megs for a 100-mile radius calculation, which is actually inadequate for some repeaters sited up on top of a mountain). Herein lies a problem that needs to be addressed rather early in this type of discussion. There's no way that we can entertain sending 4 megs of data out over the air to describe a repeater coverage area at 1200 baud. Obviously that's not needed to draw a coverage limit contour. We would only need the location along the azimuth line that corresponds to the desired signal level. So, how many azimuth lines are required to describe the coverage contour? The more lines, obviously the greater detail can be conveyed, but that is done at the expense of airtime used to send that data. The APRS spec has an area object descriptor, which allows us to send points to describe an area. How many points surrounding a repeater would be needed to adequately give a reasonable facsimile of the repeater coverage? Jon NG0E does a pretty good job of showing propagation openings by using a 12 radial descriptor, and then using bezier curves to create a coverage plot that isn't simply a 12 sided polygon. Here's how he describes calculating and drawing the propagation plots. ** The propagation maps on this site are derived as follows: * Only stations which have received 5 or more distinct station-locations in the past hour are analyzed. * For each of these stations, the average and standard deviation of reception distances is calculated for 12 equally spaced 30 degree slices; the maximum propagation distance in each direction is computed as three standard deviations over the average distance. * The computed maximum propagation distances for each of the12 slices are converted back to latitude and longitude for mapping. * The area formed by connecting these twelve spokes is smoothed using bezier curves. ** You can see this at work here: http://www.mountainlake.k12.mn.us/ham/aprs/path.cgi?map=na Obviously these maps show approximate propagation openings, and not areas where you would be guaranteed to find openings. Similarly one should not expect the repeater coverage described by an APRS object to be 100% accurate either. What I would suggest is to do something similar for repeater coverage, take that Splat! output, and reduce that 4 meg .plo file down to 12 lat/long points spaced out every 30 degrees, and output that as an area descriptor. That would give immediate capabilities to any client that can handle area objects. I would also suggest adding an addendum to the descriptor that would indicate that bezier smoothing should be used, to make the dodecagon into a blob. Bob might object, but Xastir could lead the way, and being an addendum to the descriptor, other area object renderers would not be hindered by it. Another 2 bits worth of conceptualization free of charge! James VE6SRV ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Seismic event feed?
We don't know anyone with enough free time to worry about making events for earth shivers... Personally I live where Terra Firma is exactly that! Curt will let you know all about firenet... There's more than enough stuff going on on that feed to keep you busy for a while. James VE6SRV On Wed, Aug 6, 2008 at 4:09 PM, Alex Carver [EMAIL PROTECTED] wrote: I was hunting around online to see if there was a seismic event feed that I could use in Xastir. Know any? If not, I suppose that in my copious free time I'll figure out how to write a program to parse and inject the data into Xastir. :) ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] torrents and xastir
On Fri, Aug 1, 2008 at 8:10 AM, Curt, WE7U [EMAIL PROTECTED] wrote: I guess once two people have it and are seeding it changes things, but that initial first download would take forever. Just a minor point, but it is a significant reason why torrents work so well... If you have one seeder (has the whole file), and one leecher (wants the whole file), then that download will take a while. However, if you have 2 leechers, they could possibly get the file as fast as a single leecher. Once leecher #1 gets a segment from the seeder, leecher #2 can request that segment from leecher #1. As soon as anyone in the torrent has a segment, they can start sharing it with others in the torrent. You don't need to have the whole file before you can start adding to the transfer capability. I have been in a torrent with no seeders, sharing a file for a couple weeks, slowly getting more bits and pieces as people came and went. It took a while, but when I finally got all the segments, I was able to seed that file. So, even if you don't have all the pieces, you are still contributing to the cause, by uploading segments that you do have to the others in the torrent that are in need of them. It's possible to be in a torrent, and download a whole file without ever getting a segment from a seeder. It's really a good way to share content, but only if people leechingmake sure they don't shut down their upload capabilities. James VE6SRV ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] D700 Connection
On Fri, Apr 11, 2008 at 3:06 PM, Jason KG4WSV [EMAIL PROTECTED] wrote: there's no point in connecting to more than one aprs.net or aprs2.net server (core or tier 2) Sure there is... you can set up multiple filters, and pick what you want out of the stream I can connect to one server with a radius around my house, and to another one with a radius around another area I'd like to watch. Unless I can ask for multiple areas all from one server... I've never tried that... can I ask for radius around 2 areas from the same server? James VE6SRV ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Maps
On Mon, Mar 10, 2008 at 6:11 PM, Murry [EMAIL PROTECTED] wrote: They won't load. Wondering if anyone else has problems. When you say load, do you mean download from the Toporama server, or load from your hard drive and display on screen? The script for downloading from the net is written to pull ALL of Canada. This can take a little more than 2 or 3 minutes. Okay, a lot more than 2 or 3 minutes. I used RadioMobile to define the are that I wanted to download, and used it to pull the tiles from the server. I was able to get RadioMobile working, and then go to bed, letting it pull all the 50K tiles for Alberta. I then modified the script to ignore downloading, and to simply generate the geo-reference files for each tile. James VE6SRV ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Xastir and TM-D710A
On 12/23/07, Russell Handorf [EMAIL PROTECTED] wrote: I think it's that I had it configged for 9600 baud, not 1200. When I use the internal TNC on the radio for 9600 Baud, I have no updates where as 1200 shows all the traffic. When you say you are using the internal TNC, do you mean using the radio in APRS mode, and looking at the display screen? Are you referring here to menu 601 INTERNAL TNC | DATA SPEED? This is the on-air baud rate. The problem is when I try to tell the radio to use a different port speed on the com port. 9600 baud is the lowest I can go! My options are 9600, 19200, 38400, and 57600. Now you're talking about the settings in menu 528 AUX | COM PORT BAUDRATE, or menu 519 AUX | PC PORT BAUDRATE. The COM port is on the back of the control head while the PC port is on the back of the TX/RX unit. There is also another setting that you should not be playing with, and that is the DATA Terminal Speed in menu 518 AUX | EXT. DATA SPEED. That is only for use when using an external TNC connected to the DATA terminal on the back of the TX/RX unit. Let's get your oranges out of your apple cart. The TM-D710A is a dual speed TNC. It can operate at both 1200 baud and 9600 baud on RF. This is the on air signalling rate. This has nothing to do with the speed of that the radio is communicating with the device attached to the COM port on the radio control head or via the PC port on the back of the TX/RX unit. Try plugging into the back of the control head, and watching the incoming data as you press the TNC button on the D710 to get it into Packet mode. You should see PACKET12 above the side of the radio that says 144.390. That means you are on 144.390 running at 1200 baud in packet mode. See if you can get access to the TNC that way. James VE6SRV ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Infinity GPS Microphone
On Nov 20, 2007 11:44 AM, Fred Hillhouse [EMAIL PROTECTED] wrote: Interesting product! It is unclear how it interfaces with a radio but it looks like custom cables are available. From what I read, this unit will interface through a standard microphone connector. As such, it will have to act in a fashion similar to Mic-e, doing a packet burst after transmission, and or possibly on a time or distance based position reporting system. It doesn't look like it has any mapping built-in. From looking at a single screen shot, I agree, there is no mapping in sight. Depending upon what is implemented in the GPS, you may or may not have a base map. Reading into the information in the PDF, they mention built in graphics for scenic waypoints, and also the ability to download logged data. It sounds like you will at least get a screen that can show you your own location and that of other similarily equipped users. The PDF indicates that one user can see the location of others without a PC. That could be as rudimentary as a text listing of the lat/long, or perhaps an icon overlaid on a nice basemap. We don't have enough information yet to know. Couple it to a Kenwood TH-D7 and the system looks like it might be complete. Yup, or a plain old TH-K2AT. You are not going to gain anything by coupling it to a TH-D7. The TH-D7 will not be able to parse NMEA strings out of an audio encoded stream. The positioning system is most likely not compatible with APRS, so you wouldn't even be able to view the incoming data on the TH-D7. For what it is worth, I have used remote microphones on the job for about 8 years. The microphones get a lot of abuse. I would rather affix a radio and GPS to my pack/jacket/etc and replace a cheap microphone as needed. But the product does look cool! It is an interesting looking product, and can fill a niche market nicely. People can purchase the product and add it to their existing radios very easily. I wonder how long the unit lasts on a set up batteries, and if the batteries go dead, can you still use the microphone for voice use. With enough capital, one could build a similar product that uses APRS, and connects to any amateur handheld to give it APRS capabilities. The RC-D710 provides a similar user interface for the mobile crowd, but still requires an external GPS. James VE6SRV ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Is traffic encryption possible?
On Nov 11, 2007 7:46 PM, Tom Russo [EMAIL PROTECTED] wrote: If I remember correctly, Xastir should also support the !DAO! format No. This keeps getting stated on APRSSIG as if it were fact, but it is not true. Xastir does NOT implement !DAO!. Nobody has ever coded it up. Tom, there's one sure way to fix this misconception... add the code, then you don't have to refute this everytime it comes up! ducking for cover James VE6SRV ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Feature idea for Xastir
Xastir currently is a functional piece of software that does a very decent job of acting as an APRS client. It is in no way handicapped by limited functionality. What needs to happen, is that someone (in the development group) needs to mark a line in the sand(s of time), and start development of Xastir 2.0. New Year's Day is approaching, and it is always marked by resolutions, promises, and new starts. Why not set the date as a line in the sand? 2008 is the year of Xastir 2.0. If the project never gets started, it will never be more than a dream. James VE6SRV ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] FindU trails
On 10/1/07, Tony Hunt [EMAIL PROTECTED] wrote: Did I read correctly that the Fetch FindU trails no longer work on older versions of Xastir due to a change on the FindU data base ? Does not seem to work here although it says its fetched the file .. Maybee its me again , sleeping at the wheel .. Wakey-wakey... Steve added HTML escape characters to the raw output which breaks the older fetch routines. Curt updated the fetch routine to work around the damage Steve does to the data. James VE6SRV ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Water/hydrology shapefiles for Canada?
On 9/21/07, Joe Veldhuis [EMAIL PROTECTED] wrote: I also took the one that James posted for the Geobase.ca road maps and hacked at it a bit. My goal was to make them look the same as the Tiger road maps, and that's pretty much what it does, although it doesn't correctly set the street labels yet. It might only work with the ON map, as that's the one I'm working with (going by James' call, his was probably based on the headers for the AB map). I would like to get the output looking like the Tiger Maps as well, but have found that a little difficult, as you need more information than just road data. A hydrology layer would be second on my list, followed by land use such as parks and other polygons. The dbfawk that I sent you just barely started to make the roads show up with slightly different attributes. I found it difficult to tailor the output nicely as the road classifications can make it difficult. A ramp can be a turn lane separated from the main traffic lanes on a residential street by an island right up to mile long stretches of primary highway on/off ramps. Trying to find a happy medium where you aren't driving in a field at 110 km/hr, but still don't have inner city turn lanes showing up at wide zoom levels is difficult. I never even took a stab at trying to parse out road names. James VE6SRV ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] IGating
On 8/25/07, Steve Friis [EMAIL PROTECTED] wrote: The hope is that the El Paso, Local an URFMS digi's will lower the hops they retransmit. See my comment above. I was not thinking that supposition, but the way I worded my first comment I can see how you would think that is what I meant. Aha... now I understand what you meant, not what you typed. Yes, if you provide an i-gate locally, those who's sole purpose is to be seen via the internet can use shorter paths, and by doing so, reduce the total RF load on the network as a whole. Indeed, you've got the concept. Right now, as far as I know, I am the only station IGate equipped in Las Cruces. I think that is why El Paso set their digi's for so many hops. Okay, here's another amibuous interpretation... What do you mean by the last sentence? The digipeaters don't control how many hops other set their paths to. If the digipeaters are set to a large outgoing path, it only affects the packets sent by them, not packets being digipeated. Now, under the new n-N paradigm, we suggest blocking long paths, by trapping them with the aliases programmed into the UIDIGI algorithm in the KPC-3 TNCs. It's really hard to make good comments on a system that you can only observe via the APRS-IS, without any knowledge of the local terrain. El Paso appears to have 2 digipeaters. ELPASO appears to be located on a ridge overlooking the city, with a good view of just about everywhere. It is using the proportional path concept to keep it's own load down on the network. ELPNE looks like it is a redundant digipeater. It's only a couple miles NE of ELPASO, in an area that should have excellent coverage by the ELPASO digi. The proportional path used by ELPNE shows me that the operator does not fully understand the new n-N paradigm, as he has an outgoing path of WIDE1-1, which would trigger home fill-in digipeaters. A main digipeater should never ask for help from the fill-in digis. Siting two digipeater close together in overlapping coverage areas causes a large decrease in the amount of available airtime, and is a detriment to the APRS network as a whole, rather than contributing to the network. The local network appears to support up to 4 hops. With digipeaters situated on mountaintops, 4 hops can cover a huge distance. I see JACKPK being heard by BENRDG 250km away which is it's most common access to the APRS-IS. With the amount of activity I can see around there, I highly doubt that 4 hops are needed by anyone. 2 hops in the area would get just about anyone to an i-gate, and also heard via RF over a huge area. This is true. There is a digi on Mt. Franklin which is in El Paso. The Upper Rio Grand FM Society has many interconnected digi-peaters in the area, but because of location, can not directly IGate. This is because of the remoteness of the mountain tops, and the expense of trying to run a dedicated phone line to run the internet. These digi's do a fantastic job at what they are supposed to do, which is to repeat, so they can be heard by an IGate. ELPASO is only 9.4 km from an i-gate which it hits very well, and gets i-gated through over 90% of the time. The remote digipeaters don't need internet access directly, you have a lot of i-gates in the area. You also have lots of stations using paths that cover huge distances. Take a look at how far ELPASO hears stations. http://www.db0anf.de/app/aprs/stations/digiusermap-ELPASO The best thing anyone can do for their local RF network is user education. Teach people that long paths are not required. Get them to reduce thier impact on the local network, and more people will be able to play, as well as the network reliability will increase. It's a tough job, but it needs to be done everywhere. James VE6SRV ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] IGating
On 8/25/07, Alex Carver [EMAIL PROTECTED] wrote: In that same train of thought, it would be nice if the APRS-IS could show the duplicate packets instead of discarding them. Then you possibly _could_ get a better understanding of the RF network by watching how a packet propagates and duplicates itself. It would be great to have a port that shows all unfiltered packets in real time. I think people would be shocked to see just how far their packets travel. The reason for filtering is to reduce the amount of packets being stored in the database. Even at that, the findu.com database doesn't store a whole lot of history any more. James VE6SRV ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
[Xastir] Hop number in Xastir
On 8/19/07, Bernard Tyers [EMAIL PROTECTED] wrote: Also, PHG circles - these are not valid for an APRS-IS connected station, right? What should be displayed? Nothing I presume. It should be shown by the symbol you choose? PHG can be valid for a station connected to the APRS-IS if they are also on RF. PHG describes an RF station coverage area. Finally, (sorry lots of questions) - is it better for the APRS network to have more stations connected via APRS-IS than via RF? I guess its better to have more of the same stations connected than lots of different (mobile, stationary, etc...). Define better. If you are out mobile in an RF only environment with everyone else on the APRS-IS only, how much information do you get? APRS is designed as a local information delivery system. As an APRS user, you should get information about your local area delivered to you on your display. Having local information available only on the internet doesn't do much for an RF only user. Define your idea of better, and then you can qualify your answer. APRS was conceived and designed by Bob Bruninga as an amateur radio information service. Steve Dimse added the internet connectivity portion, and changed the face of APRS forever. I lean towards the radio side of APRS, but rely heavily on the internet side for observation. If I had to only choose one side, the RF side would win. James VE6SRV ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Radio frequency question from a simpleton
On 7/19/07, Curt, WE7U [EMAIL PROTECTED] wrote: On Thu, 19 Jul 2007, Jason Winningham wrote: On Jul 19, 2007, at 2:20 PM, James Ewen wrote: Plus APRS is available for no fee to the amateur radio community, but you need to talk to Bob Bruninga about licensing it for commercial use. I thought that was for the application APRS-DOS, not the protocol itself? That's my take on it too Jason. From : http://web.usna.navy.mil/~bruninga/APRS-docs/COMMERCL.TXT COPYRIGHT 1993,94,95,96,97: The APRS formats originated for use in the amateur radio service. Anyone is encouraged to apply the APRS formats in the TRANSMISSION of position, weather, and status packets. However, the author reserves the ownership of these protocols for exclusive commercial application and for all reception and plotting applications. Other software engineers desiring to include APRS RECEPTION in their software for sale within or outside of the amateur community will require a license from the author. (very reasonably priced) The wording is poor, but the intent is pretty clear... Bob reserves ownership of the protocol for commercial use. Not just the program he wrote to encode/decode the protocol, but the actual APRS protocol. Does Xastir get around the license for reception because the software is not for sale, or did someone purchase a license? I would guess that if Xastir purchased a license somewhere along the way, that it would probably go against the GPL license... Uh-oh... sounds like the lid just popped off a can of worms. James VE6SRV ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Radio frequency question from a simpleton
On 7/19/07, Curt, WE7U [EMAIL PROTECTED] wrote: I've always heard that you can't protect a protocol, but IANAL. If you have enough money you can protect whatever you want... http://www.sbszoo.com/irlp/ When we put together the local IRLP link, I created a fun logo to put on the box. Within 6 months the Intel lawyers were threatening to sue for trademark infringement. We had to cease and desist from using the logo, and we also were not able to use the phrase inside, where was any word. Some people have no sense of humor. James VE6SRV ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Position rate possibility....
2) Moving mode. Me sees three possibilities here: A) fixed time beaconing; B) Fixed distance beaconing; C) Speed based beaconing. I would prefer speed based beaconing. Instead of having threshold points, I would make the time change linear. Have an X-Y formula: X being speed; Y being distance. Both end points on both axes are settable. At slower speeds, you usually are working city streets. This would require more transmissions because of the Urban Canyon issue and there are more opportunities to radically change course. This would avoid the big position jump on a track where you look at a map and see someone halfway across the county changing directions. Beaconing faster at slower speeds is diametrically opposite to the SmartBeaconing concept, as well as your fixed distance concept. With a fixed distance concept, you beacon slower at slow speeds due to the time required to cover the set distance. At slow speeds you beacon at a slower rate because the amount of error in your distance accumulates at a slower rate. The idea is to be able to have a circle of ambiguity that you will find the station within. The faster the station is travelling the faster you have to beacon to be able to keep the circle of ambiguity the same size. Because we send speed and course information with our packets, we can reduce that circle of ambiguity down to an arc. We can dead reckon a station's position until the next beacon is heard. This works great unless the station makes course changes before the next beacon is scheduled. The sooner the station makes that course change after a beacon, the more ambiguity there can be. CornerPegging is what make sure that we are informed of any course changes that happen between the time/distance based beacons. We set a minimum course deviation that we want to report called minimum turn angle. If we choose to only report course deviations of 45 degrees or more, so that we don't beacon a whole lot in town when making lane changes and such, then we can still get well out of that ambiguity arc when cruising down the highway, and make a moderate bend in the road. Using turn slope divided by the speed allows us to set a minimum turn angle for the highway speed, yet still requires a much larger course deviation at slow speeds so we don't go crazy in town. The HamHUD used to send extra beacons in the event it didn't receive a digi repeating it's own signal. It was taken out, I think because of other people complaining about channel congestion, but I'm not 100% sure of that -- it's been several years. The HamHUD used to listen for a digipeat to come back, and if it didn't hear that, it would beacon again. We got flack about that. Because of the nature of mobile packet radio propagation, and the need for packets to be copied 100%, it is possible for the packet sent to be copied properly at the digipeater, digipeated, and then not heard at the mobile that originated the packet. APRS is a send and forget protocol... You can not be guaranteed that others hear your packet. You can not be guaranteed that you will hear every packet. You need to send your packets when you should, and continue along your way. 3) Dealing with turns. This seems to be a sore spot - corner pegging. We only have a max data rate of 1 secoud out of most GPS units. So what I would do is modify the sending rate based on the degrees turned and instead of using a lookup table, I would use maybe cos^2 or cos^3 of the angle change as the modfier. Modify from the current beaconing rate down to 1 sec beaconing at = 90 degrees. Here in Wisconsin, U-turns are legal so those would have to be covered. No sore spot with CornerPegging... It works great. It's interesting now that you want GPS updates faster than every second. It used to confound the problem... There is no lookup table for CornerPegging. It is simple math. We compare the heading change since beacon to the turn threshold. If it is greater, and it has been longer than the minimum turn time, we send another beacon. In the math limited microprocessors, it is difficult to do squares and cubes of a cosine of an angle if not impossible. Why you would want to increase beaconing to every second while turning is a little confusing. The problem that you are trying to solve is excessive beaconing, and your solution increases the beacon rate. Now if I have covered old ground, forgive me. These are just thoughts. Look at the descriptions of SmartBeaconing and CornerPegging on the Wiki. http://info.aprs.net/wikka.php?wakka=SmartBeaconing http://info.aprs.net/wikka.php?wakka=CornerPegging Look at the description of the SmartBeaconing and CornerPegging concepts and implementation on the HamHUD site. http://www.hamhud.net/hh2/smartbeacon.html It is always better to try modifying or reinventing something by first understanding how it works. James VE6SRV ___ Xastir mailing list Xastir@xastir.org
[Xastir] SmartBeaconing routine
So, having perused the SmartBeacon code for a while now, I have a couple questions... // Check to see whether we've sped up sufficiently for the // posit_next_time variable to be too far out. If so, shorten // that interval to match the current speed. if ( (posit_next_time - curr_sec) sb_POSIT_rate) posit_next_time = curr_sec + sb_POSIT_rate; Why is this statement in there? It looks like you are checking to see if the interval is too long for the speed. This is looked after by this statement. sb_POSIT_rate = (sb_posit_fast * sb_high_speed_limit) / speed; The interval decreases as speed increases. The one shortfall in the SmartBeacon routine is that it does not report decreases in velocity. As velocity decreases, the beacon rate increases, which means that the next beacon will be further away in time. Let's use: high_speed = 60 high_rate = 120 (sec) low_speed = 5 low_rate = 1800 (sec) If I am travelling at 60, and send a beacon, my next beacon should happen in 120 seconds. If I stop right away, my beacon rate will drop to 1800 seconds. This leaves APRS clients dead reckoning me at 60 mph until that next beacon gets sent. If I am travelling at 10 mph, my rate is one beacon every 720 seconds (12 minutes). If I accelerate to 20 mph, my rate increases to on beacon every 360 seconds (6 minutes). Increases in speed increase beacon rates, so there is no need to worry about bumping rates up. When we slow down though, the opposite is true. At high speeds, SmartBeaconing is the primary reason for position reports being sent out, with the occasional beacon forced due to CornerPegging. At low speeds, the reverse is true. CornerPegging becomes the primary reason for beacons being sent, with the very rare occasion when a SmartBeacon triggered beacon is triggered. In everyday driving, you will find that the combination of SmartBeaconing and CornerPegging do a good job of representing your track. James VE6SRV ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
[Xastir] Build issues
So, I'm back at it again... having problems with building Xastir on Cygwin. Running update-xastir, I see there's a problem with permissions in updating files Merging differences between 1.11 and 1.12 into update-xastir cvs [update aborted]: cannot rename file .new.update-xastir to update-xastir: Permission denied I have no idea what I've done, but ImageMagick has disappeared as well. checking for WriteImage in -lMagick... no configure: WARNING: *** Cannot find ImageMagick library files: Building w/o ImageMagick support. *** I went through the wiki instructions, downloaded the Cygwin Binary and installed it, modified configure, etc... still no go. James VE6SRV ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
[Xastir] Partial maps on Cygwin
Here's an interesting situation... I have 1.9.1 running under Cygwin, and of all the online maps in the /usr/local/share/xastir/maps/Online directory, only TXRadar.geo and USRadar.geo show up in my Maps Chooser dialog. Any reason why the others in the directory don't show up? James VE6SRV ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Fetching a trail
On 6/17/07, Earl Needham via Kubuntu [EMAIL PROTECTED] wrote: With my Xastir call set to KD5XB-11, I click on fetch... and fill in the data for KD5XB-11, for the last 120 hours. After several seconds' delay, the window comes up telling me the track has been received, and then, right next to the icon already on my map, I see MANY MPH readings flashing by. No trail on the map, just all the MPH readings going by. Yup, I see the exact same thing happening. I high-jacked your call and set myself up at your location, and pulled the last 120 hours. The course and speed information changes, but the icon stays in the same location. Perhaps I never have pulled in a trail for the current callsign. Curt, is there a way to go out and grab a history for your current callsign? I could see a reason for doing so. If I was out on a balloon chase, and the computer died, after restarting, it would be nice to be able to grab the historical track to reload back into the map display. James VE6SRV ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Weird plotting
On 3/1/07, Tom Russo [EMAIL PROTECTED] wrote: This looks suspiciously like a digi that's holding packets too long before digipeating them. My memory's kinda dim on the subject, but as I recall it is stale packets being re-transmitted long after later posits are created. If you're seeing the behavior in a specific location, it's likely that the nearby digi is malfunctioning somehow. You might try searching the APRSSIG archives for details, as I don't remember exactly what the mechanism is or what the comment traits were. Mountaintop digipeaters that can hear far too much will exhibit this phenomenon. Let's pretend for sake of simplicity that all APRS users set their path for 1 hop, making use of the digipeaters to simply digipeat once and once only. The i-gates grab this information and forward it on to the APRS-IS. So, let's also look at the situation where Dave KJ5KG is driving along near BIGDIGI. BIGDIGI can hear 5 other digipeaters. As Dave drives along, he can be heard by the digipeater, and also a local i-gate. As Dave drives along, his packets get digipeated and gated to the APRS-IS. However, in one location Dave only gets heard by BIGDIGI... he is shadowed from the i-gate. BIGDIGI attempts to gain access to the channel, however the neighboring digipeaters are busy making noise. BIGDIGI has to wait for a chance to get on the air. Meanwhile Dave's tracker pumps out another position report which is heard by the i-gate. Finally BIGDIGI finds a spot to digipeat the packet it has been holding, and does so. The i-gate dutifully sends the packet along to the APRS-IS. This easily shows how packets can be sent 1 - 2 - 3, and get heard on the APRS-IS in 1 - 3 - 2 order. In a quiet area, it is rare to see packets get out of order, but in higher density areas, it can happen on a regular basis. One thing that quite often happens though is that people think that their local digipeater is not heavily used when in fact the digipeater is hearing a very active channel. Remember the assumption above about single hop paths? I did that specifically to get you thinking about channel usage with used up paths. BIGDIGI would never act upon any packets except those that it heard locally. It would never need to digipeat packets already handled by another digipeater. However, those digipeaters within earshot still use up local airtime according to the local digipeater. It may sound like a really quiet channel on the ground, but that digipeater up on the mountain, or on that huge tower doesn't hear as quiet a channel. Digipeaters with incorrect DWAIT and SLOTTIME or TXDELAY settings can wait for quite a while in a noisy area. The noise level is determined by adding the activity on your local digipeater PLUS all the activity on ALL digipeaters that the local digipeater can hear. When you use a single hop path, you affect the channel load for the local digipeater, and also those it can hear. When you use a 2 hop path you affect your local digipeater, all digipeaters that can hear the local digipeater, and also all digipeaters that can hear the digipeaters that heard your local digipeater. You affect people one hop further than the number of hops you are using. James VE6SRV ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
[Xastir] Xastir on VMWare Segfault
I had Xastir running from a terminal window, and found out that it seg faulted. I can't find a core dump though. I also seem to be having problems with the shapefiles. It seemed to work pretty fast when I first started playing with them. Now it can take up to 2 or 3 minutes to render an image. I thought it was because I had created a dbfawk file, and it was taking a while to parse out the file, but I removed the dbfawk file, and still get massive delays when trying to use shapefiles. James VE6SRV ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Xastir on VMWare Segfault
I've got a theory. I ran the VM this weekend for several days. It never crashed or bogged down as you describe, but when I used a bunch of shapefile maps it did use a bit more memory than I thought it would have needed. I betcha dollars to donuts what you're seeing is that xastir is starting to take up more RAM than has been allocated and eventually the VM starts thrashing. I started the VMWare appliance again... With no dbfawk file, I was able to zoom around pretty decently. No serious lags in rendering. The full province took about 10 seconds to render. Xastir sits at about 7% memory usage. There was about 8K of memory available. I zoomed close in (4 second render), and then renamed the dbfawk file back so it matched the file names. Another zoom in, and it took 45 seconds to display. Xastir moved up to about 9% memory usage, and memory available moved down to about 3K. Used swap space never changes... I think there's a problem with the dbfawk file though. I'm following the original instructions you gave me just over 2 years ago. This should have almost everything rendering in red and 4 pixels wide. Nothing ends up that way, but the names all appear as None, which means that it is working somewhat. With the huge rendering lag, I haven't been looking at the dbfawk file though. Xastir never fails to challenge me! James VE6SRV ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Xastir virtual machine now available for download
On 12/24/06, Tom Russo [EMAIL PROTECTED] wrote: I've managed to have it die more than a couple times. What dies? The whole virtual machine? Xastir? Just the instance of Xastir that is running. There's no terminal window to have a look at to see what error might have happened. I've managed to lose access to the ethernet pass through as well. Making changes on the Windows side kills the connection, and I have not figured out how to refresh the connection from within the VMWare appliance. I also can't seem to get it to use shapefiles. Check file permissions. Bingo! I forgot about file permissions! That was indeed the root of my problems. I have added a small section to the Wiki under Adding Maps in the VMWare: How-to reminding people of this fact. This is the first I have made use of the rtree function, and indeed it appears to do a very good job of speeding up the processing of shapefiles. My road .shp file is 42 MB in size, and the associated .dbf file is 504 MB in size, yet Xastir can render a map in only a few seconds. Before rtree, I cut the file into Maidenhead gridsquare chunks. This allowed Xastir to only process tiles within the viewing area. rtree appears to work faster on the huge single file. Now I have to define the dbfawk file for the Canadian shapefiles once again. I did this once before, but never got things looking decent before the file got eaten by a hard disk failure. Perhaps this time I will save a copy offsite... Seasons Greetings to all! James VE6SRV ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Xastir virtual machine now available for download
Has anyone played much with the VMWare appliance version of Xastir? I've managed to have it die more than a couple times. I also can't seem to get it to use shapefiles. The help dialog shows that shapefile support is built in, but after putting shapefiles into the map directory, and reindexing I show no maps beyond what came with the appliance. James VE6SRV ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Xastir virtual machine now available for download
On 12/2/06, Tom Russo [EMAIL PROTECTED] wrote: Thanks to Jason Winningham, the Xastir virtual machine I made for use in VMware player is now available for download I was finally able to get a chance to download and install the Xastir virtual machine... Jason's server rocks! I was able to pull down the file at an average of 3.5 Mbps, with peaks to 4.5 Mbps. If I were on a fast connection, I wonder what I could have done! The Wiki instructions fall into the usual *nix trap. Rather than simple straight forward instructions, they fall off track talking about options available. You need to read a couple paragraphs, skip a few, read another, skip 2 more, and then all of the sudden you're at Hey, I'm done. Simple linear instructions with no branches are what is required to make these things easy to follow. After the fact, you can add in all the options, and let people know what they can do if desired. The Cygwin instructions are written in a very linear fashion, and are very easy to follow. I was able to follow the VMWare instructions, but had to skip around a bit to get the proper path. I had a bit of trouble with getting access to the ethernet device, but that was my own fault. I had disabled the VMWare network devices manually attempting to solve a networking problem in the week between VMWare download and the Xastir appliance download. I did manage to get the ethernet screwed up again, which I have not yet determined if it was a one time problem, or a repeatable event. I also discovered that one needs to disable any screen savers in the VMWare world. My CPU cycles maxed out on me, which I was able to track down to the VMWare process. Switching back into it, I found the radar screen screen saver merrily chugging along. Killing the screen saver brought the CPU cycles down a whole lot, but about that time is when the ethernet broke. For being a minimalist desktop environment, Xubuntu presents a nice user interface! James VE6SRV ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Ask not what your Wiki can do for you. Ask rather what you can do for your Wiki.
Also... Do I need a password/account? You can view the Wiki information without an account. To be able to edit, you need to set up an account. The account is quick and easy to set up. It is needed to keep bots from wiping out Wikis... You can create an account and be able to edit the Wiki within a minute. James VE6SRV ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] New user..and thanks..
On 11/18/06, Jeff Mohler [EMAIL PROTECTED] wrote: Ive just this moment finished making my first map, discovered that they have to be square in the process. As Curt said... rectangular. If you make an image larger than the screen, you can zoom out view the whole image. This however allows you to zoom into an area of concern with as good of an image as you can get from the original image. Using a small image and zooming in makes it blocky (pixellated). Not sure what to do with timing yet, most of the time we'll have no more than 5 vehicles to track, at Mid Ohio I could have up to 12-15. Just to clarify for everyone, you are not tracking race cars, but the emergency support vehicles. When in action, 30s is far too slow, but I dont see how 5 vehicles could xmit updates every 5 seconds without lots of collisions. If you set up SmartBeaconing to update rapidly when the vehicles are responding, you would be able to keep the dormant response vehilce out of your way on RF because they are not sending position reports. Because SmartBeaconing is activated by movement input, there is no way to avoid collisions. You will want to use the shortest possible packets, and you will want the highest possible precision as well. The 60 foot grid precision won't cut it, you'll need the 2 to 3 foot precision. Here I'll save time ans simply quote Curt: Mic-E: No timestamp and about 60' precision, short packets. Standard APRS: Timestamp and about 60' precision, longer packets. NMEA: Timestamp and precision based on GPS sentence but LONG packets. Base91: Timestamp and 2' precision (assuming GPS puts out good precision), short packets. So, what are you using for trackers? Going to 9600 baud also shortens up the packets, but it limits the available tracker hardware. James VE6SRV ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] New user..and thanks..
On 11/18/06, Curt Mills [EMAIL PROTECTED] wrote: How much creativity do I have available to me to create a custom map? You can create your own maps in any of the formats that Xastir can use. If using images, you can create a large one, tile it into smaller pieces, and set up a .GEO file for each one. Xastir can then load the ones of interest as it needs to. Just further to what Curt has said above... You can use the track map from the website as a base map, all you need to do is tell Xastir where the corners of the image are in relation to the face of the Earth (the .geo file). You could also capture the satellite photo from Google Earth, and create a .geo file for that image. My preference would be to capture a large image (2000 pixels across or so) from Google Earth, and use that.You would be able to see a fairly decent image of the track when zoomed in, or back out to watch the full track. How many safety vehicles are you tracking? Crash Trucks, Ambulances, Tow Trucks, etc? Are you looking at time slotting them, or having them use SmartBeaconing with rapid update parameters when in motion? Smart Beaconing would have only the responding vehicles making noise, but could have the occasional packet collision. Time slotting would have the packets running all the time, with constant monitoring of operational status of each tracker. With low power handheld radios, you shouldn't have to worry about current drain too much. The safety vehicles will probably be running enough to never worry about killing the battery. I'd probably run timeslotting with every safety vehicle reporting once per minute as a minimum. I'm not sure if the OpenTracker is able to sync to the GPS time embedded in the NMEA strings or not. You would want to keep the time slotting accurate. Depending on the number of safety vehicles, you might be able to do 30 second updates. (This is on a private frequency, not 144.390... don't get your panties in a bunch!) It sure would be great to have a realtime tactical map of the location of all safety assets at all times. This is a perfect example of textbook use of APRS as a real time tactical display tool. I've run safety net control for a couple Cascar events here in Edmonton, as well as main control for the Champ Car Grand Prix of Edmonton. I've used pins/magnets for keeping track of assets, but there's nothing like having that automated for you. The Champ cars all have transponders onboard that get picked up by trackside recorders, and then their computer system dead reckons the position between trackside recorders. That gives a great view of what's happening on track. With APRS on the Safety crews, and Xastir dead reckoning their movements, you'll have just about the same thing. BTW, beautiful facility! I LOVE turn 5! That must give a great sphincter muscle workout to all the drivers. The rest of the course is pretty wild as well. What a workout for the bike riders! James VE6SRV ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Festival Speech
Festival could be a lot more useful if the proximity alerts didn't get fired off by the movement of your station. For a fixed station wathcing people drive by, it works pretty good. Every time the mobile station moves, it will tell you the callsign and distance information for that station. I tried it while driving one day, and I had the audio queued up for 1/2 an hour because I drove past 2 fixed stations within the alert proximity. I was 40 miles down the road by the time that Xastir stopped telling me that VE6*** was 5 miles away. (That can get the XYL a little upset!) Xastir needs to ignore movement updates of itself for creating audio alerts. At least it needs to ignore most of them, perhaps firing off an alert every 1/2 mile or so. This could be a user configurable parameter. It should always fire off an audio alert when remote stations send APRS position updates, but hold off due to it's own position updates. James VE6SRV ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Initial Startup
That should reduce the number of newbie questions by a fair bit, and make Xastir a little more user friendly. Xastir is one of the most feature laden APRS programs out there, with the BEST developer support available. The biggest detractor in my mind is the difficulty in initially gettting the program up and running for the first time user. The easier it is to get Xastir up and running the more people can see what it can do. It sound like the Virtual Machine concept will allow this to happen. Adding the startup map and prompted user configuration is a big step to making it happen. My initial foray into the world of UI-View was similar as Roger started up the program with a fairly close in map of his hometown of Boston, UK. It took a bit to figure out how to get a map that covered a larger area. By including a generic low detail map of the world, everyone gets to see where themeselves on the map. From there the user can grab maps for their local area. James VE6SRV ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Better and/or Easier Way to Get Xastir on Windows
On 11/9/06, Steve Friis [EMAIL PROTECTED] wrote: Gerry Creager wrote: I'll look today for a freely distributable world map, probably shapefile format. Will that satisfy anyone? That much I should be able to accomplish. Check out the one listed on the old web page called Worldhi.map. It loads very fast, and even has some color in the lines. I think it is in public domain, but I could be wrong. Would certainly provide proof that the program is working. Steve/WM5Z This is a recurring theme! The best solution in my never humble opinion is to use a chunky old DosAPRS world map. Who cares about resolution and precision. Stuff an image of the world in front of the user to show that Xastir is actually up and running. No extra libraries needed. We want to keep the map size to a minimum, but still have something on the screen. Everyone wants to add a 'decent' resolution map for their area, but that won't be the same for everyone. A simply continental outline map gives people a starting point. A grey screen with grid lines across it gives zero information about relative distances. Every user will want to customize to their own desires, but we NEED to have something pop up in front of the new user to let them know that Xastir is working! James VE6SRV ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Fishers Island Mystery
I never have on the map grid, so I know nothing of any grid bugs. I always thought grid bugs were cool and deserved more screen time. http://members.shaw.ca/jewen/gridbug.jpg You really should look into fixing that before someone gets de-rezed! James VE6SRV ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
