LittleFoot Elegance Photo Community Forum
LittleFoot Elegance Photo => Off-Topic Discussion => Topic started by: Astroquattro on Friday, 06.09.13 - 19:32:13 - CEST
-
Hi,
I got the eagle board files for the LF Display from Ananad and today the pcb arrived in a fine white look. Soldering was easy if one follows the tut's in the old forum.
Now I need the firmware to write it with my new avr-mrkII ISP to the chip. Anybody any idea where to get it?
I search the old forum, but I couldn't finde any link which isn't dead. Sourceforge just hosts the code for LFEP.
I really want to use my LF with the Display because I'm in need for a stand-alone control which is capable of autoguiding as a counterpoint to my own tracking control which will be not stand-alone.
-
You will need to contact Anand,...
Where did you find the LFEP source code, could you post the link? Or you mean the ASCOM driver I think,...
-
yeah, it is the ascom driver which is hosted at sf.
Ananad once said that he would make all the stuff opensource but till today nothing became opensource, the pcb's aren't the firmwares aren't. I know it's hard to let go, because I had to do that often times, but we I tell people I said my invention free, I do so.
I'm not complaining here, I just say that's hard to get all pieces to a functioning whole together. I'm trying and I won't stop.
What I'm doing during waiting to get all bits and pieces, I'm rebuilding the schematics's from the pcb's with fritzing (www.fritzing.org) to have a source where to get pcb's from. Fritzing-fab produces pcb's for a reasonable price and you do not have to buy series of pcb's, just one is ok, too. Buying more than one makes it cheaper, but not that much.
I'm modifiying the display's pcb to fit into a case I found in one of my old electronic collection boxes. The LF and the display be join together so I don't need the 15 pin's sub-D plugs and the IEEE plugs will be moved to the top. Therefor the pcb has to be re-routed.
I will talk to Anand about the firmware.
cheers,
Christian
PS: Images about my subversion will follow when everything is in place.
-
Hi Christian,
keep up the good work and let us know the results! 8)
I'd like to know what the IEEE plugs are (maybe I should say were :'( ) meant for. :-\
CS
Armando
-
Hi Armado,
till now I couldn't figure out the use of the ieee-plugs, but since most times cameras and massstorage devices have the plugs and protocols made by sony, I guess one could use them for autoguiding with ieee1395 cameras like the ones made by Alied Vision. A third good reason would be a dam fast connection to a computer to release the microcontrollers of its duty and get a full-fledged computer control. But since the LF Elegance and its derivates have an ascom driver that advantage would have been cancelt.
I know what one can do with AVR chips but it is an awful lot of coding by where you have to have a really good algorithm form the basic image reduction for the ieee-cameras. The LVI SmartGuider does similar things based on a microcontroller, too.
I will know when I get the firmware source code or you tell me your suggestion.
cheers,
Christian
-
Hi Christian,
Rajiva sent me only part of code related to EPEC, nothing else. I really hope you'll receive the fw source code.
It would be great if a new fw development could start... Let us know. ;)
CS
Armando
-
Hi Armando,
did you try to run a disassembler/dis-c on the firmware? Since one knows that the code is written for AVR Mega128/162 there are not many option how the code will look like and there aren't many option on the compiler ether.
My interest in the source code doesn't concern any invention stealing, because I'm not in the need of using other peoples code to get to something. My interest is just academical. It helps me to better understand how this tracking control works and that in turn help by using it more efficiently.
And secondly, moding the pcb to use, let's say, a mega 2560 entails modification of the code to built one's own subversion.
My own invention is based on openhardware like the Arduino, some available shields and breakout boards and is written in python, pyqt and pyduino. I wrote a astro-math library some years ago for a different project which comes in handy now, because it is usable with python3.3 without changing anything and it includes everything one needs to calculate oder convert for astronomical purposes.
So, you see, there is no point for me to re-engineer Arnand's stuff. I won't market my own stuff ether, nor someone else's. I don't see any benefit in that, because what keeps me going on is not the little money that could come out of marketing a universal tracking control.
If Arnand will pass me the source there won't be any point in publishing it, not even here. But we can talk about the used concepts and algorithms. I think we owe him this loyalty as one hacker to the other.
cheers,
Christian
-
Hi Christian,
did you try to run a disassembler/dis-c on the firmware?
No, I didn't. And frankly If I was interested in FW development without the sources I would start from scratch to make my own FW.
My interest in the source code doesn't concern any invention stealing, because I'm not in the need of using other peoples code to get to something. My interest is just academical. It helps me to better understand how this tracking control works and that in turn help by using it more efficiently.
And secondly, moding the pcb to use, let's say, a mega 2560 entails modification of the code to built one's own subversion.
The following one is my point of view: simply LFEP is affected by some bugs, some interesting features were not developed/completed and new features will never be available without a new development. As a LFEP user I see many reasons to be disappointed. I would be happy if a new FW development could start to make LFEP compliant to its spec.
So, you see, there is no point for me to re-engineer Arnand's stuff. I won't market my own stuff ether, nor someone else's. I don't see any benefit in that, because what keeps me going on is not the little money that could come out of marketing a universal tracking control.
Money is often the cause of many issues...
If Arnand will pass me the source there won't be any point in publishing it, not even here.
I asked you nothing...
And I never asked Rajiva to send me the FW source. My only intent was to offer my free time to help Rajiva to solve some bugs, instead of limiting to tell him what didn't work... And I did not need the source to learn something but to solve the bugs...
Because of my time spent to contribute free to solve some bugs and my EPEC tests, Rajiva sent me the code related to EPEC (and I found also the bug). Since Rajiva didn't send me the full source code I'm not interested in having it.
So I started hoping someone else could receive the sources (by Rajiva) and start the development to solve all current issues.
You wrote:
I will know when I get the firmware source code or you tell me your suggestion.
So I assumed you would have received the sources by Rajiva.
Please read the following thread: http://forum.lfep.de/index.php/topic,38.0.html
As already stated by myself I'm no more involved in LFEP FW development.
CS
Armando Beneduce
-
did you try to run a disassembler/dis-c on the firmware?
No, I didn't. And frankly If I was interested in FW development without the sources I would start from scratch to make my own FW.
Of course one would start one's own invention, but one does not need to invent the wheel over and over again. As I see it now, there are pretty good reasons for both ways, re-engineering the LF and building something new based on open hardware.
The following one is my point of view: simply LFEP is affected by some bugs, some interesting features were not developed/completed and new features will never be available without a new development. As a LFEP user I see many reasons to be disappointed. I would be happy if a new FW development could start to make LFEP compliant to its spec.
You're right, there are some disappointing things about the LFEP and it's more than only the missing features or the bugs. I started building the LFEP myself and took a deep look into the pcb and the description as well. What it should do and how that is meant do be done be the hardware is not worth the 600 to 800 one has to pay at ebay and TS (yes, they have one left). So I stalled the building process to first get my LF the display.
I am tossed between going on with the LFED and stalling it for unknown time, because my own tracking control will solve the issues anyway. A close friend of mine said something some weeks ago. He said, "Sometime, you want to complete your series." He is right about that and that's what makes you feel disappointed with the state the LFEP is in.
I can't give any advise at the moment, but I do understand you with your feelings.
If Arnand will pass me the source there won't be any point in publishing it, not even here.
I asked you nothing...
That was not the point. I just wanted to state that it's about trust and loyalty from one developer to the other.
And I never asked Rajiva to send me the FW source. My only intent was to offer my free time to help Rajiva to solve some bugs, instead of limiting to tell him what didn't work... And I did not need the source to learn something but to solve the bugs...
Because of my time spent to contribute free to solve some bugs and my EPEC tests, Rajiva sent me the code related to EPEC (and I found also the bug). Since Rajiva didn't send me the full source code I'm not interested in having it.
So I started hoping someone else could receive the sources (by Rajiva) and start the development to solve all current issues.
You wrote:
I will know when I get the firmware source code or you tell me your suggestion.
So I assumed you would have received the sources by Rajiva.
Please read the following thread: http://forum.lfep.de/index.php/topic,38.0.html
As already stated by myself I'm no more involved in LFEP FW development.
Ok let's talk about what has to be done and what should be done in the end.
As there isn't any universal tracking control on the market, I'm in the need of something to solve a problem at my home town observatory. We operate a 24" Cassegrain with f=7620mm, an orange C8 (one of the good ones) and a 130mm Fraunhofer refractor. All is mounted on a german mount, which was built by a colleague that died 2004. It has a wurm gear for each axis but they are a little bit to small for the precision of the main telescope. The actual tracking control is from the 70th and has a computer program from 1992, which was written by an other colleague in pascal. It is complete outdated. It does its job for visual observation but you can expose for more then 27 seconds without getting the stars eggy. An other colleague transfered the controlling software after a computer crash in my absence to a new computer with Windows XP ans dosbox, because the controlling software is dos-based. Since XP and what followed are no realtime os, one gets misplacements by 4 to 7 arminutes. Even if the system time is corrected before one starts the software. This is based on XP's bugs in the time routines. We do not have any internet connection at our observatory, so we can't correct the systemtime permanently by ntp. Our time signal receiver is to old for XP and there's no point in using such technology anymore.
So that's our situation. I needed a thesis for my master's degree in computer science and so I ask if I build a new tracking control. They agreed because the master's degree will be included in my Ph.D, too. So in the end I will have build a complete observation and analysis pipeline with a tracking system which is adaptable to any telescope to a certain size.
In our local club we do not have any member with skills in electronics, nor do we have more than two professional astronmers... ...and the other one has it's problems with technology. So there is just one guy to help. It's my friend Lothar. He's a welder, so he can't help me with the electronics either.
That hardens the situation, too. Our observatory hit the 20 years last year and we have to do something.
As I wrote these lines, I ran your words through the back of my mind again.
I'm in the need of a new tracking system and you're disappointed of the LFEP because it is unfinished.
I read in this forum, that people like to go on with having a nice universal tracking control.
Why don't we put our peaces together and build something new?
Open Hardware and using plattform independent programming languages, hosting the code on sourceforge makes it flexible from the start.
So if someone who takes part in the development process and has to leave for any reason, nothing is lost and he/she can be replaced by anyone who likes to join.
The point why I started with Arduino was, it's ease to talk to sensors and motors. At first I took nearly three quarters of a year searching what's on the web but Boxdörfer doesn't sell to Germany anymore, LF/LFEP is now discontinued and about FS2 we do not have to talk. It was obvious that I would have to build my own hardware. I started by doing resaryh on the web about motion controllers and found a robotic board which could do the trick. Is the FNB of the RoboterNetz. Having an Atmel mega on board and a 52 pin bus, it was a start. During my work on the board, I realized that I don't want to have the mount controlled by an MCU because autoguiding will be a pain and using encoders will be pain, too, because all in all it will get over the MCU's head. And second, I didn't want it to be stand alone, since one has to use a computer/laptop for the ccd camera anyway. Some days of searching the net for usb/firewire interfaces passed and I found the IOWarrior56 of CodeMercanaries. It has 35 I/O ports, not the 52 I wanted but that's ok I won't use the 10 servo bank anyway. An email from an old friend brought my attention to the WIZ8300, an ethernet breakout board with all the pin I needed. The minute I started writing some code I got a call with an invitation to a meeting. That meeting tooks place two weeks after and we discussed the FNB and my I/O boards. Attention then was drawn away by personal issues (like broke up with my girl friend, moving, and health...)
Much changed within a few weeks and the next time I could thing about carrying on, I found myself searching the web again and I stumbled about the Arduino. There it was, controlling motors with ease and reading from any sensor I would like.
I found some shields to do microstepping up to 1/128th.
Till now, I have the Adafruit MotorShield working a 0.9°-stepper and the steppers at the observatory by the Arduino itself. My next steps are to bypass the Arduino's Atmel Mega2560 with firmata and run it from the laptop I'm using.
Maybe that could be a start...
What do you think?
cheers,
Christian
-
Hi Christian,
What do you think?
You can see a really interesting project at http://www.astrohome.info/Teleskopsteuerung2.htm
I asked the author if development is still in progress or finished. I hope to receive an answer.
CS
Armando
-
Hi Christian,
anyway 128 microsteps is surely a good starting point. 8)
Let's see if Thomas Westerhoff will answer...
CS
Armando
-
I already talked to this guy,... I asked him if he wants to join us. However Rajiva was making him troubles, said he was taking ideas from him - so he was very pissed off and stopped working public and of course do not want to join us.
He finished the project but made only one piece for a private observatory and meanwhile they even do not use it anmore,...
-
Hi,
yes, I'm aware that there are two sides of a medal and that AR may have done the same as he accuses other of. Money makes people paranoid and greedy.
As I read in this forum some of the other post one think becomes more and more clearly. Maybe this is not the right place start a new version of a tracking system.
I know of Thomas Westerhoffs project and in some points he is very right. I think the way he sees it, turning in his project and not going public anymore reflects that he is aware of all those Gollums who think that society owes him. His reaction, in my opinion, is the right one. I myself thought about this issue from the beginning, when I started to my project in 2011.
The facts are, Boxdörfer beared the consequences from tighter law's and the behavior of others, AR and M. Koch are of the same kind but may have lost beyond repair and guys like Thomas and others won't go to market with their inventions.
I won't distribute my tracking system either because, it is not meant for. I is a solution for my home town observatory.
On the other hand I see the needs of other to have a working and reliable tracking system. Since there is not industry to distribute such systems in a way suitable and the number of needy people can be counted on two hands or double there is no market at all. Facing all the problems is not worth the effort one has to take to develop one's own solution to the problem.
I write that to make clear that I'm aware of what is at stake here. That's why I mentioned my question, if this forum really is the right place, in the first few lines.
Thomas' solution is a typical stand-alone solution which is called "Goto" by those who do not have any clue what where talking about, so 99% of the amateur astronomers.
With my solution there will never be a stand-alone version, because since it's made for tracking to get scientific evaluable data. It's meant for using with ccd camera only. Of course what is good for ccd cameras is good for visual observations, but there won't be any support for that or any lower claims/requirements. Being science-grade is all that matters. Today we are in the position that every amateur is cable of doing it the science way. This way is the only way that really makes sense when it comes to meaningful observations, because it is the optimum level of entertainment. The rest can, with right, be called esoteric.
It may sound a little harsh but we there shall be an open project, we have to have straight lines and clear goals.
I agree to Thomas' requirements list with some minor changes, because I don't want closed hardware, because that will kill the project, if I retire from. Open hardware has some major advantages and just a few disadvantages. The advantages are, everyone can buy it via Internet and have it delivered in a short amount of time. It is certificated lawful, tested and you have companies for guarantees. Open hardware can be replaced easily with more modern parts and so adapt to new developments. One has not to build the pcbs of one's own or buy expensive small series. Open hardware is extendable or downsizeable and that can be left to the user ans his responsibility. If released to public on a strict website that states it's just to inform others about and makes it clear that there will be no customer support, only the competent will get one.
Disadvantages are that one does not get alway get the perfect chips to do the job and one has to take what's there.
It won't become a mass product and stays exclusive for the needys what may keep the prices higher than necessary.
I think there is more on the plus side.
But first things first, let's talk about it here is the right place to build a more public project.
cheers,
Christian
-
Hi Christian,
But first things first, let's talk about it here is the right place to build a more public project.
I assumed Thomas Westerhoff controller had not been completed and, because of the details published online, my hope was that he could evaluate the idea of offering his contribution to start a new open project or to open and finish his own project with the contribution of other users.
I did not imagine he could have been annoyed by Rajiva! And, frankly, Rajiva developed nothing more than a controller integrating many features, each of which is nothing new. Should we move our mounts by hand? :)
I think this forum can be the right place to build an open project.
What I'm not sure about is the preference for a not stand-alone controller.
CS
Armando
-
Sure - I would say it would be a good start to go with audorino as this makes things easy to play with and also we would have the epec feature more or less in place. There are many projects outside from which we could get some inspiration of and many people know how to deal with it. Starting from that we could go and programm the chips then,... once stable and working.
-
Hi,
@Armado,
I just told you my motives why I'm not looking for a stand-alone version. That was a good idea for a time in which powerful computers filled an entire floor of on office building and personal computers where huge and heavy fawn boxes which needed power cords.
Today everybody can have a capable labtop or notebook computer for less than 150 (www.luxnote.com for example) or run a tablet for less than 100 (http://www.efox-shop.com/tablet-pc-notebook-c-129 for example) which provide a very usable usb port.
That in mint there is no point in having a stand-alone version anymore. Despite, if one chooses the Arduino as basis, one sure can have a stand-alone version but it's less capable. The main reason for not choosing such a version is, that my ideas involve ccd cameras. And that is a key requirement! Because you definitely NEED a computer anyway, there really is no point in doing less.
I told you that I don't want to go to market with my solution, which I need for my home town observatory, because I don't have the time nor the wish to run a company. I am a professional astronomer and my duty is to research the universe. I've been to Kit Peak, Skinakas, Carla Alto and other observatory they have a variety of tracking systems, but mainly they use SPC which stands for serial programable controls. They operate huge DC motors attached to cvt gear drives to reach nano-arcsecond resolution and being able to move up to 300 tons of steal from on horizon to the other in less than 5 minutes.
For smaller telescope like our 24" Cassegrain or the one's RC optics produces or planewave the mounts are smaller and the weight is less so one does not need heavy duty motors but DC motors with gears attached to belt drives or friction gear drives are common. I moding my on modified Vixen SPdx (images attached) to make use of a belt drive in declination. I have an eight inch fork mount from Meade operating a C8 (when it arrives by mail the next days) which will be modified in more than the same way (both axis). During my research on tracking systems I found out that worm drives came up in the 70th because belts didn't provide the same duration at that time. Older people might remember that it was useful to have a spare belt in they car or at least have accompany by a tights wearing girl because cars those days broke down with ripped belts. Today this belt are high-end products if they are taken care of. As a racing bike driver I change my chain every year to get the most out of it and thats about 12k to 15k kilometer a year.
You see, if one goes professional one climbs up the ladder in the requirements. The third image attached are the optics at our observatory. 24" of course could be pointed by hand because the mounting is so smooth-running that if it's not fastened by the gears of the motor it is moved by the slightest air-movement in the dome.
Thomas will agree that with such an instrument you won't go for a stand-alone version. Whats good for semi-professional use is good for amateur use because you get both for a small price.
It is the same discussion why one would choose a dobson mounting. Ok if one just wants to look or do a messier marathon (which one could do just two times a year) a dobson is ok, but for all other purposes you need a tracking to be comfortable. For taking photos (whatever scientific or entertaining) you need a guided tracking, not only to even out the pendulum which comes from the conversion of a circle (angular based) to a linear movement, but to deal with the seeing. Yes, down to six inch telescopes you have to deal with shifts caused by the seeing because those scopes' resolution lies in the seeing area up to 1arcsecond. Even a five inch scope suffers by that, when seeing is high (>1,8"). If you have a normal Vixen SP/GPdx or those replica called EQ up to 8" scopes wind is effecting the mount and that has to taken into account, too. (See image four)
Ok my modded SPdx doesn't suffer by that because I change the RA-axis to be filled with a massive 6cm Axis and the declination head is completely change to make room for a 5,2 cm axis which was drilled to 4,2 when it comes out of the head's housing. The maximum reasonable weight you can put on is 70kg (separated into telescope and counter weight). Ok I don't have such an instrument but an old friend had a 12,5" planetary newton which's weight was 36kg. That was back in the 90th's.
Maybe that cleared up why I am not looking for a stand-alone system, despite, I have the LF which runs nicely if I just want to look for wellness reasons.
@lizard,
I have a working implementation of Arduino Mega 2560 plus Adafruit MotoShieldv2 operating various Steppers by now. So the start was done some weeks ago. I have two different breakout boards L6470 from SparkFun which do 1/128 microstepping by hardware. The Adafruit MotorShield does microstepping by software and I implemented a small routine to calculate the angulars for getting infinite microsteps out of it if one wishes. The Adadruit stepper library does 1/8th and 1/16th when you down load it. I added 1/32th to show how easy it is to climb up the ladder. But 1/32th will do good for amateur telescopes.
MT-1 based drives have a 48 steps motor with an 1/120th gearhead which brings down the smalles moving angular of the motor to 0.07° a step. I bought a 0.9°steps stepper from Munich Motors on Ebay for less than 12, which does 0.05° running with 1/32 without a reducing gear.
The next steps, I have to repeat that, are filling my implemented gui with functionality and communicating with the motor via the Arduino/MotorShield by the computer.
With pyduino, a library that talks to firmata uploaded to the Arduino one can surpass the Mega2560 and just use the i/o ports leaving the calculations to the computers (multicore) cpu(s).
At that point the guiding camera comes in. We're in the possession of a 17 year old Apogee Ap7p which takes good image till today (see the unreduced forth image of ngc7331). A friend of mine bought a Sbig ST8300M five month ago. So using the Ap7p as guiding camera one need the computer to take very short image or a subregion of it make another one, favorable with in a tenth of a second, calculate the difference throw away the first image, change the second to be first, and pass the offset to the motors, all-in-all as fast as possible. The imaging camera has an e-/adu of 0.35 which does not allow lame guiding.
There are guiding systems on the market like LVI SmartGuider I and II or the SynGuider of Skywatcher. Celestron provides similar. They are stand-alone verion but suffer from the speed and accurateness of the integrated MCU's.
The fourth image show it quite clearly, Vixen N200S on a normal SPdx with a Vixen N130 as guiding scope and counter weight can't be tracked anymore with the highest aggressiveness chosen at the LVI SmartGuiderI. We're taling here about wind up to 20km/h which is common in spring and autum around here.
Stand-alone comes to a limit here and that's use amateur stuff!
Ok after having answered question one about if 'here' is the right place to talk about an open_hardware solution, let's move on to step two, questioning the requirements list:
- What do we need?
cheers,
Christian
Ps: The images have to be reduced in size to fit those tight and ancient requirements of the forum software, that I provide image number for at once and the others in a different post. Image ngc7331xxx is a raw fits image on a windy day in April this year. The LVI got to it's limits.
-
But let's open up a new thread for the requirements. Look here http://forum.lfep.de/index.php/topic,290.0.html (http://forum.lfep.de/index.php/topic,290.0.html)
Attached are the missing images from above.
-
I started to build an encoder based PEC with Arduino 2560 based on the idea of Orlando and he is almost finished, I think we will get this code so we catched already two birds with one song.
-
Hi Christian,
as stand-alone controller I meant a controller able to track with no PC aid. I was not referring to GoTo...
I agree with you about the GoTo capabilities that can be simply available by PC. Since guiding is a requirement that obliges to use a PC then we can ignore stand-alone GoTo capabilities...
When you spoke about "surpassing the Mega2560 and just use the i/o ports leaving the calculations to the computers (multicore) cpu(s)" were you referring to guiding calculations?
In a few word what we need is a controller that can track by itself. Ok?
CS
Armando
-
Hi Christian,
as stand-alone controller I meant a controller able to track with no PC aid. I was not referring to GoTo...
I agree with you about the GoTo capabilities that can be simply available by PC. Since guiding is a requirement that obliges to use a PC then we can ignore stand-alone GoTo capabilities...
When you spoke about "surpassing the Mega2560 and just use the i/o ports leaving the calculations to the computers (multicore) cpu(s)" were you referring to guiding calculations?
In a few word what we need is a controller that can track by itself. Ok?
CS
Armando
No, Goto was never an option, you're right, but stand-alone isn't an option to as I pointed it out.
You're right, stand-alone means a device that does control the motors without a high-level computer. Acutally a microprocessor aka MCU is a computer but on a lower level. There are plenty of similarities between a CPU and MCU. The manufacturing process, internal memory banks, bus-systems, but CPUs do have a different architecture and therefor different instruction sets.
Atmel produces microcontrollers like the Mega32 or the Mega128 or the Mega162 like AR used in the LF but that was years ago. Arduino started with a Mega162 and evolved their boards to a Mega2560. Those MCU do have frequencies about 40 Mhz. CPU's have core frequencies up to 4Ghz.
You see, all we're talking about here is speed, huge amounts of data to get really precise ans very fast movements here. We are talking about 1/10 to 1/100 arcseconds here. MCU are not capable of calculating so fast. Their bus systems are slow, too, so the calcualted signal takes time to get to the motors. Responses time is as important as calculation speed.
When I was talking about calculations above, I didn't only meant auto guiding but position changing in general. There is more to control a stepper motor than meets the eye.
Microstepping for example. To understand what where talking about you have to get the right picture. A stepper motor consists of at least to or more coils which are placed at right angles with each other. There is a magnet attached to the rotoraxis. Let's number the coil wires going from right to left and afterwards from bottom to top. If you give power to the first coil the electrons move from wire 1 to 2 generating a field which forces pushes off the magnet for a certain angle producing one step. Next power has to be given to the second coil and electron move from wire port 3 to 4 doing the same. Now the magnet turnt around so much that the fields have to be switched, the next sequence will start from wire end 4 to 3 turning the magnet and so on. This is called full step. Of course that is the easiest model of a stepper but in principal it's what happens inside. At half step mode, there is a specialty and both coils are getting powered.
For microstepping changing reference voltage is needed to do subturns.
To get the signals to the right coils in the right sequence a principal called h-bridge is used and it is available in a variety of chips. The most popular are the L293 and the L298.
The controlling technique is called pulse width modulation or short PWM. DC motors can be controlled with it to but normally PID is used to control the speed. PID stands for proportinal integral differential.
Steppers can only be controlled by PWM and that's what makes the controlling hardware so special. DC motors can be controlled by just a power source and a potentiometer because you do not have to subdivide the signal and send it to different coils.
Steppers are made for precision and max torque. That's why the are used in telescope mounts, drilling machines, 3D printers (preferable with glas scales).
I think at this point we can finish our small excourse into what's about electric motors. Now we have an equal understand and won't suffer from different definitions.
Back to topic.
So we do need at least a h-bridge but we can't attach it to a serial, parallel or usb port right away. Singals have to be prepared. That means they have to be converted from digital to analog, they possibly have to be amplified to be at use. Sometimes the power has to be limited to shield the motor coils from damage. Therefor we need peripheral hardware like capacitors, resistors, rectifiers, transistors... But that's not all there is. In principal we have to generate a PWM signal which basically is a timer.
Of course the basic parts can be done with a MCU as good as with a CPU but CPU can do that faster and twice at the same time. MCU can used to one operation at a time. Actual Intel CPU's can do up to four operation simultaneously. So one can calculate the off-sets in right ascension and declination at the same time and pass that signal at the same time to the motor.
So that makes stand-alone version slow and sluggish. That's not what we want. That's why we turned to more modern hardware and that forbids building a stand-alone version.
@lizard,
What do you think a PEC really is? For what do we will need PEC if we have auto guiding. As a matter of a fact, for auto guiding every camera can be used not only ccds but preferable.
cheers,
Christian
-
...
I think at this point we can finish our small excourse into what's about electric motors. Now we have an equal understand and won't suffer from different definitions.
...
I think to know how a stepper motor works.
Without taking into account mechanical aspects (step angle and overall reduction) tracking resolution is still related to the number of microsteps/step. Voltage PWM output with coils current feedback is what is required to make microstepping working. Appropriate IC stepper driver exist to properly move stepper motors with adequate PWM frequencies and appropriate (variable thanks to the feedback) PWM duty cycles.
Nothing else is required except the need to make the MCU asking for a ustep CW or CCW to the motor driver.
While referring to PID solution I meant to "guide" at variable speed (no more fixed usteps/s) according to the current detected tracking error.
CS
Armando
-
Yes, you're right about the deeper understanding.
About the PID we have to talk about a bit more. But let's do that when it come to implementing this module.
Since auto guiding is based on looking at the offset of a guiding star between to images, and correcting that offset right away, the speed differs because of how far the shift was. To do that as accurate as possible taking the image, downloading it from the ccd or cmos, pinpointing the center of the guiding star, measuring its x and y position and calculating the offset transferring it to µsteps and passing it to the motors, a CPU has it's advantages as I pointed out.
Normally one uses a subset of lets say 40 by 60 pixels depending on how large a pixel is and how faint the guiding star was chosen. An MCU can do that in a couple of hundred milliseconds where a CPU does that in some some milliseconds to hundred nanoseconds. All we have to ensure is to stay below 997 milliseconds because that's what is the critical time you see a result with common telescope apertures. The large a telescope is, the more accurate it has to be and what's good for the large is good for the smaller ones, too.
cheers,
Christian
-
Since auto guiding is based on looking at the offset of a guiding star between to images, and correcting that offset right away, the speed differs because of how far the shift was. To do that as accurate as possible taking the image, downloading it from the ccd or cmos, pinpointing the center of the guiding star, measuring its x and y position and calculating the offset transferring it to µsteps and passing it to the motors, a CPU has it's advantages as I pointed out.
In fact I think the controller should be compatible with current guiding software...
The PC guiding software computes the error and corresponding pulse durations on RA and Dec. But the MCU should properly manage it. Nothing new...
Normally one uses a subset of lets say 40 by 60 pixels depending on how large a pixel is and how faint the guiding star was chosen. An MCU can do that in a couple of hundred milliseconds where a CPU does that in some some milliseconds to hundred nanoseconds. All we have to ensure is to stay below 997 milliseconds because that's what is the critical time you see a result with common telescope apertures. The large a telescope is, the more accurate it has to be and what's good for the large is good for the smaller ones, too.
It's obvious a PC guiding software is required. Do you mean to implement also a new guiding software? I think it's not worth it.
CS
Armando
-
Since auto guiding is based on looking at the offset of a guiding star between to images, and correcting that offset right away, the speed differs because of how far the shift was. To do that as accurate as possible taking the image, downloading it from the ccd or cmos, pinpointing the center of the guiding star, measuring its x and y position and calculating the offset transferring it to µsteps and passing it to the motors, a CPU has it's advantages as I pointed out.
In fact I think the controller should be compatible with current guiding software...
The PC guiding software computes the error and corresponding pulse durations on RA and Dec. But the MCU should properly manage it. Nothing new...
Normally one uses a subset of lets say 40 by 60 pixels depending on how large a pixel is and how faint the guiding star was chosen. An MCU can do that in a couple of hundred milliseconds where a CPU does that in some some milliseconds to hundred nanoseconds. All we have to ensure is to stay below 997 milliseconds because that's what is the critical time you see a result with common telescope apertures. The large a telescope is, the more accurate it has to be and what's good for the large is good for the smaller ones, too.
It's obvious a PC guiding software is required. Do you mean to implement also a new guiding software? I think it's not worth it.
CS
Armando
Did you take a look at the software lately? Guide9's gui is pretty oldschool. It is infact the same look and feel as it was when it started as a DOS program. Bill Grey said, that he know C and C++ to get the algorithms right and the concepts fast, but he does not know opengl nor direct_lightning nor other graphics libraries and he does not have the time to get them to know good enough to build a modern gui. The Sky is nearly the same but it relies completely on Windows therefore forget about it's calculations they have nothing to do with realtime. If you run Guide with Windows it's the same, but you can use wine under Linux and than you have realtime and the benefits. Those two programs are nice for pointing to targets and moving the telescope but they do not support autoguiding the way it is useful. MaximDL does that for good, but it lacks the other way round, no good star map program and it's pointing is rather bad. Stellarium is a virtual planetarium with the capability to move telescopes. It claims to be as accurate as Guide9 but it isn't. What ever, it moves the telescope but has not autoguiding section. CCDobs, Nebulosity3 and all the other do control the camera but their guiding has issues and lack important parts one needs by getting all necessary images like bias frames in the first place, the do it amateur style and think that "a calibration" is what has to be done. It's like Msoft think that you need a "logical device (c:)" and the user is not capable of understanding the concept of partitions and file systems. I had a little test on all those ccd recording programs which give the user reduction capabilities and compared them to pro stuff like IRAF and MIDAS. Producing a masterbias should, if you use the same images and the same algorithm without any weighting function in it, the same result over and over again. You get that with for example IRAF and can proof it by doing so and substracting the resulting images from each other with complete black images. However I did that with MaximDL's "calibration", with images I got out from Fitswork, AstroImageJ, Nebulosity, CCDStack etc, the results were different and even if you do it ten time with one program allone, the results were different.
So much for that.
For example the Badlands Observatory in South Dokota uses old Dos software for slewing the telescope and that is common.
At my home town observatory we do the same. Our control software was written in pascal and is still a Dos program because you can't compile it for Windows. It won't run! It is specificly written for Dos. I won't compile with necessary changes on Linux either. Badlands uses MaximDL for guiding because their is no better.
Yes of course I have to write new Software because we are using new hardware. Using Arduino with shields doesn't free you from writing new Software. I don't want to develop the wheel again, but since what's on the market isn't a complete suite which gives us the opportunity to get a piece of software that is a summarization of all the good things without the lacks.
We won't start writing another ASCOM driver, because that would turn all the advantages we just pointed out in. Besides, the software should be plattform independant. So no ASCOM allowed. Building a gui with python3 and QT which runs on every OS even on smartphones and tablets is easy because of QT's designer. Implementing all the nice features within modules is easy, too and gives us the possibility to just use or provide what the telescope and the other equipment let's us do. For example, you do not need auto guiding if you just want to go visual or haven't cameras. The bare minimum can also be used as stand-alone version, but that is only optional not the main goal!
Loose yourselves from the idea that a handheld stand-alone version mirrors state of the art telescope usage. What's good for scientists is good for amateurs, too. Not only the hard- and software but methods and ways of doing things. Scientist like it easy, reliable and comfortable but not screwed up.
The telescope controls at the big observatories are very easy to use so most times, it's profound to the observer and one can do that after half an hour. What's very much more complicated is, setting up an amateur telescope for the night because hard- and software, when it's even there, is not meant to be use for such equipment.
One or two sentences to writing new software for the Arduino or in general... whether you build new closed or open hardware you need to write a new piece of software anyway. You have to implement ASCOM support, you have to write cpp code to be loaded to Arduino, that is new software!
cheers,
Christian
-
Hi Christian,
what do you think about Metaguide?
Anyway I think Qt framework is a cross-platform framework if you don't mean to communicate to specific hardware.
Try just to make use of serial COMs on Linux and XP/W7 by an unique code... Try to make use of an USB HID; then let me know...
What camera should be supported by your guiding software?
I think you meant to make a new mount controller; now I really don't know...
whether you build new closed or open hardware you need to write a new piece of software anyway. You have to implement ASCOM support, you have to write cpp code to be loaded to Arduino, that is new software!
Ok, you excluded ASCOM. So develop a new controller, a new cross-platform guiding software able to communicate to the controller on each OS. Then remember your guiding software should be able to communicate to a guiding camera. Only one? You'll have to offer support for each camera on each OS... Good work! :)
CS
Armando
-
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
-
Maybe some interesting link related to our discussion sent by Orlando:
https://github.com/TCWORLD/AstroEQ
-
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...
-
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
-
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
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.
-
Hi,
the board is also open source!
Using newer Atmels is possible if you reroute it... But I know, what you mean! But the code is interesting for every hardware!
I just wanted to give the link to get some code bits for the development!
Why invent always a new wheel?
regards,
Stefan
-
I think we will never get code,... and the current code is anyway so buggy that we will need to re-write most of the things except the standard function that are almost running ok.
So we code create a new code simply, that would be a possible solution,...
cs
-
Why invent always a new wheel?
That isn't the problem, because the algorithms, what is behind every implementation doesn't change. The problem is, that with every new piece of hardware, with every new board the implementation has to be change to get straight with it.
One solution which is used in modern computers since 2004 is something which is called acpi-handler which can talk to hardware and tell it what it has to do leaving code once written as it is, so changes in production series won't bring up the issue of changing the code.
You know that problem from the time prism-chips in network cards on windows needed up to 37 different drivers. Based on that problem the building of the acpi-handler was triggered.
All in all that's why I was looking for open hardware like arduino and stuff where you can leave the original coding as it is because the libraries of the different hardware are standards and do the trick.
Python will come in handy, too, because you can just write one implementation and be platform independent. Pyduino is really a way to go.
I think we will never get code,... and the current code is anyway so buggy that we will need to re-write most of the things except the standard function that are almost running ok.
So we code create a new code simply, that would be a possible solution,...
cs
You are right about we will never get the complete code, which isn't really neccessary anymore because the hardware itself got old and there are better ways to go. If we just port what was achieved to more modern and open hardware we just have to choose the right programming language and implement the code once because with the right selection one use parsers to transfer the code later to more modern languages in the future without having to re-implement again. That is code recycling at it's most, and I think the best way to go.
Writing special code for special closed hardware is the past.
Anotherway to go is, transfering our guiding tasks to FPGA's which won't be a solution to not having to invent the wheel again but is a solution to react on hardware and task changes very quickly and very inexpensive.
I prefer the first solution because we don't have to invent the hardware ourselves and the availability correlates with the market.
cheers
-
You are for sure right,... the hardware is old,... too old meantime,...
-
I would say, let's leave it like it is and concentrate on having a new tracking control based an open hardware and on languages which evolve with the same pace. The concepts behind each realisation didn't change since the 70ths but what was expensive by hardware those days is low-cost today and what was available and ugly in the 90ths is fine and sophisticated today.
I think the main problem will be time to implement things.
We already started a thread on what should a new version contain. Next step is to bring all the guys who want to participate up to speed with python3, pyduino, firmata, qt and maybe qpython (if one wants to have android support).
The basic stuff like running the motors in tracking speed will be short to have. The more convenient stuff like knowing where the scope is pointing at, parking position and how to slew to coordinates will take a bit ans finally having a nice gui with Guide 9's precision and stellarium's transparent look may come in to existence at the end in phase 3. We should manage such a project with a pms where every piece of work can be split up into task and everyone participating can choose his/her task without being forced to anything. Those project management systems do have links to sourceforge or are able to use version control systems like gitorious, subversion or darcs. Today we are in the comfortable position to have all these features compared with the time 15 years ago where such tools were restricted to professionals and nerds.
But we got off-topic for a bit.
The display firmware is obsolete with the new tracking control.