OK, I have designed a neat new data collector

When you are done with that

[sarcasm]you could get a job on the Autodesk design team and teach them a thing or two[/sarcasm].

I remember when rotation meant adjusting the sheet of clearprint on which you had plotted the record so you could get a good fit with the sheet that had the found stuff plotted on it.
Translation meant shifting a few inches to the right (or left, depending on your outlook) :O)

Clyde

What language should it be in? It (my daydream) is designed to run on a tablet PC, or on an IPOD, IPAD, or similar device. Touch screen, larger is better.

Nate

I always dream about new survey software. The truth is the magic is in the code, not the idea. 99% of the work is going to be getting clean code written that people will buy/use in a professional environment. Something that is 99.99% reliable. This is hundreds of hours worth of skillful programming work for an alpha product.

Nate...

Hate to change the subject, but do you guys get UPS in Caddo Gap?

A notebook and writing implement is data collection.

What you want is data storage and manipulation without loss of the original data.

One thing to always keep in mind: The value of the product is not determined by the price of the tool involved. The value is determined by the little grey cells between the ears of the field surveyor.

Paden

What is pecan and apricot, and half gone?

🙂

Nate

Nate,
You need to patent this before anyone else thinks of this!
Someone may beat you to the patent and they will be rich and you will still be doing field work.
And don't send it to China either or they will take your idea and replicate it and you will be out.
Good Luck

Ok, how much time do you think it would take to make a full featured and de-bugged DC?

I honestly think that what I want would take around 200k. That is a gut feeling. Then, to make it do all I want it to do, with finesse, would take 500k.

It would run in an ipad. or the like.

N

If you're really thinking about pursuing this, I highly recommend having a conversation with John Evans, who designed, built and marketed the DC50, with help from some very talented programmers and business people. John had what was, in my opinion, a really good product, but found that the market wouldn't support it. Sales were disappointing, and he ended up folding up the operation. He can give you the down-and-dirty about what works and what doesn't in the data collector market, and might save you a lot of grief.

P.S. Although I drive my Leica robot with SurvCE -- the DC50 won't run it-- when I work 2-man with my old Topcon, we still use the DC50.

Nate,

Interesting idea ...
and it would be great if all our dc should talk the same language ... some kind of landxml for storing observations and atrribute data.

However, as Jim alleready mentioned, a lot off challenges to take and a lot of questions to ask.

you want us to run the software on a tablet? will it run Win7, Android, Apple Ois, they all need different program languages i think.
I prefer my TSC2 with full keyboard for my topo work, can handle it with gloves in the winter, it is very rugged!

And then you have to let all the different branches of equipment to talk to your tablet device,
when brand x releases a new GNSS or TS you'll be updating your drivers. Some brands won't be very helpfull in sharing information.

A lot of stuff to handle ... a giant task ...
Maybe some open source programming group could be interested or/and some university surveying/programming project?

If you need a beta tester ... you know where to find me!

keep us posted,

Christof

Jim, that would be John Evers. I spent many hours on the phone with John. John developed his own data collection program to run on the HP49 and then the HP50. And it worked exceptionally well for his own use. Others found out about what he was doing and expressed interest but there was just not enough interest to develop AND market it. Of course John knew his own system inside and out and, as the designer, was very comfortable using it. I tried it and with time, would have probably liked it. In my opinion, it was way beyond the simplicity and ease of use I was familiar with using SMI - which is what I still use for day to day surveying and field computing. I also have available the latest and greatest version of MicroSurvey Field Genius which is excellent for topo work. But for day to day land surveying and the associated field calcs needed, SMI is the preferred product for me. I find that running SMI on a Recon is so much nicer than on the HP48 and is very close to the ideal data collector for me.

Paden

:good:

Why have any buttons at all.

It would need to be able to run DRAGON or similar program that has been expanded to include complete voice commands.

0.02

Why even talk , they have just developed technology for tablets that will allow the user to use their eyes to preform movements on the tablet screen such as key clicks ect . Should be out in a year or so.

Jim's right about the challenges facing a data collection manufacturer. It isn't easy. I think John could have made it had the recession not hit when it did. Obviously, being calculator based, it didn't offer the graphics capabilities of the Windows CE class of hardware, but in terms of features and customization it held its own and bested them in a lot of ways. His was the first (that I'm aware of) to make use of internal long-range Bluetooth to communicate with robotics or conventional total stations. Screen visibility far exceeds anything available today. And, for the initiated user, everything was far quicker to access and execute, from coordinate transformations to offset shots. As Dave mentions, it wasn't quite as user friendly to the novice, such as TDS. However, once you know how to run it, do you really want step by step instructions slowing down your work flow or would you prefer to just press two buttons to perform your task?

I do recall very early in beta development on the DC50, randomly the database containing the coordinates and raw data would crash, resulting in a complete loss of the job. The temporary solution was to store a backup of the job every few collected points, so that in the event of said random crash, the user would only lose a few points and not the entire day's work. Ultimately the error in the programming database was found and corrected, eliminating this "undocumented feature" (programming speak for eff-up) and data storage worked perfectly. But this is the kind of stuff a developer experiences in development - microkinks that could be in the operating system, code, user, hardware, instrument, etc. It's not as easy as it sounds.

Then you have debates over whether a feature really should be added. Do people really need to be able to do this kind of offset, or will it just be a waste of effort and confuse the interface? Should a routine be accessed via a page 3 menu selection, or should it be less intuitive and faster to access? Should you stick to the common rw5 format or develop your own raw data format? If you develop your own, will you also be developing the desktop software to process it (since no other program will be able to use it)? What hardware will you make this available on, because every hardware has its own vague peculiarities or will you limit it to a few or one (as Evers did)? If you limit it to a few, will the manufacturer of said hardware support you and be in production for the amount of time you'll need for ROI?

Oh yeah. And it's an incredibly competitive market with serious brand loyalty and a pretty low profit margin. Not trying to pee on your parade, I just found all of this stuff surprising when I started helping John and Tim on the DC50 project.

> ANYBODY interested?

I have some contacts in management at Trimble if you want them 😛

Thanks... James, Trimble seems to me to want to not deal with little things. All I have is little things!

N