Request for help testing on Garmin

[+HackAMen]

I have a cart out in the wild called Titan Nick which works fine on all smart devices but a few people have tried it recently with Oregon 550t and they reported it crashed. Unfortunately I don't have one to test with.

 

So I was wondering if anyone here could try out a new version of my cart which I've updated for Garmins.

 

Everyone who saw the crash said it happened within the first zone or two, which are only a few meters apart so it should be quick to test. That said the only issue I saw was that I automatically saved on entrance to zones, which I have read can cause issues with setting up zones so I moved that to zone exit.

 

It seems that smart devices are the future for Wherigo but it looks like there's still quite a base of Garmin devices. Any help to test and maybe give information on when the crash happens would be greatly appreciated.

 

I have created a play anywhere version of the cart which I can supply if you ping me.

 

Thanks again.

[Geo-Magician]

It seems that smart devices are the future for Wherigo but it looks like there's still quite a base of Garmin devices.

I fear that is a true statement. A dedicated outdoor device has its benefits when the terrain gets rougher and the weather turns bad on you. The Wherigo problem with the Garmin devices is that the software implementation is incomplete. The smartphones have a better implementation because most of the software that was done for them or is still done is/was programmed by enthusiasts.

 

Any help to test and maybe give information on when the crash happens would be greatly appreciated.

The Earwigo builder has a plausibility check integrated that will help you over most Garmin bumps during the cartridge design. I have written a wiki section that deals with Garmin compatibility issues for Earwigo. Check it out, it lists several Garmin crash traps.

http://earwigo.net/WWB/wiki/doku.php?id=tips_and_tricks#how_to_make_sure_your_cartridge_works_for_all_players

[+HackAMen]

That is the exact page I was pouring over to try and figure what may be wrong with my cache.

 

I think I've ticked off everything in your wiki and thanks for wiring it. There are a few other sites I've read as well that mentioned picture sizes and dialogues over input screens. All these things I think in not doing so it's hard to know at this point without testing.

 

Do you know if the emulator can be made to behave more like a GPSr ?

[Geo-Magician]

Do you know if the emulator can be made to behave more like a GPSr ?

I like the idea but there is no way to persuade the emulators to reproduce the more or less erratic behavior of the Garmin devices.

 

Are you aware that here is a new web based emulator http://www.webwigo.net/ It is still under development but quite stable and useful as a quick tool. Sound is not yet working but I use this tool quite often. It offers a console tab that gives you a closer look at the actions that happen in your cartridge. Looking at the console printout might give you an idea what to look for.

 

One thing causes me a lot of pain with the Garmin Colorado. It allows the user to terminate an input (the user can press some kind of an "ESC button" that Garmin has introduced). This termination does not clear the Lua input stack and will cause problems directly or further down the road. The second problem of this "feature" is that once the user returns to the old Wherigo screen the input will be gone. Leaving the program in a state where it expects the answer to an input without any input possibility for the user.

 

It might also help to pester your Garmin users for a better crash report while you are waiting for the forum Garmin tester. What happened when. Did the cartridge really crash or was it unresponsive. Which buttons were pressed, which screens did appear ... If we get a better idea what happens before the crash someone that watches this thread might get an idea where to look.

 

Last idea: while reading your original post I see that the zones are only a few meters apart. If the zones are to close to each other (zone borders closer than 20m) GPS jitter might add to your trouble.

Edited April 15, 2015 by Geo-Magician

[+HackAMen]

 

One thing causes me a lot of pain with the Garmin Colorado. It allows the user to terminate an input (the user can press some kind of an "ESC button" that Garmin has introduced). This termination does not clear the Lua input stack and will cause problems directly or further down the road. The second problem of this "feature" is that once the user returns to the old Wherigo screen the input will be gone. Leaving the program in a state where it expects the answer to an input without any input possibility for the user.

 

That's just evil

 

It might also help to pester your Garmin users for a better crash report while you are waiting for the forum Garmin tester. What happened when. Did the cartridge really crash or was it unresponsive. Which buttons were pressed, which screens did appear ... If we get a better idea what happens before the crash someone that watches this thread might get an idea where to look.

 

I have been quite happily pestering them, they've been very good on giving me details, but the first crash looks spontaneous and hard to nail down.

 

Last idea: while reading your original post I see that the zones are only a few meters apart. If the zones are to close to each other (zone borders closer than 20m) GPS jitter might add to your trouble.

 

I forgot about that, will test that later.

[+charlenni]

There could be many problems when creating cartridges for Garmins Perhaps you encountered one of them.

 

I want to ask for the cartridge to test it. Beside this, it would be usefull, if you could describe, what type of crash they have. Did the Garmin shut off or could they see a error message on the screen? Was an input open? What was the last screen they saw? Are there any informations in the Wherigo/Logs/WherigoLog.log file on the Garmin device?

[Ranger Fox]

If you're asking a question when the users get to a zone, you need to deactivate the zone before the question is shown. If a second input is shown while another is active, the device will power off. People run across this problem frequently when they create a zone to ask someone a question and forget to deactivate the zone before or after the question is asked. Thus, the user will enter the zone, the input will be displayed, the GPSr's coordinates will drift and the user might exit the zone, then the coordinates will drift again, cause the user to enter the zone a second time, and the same input will be displayed while the other one is already on the screen. Please do make sure this is not the case with your cartridge. It's easy to make that mistake.

[+HackAMen]

If you're asking a question when the users get to a zone, you need to deactivate the zone before the question is shown.

 

Great point. I know that where the crash is reported this doesn't happen but I do have a number of other inputs where it could. I didn't realise I had to deactivate zones when this happens.

 

This means a load more testing for me