Jump to content

Geofellas

+Premium Members
 View Profile  See their activity

  • Posts

    332

  • Joined

  • Last visited

 Content Type 

Posts posted by Geofellas

    Waypoint Averaging on the Colorado

    in GPS technology and devices

    Posted

     

    Just saw your reply, email with log file sent. Thanks.

     

    Thanks - it looks like your last attempt at averaging was when you didn't have a GPS signal since the accuracy was being reported as 9.9999995620235e+24 m - I'm obviously not handling that situation well :)

     

    Clearly I am going to have to do item number 1 on the "still to do" list (which IS in the description of the cartridge :anicute: ) - that is to deal with when the accuracy is not acceptable.

     

    For now folks, please don't try this when you have no GPS signal

     

    It's great to have a group of testers like this - it really helps to eke out the bugs and get a handle on how people use the tool so thanks to all

    Waypoint Averaging on the Colorado

    in GPS technology and devices

    Posted

    Looked it up 'cause I just can't leave well enough alone. CEP (circular error probable) is the EPE formula which has a 50% probability rating. If you double the EPE calculated via CEP, you will have something with approximately a 95% probability rating. Of course, we have no idea what EPE formula any given unit uses. But the typical certainty factors are between 50% and 65%.

     

    OK - thanks - that helps

     

    Might be a while before I do anything though

    Waypoint Averaging on the Colorado

    in GPS technology and devices

    Posted

    Geofellas, I played some more with your cartridge outdoors today and I can average a waypoint, name it, and it shows up in the Locations. I then exit and say Yes to "would you like to save your game", and it says saving cartridge and exits. All good. Upon resuming the saved game my single waypoint is there.

     

    Now, if I go and average a second waypoint (in a new geographic location) and name it I get an error message saying "Unexpected Error Closing Cartridge". I'm fairly new to Wherigo playing so wondered if I am causing the errors? It seems as if I can only average a single waypoint on the saved game. If I choose 'No' vs. 'Resume the saved game' upon starting the cartridge I can average a new waypoint, but have lost the first one. Thanks for building this!

     

    OK - I'll try and see if I can replicate that.

     

    If you could send your log file to geofellas@gmail.com that would help

     

    Thanks

    Waypoint Averaging on the Colorado

    in GPS technology and devices

    Posted

     

    Raises a few issues:

     

    1) Need to check you are at or close to the saved coordinates or it makes no sense to do it - what should be the allowable margin of error? Current accuracy perhaps?

    2) It would require saving some statistics along with the saved waypoint (specifically number of samples taken, and, for the benefit of the user's understanding the likely accuracy of the result, the previous values of min/max accuracy) and neither of these are standard waypoint properties - could probably be done though. Gets even more complicated if a weighted average is used - needs more thought.

     

    I'll ponder this one :)

     

    I'm not sure about your question # (1) but if I hide a cache or mark an important landmark I would simply return to the site of the cache or landmark to add more data to the coordinates (more averaging). The accuracy in returning to the point would be mute since there is something on the ground telling me where I am. Just think of the accuracy one could achieve if you checked PDOP and returned over several days for some more averaging.

     

    (2) Would a "resume" type function work? You could simply return to the site and addmore data continuing where you left off sort of speak. I don't know, just speculation.

     

     

    PS: I'll get you that log file ASAP (UPDATE-SENT). I experienced aanother crash right after naming my waypoint twice now (seperate condition. I pretty sure it's what Timpat is experiencing).

     

    On 1 the program still should check or you could restart a million miles away and get meaningless results.

     

    On 2 - yes - that is what we are talking about - but you still need to keep the old data around.

    Waypoint Averaging on the Colorado

    in GPS technology and devices

    Posted

    Issue: When I go to delete a waypoint the cartridge crashed.

     

    Can you send me your log file so I can see if I can replicate the problem. I assume this was on the Colorado?

     

     

    Suggestion: Would there be any way to take the "saved" waypoint and bring it up again for another round of averaging? I know Delorme is including this feature in the new PN-40. Say you had a point you want to dial in real good and you want to revisit the sight a few days later under different satellite conditions. Could this be a possibility with the cartridge? I don't know how Wherigo cartridges work but this would be a great asset to have if you really wanted to dial in the coordinates under varying array conditions.

     

    Hmm - thanks for the suggestion.

     

    Raises a few issues:

     

    1) Need to check you are at or close to the saved coordinates or it makes no sense to do it - what should be the allowable margin of error? Current accuracy perhaps?

    2) It would require saving some statistics along with the saved waypoint (specifically number of samples taken, and, for the benefit of the user's understanding the likely accuracy of the result, the previous values of min/max accuracy) and neither of these are standard waypoint properties - could probably be done though. Gets even more complicated if a weighted average is used - needs more thought.

     

    I'll ponder this one :)

    Colorado Firmware Version 2.7

    in GPS technology and devices

    Posted

    The accuracy is in meters, but it will do the job.

     

    Since the majority of the world uses metres (sic) I chose to make this the default. At present you can change this to feet by projecting a waypoint and selecting the "feet" option from there - not entirely obvious I grant you.

     

    I might enhance the cartridge to provide a setup facility as well to enable you to select your preferences. Obviously metres/feet is one that would be of interest - what other preferences would people find most useful?

     

    It would be nice if I could figure out how to get the preferences from the host GPS itself but that is probably device dependent and therefore not practical.

    Waypoint Averaging on the Colorado

    in GPS technology and devices

    Posted

    Hello,

     

    I am wondering about what all is involved in the equation. I know that averaging is the average of coordinates over time but will it give you the estimated error value of the waypoints? Is the GPS "Accuracy" involved in the equation to add a "weight" to the coordinates? Thanks for your reply.

     

    No, as it says on the screen when you run the thing, there is no weighting included in this first implementation. It calculates a simple average of the points collected at 2 second intervals over the time you choose to average for - which I have set to a maximum of 10 minutes (randomly!)

     

    The displayed accuracy statistics are intended to give you a subjective sense of how effective the averaging has been.

     

    Another measure would be to calculate the standard deviation of the sample set - but most people are not likely to really understand what that number would be telling them anyway.

     

    I seriously wonder how beneficial including weighting into the algorithm would be. If there is any prior art available on the subject I would be interested to know - my gut feel is that weighting is not going to significantly affect the final result to any practically useful extent.

     

    For placing caches I have to think that a simple average is going to be "good enough"

    Waypoint Averaging on the Colorado

    in GPS technology and devices

    Posted · Edited by Geofellas

    I seem to have fixed it by saving out another blank game.

     

    :rolleyes:

     

    BTW - can you only have one waypoint at the moment? I've tried saving a number of waypoints with different names and only the last one appears in the list.

     

    EDIT: All of them appear in the 'Go to List' but just one appears in the 'Locations' list.

     

    Yes - that is intentional as good Wherigo programming practice. The more locations you have active and visible the more work the processor has to do continually checking on them and that could ultimately cause a crash or reduced performance. So I have set it up so that only one can be active and visible at any one time.

     

    When you "Go To" one that is not in the "Locations" list it then appears in the Locations list instead of any one that was there previously.

    Waypoint Averaging on the Colorado

    in GPS technology and devices

    Posted

    Answering 'No' results in no GPS being available in the inventory - just a blank entry. You can work-around this by starting to exit the cartridge and then canceling the exit (using the 'curvy' arrow button) - the GPS then re-appears in the inventory!

     

    Hmm - can't replicate it on my CO - no idea how to solve that one at the moment.

    Build your own GPSr

    in Wherigo

    Posted · Edited by Geofellas

    Great Thanx!

     

    i think i found a bug :rolleyes:

     

     

    Yes you did - many thanks.

     

    It was a regression error in the coordinate display function and should now be fixed in version 1.4 just uploaded

    Ask J2B2

    in Wherigo

    Posted

    In the gizmo cartridge (the tutorial) there are 2 calls to

     

    Player:RefreshLocation()

     

    (lines 1154 and 1162)

     

    What is the purpose of these? What do these calls do?

     

    Thanks

    Commas in Dialog Boxes

    in Wherigo

    Posted

    I can reproduce this with builder version 2.0.5129.5086.

     

    My guess is that the builder's parser is looking for "the first comma after the pair of right brackets which (it presumes) closes the string", and isn't sophisticated enough to handle string expressions.

     

    I too have experienced this. Since I make extensive use of string expressions (rather than simple strings), I suspect that this is a very likely explanation for the cause of the problem. Now I know what to avoid in future.

     

    Workarounds that come to mind are:

     

    1) move the function to the author area, or

    2) create a string variable called comma with the value of "," and use it instead of typing a comma, or

    3) avoid using commas in dialogs

    ObjectLocation

    in Wherigo

    Posted

    I think you could get the individual lat and long (as numbers) this way too if you needed it. I know it works when I do Player.ObjectLocation.latitude etc.

     

    lat = v.ObjectLocation.latitude
long = v.ObjectLocation.longitude

    Date and time information

    in Wherigo

    Posted

    I'm working on a cartridge that involves touring a park. One particular area of the park is closed in the Winter. Can I design the cartridge so it will automatically skip that area during the winter?

     

    You could include some author code that uses the lua function os.date (google "lua os.date" for more info) to determine the current date and insert logic based on that. This is definitely stepping outside the builder :(

     

    Here is some code (incomplete) that I have been playing with in case it helps:

     

    dow = {"Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday" }
month = {"January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December" }

function ztimerEvery5seconds:OnTick()
-- #GroupDescription=Script --
-- #Comment=Script Comment --

local i = os.date("!%c")
Wherigo.MessageBox{Text=[[]] .. i .. [[

Processed = ]] .. getdow(i) .. [[ ]] .. getdom(i) .. [[ ]]  .. getmonth(i) .. [[(]] .. getmonthnum(i) .. [[)]]  .. getyear(i)  .. [[ ]]  .. get24hour(i) .. [[:]] .. getmin(i) .. [[:]]  .. getsec(i),}
end

function getdow(t)
for j = 1 , 7, 1 do
if string.sub(dow[j], 1, 3) == string.sub(t,1,3) then
return dow[j]
end
end
end

function getmonth(t)
for j = 1 , 12, 1 do
if string.sub(month[j], 1, 3) == string.sub(t,5,7) then
return month[j]
end
end
end

function getmonthnum(t)
for j = 1 , 12, 1 do
if string.sub(month[j], 1, 3) == string.sub(t,5,7) then
return j
end
end
end

function getdom(t)
return tonumber(string.sub(t,9,10))
end

function getyear(t)
return tonumber(string.sub(t,21,24))
end

function get24hour(t)
return tonumber(string.sub(t,12,13))
end
function getmin(t)
return tonumber(string.sub(t,15,16))
end

function getsec(t)
return tonumber(string.sub(t,18,19))
end

    Function Call

    in Wherigo

    Posted

    So where did you discover about "GetAllOfType" anyway?

     

    I don't see it referenced anywhere else in the forums - there must be all sorts of useful stuff like that around that we only find out about by luck unless someone can point to some documentation that I haven't found yet.

     

    Thanks

    Prepopulating an input field with a "default" value

    in Wherigo

    Posted · Edited by Geofellas

    Hey RF - I think you answered a different question here. I've got a good handle on manipulating zones - I am interested in how to prepopulate an input field with a good guess at (some of) the data the user is going to enter so as to reduce roller manipulation (on the CO anyway). Maybe this was intended for a different thread

×
×
  • Create New...