Jump to content

sataraid1

+Premium Members
  • Posts

    145
  • Joined

  • Last visited

Posts posted by sataraid1

  1. ..how about grabbing a cheap Netbook & use it instead of a PDA?

     

    If I can't find a PPC solution, that's probably what I'll do.

     

    That would solve my cache management and waypoint loading problems on the road, and would even allow me to do map swaps on the GPS, but it would mean yet more hardware I have to take with me. The Axim (or similar) held promise of being an all-in-one solution at a very reasonable price.

  2. I have to confess, I'm a little surprised that the issues I wanted to address directly have been a bust. No full-featured cache management software for PPC? The PPC can't talk directly to the GPSr for data transfer?

     

    I'm beginning to think my suspicions about it not being possible are true.

     

    Using PPC as a GPSr sounds like an interesting idea but I'm not willing to give up using my Map60C in the field. That, coupled with the fact that the PPC software mentioned above doesn't seem to be capable of storing or managing large numbers of caches is a dealbreaker.

     

    So close, yet so far.

  3. I need a portable solution for cache management when on the road. What I'm hoping is that a late-model PPC like an Axim X51V is the solution.

     

    What I want to be able to do is:

     

    1. Build and download a PQ via wifi.

    2. Load the PQ into a management program for storage.

    3. Send desired waypoints from the PPC to my Map60C.

    4. Use the PPC in the field for paperless caching.

     

    The information I have been able to find regarding this is incredibly shattershot. Most of it is centered around simply being able to view the GPX files for paperless caching, but that alone isn't enough to justify the new hardware, because my current Handspring Visor running Cachemate is already more than sufficient for paperless caching.

     

    I know getting the PQ GPX file into the PPC isn't a problem, and I know there's lots of software to let me view said GPX file, but what about cache management? I currently use MacCaching on my Mac ... is there anything like that for PPC?

     

    And the biggest issue seems to be concerning getting the PPC to talk to the Garmin GPS. There seem to be cables for letting the GPS send location data to the PPC for things like mapping applications and even Wherigo caching, but does that connection allow the PPC to send data to the GPSr?

     

    If not, can the PPC send data via a USB cable? If the PPC can sync data via USB, can it talk to the GPSr?

     

    If anyone is using this, or a similar setup, some help and information would be appreciated. Or if someone wants to recommend a similarly-priced PPC that's more appropriate for what I want to do, that would be great too. But it needs to be able to do everything I've listed above, otherwise there's no point in upgrading.

     

    Thanks in advance.

  4. Nope, bold == 24 hour period

     

    Thanks for the clarification.

     

    So should I consider resubmitting the PQs I set up this morning? (Which are all new and have never been run.)

  5. I've noticed that my 4 PQs from yesterday still show as bolded, which means the counter hasn't been reset since yesterday, correct?

     

    They remain bolded for 24 hours. It doesn't affect the daily counter.

     

    Are you sure about that? I don't recall ever seeing bolded PQs remaining when coming back the next day to set up more, but I can't say I'm 100% certain about that.

     

    I thought the bolded PQs indicated that they had been run during during that calendar day's allocation.

  6. I would absolutely LOVE something like this myself. With the current "radius" method, you either end up with lots of overlap between PQ zones, or voids in between them where caches slip through the cracks.

     

    It wouldn't even have to be as elaborate as clicking and dragging. If I could simply enter the coordinates of the four corners of the rectangle, that would be great.

     

    It would then be VERY easy to create a grid of PQ zones to canvas a wide area, and not have to worry about redundancy or missing patches.

  7. Did you catch that Raine was doing something to the PQ system yesterday particularly last night - that made several unusual things happen.....

     

    No, I didn't, and if that's the cause of yesterday's weirdness then it's perfectly understandable.

     

    Still, this sort of thing has happened to me a number of times in the past. More often than could realistically be attributed to maintenance or extenuating circumstances.

     

    It's not the end of the world. I just wish there was enough consistency that I could work around it.

  8. My understanding of the priority system is that it gives priority to those people that actually have gotten on the system and requested a PQ (a new one). The idea being that the person is actually active and needs a PQ.

     

    This is definitely not the case, because *none* of my PQs are set to automatically run.

     

    And if anyone's interested, here's what happened to my three missing PQs yesterday. Reference the screen shot above, then look at this:

     

    pq2.jpg

     

    One of the missing PQs ran about 11:30 local time, a delay of 14 hours . The other two ran *at 3 AM*!

     

    And bear in mind ... all three of these PQs had been previously run on the same date! Again, why the difference?

     

    But of course, here's the annoying part:

     

    pq3.jpg

     

    The "late" PQs from yesterday got counted against TODAY's allocation. :D

     

    Anyway, there's really not a lot more to say. The current PQ system is broken. I hope for something better very soon.

     

    I just wanted to prove that when I assert that the current system is "unpredictable", I'm not just making stuff up or wildly exaggerating to call attention to myself. If there's one word to describe the way my PQs ran yesterday, it's definitely "unpredictable".

     

    The bad part is, there's no way to plan around "unpredictable".

  9. This argument becomes moot (or will) when you consider our primary goal for the PQ redesign is to have all PQs run within the first 2 hours of every day. I can't be certain that goal will be fully met but it certainly won't be far off.

     

    That would be splendid. Then, a person could simply plan on running their PQs when they go to bed, and they'll be waiting in the inbox when they wake up.

     

    That's something to be looking forward to.

  10. What I'm trying to say is, if the "decay rate" on PQs is even remotely linear, the processing delay of two PQs of such similar ages wouldn't be so wide, especially considering that the first ones ran instantly.

  11.  

    You don't have to "buy" it - it is what it is. Simple fact.

     

    The theory behind it is:

    not run=user with no data

    ran yesterday = user with 24 hour old data - very little stale data

    ran 7 days ago = user with 7 day old data - liklihood of stale data much higher but not bad either

    ran 2 months ago = user with ancient data - data has just about got to be stale.

     

    Looked at that way does the priority make a bit more sense?

     

    Yes, yes it does. Thank you.

     

    But it doesn't appear to be executed that evenly.

     

    It would seem highly unlikely that the difference between 8 days old (the 11th) and 6 days (the 13th) old would be the difference between instant processing and a delay of 7+ hours and counting.

     

    We're only taking about a difference of 48 hours here.

  12. Sadly, most astute PQ users simply get around the bottlenecks by creating multiple copies of the same PQ and schedule each one to run once a week. After a few months, creep will have moved them down the queue and you will have to delete them all and recreate it.

     

    But it does get you around the ever increasing delays of previously scheduled PQ's.

     

    You don't even have to recreate them. Just use the "copy" button in the PQ list, and it will run instantly. I have been forced into doing that on several occasions, where I'm basically sitting packed and ready go go and still waiting on PQs I submitted hours previously.

     

    But I'd prefer not to have to do that, and continuing to do so doesn't answer any of the questions I've asked.

    How ironic... You're complaining how FIFO would be better in one post, and complaining about not getting your fresh PQ right away in another.

     

    Why does my post say "Ringbone"? :ph34r:

     

    You're quoting two different people.

     

    At no point have I complained about fresh PQs not running. I know they do.

  13. Sadly, most astute PQ users simply get around the bottlenecks by creating multiple copies of the same PQ and schedule each one to run once a week. After a few months, creep will have moved them down the queue and you will have to delete them all and recreate it.

     

    But it does get you around the ever increasing delays of previously scheduled PQ's.

     

    You don't even have to recreate them. Just use the "copy" button in the PQ list, and it will run instantly. I have been forced into doing that on several occasions, where I'm basically sitting packed and ready go go and still waiting on PQs I submitted hours previously.

     

    But I'd prefer not to have to do that, and continuing to do so doesn't answer any of the questions I've asked.

  14. Think of it this way. You stop off at the grocery stop to buy a gallon of milk. They have only one checkout open. In front of you are 6 or 7 shoppers with their carts overflowing. You have to stand behind them to get checked out. Would you be happy standing in line knowing that the simpler FIFO queue was being used or would you rather the queue be number of items based?

     

    Respectfully, that doesn't work because the amount of time involved in processing both queries/checkout carts is equal. What's being arbitrarily judged is the interval.

  15. I think some are totally misunderstanding the priorty scheme of PQs.

     

    New PQs (never run) are bumped up to the front of the line.

     

    Why?

     

    Older PQs are prioritized based on the last daytime they ran in reverse.

     

    If the delays seemed linear, I could almost buy that. Yet in my case, the difference of one day seems to be the difference between running instantly, and pushing 5 hours.

     

    I still don't see why "first come first served" isn't simpler.

  16. I would guess the two that did run were last run 7 or more days ago.

     

    For the ones that haven't run yet...they last ran 6 days ago. The PQ server is probably busy dealing with PQs that run once a week.

     

    (If TPTB would provide a "now serving" display that showed the date/time last run for the PQ currently running, these mysteries would disappear.)

     

    If I had to guess, I'd say that the two which already ran were part of my allotment on the 11th.

     

    So what you're saying is, greater than 7 days = instant, less than 7 days = maybe, maybe not? The difference of one day means I probably won't get my PQs at all?

     

    FWIW, none of my PQs are set to run automatically on a recurring basis. I simply sit down and decide which ones I need to run, and run them. All of the PQs in the list above have been run countless times.

     

    Also, all 5 I ran on the 13th ran nearly instantly as well. My experience indicates that if you don't get them in the first 30 minutes, you won't get them at all.

     

    For the record, I think the fuzzy logic of running some PQs ahead of others based on arbitrary intervals is ridiculous. It should be first come, first served, period.

  17. The problem with the current PQ situation is that it's incredibly unpredictable. Sometimes queries run almost instantly, sometimes they simply never run.

     

    If PQs were slow, but were ALWAYS slow, one could plan around it. But you can't.

     

    This morning I manually ran 5 saved PQs. Two ran so fast they were in my mailbox before I could finish making my selections. Three of them are still just sitting there, and haven't run yet.

     

    All of the queries have been run countless times, so it's not a case of "new ones running first".

×
×
  • Create New...