really want some input from FieldGenuis users!!!!!

[Kevin B.]

We purchased MicroSurvey Cad2004 this past spring. We are very happy with it, especially the tech support, which helps you through every problem whether it’s something I created it or it is a software problem. We are thinking of purchasing FieldGenius in the very near future. It would be very helpful to hear from some current users about their experiences with it.
Thanks Alot

[Darcy Detlor]

Hi Kevin,

Sorry that our users are such a quiet bunch.

Maybe they don't want to give away any secrets

Actually, FG2004 is a huge change from the previous version and I think that our users are still getting a handle on the new program.

We have some demo Trackers that we send out to people who are interested in the program.

If you would like to try one out, send me an email.

[Ned Ferguson]

Kevin, I am currently in the midst of the 6 month "upgrade from a different data collection package" evaluation period. I run FG on an Allegro CE. While I am happy with FG overall, I do have some issues with the program. There are also a few features that I love.

The "offset intersections" routine is great. The ability to offset intersecting lines is a real time saver. I do not know why other software companies (TDS, cough cough) have not incorporated a similar feature. Also, I love the way FG gives the ability to translate/rotate/scale in one process.

My biggest problem with FG so far is SPEED (or the lack thereof). If you have a point file with just a few points, say 50 to 100, FG performs adequately. But if you have a file with 1 or 2 thousand points and up - FG is AGONIZINGLY slow.

Even the process of importing an ascii point file can easily take 2 minutes and up.

GPS transformations are a veritable nightmare. Even connecting to and setting up my base and rover units (HiPer) takes at least 20 times longer than before. Doing a simple 2 point GPS transformation to a local system containing a couple of thousand points can require 10 to 15 minutes processing time.

I hope that these speed issues can be ironed out. They seriously detract from an otherwise interesting and productive package.

Other positives include custom keyboard mapping for shortcuts. This is a great feature. I am currently leaning towards "keep it" - (provided I do not have too many more frustrating 30 minute field processing sessions.)

[louismullen]

Hi Kevin

We use the 400 mhz model Tracker and we make sure that most of system memory is reserved for programs ( not Storage) It handles large numbers of points quite well.

Regards

Louis

[surveyjoe]

Hi Ned Ferguson,

If you are using an Allegro CE that runs around 200mhz..... that is the problem with the lack of speed with point files that have around 2000 points.

I have FG2006 on the TDS Ranger 200C and if I put my biggest file of 1,900 points, FieldGenius slows down very much. I can open the same job on my 400mhz Ipaq and FieldGenius runs just fine.

To help the speed of FieldGenius you can set the memory slider to allow for more memory storage or more program storage. This may help some.

My silder is set at about 90% program memory and about 10% for storage memory on the Ranger 200C at 206mhz. Jobs with about 1,000 points run ok and jobs with about 2,000 points do have a definate lag to them.

The problem is not really with FieldGenius but probably is with the Allegro CE (if it runs around 200mhz).

Windows XP won't run on a 386 computer and FG2006 won't run very well on less than 400mhz.

If you are also opening a DXF file that is above 300k, that also will slow down FG2006. I only open DXF files that are just a "stick file" of the actual drawing. It took me a while to figure this out, but once I did, FG2006 starting running very well.

Goto some computer store like CompUSA and buy a 400mhz Ipaq and try FG2006 on it. You will see a BIG difference in the speed. After that, get a new Allegro or the Tracker.

Hope this helps

Thanks

John R

PS...... How's Jeff Shipley doing?

[Jason Poitras]

Hi Ned,

I don't know what version of FieldGenius you are running, but there were huge performance fixes in the 2006 version of FieldGenius. If you haven't upgraded yet I would suggest that you do so.

We decreased the overall time it take to open the figure and point databases as well as decreased the amount of time it takes to import ASCII files.

[Ned Ferguson]

Jason,
I am running v.2.0.2. According to your release notes the next available update is 2.0.3, consisting of one minor GPS fix. Were there speed issues addressed in 2.0.3 also? If so, I will gladly try it.

Incidentally, I needed to load an ASCII file this morning, so I decided to time it. It is a standard, comma delimited ascii file containing 2174 points.

Time to load to mobile device: 12 sec.

Time to import into FieldGenius: 5 min. 03 sec.

That is embarrassing.

I am going to take this same job and orient to it using the GPS local transformation program. I will time it also and report back the results.


surveyjoe,
FG is purported to run on the AllegroCE... it should do so. I am no programmer, but is amazes be that my old DOS Husky will outperform so many supposed better, faster Windows-based data collectors when it comes to cogo. Unfortunately, getting new hardware as you suggest is not an option, since the software license is tied to the hardware. The user cannot simply migrate to new hardware (without repurchasing the software). I wish it were that easy. I have tried changing the memory slider to make most of the memory available for running programs. It did not result in any noteworthy improvements.

As for Shipley, my Shipley-tolerance was exceeded a few years ago - if you know what I mean.

[louismullen]

Joe

I am not very certain but I reckon if you go out and buy a new data collecter e.g ipaq or similar the people at MicroSurvey will organise to transfer the FG to it for a nominal fee.

Do yourself a real favour and try the 400 mhz IP65 Tracker. You can organise to get it on demo for a trial period. You will be impressed.

Louis

[CHRIS L]

I second or third .....what ever number its on that using a higher speed device would most likely fix your problem since I have a Allegro CX that 400 mhz and it flies through opening jobs....even the ones in with thousands of points

For what its worth.....you might try adjusting your Systems/Memory speed and see if that helps any......you can adjust the amount of memory the device uses to run programs verse the use of ram.....might help a little on the slower devices

Thats found in control Panel/ systems/ memory on the allegro.

Chris

[Ned Ferguson]

As promised, I am reporting the results of my GPS localization. Unfortunately, I could not get FieldGenius to work at all. It is not like I haven't done this before. I have successfully localized to several projects by now.

I collected 6 control points on a forty-acre site. I was supposedly getting good residuals. Then I began the localization process. While I was "adding control" to the list I noticed that every RTK collected point was listing a coordinate of 0,0. I was getting the same coordinate for every point, regardless of my location! Luckily, I was using an ATV to navigate the site so I only wasted 1 hour (not including drive time, loading and unloading.) I reset both receivers and tried it again, getting the same results. I ultimately just gave up.

[CHRIS L]

Ned

What GPS system are you using? We use FG 2006 with a Leica 530 GPS and have never had any issue with taking shots....The first time we tried the localization, we got some screwy results, but that was just my own case of "Operator Error" by not entering it in correctly. After a few adjustments, It came out correct and has everytime since.....

Are you still using 2004 or 2006 seems like the localization screens changed alittle inbetween the two versions

[Ned Ferguson]

Chris,
I am using the Topcon Hiper with FG 2006 on the AllegroCE. I do not usually have this problem either. I simply set up the base, stored an autonomous point for it, and took some sideshots. One would think that is pretty straightforward. I am at a loss...

[CHRIS L]

Ned

You got me....obviously something was screwy with the setup...Configuration settings somehow get changed?? ....has it done the same thing since then? I am pretty sure there are other guys that use the TC Hiper with FG.....check on here and see if ther are any post or check on the www.rpls.com message board for guys using that combo and see if anyone else has had that problem.....

We've never had problems with it giving us screwy coords....
I'd say check your config. setting and try it again....Would your boss possibly let you take the unit home and check it out on your own time...if your willing to do that?

Chris

[Brian Sloman]

If you are getting coordinates of 0,0 for every point, check the Transformation Settings and make sure you don't have a scale factor of 0 entered. It should be close to 1.

[surveyjoe]

Chris........

Ned is the owner of the company.

[Jason Poitras]

Hi Ned,

I am surprised that it is taking so long to import an ASCII file. On our Allegro CE (200 Mhz), a 2000 point ASCII file takes around 45 seconds to import, not 5 minutes. Do you have FieldGenius stored in the Allegro's C_Drive?

When you import an ASCII file, FieldGenius creates a SP "Store Point" record for each point being imported which in your case would instantly create 2000 extra records in the raw file. The reason we do this is because we treat the raw file as a complete record of everything that was done. So 4 years from now if you review your raw file you can see exactly what points were imported, shot or calculated. This adds some overhead to the process.

As for what happened to you with the GPS we've had some reports of this happening to some of our customers. For some reason the Transformation Settings are getting set to zero and we don't know why. It's a tough bug to track down.

[surveyjoe]

Jason,

If I import a 2000 point ASCII file and then delete 1000 of those points, FG is going to 2000 SP records and 1000 DP records into the Raw Data file. If I then localize on 1 point and try to adjust that 1 GPS point, FG is going to take about 30 to 45 minutes to adjust 1 GPS point.

By the same token..... If I import a large topo that contains around 4000 points that were shot with a total station and then goto the site, localize on a couple of points, adjust the couple of GPS points, and then try to store 50 extra shots with GPS...... FieldGenius is going to take more time to adjust the localization points than it will take to shoot the extra 50 topo shots.

Many, if not all of us, can afford to sit on the tailgate of the truck for 30 to 45 minutes while FG adjusts 3 or 4 localization points.

Four years down the road no one is going to care that the Raw Data file tells them what points were imported into the data collector. They will remember that it took 3 hours to complete a job that should have taken only 1.5 or 2 hours.

Most of my jobs don't approach the 2000 point range. My jobs usually only have at the most 500 points. FG handles the 500 point and less jobs in a reasonable amount of time.

Maybe as an alternative....... you should consider keeping the Raw Data file as small as possible and write the SP, DP, adjustment records, etc... to someother file that the user can archive for future use. Having FG create a secondary file named something like "RawDataAdditions.txt" would be a good idea and keep the main Raw Data file to only contain shot data.

Something has to be done about this.

Thanks

SurveyJoe

[CHRIS L]

Survey Joe

Thank...then I'm sure he'd have no problem getting permission to taking it home

Thanks
Chris

[Ned Ferguson]

Jason,
FieldGenius and it's project directory definitely resides on C_drive, per the installation instructions. I wish I could be more help.

My setup is as follows:

Processor: Strong ARM
Memory: 52692 KB RAM? (Supposed to be 64MB)
MS Windows CE v3.0 (Build 126)

Allegro Version: 1.01
Date: 10/03/2002
PIC Firmware: 1.04
Logic: 11

As in most businesses, time is money. We use RTK on a great many jobs now. Excessive processing time spread over dozens (if not hundreds) of jobs results in a scenario that I cannot live with. Plus, let's say the user makes a mistake and needs to reprocess the same job again, then the time factor becomes grossly exaggerated. I say this from already having the experience of needing an hour and a half to get localized into a large topo/boundary/construction site.

The productivity of RTK makes the excessive time factor seem even more painful. In just a few minutes, 2 people can get a bunch of stakes in the ground.

I am not beating up here, but I concur with John (surveyjoe); this is a circumstance that most surveyors are not going to live with.

[Jason Poitras]

Hello,

I agree with both of you that it takes too long to reprocess the raw file if there are a lot of records in the raw file. We will look into it and see what we can do about speeding it up.

Thank you for all the feedback - it isn't ignored.

[marko]

Hello,

We use FG2006 with a pair of Hiper+ and it's working fantastic for us. However, our files do not have thousands of points in them so maybe we don’t “push” it too hard.

Incidentally, I strongly support the idea of having all of the job history saved in the project.

Should an ugly skeleton come out of the closet on a survey that I did 4 years ago, I want to have all the facts at hand to back me in defense of the steps I took to complete the survey.

Furthermore, should I find a problem with any survey, having a complete history of the steps taken on-site would help me to figure out what went wrong? Lots of software can connect the dots, but only the best software will help you when you have a problem.

My vote is please do not completely remove the history functionality. Hopefully you can find more speed for these folks without removing or disabling a fantastic feature.

Marko

[Red Dog]

I have to say I HATE when other programs don't include ALL data in the raw file. The raw file is supposed to be the ONE place to find EVERY piece of info on how the data was collected. To me, this even includes HOW intersection, POL (points on line/curve) etc points were computed in the field.

I understand processing takes longer with more data. I would think the program could easily ignore SP and note records. Maybe there could be a note at the top of the list of points imported that says "1,435 Points imported" and the program would just skip down 1435 lines at one rather than "decide" to ingnore a line 1435 times over.

[Ned Ferguson]

GPS raw data workaround (hopefully temporary):

Problem: When processing a GPS localization, if numerous ascii points were imported into the job, the processing takes an extremely excessive amount of time due to reading all the "SP" raw data records.

Solution: Exit the FieldGenius program. Go to the file explorer, locate raw data file and rename. I usually just append a "bak" extention (ex: myjob.raw.bak). When the job is reopened, FG will create a new, clean raw data file. This procedure vastly improves the required processing time.

[Brian Sloman]

Ned, the same thing can also be done right within FieldGenius, when you are about to open the FG Project. On the Review Project screen, press the New button and to create a new raw file without having to manually rename the old one through the file manager.

[surveyjoe]

If FieldGenius 2006 will adjust the GPS points with a "new" raw file, then why does the program read every line of a 2000 point coordinate raw file?

Why not just have the program go ahead and adjust the GPS points without reading every line of the point file?

John