Amizaur

My Lowrance Endura Out&Back unit just stopped working. To be precise, the whole unit works, but it can't get GPS fix anymore. The sattelites continue to be found and lost second or two later, and found and lost, and that's forever. Month ago it could eventually get a fix sometimes, which was lost after some time. Now, it seems it lost ability to fix forever. It seems for me that it's the internal GPS module is the thing that is broken. The rest of the unit (power supply, microprocessor, electronics, memory) are working just fine, applications are working without problems. I haven't decide yet what to do with it. I own it for less than 2 years, so I could send it to the seller, and get money back. I bought it for about $140 (and this is what it's really worth, not more). But maybe, instead of that, I'll deassemble it and try to replace the GPS module with new one, some good MTK or SIRF3 unit. I think there are good chances it could work, if it's using NMEA for communication with Endura software. I could also put electronic compass unit into it (it's not that expensive) but I'm not sure it's possible to reflash it with Sierra/Safari firmware. And Out&Back software doesn't know how to use the electronic compass anyway . Sending it to US to the Lowrance is not an option - the shipping costs would exceed the cost of the unit. But it would be great if the Lowrance technicians could give me some advice what kind of commercially available electronic GPS module (MTK or SIRF) would be a good replacement for the broken one from my Endura (it's probably an Nemerix chip, discontinued). I'm an electronic technician too, it's no problem for me to desolder the electronic module and replace it with similar one. Or maybe they could tell that it won't work, because the communication is not by NMEA protocol.... If anyone had experienced similar problem - Endura GPS continously finding and losing sattelites and never actually getting a GPS fix, or only occassionaly/2D and losing it quickly, please tell me what was the cause and how it was fixed (probably just replaced with new unit...). The problems had become to show up when I took the Endura onboard of the plane going from Gdansk to Oslo. It worked somewhat onboard, but lost the fix exactly after the plane has exceeded 10.000m altitude. After returning to Poland, I had great difficulties getting ANY lock on the ground, with clear skies. After week or two I tried it two more times and eventually it started working. After taking it onboard of a plane going to London, it worked a bit onboard but lost fix few minutes after take-off. It worked on the ground in London, although my feeling was that it's very unprecise. During return flight London-Gdansk, after getting a GPS fix on the ground before boarding it kept it in the air, and again it lost it exactly after reaching altitude of 10 thousands meters, so I think it's some kind of limiter in GPS module internal firmware. On the ground - I never got any STABLE GPX fix again. Satelites continously being found, the bars raising, only to disappear second or two later. Sometimes a 2D lock that was usually lost afer few seconds. Basically, it doesn't work (find a position) anymore. If so, I will probably buy some Garmin, then.... but I'm curious what's the cause of the malfunction and if it's related to those two airplane flights

I'd like to add that the only problem so far I noticed after 1.51a update, is that sometimes in the map screen the zoom locks - the zoom bar doesn't disappear and the zoom keys - both "real" ones and those on the screen - do not respond. Only switching to a different screen and back helps. After returning to the map screen, the zoom level seem to conform with the key actions I made in the "locked" state (so if I pressed multiple times the + key with screen not responding, after switching screens and returning to the map again the zoom is usually max on 10m level). Because of that I believe it's a zoom refresh problem, not zoom locking literally. I can't recreate it reliably, but think it happens when I use the zoom and then try to do some things (change screen, go into options) before the zoom bar disappears. Once or twice I had completly blank map screen, it doesnt' appear even after more than 10 seconds. I had to switch to different screens twice to see it showing at last and responding quite slowly. Things that could be improved: In the Endura Out&Back model, lacking the electronic compass, the "navigating/compass" screen is responding very slowly, probably averaging some readings, which makes it more stable and usefull on longer distances, but also slowly responding, inaccurate and in many cases really USELESS inside 10m from the waypoint. Being close to a waypoint I have to move in straight line for at least 10 meters before the compass become showing proper direction. Using only "navigation copmpass" screen, I would have very hard time finding where the waypoint actually is. Left or right or behind me. I only see the distance, but the direction is not refreshing properly and the only way is to out at least 20m and return back. I understand it's hard to make better pure-GPS-compass alghoritms, but because of that I would prefer to navigate in close proximity of the waypoint with map screen instead of nav compass (map position is refreshed every second, even if the direction of the "position indicator" is not). Unfortunately with the current max zoom of "10m" it's not precise enough! The waypoint and position indicator icons are big, being close to the point even at highest zoom level they are very close and overlapping. It would be REALLY usefull to have at least one zoom level more, a "5m" level. I hope it's not a problemating thing to do from a programmer's point of view. The position given by Endura is usually around 3m out, sometimes it happen to be better (around 1m) so having the highest zoom level "10m" is a waste of the precision. 90% of the time Endura could easily show position more precisely and in closer proximity of the waypoints with "5m" or "3m" zoom levels. If it's an issue that this would make too much zoom levels to swich for normal use, then make the highest "5m" and "3m" zoom levels only active in close proximity of an active waypoint ? Then in normal use the max zoom would be "10m" level like now, but when navigating to a waypoint in it's close proximity user could swith to even higher zoom levels. Please also consider making the "nav compass" arrow to "sense" the direction better, with less averaging (after moving only few meters) if inside 20m from an active waypoint. In other words, to increase the compass "Sensivity" inside 20m from an active waypoint. When talking about direction sensing, I have a "feeling" that after 1.51a upgrade the "position indicator" arrow is responding much more slowly to changes in direction. When turn 90 deg or even 180deg, for several meters (as much as 10) the arrow is moving "sideways" or even backward, before it turns to the proper direction. Before the update, the 1.4 white arrow sensed the direction very nicely, I wouldn't expect better working position&direction indicator arrow witout true electronic compass. It seemed to be very well balanced between being stable and fast responding. I prefer it to being little less stable (after all I can check my "average" course just looking at my trail line) but showing the actual directon only after 2-3 meters. It worked this way when it was white (so v 1.4). Now the black one from 1.51a is responding very slowly and I have to move about 10m to see it showing my new direction. Talking about my Out&Back here. For Safari and Sierra it's probably a no-issue because of electronic compass. From a visual point of view, in my opinion the older white arrow was much better than current black "something" . The new one seems also bigger for me, making waypoint navigation in very close proximity to them, more difficult - it's obscuring the waypoints more easily. When using the 1.4 software, it bothered me that the on-screen buttons are so large, obscuring much of the map when displayed. I found they are simple textures and modded them to my preference, making them smaller but big enough to hold the txt button names. I couldn't change the font size, so I shortened few long-button-names that were too big to fit on my smaller buttons. For example "Find menu" was shortened to "Find". The result was quite satisfying for me and I used them. Thing that bothered me even more, was the size of other graphic-interface elements - the moveable aim-cross and the waypoint symbols on the map screen. They were much to large for such a small screen size, to my preference. Maybe with current size they look good on web-presentations, small screenshots and commercials, but are too big to be practical in actual use on the screen. I'm not a person with failing eyesight, personally I don't need them to be so large. Waypoint symbols are also simple textures, so I decreased (some of) them a bit so they are still easily readable, but almost 2 times smaller. I was quite happy with the results and used them too. I decreased the X and diamond waypoint icons (first six from the list), the rest is left unchanched as rarely used by me and also decreasing them in gfx program would made those more complicated icons less readable. The aim-cross was also a texture, I considered re-doing it from scratch, but simple scaling-down gave very satysfying results. Thing I was not able to make smaller was the central arrow of the position indicator. I have not found a texture for it. After 1.51a update, there are new button graphics so my mod was overwritten with new textures. I'm getting used to the new colours, but couldn't stand having back the large buttons so I replaced new ones with my modded 1.4 "yellow" ones. I also preferred my 1.4 decreased size aim-cross than the new one. Someday I'll make smaller version of new ones, for now I'm using old modded "yellow" ones. New thing that bothered me with it's size was a "zoom indicating bar". I edited the texture too, making it smaller (especially the moving "button") and yellow (to be same as button colour I use). For comparison, a screen of stock 1.4 interface: And here are screens of my 1.51a interface modified with elements from modded 1.4 interface: Note smaller buttons (bottom ones and zoom buttons), smaller aim-cross, smaller X and diamond waypoints, smaller button on the zoom bar. Remember that's it's mainly a mod of older 1.4 interface. Main and zoom buttons can be still easily activated with a finger even wearing a thin gloves. After those changes I'm much more happy with my Endura visual interface. For me it makes the map screen much less cluttered for it's size and much more readable. Maybe it's a good thing to consider - a Settings Menu option to choose the size of interface elements (Large, Normal, Small) with separate textures for each one. Easy to implement and makes the interface much more customisable for client's needs. Not everyone is happy with so large icons and buttons. And "customisable interface" sounds good in the "feature list" . Please also think about an option for central position indicator arrow - make possible to choose it's size (it's easy to scale it, if it's a vectorised one) and to choose between the arrow graphics - an "old" white one and "new" black one. I would like to post this notes on Lowrance forums directly, but I'm not aware of any official Lowrance forums that include active discussions about Endura software. If they are any, please redirect me there. Regards!

Thanks! Today the I left it averaging the waypoint and after some over 2 hours (10k samples on my balcony) the averaged location was quite different from start position. So it did moved from the "frozen" position showed at the moment the waypoint was marked. On the other hand, the averaged waypoint was different from start location by... about 30m and unfortunately clearly wrong . I had some accidental 30+ m position reading errors at this location - from time to time, but the position always returned closer to actual only after 10-20 seconds. Only sometimes had to wave the unit to "update" the position... In some cases, because of active "static navigation" - the "wrong" position (different by 20-30m from actual) could accidentaly "froze" on the unit laying stationary and be still displayed on the screen even after few minutes. If such a thing happened, then only waving the unit to break the min velocity threshold (and update the position) caused it to return where it should be (inside few meters from actual). Seem for me that during waypoint averaging for some reason the satellite signal or satellite lock went worse, the position "jumped" 30m out, simultaneously a false velocity reading (higher than threshold) disabled the SN and the position was "updated" to current "bad" one. Then again conditions improved, velocity readings settled at zero again, few seconds later SN kicked in and "frozen" the "bad" (30m out from true) position. It remained "frozen" maybe for an hour or so, generating thousands of "frozen" identical and identically bad position readings that were used for averaging. So the final averaged position was calculated about 30m SE from where the "true" position is located. By "true" position I mean a circle with about 10m diamater, containing both the GoogleMaps position of my balcony and 90% of all position measurements collected with both Endura and another GPS unit. I'm pretty confident in true GPS coordinates of my balcony are - the uncertainity is only about 3-4 meters. In short - a waypoint position that was averaged for almost 3 hours (10k seconds) is placed 30 meters SE from true position, when both starting position (displayed at the moment I marked the waypoint) and exit position (my position on map afer exiting from waypoint averaging) were much closer to true one (maybe 4-6 meters)!! The only explanation I see is that accidental low-quality position measurement was also accidentally "frozen" by active SN (static navigation) and most of the samples used for averaging were just from this "bad" frozen measurement. ... I made another test an hour ago. I enabled the Endura waypoint averaging function and simultaneously (15 seconds before) enabled also logging of the NMEA stream with SirfTECH. After some 15 minutes I stopped waypoint averaging and also closed the NMEA log. Then checked the log (looked at it in text ed and also opened it in VisualGPS). What was happening with NMEA position during averaging: for most of the time the position was "frozen" in the starting point. Then after about 300 samples (5 minutes) it suddenly moved about 6m NE, generated short serie of few independant data points walking backwards toward the starting point and then it frozed again in place generating next serie of about 700 identical data points. This started to "shift" the averaged point from starting position toward the new position. After 10 more minutes averaging was stopped with the average point calculated being somewhere between those two locations. At the very end of the log, some seconds before the averaging was over, the NMEA position suddenly again returned close to the starting point and generated few independant samples (it is visible in the NMEA log, it happened probably when I took the unit into my hand to disable averaging and stop logging). I don't see any other explanation of this behaviour (averaging few hundred or sometimes maybe few thousands identical samples, then sudden move by several meters, then again averaging several hundreds identical readings and so on) other than the SN (static navigation) is enabled during data collection. Maybe it was ommited that it is needed to disable it for this purpose. It also explains a bit how the "30m out" position averaged in good conditions was possible to happen, when mostof the readings from same place are within 6 meters. Good that the Lowrance engineers will take a look at that and check the waypoint averaging algorithms - if it works properly and if the the SN is really disabled during waypoint averaging or not. I hope the above observation (if it's true) will help to improve the Endura software. Note to them: it would be very very nice if - in addition to correctly working Waypoint Averaging feature - we could see an option to enable or disable SN by hand in Endura GPS settings menu in some future versions of software... Excuse me please producing so much text for so simple issue but I tried to do my best in describing it fully and clearly. P.S. Some time ago I've read an interesting article about US Forest Service test of few hand-held GPS receivers of different brands. Now I reminded it because of some asociation that came into my mind. They tried to evaluate if they are suited for work of forest servicemans in forested areas. They tested the accuracy in different conditions using waypoint averaging. They also tested the Sierra, but noted that it's unsuitable for their needs because it lacks the waypoint averaging funtion. Now it would had it . But what was _really_ interesting and was an observation noted on statistical data collected, that for some GPS units waypoint averaging DOES NOT improve the accuracy. Single collected waypoint was just as good (or bad) as averaged one. Maybe those GPS units which didn't improve accuracy using waypoint averaging also didn't disable the SN mode during the process - so this feature was in fact also not working properly on them.... Regards !!

Hi everyone ! I'm owing an Endura Out&Back unit (for about two months) and recently upgraded it from 1.4 to 1.51a software. Many thanks to Lowrance - a really great upgrade !! Lot's of important improvements and some features. I do not like the new interface colours but probably it's just me - that's subjective . The functional fixes and improvements are great. (The only thing I do not like after the update is the new rotating position indicator I liked the white one better. Is there any way to get it back ? It seems for me the arrow i's not a texture... I guess it's coded inside the .exe file.... An option to choose one or other would be great ) Now the main issue: In 1.5 update of the Endura software the long awaited "waypoint position averaging" feature was added. Now, I tried it and I'm confused a bit. Is it working at all when stationary in good conditions (with strong satellite signals) ? The Endura's GPS unit seem to have the "static navigation" mode enabled. So if the velocity is lower than the threeshold, the displayed position is "frozen". In most other GPS units the threeshold is set to something like 5km/h, in Endura it seem to be tuned to value better suited for hand-held unit - something around 1km/h. So, as long as I'm walking at least 1km/h the position updates just fine. Now when I stop, the position is frozen and does not update as long as I'm stationary and have a good satellite lock (so "velocity" readings are zero or below 1km/h). As long as Endura doesn't "feel" the velocity to be over ~1km/h - the displayed position will not change. In one try I was even able to move VEEEEERY SLOOOOOWLY for more than 10 meters and position was still not refreshed. Only when I waved the unit a bit (generating for a moment a velocity greater than the threeshold) the position have updated. Now this is all good and fine, in normal operations - it's better to "froze" the position when stationary than to generate a "spider" pattern track around the point. But the "static mode" is definitely NOT welcomed when it comes to position averaging. When I positioned the unit stationary with a good satellite lock - the position quickly frozed. Then I have activated the waypoint averaging mode - the displayed position was still frozen... Every digit of displayed position was the same for several minutes. The "averaging" was done on few hundreds identical position readings ! Of course the "averaged" position was identical to the start position. I also managed to log the NMEA readings at the very moment of waypoint averaging and guess what - it was a stream of identical "frozen" position readings. Not a single digit in position coordinates chagned over few minutes again. Position frozen. Only when I came after few minutes and waved the unit with my hand - the position have refreshed. The averaging - as it works currently - would actually work only on long measurement periods (the position would refresh from time to time, when the fluctuating "velocity readings" of the stationary unit occasionaly rise above the threeshold), and with weak singnals - in such conditions the fluctuating velocity readings would constantly break the threshold which cause continuous position refreshing. I think it would be better if the the "static navigation mode" in the build-in GPS unit was automatically DISABLED at the start of waypoint position averaging - then the position would be resfreshed every second and it would be actually averaging multiple independent readings - which is the whole point of "averaging". After the waypoint averaging is over - the "static navigation mode" would be automatically turned ON again. Currently the only way to really average a waypoint (with a strong signal) is to constantly wave the unit to generate velocity readings >1km/h, or to walk in small, slow circles around the measured point. (by slow I mean over 1km/h - to disable the static navigation, but below 5km/h - which is said to be upper limit of velocity for averaging). What are your experiences with position averaging ? When you are doing it with a stationary unit - are the position coordinates refreshing every second, or are frozen too ? Question to Lowrance representatives - what is the chance of this being fixed in next patch release ? The "static navigation" being disabled during waypoint averaging and enabled again when it's over ? Without that, the feature is almost worthless... My second and much less important question would be - is there a plan for "look ahead" mode when in "course up" map orientation, when the position indicator would not be centered but moved some way back, to 1/4 - 1/3 of the screen height, showing more terrain "ahead" than "behind" current position? P.S. And an option to choose the type od position indicator - old white 2D arrow or new black 3D arrow Regards! Ami