Re: Spam:*****, Re: [Xastir] Mac: odd process problem

[Jason Winningham]

On Jul 8, 2007, at 7:12 PM, Chip G. wrote:


 is it certain to he the driver?


Nope.  I was getting pretty wound up trying to solve a similar  
problem.  It eventually occurred to me that my faithful Keyspan  
device might actually be dead.  It was.


-Jason
kg4wsv



___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: Spam:*****, Re: [Xastir] Mac: odd process problem

[Alex Carver]

--- "Chip G." <[EMAIL PROTECTED]> wrote:
> I'd love to hear other suggestions. If the problem
> does relate to the  
> USB adapter, is there any chance it relates to the
> Xastir code? Or is  
> it certain to he the driver?

I doubt it's Xastir because Xastir doesn't really know
it's a USB device.  As far as it knows, it's just a
serial port so it's likely the device itself or its
drivers.  You may want to try an adapter made by
someone else.  Several manufacturers use a chipset
from FTDI (Keyspan does not last I knew) and
apparently the FTDI chipset is well supported in many
OSes.  Even some Windows people have issues with Keyspans.


  

Shape Yahoo! in your own image.  Join our Network Research Panel today!   
http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 


___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: Spam:*****, Re: [Xastir] Mac: odd process problem

[Chip G.]

On Jul 5, 2007, at 07:34, N1OFZ wrote:

I have had Xastir running here for over a month and I've had it run  
even longer with no usb dongles.  I ONLY use Keyspan usb -> serial  
adapters on the Mac.  I have others that are Prolific based and  
have had varying success, though they run fine under Linux.  Last  
year I did a 5 hour car ride and ran a pair of Keyspan adapters  
(one on the gps, the other on the tnc) with no problems.


What is your device string?  Using a Keyspan it should be something  
like: /dev/cu.USA19QI181P1.1.  Do not use the /dev/tty devices.


/dev/cu.USA19QW3b11P1.1

It is still running, no crashes since I disabled the USB dongle. So I  
suspect that is the culprit. It is running the latest update (2.4)  
which I tried before the last crash (the last thing before I disabled  
it). I have nothing but Keyspan USB/serial adapters. I have three.  
Only one is connected to that machine. Perhaps the next time I am  
feeling motivated I might try one of my others to see if it's that  
specific device rather than the software.


I'd love to hear other suggestions. If the problem does relate to the  
USB adapter, is there any chance it relates to the Xastir code? Or is  
it certain to he the driver?




-- Chip
new email: [EMAIL PROTECTED]


___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

[Xastir] WXSVR appears to be dead...

[Richard Polivka, N6NKO]

Warnings abound in UP of Michigan and Xastir shows none and the log is 
blank.


Richard, N6NKO

___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

[Xastir] SmartBeaconing routine

[James Ewen]

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] openSUSE 10.2 CVS Success

[Lee Bengston]

On 7/8/07, Steve Friis <[EMAIL PROTECTED]> wrote:


What you have below is great. Just one thought here though. In the
scripts folder there is a script file  that pretty much
installs everything. Is this going to go away? I think it sure made the
install easy. Gives you all the needed libraries.

Steve/WM5Z



It might be just me, but I like to install as much as possible from the
repositories for the applicable distribution, and then if there is anything
left, use the get-maptools script to make up the difference.  That looks
like the approach taken in the HowTo:Ubuntu 6.10 or
7.04.
With OpenSUSE, I was able to get everything from the repositories, so there
was no need to use get-maptools.sh.  With other distributions, it might be
best to use the get-maptools script either as is or slightly edited
depending on what is or is not available in the repositories and/or how
difficult it is to locate the right repositories.  Of course, it also
depends on what libraries the person installing actually needs.

Lee - K5DAT
Murphy, TX
___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] openSUSE 10.2 CVS Success

[Steve Friis]

What you have below is great. Just one thought here though. In the 
scripts folder there is a script file  that pretty much 
installs everything. Is this going to go away? I think it sure made the 
install easy. Gives you all the needed libraries.


Steve/WM5Z


Lee Bengston wrote:

On 7/6/07, Curt, WE7U <[EMAIL PROTECTED]> wrote:



The latest CVS:


MINIMUM OPTIONS:
  Building with ShapeLib (Vector maps) . : yes

RECOMMENDED OPTIONS:
  Building with GraphicsMagick/ImageMagick (Raster maps) : yes
(GraphicsMagick)
  Building with pcre (Shapefile customization) . : yes
  Building with dbfawk (Shapefile customization) ... : yes
  Building with rtree indexing (Shapefile speedups)  : yes
  Building with map caching (Raster map speedups) .. : yes
  Building with internet map retrieval . : yes (libcurl)

FOR THE ADVENTUROUS:
  Building with AX25 (Linux Kernel I/O Drivers)  : yes
  Building with libproj (USGS Topos & Aerial Photos) ... : yes
  Building with GeoTiff (USGS Topos & Aerial Photos) ... : yes
  Building with Festival (Text-to-speech) .. : yes
  Building with GDAL/OGR (Obtuse map formats) .. : yes
  Building with GPSMan/gpsmanshp (GPS downloads) ... : yes

DEVELOPER OPTIONS:
  Building with ErrorPopups (Old Method) ... : no
  Building with libgc (Debug memory usage) . : no
  Building with profiling (Debug code efficiency) .. : no
  Building with Linux Standard Base (LSB) .. : no



Looking good.  Thanks for all the effort - never thought I would start 
what

ended up to be this when building XASTIR with all the bells and whistles
last night, but the results are nice.

Noticing in the Wiki there was not an equivalent of the HowTo:Ubuntu 
6.10 or

7.04 for openSUSE, I set out to try to accomplish the same tasks that are
layed out in a very nice step by step fashion in the HowTo for Ubuntu so
that they could possibly be documented in a new HowTo for openSUSE 
10.2.  I
figured it was a way I could contribute given the help I have 
received.  The

information above helps with creating the HowTo because the steps can be
organized to cover the recommended options first before moving on to the
more adventurous options for those who want to.  My main motivation for
loading everything last night was so that I could document how, but 
I'm sure

perfectionism had something to do with it, too.

Have a great weekend,
Lee - K5DAT
___
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] openSUSE 10.2 CVS Success

[Lee Bengston]

On 7/7/07, Lee Bengston <[EMAIL PROTECTED]> wrote:


On 7/7/07, Tom Russo <[EMAIL PROTECTED]> wrote:

> Do you have an account on the Wiki, and have you got wikieditor
> privileges?
> If not, please register and then email to me, Curt and Chuck, and one of
> us
> will make sure your account gets the appropriate privileges so you can
> actually
> do the editing you want to do.
>
> We had to lock down the Xastir wiki after a round of vandalism.  Looking
> at
> the disaster that the APRS wiki at info.aprs.net has become due to being
>
> completely open (it's been completely trashed twice this week, and it's
> only
> a matter of tine before it happens again), it's a good thing we did this
> to
> the Xastir wiki.


I have an account now - thanks for the opportunity.  I'm glad the security
is there - the current Wiki has been a big help to me, so it would be a
shame if it was getting hacked.




http://www.xastir.org/wiki/index.php/HowTo%27s

HowTo:OpenSUSE 10.2
has now been added to the list. Further refinements are planned - this
version is based on notes taken and retracing steps. At some point I'll
run through the process again and fill in more detail.



Lee - K5DAT
Murphy, TX
___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] Position rate possibility....

[Earl Needham via Kubuntu]

Richard Polivka, N6NKO wrote:

1) Fixed position. If the vehicle drops below a certain threshold speed, 
call it STOP SPEED, we send out a quick burst of packets, say three to 
five , to show the speed coming to zero for at least two packets.


	I'm not sure we would want to do this, because every time you come to a 
red light, you'd be going through this procedure.  Some parts of the 
country can't take that.  Maybe ONE packet would be OK.


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.


	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.


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.


Now if I have covered old ground, forgive me. These are just thoughts.


	When I first got started with the HamHUD, I tried and tried to do 
perfect corner pegging, but I was never succesful.  The problem being 
that, in a 90-degree turn at an intersection, you need one set of 
parameters, but in a 90-degree sweeper at 70 MPH, you need an entirely 
different set of parameters.  I don't think slope is enough to get it 
right.  I used to get 2 or 3 position packets sent out in the sweepers, 
and while I could make adjustments to reduce that, it generally messed 
up the intersections.


	The other problem that I though I was seeing, but no one else agreed, 
was if I came to, say, a 20-degree bend in the road and I was travelling 
65 MPH, I did NOT get a position packet sent out.  I think I was told 
that, at those speeds, almost all the beacons are done by timing and not 
by turning.


	In the end, I just set everything to the default values and forgot 
about it.


7 3
Earl
--
Earl Needham KD5XB
Clovis, New Mexico DM84jk
ZUT
___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

[Xastir] Position rate possibility....

[Richard Polivka, N6NKO]

Alright, now I have a bug on the brain. That is good. Keeps me from 
thinking about spending money. Plus, XM Classics is on - no wine yet - 
way too early. But I am wired to the neck in caffeine and the pot is empty.


Let me make a proposal. Now I will run it up the flagpole so make sure 
your sights are lined up to shoot at it...


1) Fixed position. If the vehicle drops below a certain threshold speed, 
call it STOP SPEED, we send out a quick burst of packets, say three to 
five , to show the speed coming to zero for at least two packets. In 
STOP MODE, we send out packets at some set rate. We do not leave this 
mode until we have a net positive speed above START SPEED and a change 
in position defined by START POSITION CHANGE. This should allow for 
compensating for "wild positions" and not allowing them to cause the 
unit to do massive transmissions.


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.


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.


Now if I have covered old ground, forgive me. These are just thoughts.

73 from 807,

Richard, N6NKO

___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] Position rate question

[Richard Polivka, N6NKO]

I will look at the routine also. Many eyes make a load light (duck). 
Plus, outside they are talking about temps with THREE digits here in 
Brew City today. Plus, winds in the 15-30 MPH range - can you spell 
"convection oven"?


The threshold setup is akin to windowing. I may be going over previously 
discussed material here, so forgive me. Fixed position operation is 
simple, beacon every x minutes. Moving, it should be either time or 
distance traveled. When you have a GPS unit sending data every second or 
two, this confounds the issue. Turning is the issue with these beacon 
rates. You can turn at an intersection and be done with the turn in two 
seconds.


Before I dig myself a hole (It's not Black Friday), let me see what the 
code is really doing. Maybe we can all participate in getting this to work.


73 from 807 (breakfast bell),

Richard, N6NKO


Tom Russo wrote:

On Sun, Jul 08, 2007 at 12:01:47AM -0600, we recorded a bogon-computron collision of 
the <[EMAIL PROTECTED]> flavor, containing:
  

 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.



It's in db.c, the routine "compute_smart_beacon".

  

___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] Position rate question

[Tom Russo]

On Sun, Jul 08, 2007 at 12:01:47AM -0600, we recorded a bogon-computron 
collision of the <[EMAIL PROTECTED]> flavor, containing:
>  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.

It's in db.c, the routine "compute_smart_beacon".

-- 
Tom RussoKM5VY   SAR502   DM64ux  http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236 AHTB#1 http://kevan.org/brain.cgi?DDTNM
"And, isn't sanity really just a one-trick pony anyway? I mean all you get is
 one trick, rational thinking, but when you're good and crazy, oooh, oooh,
 oooh, the sky is the limit!"  --- The Tick
___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] Position rate question

[Earl Needham via Kubuntu]

James Ewen wrote:

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.


	Oh -- I've been using 240 as the high speed for some years now. 
Originally with the idea that I might get my HamHUD up in a Cessna at 
some point.  It's never happened, but it might.  Someday.


7 3
Earl


--
Earl Needham KD5XB
Clovis, New Mexico DM84jk
ZUT
___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir