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] Speeding up map processing?
On Wed, Jul 23, 2008 at 8:53 AM, Curt, WE7U <[EMAIL PROTECTED]> wrote: > On Wed, 23 Jul 2008, Andreas Weller wrote: >> Another thing I thought about: >> Can I convert the Openstreetmaps data to a vector file format usable >> with Xastir? > > I don't know what vector format they're in now. If you can find > something to convert them to ESRI Shapefile format, it's likely they > can be used in Xastir. You'll need to assure the vertices are in > lat/long format and preferably WGS84 or NAD83 datum, plus you'll > more than likely need to create your own dbfawk file to get them > displayed and colored as you prefer. You can get the OSM tiles as raster images, but you would have to create .geo files for each tile. 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] Maps
On Feb 12, 2008 9:26 AM, Curt, WE7U <[EMAIL PROTECTED]> wrote: > > Anyone know where I can get Canadian maps comparable to tiger maps? >http://wiki.ampr2.net/nwaprs/XastirMaps > > Search there. There are Shapefile maps for Canada with the streets, > I think downloadable a province at a time. Look for geobase.ca, they have the NRN (National Road Network) available there, which will give you all the roads in the area you are interested in. I haven't checked to see how far along they are yet, some areas in Canada were not completed last time I looked. You will have to search elsewhere to find information such as provincial borders. I still have not found any decent hydrology shapefiles, nor populated area shapefiles available for free. > There are also topo maps for Canada. We have scripts in the > xastir/scripts directory for downloading these. Warning: They're > big! Toporama maps are not too bad. They aren't great, but they are better than looking at a white screen. The script for downloading the toporama tiles is written to grab all of Canada. This is a HUGE download, especially if you are only interested in New Brunswick. I don't bother with the Xastir script, but rather select the area I want tiles for using RadioMobile, and ask it to download the 250k and 50k tiles for the area. I then modified the Xastir script to skip downloading the tiles, but still create the index files for the tiles that I do have already downloaded. 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! 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, Earl Needham <[EMAIL PROTECTED]> wrote: > At 03:20 PM 8/25/2007, James Ewen wrote: > >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. > > Wow, it's GREAT to see somebody finally acknowledge > this! I've been trying to tell people that for maybe 10 years over > on the APRSSIG and they just don't seem to get it. Earl, your memory is short... We've been over this before. You just want to see all that activity way out in the boonies where you live. You need to move to the big city so you can live in an overloaded network. Some people would love to have a few seconds of Clovis activity levels every minute. 8) 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
Re: [Xastir] IGating
On 8/25/07, Greg Eigsti <[EMAIL PROTECTED]> wrote: > I think we are both agreeing that the DB0ANF tool is better for > looking at iGate activity than Findu. Not because the data is > different but because the DB0ANF tool allow you to view the data > differently. Most definitely. Presentation of the data allows you to observe different aspects of the same information. Findu does not allow much more than observation of the raw data, or a simple map. > I am not convinced that the data is *the same*. Granted it may come > from the same source but local conditions may cause the data to > differ slightly (e.g. server problems, connectivity issues, software > bugs, etc.). No necessarily local conditions, but quite probably network conditions. Findu used to run on a single machine, and that machine was the only collection point for the APRS-IS data. Now there are 3 machines that findu runs on, with multiple tier-one servers, and a multitude of tier 2 servers. Where exactly DB0ANF pulls his data from is unknown. While the APRS servers are designed to share all the data, and in an ideal world no packets would ever get lost, I beleive they all share data via UDP rather than TCP. This means that there are no acknowledgement packets sent. This is how APRS works on RF as well, send and forget. It is possible that a few packets get stomped in the APRS-IS, which is why I think you see discrepencies between findu and DB0ANF's servers. > From my experiment(s) yesterday I still am not > understanding why DB0ANF showed my last packet sent and Findu did not > - this makes me think there are (or were) problems at Findu. If you > can explain away this issue in a way that a dumb monkey like myself > can understand I'd be grateful! Hey, I'm just another dumb monkey over here too! Just stay away from my pile of bananas! 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] Making better looking maps
On 8/25/07, Stephen - K1LNX <[EMAIL PROTECTED]> wrote: > My first thoughts on implementation for this would be some kind of scraping > method maybe? I certainly wouldn't want to abuse Google's servers, but what > about passing static strings with the positional as a standard http request > and then somehow getting that data to display inside Xastir? Roger Coude has RadioMobile configured to grab tiles from the Google Maps site. You can tell RadioMobile to grab images from Google Maps at various zoom levels. You can watch the tiles get pulled in, and merged with the local data. The nice thing is that you can also save the tiles to your local hard drive so that if you ask for that same area and zoom level, RadioMobile will pull that tile from the hard drive, and not the internet. That means I can have Google Maps satellite images even without connectivity. Roger doesn't pull the road maps, but I would guess that they are produced the same way as the satellite images, in tiles. They too could be saved to the local hard drive for use off the net. James VE6SRV ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] IGating
On 8/24/07, Steve Friis <[EMAIL PROTECTED]> wrote: > Way cool. Since the RF pollution is so high here, I am trying to lower > it some to that low power stations can be heard, or at least stand a > chance. Steve, Another incorrect supposition. Adding i-gating to your station will not lower the amount of noise on the RF network directly. > As it has been, there was not much chance for the low power > stations in this area getting heard. My hope is that once heard and > gated here, then the need to repeatedly be digipeated will be lowered. By running an i-gate you will be able to help those low powered stations located close to you to get to the APRS-IS internet stream. You will not help lower the amount of traffic on RF though. The amount of traffic on the local RF network is a product of the number of stations in your area, the frequency of the beacons from those stations, the path used by those stations, and finally the RF digipeater network in your area. It sounds like you have made the supposition that once a packet from the RF network gets i-gated, that the packet stops on the RF network. The RF network has no way of knowing anything about the internet. If your local RF network has too many overlapping digipeaters that don't support the new n-N paradigm, used by local users that use old RELAY,WIDE paths, who beacon too often and with their power set too high, then the low powered guys don't stand a chance. You can fix any or nearly all of the above, which will make things a little better for the low powered trackers, but the best thing to do is to try and fix all of it. Of course that's easier said than done. Adding more i-gates does not hurt the network, especially if you don't send anything from your station to the rf network. Having redundant i-gates in an area helps with the reliability of stations getting to the APRS-IS. This can possibly help reduce the RF overload IF people see that using a shorter path still gets them heard on the APRS-IS, and that is their ultimate goal. If those stations use a shorter path, or lower power, then the RF load gets reduced as a side effect. You are in a very well developed area, and most likely you have digipeaters located on mountain tops that can hear very large areas, as well as users using long paths. This all adds up to too many stations being heard on a limited RF channel. Keep your station acting as an i-gate, but keep your outgoing path short, and beacon frequency low so you don't add to the RF congestion. James VE6SRV ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] IGating
On 8/24/07, Greg Eigsti <[EMAIL PROTECTED]> wrote: > > >>How do I use Findu to see if I am IGating? > > > > The tool mentioned by VE7MKF is a better iGate 'test' than Findu. > However if you know you are iGating someone (or think you are) you > can look them up in findu and see their raw data. Just change the > callsign to the one that you are interested in... Greg, You have made an incorrect supposition above. The information seen at DB0ANF and at findu.com are the same. You will not find more information about who has i-gated a station via findu than you will at DB0ANF. The both use the same source of packets. The APRS-IS filters duplicate packets as they are received. Only the first packet received by the APRS-IS is kept. Any duplicates of that same packet are dropped. If you look at raw data for a station via any internet server, you will only see one copy of the packet, unless for some reason the packet has been mangled somewhere along the way. We run 3 or 4 i-gate stations in Edmonton. My station has a good vantage point, and usually is the first to gate to the internet. When my Windows based station locks up, then you will see stations gated by VE6AEW. When his station is turned off, you might see stations gated by VE6PS. When all the stations are up and running, only the first station to gate to the internet is the one seen. High altitude balloon launches show this phenomenon quite well. Our SABLE-III balloon launch on Aug 11 under the call VA6TNY-11. If you look at the historical track of that callsign at http://aprs.he.fi, you will see that it was gated by my station, VE6DJJ in Calgary, VE6BLK on Grande Prairie, VE6CNO in Crowsnest Pass, and even VE7EOK, and VE7CHW in Kamloop, BC. Kamloops is 600 km away. The balloon was heard by many more stations that act as i-gates, but only the first to gate to the internet is recorded by the APRS-IS. Go to file and click the button beside IGate logging. Enable IGate logging Logs all data forwarded in both directions, and rejected forwards with reasons for rejection. Includes NWS messages forwarded to RF. Your log file will then show you if you are or are not gating to the internet. 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] basic map question
On 7/27/07, Curt, WE7U <[EMAIL PROTECTED]> wrote: > On Wed, 25 Jul 2007, Earl Needham wrote: > > > Is there some way to simply drop the amount of detail as I zoom out > > to a larger area? I sure don't need to see every little dirt road and > > cow path when I'm looking at an entire state. > > If you're using local Shapefiles then Map->Enable Map Levels should > enable that feature. What about everyone's favorite... dbfawk? 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] 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, Tom Russo <[EMAIL PROTECTED]> wrote: Getting a new license with data emissions permitted will take quite some time (6 months or so turnaround in my experience to get a public safety pool license application through the system). 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. Play in the amateur world for free to do an proof of concept ideas... 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 Xas
[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
Re: [Xastir] Position rate question
> I running mobile in an 18-wheeler as KD5XB-11. SmartBeaconing is enabled, > and set for high speed of 240 MPH with a beacon rate at that speed of once > every 75 seconds. (I calculate that out to one position report every 5 > miles.) When below the low speed threshold of 2 MPH, I should be getting a > positinb report every 30 minutes. When do you plan on getting your 18 wheeler up to 240 MPH? If you want one position report every 5 miles at highway speed, why not set your high speed to 60 MPH, and high rate to 300. When you exceed the high speed, your beacon rate will not go less than 300 seconds. I guess you will always beacon every 5 miles, where my settings beacon closer than every 5 miles when exceeding the high speed rate. Bring your low speed threshold up to about 5 MPH. This is most likely the source of the numerous zero speed triggered reports. > When I right-click on my own station and get station info, the list of > recent packets received fills up really quickly with 0 MPH reports. For > instance, I've been sitting here in Shreveport for about 45 minutes, and the > entire list is made up of 0 MPH reports. I really expected to see only 1 or > 2. > > So -- is this something I have mis-configured? A bug? Or am I > interpreting this list incorrectly? Probably a combination of the low speed threshold being set too low, and possibly a logic problem in the programming. I, too, have had trouble with the smartbeaconing parameters. A long time ago I saw exactly the same behavior you see, and disabled smartbeaconing at that time. Near as I can tell, somehow the random fluctuations of GPS fixes seem to allow Xastir to beacon very, very often when stationary if you don't set your smartbeaconing just so. But I never spent any time figuring out why. CornerPegging watches for changes in direction that exceed the threshold. Random position changes due to GPS wandering look like you are making changes in your direction of travel. In the HamHUD, the first thing we look for is if the current speed is lower than the low speed threshold. If it is, we set the beacon rate to the low rate. We never look at any other parameters after that. Changes in direction only get processed if we are exceeding the low speed threshold. Curt, since you are so intimate with the code, can you point me at the relevant section of Xastir code that deals with SmartBeaconing and CornerPegging? I'll have a look at it to see if how the logic is processed. In the mean time, there are a couple pages describing SmartBeaconing and CornerPegging on the APRS Wiki... http://info.aprs.net/wikka.php?wakka=SmartBeaconing 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] Fetching a trail
> Ah -- maybe I misunderstood. I thought the question was > whether I had moved while downloading the track. The track should > have actually shown my movement of perhaps 2000 miles. KD5XB-11 shows a trail when I download the last 120 hours, just pulled it in on Xastir. It seems that all the positions are plotted on top of my current position -- did I goof something up?? So, we now know that the station you are fetching data for exists, and has track information that covers a significant distance, which is able to be grabbed and displayed by Xastir for at least one other person. What callsign do you use for your Xastir client? It shouldn't make a difference, and I am fairly certain that I have pulled in historical data for VE6SRV-15 on an instance of Xastir running as VE6SRV-15, but lets double check. What zoom level were you at? If you were zoomed out far enough, the trail may have appeared to all be on one spot. If you were zoomed in real close, you might have missed the trail being plotted out of view, and assumed that it was plotting on your current location. 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
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
[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 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] Setting up unproto paths in the UK
On 12/6/06, Dave h <[EMAIL PROTECTED]> wrote: There seems a lot of info about but has anyone got some advice for a UK station please. I have looked around for information, but there's such a mixture of out-of-date, innapropriate to locality and other data about that knowing what to set the Unproto too isn't clear. So - for a UK user fixed station, with a local digi - what would people suggest I change, if anything? Perhaps a little more info about what is currently supported in the UK would help. From your info, can I assume RELAY, TRACEn-N and named stations are supported? If so, and the UK network is implemented in a way that is similar to the North American network, then you should not need to use RELAY in a fixed station. In North America, the APRS network consists of fixed high level digipeater that support all current aliases. If an area requires a fill-in digi to help low powered handheld or mobile stations to get to the high level digis, then a home fill-in station is added. This used to by RELAY in North America, but is now using the WIDE1-1 alias to reduce ping-ponging packets. We have an informal group throughout the Pacific Northwest, and western Canada called NWAPRS www.nwaprs.info, where we discuss items like this, as well as work at keeping up to date on the optimal settings for APRS users and infrastructure. Looking at packets from around the UK, it is difficult to know what is happening around there... Long paths, and misconfigured stations seem to abound. Having a group like the NWAPRS group allows us to keep in touch, and try to help people get optimal use out of the APRS network. We also have a reflector that we use to keep in touch. Is there such a group in the UK? 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] RE: Tiger -> Shapefile Processing
> All I can say is that I stated that I'd wait for > someone to say "Yeah, sure, go ahead" or "No > that's okay" and I didn't receive any direction > one way or another. Sometime you have to assume tacit consent... Waiting for an "Attaboy!", or a "Way to go!" can leave you sitting for a long time! If nobody screams "No, don't do it!", you can probably consider that a yes. > Let's change the protocol to: Tell the list if > you're going to do it. In other words, don't ask, > don't coordinate, just do it. ;-) I think Curt fell in the deep end here... He's got a good idea, but let's forget the don't coordinate bit. This list is a resource that can be used to coordinate all kinds of tasks associated with the Xastir project. This is enough of a "geek" list that you won't get flamed for discussing the inner workings of your script processes. Unlike other SIGs that I belong to, never once that I can recall have I ever seen one "I don't want all this useless garbage in my Inbox!" type message. I would suggest modifying Curt's new policy to something more like this: Tell the list you are going to do it. Ask if anyone is working on something similar. If so, possibly share ideas, coordinate and work together and do it. If not, just do it. Notice that no matter whether you get a yes or a no, the job still gets done! Xastir is a quasi-uncoordinated group project. There's no official project manager to go to to be assigned a task. (I didn't know you could use 'to' so many times in close succession!) You can always make changes to code, or add to the pool of resources available. If what you have done is a good thing, it will be incorporated in the code base, or used by others. 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