math coprocessors

David B

Does anyone have experience with the Micromegacorp floating point processor UM-FPU V2 and the AWC PAK versions of FPU? Would you recommend one over the other for any reason? They seem pretty similar.

I just bought my wife a Dobsonian telescope for her birthday. Nice optics, but a super-simple mount. So I was wondering what it would take to measure the alt-azimuth position, convert it to right-ascension-declination and display on an LED - it looks like it could be doeable if only I had a coprocessor to deal with sines, cosines and·floating point multiplication and division.

Both of these chips look like they could do the job. One is a few more dollars more than the other, but both are inexpensive enough.

Any advice or warnings?

thanks,

David

LoopyByteloose

I think you should take a look at the software documentation as I have the UM-FPU V2 and while it really can do a lot, it requires a desire to become competent in its programing language [noparse][[/noparse]which is highly mathematical].

I just have too much on my agenda to sitdown and learn it all.

Obviously if you are already knowledgible in the astronomical calculations, it might be user friendlier to you. Which ever you choose, you wil have to handle the interface.

Mine -the UM-FPU V2 will do both I2c and SPI. That seems to leave you with a bit more programing flexiblity.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)

······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan

David B

Thanks for the reply. I did already look at documentation for both; I was wondering if anyone had personal experience that would recommend one over the other. For example, the PAK units use an external resonator but the UM-FPU doesn't. So how can I compare their conversion speeds?

I was hoping that this wouldn't take math expertise; the reason for getting this chip is to avoid the math. I should be able to plug in values to perform a calculation like this:

declination = arcsin(sin(altitude) * sin(latitude) + cos(altitude) * cos(latitude) * cos(azimuth))

So once I turn movements on the telescope altitude and azimuth axes into counts, then into radians, its really just a matter of shuffling values in and out of registers and performing sin and cos and multiplication operations on them at the right times, and after a while, out pops my declination.

I think I'll go ahead and buy the PAK-IX and try it out.

rockin_rick

I'd be interested in how this works out for you, please post a follow up when you get this done...

What processor are you connecting this to?

Rick

Jon Williams

Sorry I'm late on this, but this article may give you some insight into the um-FPU: http://www.parallax.com/dl/docs/cols/nv/vol6/col/nv123.pdf

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

David B

Thanks for the Nuts and Volts article reference, Jon, now I see what Kramer meant by having to learn another language!

Rick, I haven't really thought very far ahead about this. I would think either an SX18 or SX28 would be suitable, as long as there are enough IO pins to read the axis rotation sensors, run the FPU chip and run the display. Plus I think I'll have to interface to a time chip to be able to do the right ascension calculation. Plus I'll probably need a way to initialize the time, and maybe also the reference latitude and longitude, if I want to get fancy...

If and when I actually get this project up and running I'll post it as a project on this forum.

StarMan

David,

I would also be very interested in the results of your project.· I have been considering picking up a Dobsonian mount telescope and your device could really add to the fun.



Chris I.

LoopyByteloose

We all tend to look at speed first, but what about the ability to record and keep various formulas.

THERE IS AN IDE which may make the UM-FPU-v2 easier to program and revise.

Using an SX18 with a 50Mhz resonator may just spend a lot of time in waiting.
You might even find that a BS24p would get you running without having to figure out the Shift IN and Shift Out code and without figuring out how to create FIFO buffers for your data.

Since it is 32bit internally, you really want to keep that internal and have it output useful 8bit binary data for your motor control [noparse][[/noparse]if at all possible]. Direct stepper motor control comes to mind.

I suppose the ideal input format for it would be Binary Coded Decimal [noparse][[/noparse]4bits wide] or ASCII Numercal [noparse][[/noparse]8bits wide] for change of variables and constants.

It seems that once you get this working, the UM-FPU-v2 would do all that nicely.

You really need to just try to get a reasonable estimate of how often your mechanical devices need to be driven.
If the calcualtions can provide more than one iteration in the cycle, you have more speed than you need anyway.
Looking at stepper motors, they come in 100, 200, and 400 steps per revolution.
So if you know your RPM, you could easily figure out a stepper rate.

As I recall, telescopes move very slowly.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)

······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan

Post Edited (Kramer) : 1/14/2006 2:56:35 PM GMT