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

Discussion of FieldGenius related issues and questions.

Moderators: Brian Sloman, Jason Poitras, James Johnston

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

Postby Kevin B. » Mon Aug 09, 2004 6:41 pm

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
Kevin B.
 
Posts: 36
Joined: Wed Mar 17, 2004 4:10 am
Location: Damariscotta, Maine

Postby Darcy Detlor » Tue Aug 10, 2004 8:22 pm

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.
Darcy Detlor,
President,
MicroSurvey Software Inc.
[email protected]
User avatar
Darcy Detlor
Site Admin
 
Posts: 205
Joined: Tue Oct 29, 2002 10:14 am
Location: West Kelowna, BC

Slow, slow, slow

Postby Ned Ferguson » Wed Mar 01, 2006 6:57 pm

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.)
Ned Ferguson
 
Posts: 37
Joined: Wed Mar 01, 2006 6:35 pm

FG2006 Benefits

Postby louismullen » Thu Mar 02, 2006 2:32 am

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
louismullen
 
Posts: 8
Joined: Fri Nov 04, 2005 3:48 pm
Location: Ireland

Postby surveyjoe » Fri Mar 03, 2006 3:47 pm

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?
surveyjoe
 
Posts: 33
Joined: Tue Nov 15, 2005 10:41 pm

Postby Jason Poitras » Thu Mar 09, 2006 10:29 am

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.
Jason Poitras
General Manager
[email protected]
User avatar
Jason Poitras
Site Admin
 
Posts: 443
Joined: Tue Oct 29, 2002 5:17 pm
Location: Kelowna, BC, Canada

Postby Ned Ferguson » Sat Mar 11, 2006 8:14 am

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.
Ned Ferguson
 
Posts: 37
Joined: Wed Mar 01, 2006 6:35 pm

Postby louismullen » Sun Mar 12, 2006 2:06 pm

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
louismullen
 
Posts: 8
Joined: Fri Nov 04, 2005 3:48 pm
Location: Ireland

Postby CHRIS L » Mon Mar 13, 2006 6:16 am

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
CHRIS L
 
Posts: 94
Joined: Wed Aug 27, 2003 8:45 am
Location: ILLINOIS

GPS follow-up

Postby Ned Ferguson » Mon Mar 13, 2006 6:26 am

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.
Ned Ferguson
 
Posts: 37
Joined: Wed Mar 01, 2006 6:35 pm

Postby CHRIS L » Mon Mar 13, 2006 8:51 am

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
CHRIS L
 
Posts: 94
Joined: Wed Aug 27, 2003 8:45 am
Location: ILLINOIS

Postby Ned Ferguson » Mon Mar 13, 2006 9:50 am

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...
Ned Ferguson
 
Posts: 37
Joined: Wed Mar 01, 2006 6:35 pm

Postby CHRIS L » Mon Mar 13, 2006 11:08 am

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
CHRIS L
 
Posts: 94
Joined: Wed Aug 27, 2003 8:45 am
Location: ILLINOIS

Postby Brian Sloman » Mon Mar 13, 2006 2:39 pm

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.
User avatar
Brian Sloman
Product Manager
 
Posts: 399
Joined: Fri Jan 07, 2005 4:42 pm
Location: Westbank, BC, Canada

Postby surveyjoe » Mon Mar 13, 2006 3:55 pm

Chris........

Ned is the owner of the company.
surveyjoe
 
Posts: 33
Joined: Tue Nov 15, 2005 10:41 pm

Postby Jason Poitras » Wed Mar 15, 2006 3:39 pm

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.
Jason Poitras
General Manager
[email protected]
User avatar
Jason Poitras
Site Admin
 
Posts: 443
Joined: Tue Oct 29, 2002 5:17 pm
Location: Kelowna, BC, Canada

Postby surveyjoe » Wed Mar 15, 2006 7:57 pm

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
surveyjoe
 
Posts: 33
Joined: Tue Nov 15, 2005 10:41 pm

Postby CHRIS L » Wed Mar 15, 2006 9:46 pm

Survey Joe

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

Thanks
Chris
CHRIS L
 
Posts: 94
Joined: Wed Aug 27, 2003 8:45 am
Location: ILLINOIS

Postby Ned Ferguson » Thu Mar 16, 2006 5:57 am

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.
Ned Ferguson
 
Posts: 37
Joined: Wed Mar 01, 2006 6:35 pm

Postby Jason Poitras » Thu Mar 16, 2006 9:54 am

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.
Jason Poitras
General Manager
[email protected]
User avatar
Jason Poitras
Site Admin
 
Posts: 443
Joined: Tue Oct 29, 2002 5:17 pm
Location: Kelowna, BC, Canada

Postby marko » Fri Mar 17, 2006 12:14 pm

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
Mark Cahill BCLS
marko
 
Posts: 25
Joined: Tue Oct 29, 2002 10:41 am

Complete raw data

Postby Red Dog » Wed Apr 12, 2006 11:21 am

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.
Red Dog
 
Posts: 1
Joined: Wed Apr 12, 2006 10:50 am

GPS workaround

Postby Ned Ferguson » Mon Jun 05, 2006 7:47 am

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.
Ned Ferguson
 
Posts: 37
Joined: Wed Mar 01, 2006 6:35 pm

Postby Brian Sloman » Mon Jun 05, 2006 8:19 am

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.
User avatar
Brian Sloman
Product Manager
 
Posts: 399
Joined: Fri Jan 07, 2005 4:42 pm
Location: Westbank, BC, Canada

Postby surveyjoe » Mon Jun 05, 2006 8:37 pm

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
surveyjoe
 
Posts: 33
Joined: Tue Nov 15, 2005 10:41 pm


Return to FieldGenius

Who is online

Users browsing this forum: No registered users and 1 guest