LittleFoot Elegance Photo > Off-Topic Discussion

Little Foot Display Firmware

<< < (6/7) > >>

Astroquattro:
Of course I was talking about having a new controller based on open hardware, like Arduino. For a new controller you need new software because the old one can't be used on a complete new model.  How else can you get rid of all the annoyances if you keep something from the, despite it won't be usable with complete different electronics?

Do you have an idea why there isn't any such system open hardware with python/QT coding on the market?
I give you a hint: it's not because it's undoable...

cheers,
Christian

the_lizardking:
Maybe some interesting link related to our discussion sent by Orlando:
https://github.com/TCWORLD/AstroEQ

Astroquattro:
This is indeed interesting and I found it on the web earlier this year. It started going in the right direction but ended up where one was before because the mind behind it do not know much about computer science and how to put up controls the right way.

I've been on some busyness trips the last weeks, meeting people who work in the field of serial programming controls and some working on FPGAs. All in all they know about the issues with closed hardware. We had many talks about the pro's and con's and in the end we agreed: The answer to the question why there are no universal tracking controls on the astronomy market is: There is no professional electronic engineer involved who is an amateur astronomer and know as much about astronomy than electronics. At second, there are too few serious amateur astronomers pay for such a device the amount professional companies want to have. At third, there are no companies who would built such devices based on open hardware because anybody could kick them out of busyness.

So if we want to have a cool and freaking tracking control, future ready and expandable based on open hardware we have to do it on our own. And we have to treat the result like that and distribute just the information how to built such a thing and not distribute the device itself. Such tracking devices which can evolve with it's user needs the user, or more to the point only if the user evolves from an unexperienced buyer to a serious observer he deserves such a tracking control because if he builds it he will know how it works and therefore know what it does and how to use it right. As like a car, if you have build or re-build it because you know what it consits you, you will drive it better. Then you know how every part works together with every other part. This understanding brings you to the point of using this self-learned knowledge in your driving skills, like reducing your usage of the break less by controlling the speed more accurately, or by trusting the side guiding forces of the tires when driving through narrow curves with higher speeds.
Just for example.

The mistakes in the astroeq lie in the wrong choosen ascom environment again. If one would have relied on the arduinos internally used c++ language or turned to the pyduino library and not screwing things up with ascom, we would not have to build our own. And if they didn't start using the microcontroller, which is just copying all other controls from the past, we won't start our own, too.

To sum it up:

no-goes are: ascom, microcontroller based tracking, sub-d-plugs, closed-hardware and closed os-support (msoft os are just an option not a requirement, pec

requirements:
 - open-hardware, to make rooms for evolution
 - Linux as standard os because of it's realtimeness (MacOs is linux!)
 - USB and Ethernet interfaces because no one hase sub-d, ieee1394, pcmcia, cardbus interfaces anymore
 - microstepping: hardware and software (h: >= 128x, s: expandable by formula)
 - gui has to work on all os-types preferable Linux, see Linux as standard for why
 - modularity, not everyone needs autoguiding, not everyone needs star map-based object selection and slewing, etc
 - indi-library inclusion for controlling filters, cameras etc
 - opengl inclusion for realtime star maps and modern look and feel -> there is a kick-ass opengl-lib for python3 which does not exlcude ATI-cards like other languages.
 - UCAC4 and USNO B2.0 as main catalogs for positioning and object databases
 - objects and informations are organized in database -> mysql, there are nice python-mysql-libraries which give good gui support
 - parallization! if available make us of as much cpu-cores or cpus as possible

to be continued...

SurfaceCleanerZ:
Hi,
do you know the µstic stepper control? It is open source and is probably a basis for an development.

http://www.s-line.de/homepages/schweikert/SMCtrl/smctrldocu.htm
sorry just german.

regards,
Stefan

Astroquattro:

--- Quote from: SurfaceCleanerZ on Sunday, 20.10.13 - 18:38:25 - CEST ---Hi,
do you know the µstic stepper control? It is open source and is probably a basis for an development.

http://www.s-line.de/homepages/schweikert/SMCtrl/smctrldocu.htm
sorry just german.

regards,
Stefan

--- End quote ---
Hi Stefan,

yes it is open source but it is still what we don't want. It uses very old Atmel microcontrollers AT90S2313 and as old and not available any more rs232 interfaces. The board is closed hardware. The concept presented on this site is what is used since the late 70th and the improvements a little down the site suggest using a h-bridge like L293 which is replaced in more modern controlls by several ic like the A4988 or TMC 262 or TLC5940 etc.
Our main problem today is, that there are no electronic engineers in astronomy anymore who know all possible chips. That's why open_hardware is the key to get an universal controll which will stay and evolve with the future.

Navigation

[0] Message Index

[#] Next page

[*] Previous page