next topic »

[Reply #15 on:]

So it will work, NOT real time, with Uno!  A few minutes delay would be cool for accurately measuring distances.

[Reply #16 on:]

I think the Due will be out in volume and have some kinks worked out before an RTK system was ready for prime time if we started today.  The Arduinos are great platforms for the right task, but sometimes they are vast overkill, then I go to the ATTINYs straight from AVR Studio and some times they just do not have the capabilities.

wade

[Reply #17 on:]

Does anybody agree that using a Uno is possible with only a reasonable amount of effort?

[Reply #18 on:]

Does anybody agree that using a Uno is possible with only a reasonable amount of effort?

I don't see how anyone could possibly judge that unless they also knew how much code, data and processing power was required to implement whatever it is that you think the Arduino would be doing in this solution. If you want the answer to that question, I think you need to find somebody who understands the solution - or learn about it for yourself - so that you understand what the Arduino would need to do and what resources that would need.

[Reply #19 on:]

You could read the many links in a row I posted if you were curious.  It does seem possible to me, although not in real time with frequent updates.  I was hoping to get a discussion going with reasons it will not work.  I believe the only limitation is the processing power of the Uno.  This is why I said it will not work with frequent updates.  Can we agree on that?  If not, why not?

[Reply #20 on:]

You might want to do a SLOC count as a rough metric of whether the processor has enough memory to handle the size of the executable.  I do not have the time to do this and if I were to build a system like this I would port it to a processor that has enough power to do near real time updates.

[Reply #21 on:]

I believe the only limitation is the processing power of the Uno.  This is why I said it will not work with frequent updates.  Can we agree on that?  If not, why not?

As I said before, to know the answer you need to understand what the code is required to do. This will enable you to work out the amount of program space, memory and processing speed that would be required to do it. Are you seriously asking somebody to undertake all that research for you? If you're interested in the possibility, then go see what would be required. It's just as easy for you as it is for anyone else, and you have the advantage that you're the person who wants to know the answer.

Or to put it another way: No, it has no chance of working; the Arduino does not have sufficient program space, RAM or processing power to do this. Now go prove me wrong.

[Reply #22 on:]

I guess the only way to know for sure is to try to do it!  You've raised some good points.  The Speed is only relevant if you want to do it in real time.  The program space is sufficient.  2K RAM is the biggest problem.  Luckily you can add RAM or use UNO32 instead.

[Reply #23 on:]

The Speed is only relevant if you want to do it in real time.

Are you sure? I thought that timing in GPS was crucial, given that you're measuring the distances to a set of objects all moving. Given that you're trying to measure cycle-to-cycle variations in the phase if a signal that has a very short wave length, with the signal passing between objects that are moving at thousands of miles per hour, it seems to me that you have a *lot* of data to process and that the data is inherently real time.

I could be wrong - I have no idea how this clever algorithm works other than what you've told us - but to me this sounds like a maths-heavy number crunching problem. This is why I thought you might want to get it working on a decent spec PC (if that's possible) and then see what resources it needs and whether you can finesse it down to run on something that's about a thousands times slower.

[Reply #24 on:]

They already got it working on a PC.  It seems like the parts where you have to measure time are doable on Uno or Uno32.