Messages

The data in those maps are at least 12 years old.  Since you seam to have software capable of modifying geographic data, just download and use the current data from the non-copyrighted government sources.

That fixed it.   In trying to solve the 'memory full' issue I had not noticed that doing a 'Reset' / 'Restore Defaults to Factory Settings'  changed the 'System' /Interface' to 'Garmin Serial'.

Many thanks.

A firmware update and master reset fixed the 'Memory Full' message.
While in mass storage mode, files can now be upload and be displayed on the GPSr.

However, the unit is still going directly into mass storage mode when the USB cable in plugged into a computer USB port.  No screen with 'USB cable detected  - do you want to go into mass storage mode - Yes/No ?'  I have again tried three cables, on various USB ports on two computers.  The Or300 does go to the dashboard screen when plugged into the automobile USB port.

I will try calling Garmin on Monday if a solution is not be found by then.  It appears that at the cost of a few AA batteries I can continue to develop my multicolored geologic map and reference topo data.

Thanks for your help and suggestions

Red90,

Used the Windows command prompt window and used the attrib command to check the root folder and all subfolders on the Or300 and the microSD card - no .gpx file anywhere. 
There is a small hidden file in the Or300's Garmin folder named fs_image.ver with a data back in 2009.  Found a second .xml file in the Garmin folder, system.xml (22285 bytes) and GarminDevice.xml (10244 bytes), both have the file date of the most recent time the Or300 was turned on.

I did another 'Setup' - 'Reset' - 'Restore Defaults To Factory Settings' .  Factory settings were again restored to when the Or300 was new; however still have the 'memory full' message on startup, then goes into USB mode if the USB cable is connect; and does not recognize any .img map file sent via sendmap2 nor transferred via Microsoft Edge.
Is the 'master reset' you suggest different than the RDtoFS I have done?  If so how do I do it?

Thanks

Using Windows 10 on a dedicated laptop not connected to the web (nor having and updates for the past 1 1/2 years).  By 'wore out unit' I was thinking that 12 years ago when the Or300 was new thumb drives were often not lasting much more than a year, so maybe the Or300's internal memory might be failing. 

Definitely not a segment limit as the data map file and test 8 x 16 square polygon file are each only one 'segment'.  Many maps with 10's to 100's of map segments each were removed  before starting testing with the new data last fall.  Each of the new files was removed before starting on the next test.

There is an .xml file on the Or300 whose file date gets changed to the most recent time the unit was turned on.  I have not checked it for internal changes.  There did not appear to be anything in it related to the maximum number of 'uploads' the unit might be limited to.   
The recent testing has been mostly on the test polygon file assigning different RGB color codes to the different mp_types (Garmin feature codes) to determine usable shades of color on the unit.   I am working on a geologic map of a 2x1 degree area.  The paper maps have more than 150 different units, each in a different shade of color.  No way to get that many on the OR300 and even less easily distinguishable in outdoor changeable lighting.  At times I have been using sendmap2 to combine the .img and changed .typ file and send the result to the micoSD card on the Or300 as many as fifty+ times a day.  Thus the 'question' of a hidden install limit on the unit(s)?

In 'battery mode' the OR300 will display the 'dashboard' after pressing 'OK option' on  the  'Memory Full screen'.  The topo map on the microSD card and the Garmin world map and an early version of the geologic map (with polygons and lines) on the OR300's internal memory can be display.  No additional map .img file (nor a .gpx file) added to either will display.


Thanks for the info and stay safe.

I have hardly used my Oregon 300 in the past 6 years.  Last fall started making experimental layers with the current data from USGS, Census and OSM.  I did many hundreds of uploads to the Or300 using sendmap2; some without a custom type file, others with.  The .img file(s) were deleted from the Or300 after every one or two file were uploaded.  Three days ago I stated to get a 'memory full' message almost every time the Or300 was connect to my computer USB port.  Initially a file sent using sendmap2 was OK; then after a few uploads the Or300 would not show the file on the map select menu (it would show with the proper upload/build time using edge).  The Or300 now goes into USB access mode about 6-7 seconds after the 'memory full' message appears whether 'OK' is pressed or not.

There are no waypoints, tracks nor geocashes on the Or300 nor on the microSD card.  The OR300 has the Garmin basemap and the MicroSD has my state map from a decade ago.
Free space on the OR300 is 900Mb of 1Gb and on the microSD is 3.7Gb of 4.0Gb.  Neither removing the microSD card nor using another changes anything, nor does trying two other USB cables.  The 'memory full' message also appears when in 'battery mode'.  Also tried another computer, transferring the sendmap2 gmapsupp.img file via edge to the microSD and transferring other .img files made years ago - none work.

Any suggestions?
   Wore out unit?
   A corrupt file?  I have done a 'factory reinstall' twice.
   

I doubt that would exist.  The most detailed file on BLM's Colorado site is 1/4 of 1/4.  Their Geocommunicator site for active and closed claims states 'Keep in Mind that these are only the BLM LR2000 claims. To find out their actual boundaries you must go to the appropriate County Recorders office.'

BTW - SW of SW of NW of SE is 1/4*1/4*1/4*1/4 = 256 equal sub-sections
                                               1/4*1/4*1/4  =  64 
                                               1/4*1/4 = 16



Thinking back to my Colorado PLSS and Colorado PLSS QQS overlay map sets; the PLSS QQS one appears to include outlines of mining claims.  Current file (in shape format) on the BLM website was created 2020 Sept 11. 

https://www.blm.gov/services/geospatial/GISData    Click on state list at left (Colorado)
Third screen down under Administrative Units - click on + for cadastral.
Fifth bullet down - PLSS Second Division (Aliquots)

I would expect the other BLM state office websites to have similar data files.  No info on the 'claim holes', just the 'name' and acreage for the 1/4*1/4's

  Blocks/tiles/quads may have a blank area to conform to the widest area of data.  A tile in Florida is probably overriding the Georgia map data in that area.  This may also be happening around the projection in northeastern Florida.  BaseCamp can only load one map at a time, so this is not an issue there.  Try disabling the Florida map on your GPSr; the entire Georgia map should then be visible.   

With OZ's installer for the registry being about 130+- lines long and having no understanding of installers, etc., it was something I was hoping someone would make available - which did not happen. 

Agreed, for most people likely not.  We did have a few that had problems simply clicking on the .exe file and using the defaults.  Even one or two the kept insisting the install process should be done the way they wanted and not how Garmin required it - and helping those can take a lot of time away from creating/updating mapsets.

Nice USGS link Boyd.  I was able to attend a local USGS hydro meeting where the head person for the 'project' presented info on the intent and progress of the effort.  Unfortunately my home state was one of the first and used 2007 Census Tiger for the transportation.  The three year refresh seems not to have taken place since as of about two years ago the National Map was still using the 2007 data for transportation.  In the 2007 Tiger files slightly over 1/3 of the counties had NOT undergone spatial realignment.   OSM also used unrealigned TIGER when the seaded it.  Funding has been drastically cut, priorities change and the price for quality is ever increasing, but some of the decisions could have been a lot better and more? efficient.

From the first line of the wright-ups for my state mapsets 'This map ... developed ... with shaded relief set to 'do not show'.  The tan background is likely due to Garmin's shaded relief DEM file being active.  This made maps on an OR300 look so much harder to use compared to the 76SCX I was replacing I was about to return it.  I asked about it on the groundspeak geocaching forum and was told to turn  Garmin's relief shading to do not show..

For a number of years I have urged mapmakers to switch to Garmin's new gmap format which does not use the registry. I have had very little success in convincing others to do this.

I think there was even an additional advantage at that time that was never mentioned.
*However*, as I understood it at the time, there would have been an additional step PC users would need to do on there own, unless someone with the necessary programing skills found a way to include it).  Since no-one did and about 90% of my mapset downloads were PC versions (with some even having trouble installing a working 32-bit .exe file) it did not seam user friendly change to me.   

If they are USGS topos they will not be very up to date.  IIRC the most recently updated 1:250k was about 1980's vintage, 1:100k was late 1990's, and 1:24k about 2000 or 2001 (unless USGS decided to reinter the map production sector in the past few years).

Sounds like you might have night mode turned on; or auto mode which uses night mode when it thinks it is night at your location and time.

I would like to try to clarify some ' :)wildly inaccurate' statements/impressions often made/held about map accuracy.

All federal government maps for standard or principal needs have to meet horizontal and vertical accuracy criteria/tests.  'For maps on publication scales' ... of 1:20,000 or smaller (ie. 1:24k, 1:63,360, 1:100k, 1:250k, etc.) 'not more than 10% of the points tested shall be in error by more than 1/50 inch' - that is 40 feet on a 1:24k map and 167 feet on a 1:100k map.
Furthermore 'these limits of accuracy shall apply in all cases to positions of well-defined points only.  ....'  [I was once told by a USGS cartographer in Reston that the thinnest line that could be printed on paper was 1/100 inch]

Would not be much reason to use 32 sheets of paper for 1:24k's if they did not show more detail than a 1 sheet 1:100k.   Except in special cases like a small over-edge area, the 1:100k's covered an area of 30 x 60 minutes; the 1:24k's were 7-1/2 by 7-12 minutes.  There are edge and central tic marks showing the 4 by 8 array of 1:24k's.  FYI - the 1:100k data was created by paneling the 32 1:24k maps.  I never got a detailed explanation from USGS of the process; however, the 1:24k maps needed to be created first - this required the creation of those 20,000+ preliminary version (only a few of which went to final/standard maps).

No Assumption needed - a 1:24k has 4+ (100,000 / 24,000) by 4+ times the paper area available to show the same area of the ground surface and it's various features.  IIRC at the time Garmin released the 1:100k mapset the only other topo product they were selling was 1:24,000 mapsets of individual National Parks on 3 CDROMS sold separately.

Only the hydro and transportation data was digitized (for the Bureau of Census).  Garmin must have digitized the other types of features themselves or found other data sources.  Boyd or anyone; have you ever over-layed the Garmin data on the USGS 1:100k DRG (digital raster graphic) images of the same area or compared it with the USGS 1:100k DLG (digital line graphs)?  The USGS DLG files were in NAD27 and UTM coordinates - perhaps there was a glitch in the conversion process - I initially had some using GM when I created the Trails from USGS 1:100k overlay mapset.