LittleFoot Elegance Photo > Off-Topic Discussion

Requirements for an up to date trackings system

<< < (2/3) > >>

the_lizardking:
Its long time that we discussed here on the forum about a new controller. Maybe you missunderstod me in my first statement Astro - so I would like to refine it. For me a display would be optional but should be possible - the logic must be made on the Handpad then not on the controller but there must be at least an interface for it. I ment only the GoTo command by chosing an object not the logic behind as well as I agree that smartphone would also be my first choice. And to be honest we both know there are lightsensors and Oled Displays out on the market that can be supported and having low power consumtion... so I think we lose us here in details or polemic a bit.

I would have a vision that we get the ASCOM driver more than only LFEP compatible with a bit more looking into future for having a new controller now. I totally agree with you guys that we should work more and more on the PC and only push outputs to the controller, However controller should have data stored when switching the PC or whatever using another humian interface device like smartphone during observing and should do work for controlling the motors. Also independ (PC gets lost or whatever).

So my idea would be also to have PC driver that can fit all needs a Handbox does, including Polar Alignment calculation with 2 or 3 stars, autocalculating drifts and compensate bad alignment in the next step. And after this we should be able to make also PEC as well as KingRate over this driver ignoring the Handbox. We should get rid off these old buggy old LFEP stuff focusing on a new controller that does not use a Handbox to speed up developement and have time to work on encoder solutions and so on. Like ASA did,...

Everybody uses a PC today even when a handbox is available,... the Handbox is only used to make fast correction during observing or to make better positioning when the GoTo is worst,... So a handbox havin speed and directionbuttons is the only thing you need normaly. Having a WEB Cam on the controller or these bullshits nobody uses does not make sense, I agree. The most important things a controller must have is on the Hardware side:

- Good Motormanagement (means logic with stall technologie, precise with big tables, fast with different full stepp and micro stepp options, sinus ramp and linear ramping, auto offset calculation,...)
- Encoder Interface that acts fast and precise without stopping the processor + option to have analog and digital encoders (TTL or Sin/Cos - as you cant get 1,2 Mio tick TTL on the market)
- Weather interface that alows to have air pressure, moisture and temperatur (King Rate calculation not from a table, by weather and switching heater as well as focus)
- ST-4 Interface (needed and should be possible to crossover with ASCOM commands in rela time by the processor)
- Real USB HOST coomunication
- Two or 3 stable 5V signals for relais to have heater and roof (+smth BUT not bullshit Filterwheel as it mostly integrated in cameras or has to be served extra anyhow)
- I2C interface for cloud sensor or whatever the people want to have
- Robofocus not over LX but over the real Robofocus protcoll
- LAN with all in one solution like Lantronix as an option if someone wants to have it, best would be to include simply a wireless LAN on board
- USB Host HUB to LAN solution for those who want to go over LAN only an connect cameras and so on on the controller having data sent over LAN to a PC (I did not find any vendor here, Lantronix has nothing but there are stand alone solutions out in the market that work --> see this article: http://www.eetasia.com/ART_8800587767_1034362_NP_dcaf2e2a.HTM) as an option of course
- A very simple handbox for those who have no mobile cellphone or ipad or PC as an option
- Timer for DSLR as option if someone wants it

All option are lower priority from my point of view and could be integrated later on.

On the Software driver side:
- 2 or 3 Star Polar Alignment with drift calculation with possibilty to run it more than one time having first a physical setting and/or logical calculation of the software compensating drifts
- Autobacklash compensation using stalling technologie on startup
- logical PEC (idea based on intelly track) or Drift Compensation over ASCOM as we have (for those that dont have Encoders) - fuck the old PEC that nobody uses!
- Encoder based PE correction with encoder settings calculated automatic by making a testdrive 180° (so we can make antiswashing and count ticks)
- Flip and positioning management
- Motor Management to configure motor settings and tables and speeds up to 2048x possible even when not needed, micro an dfullstep free programable, programable Microsteptable
- Location and Time settings
- Parking function having more than one positions
- Programmable and Nameable Pullup configuration, switching heater and roof in certain situations (like dewpoint reached switch heating, or scope unparked open roof)
- Robofucs controll having possibility to store positions for different observing tools like Cameras different filters and temp compensation and backlash with a good stalling motorcomtroller + caliper
- Backlash compensation, should be calculated during Polar Alignment routine using the stalling option of the motor controller
- Scope movement control with directionbuttons and speeds
- King Rate using the weather interface to calculate sphearical aberation and NOT using a shity table
- Roof management
- Fully ASCOM compatible (even when many dont like it but it works and is the standard)
- Tracking speed User, Siderial, Solar, Lunar --> to the controller side we only have one speed which is free programmable
- LAN configuration
- Backup routine (power controll) that stores all information permanent on the controller having him parked and aligned, encoder ready when powering up waiting to get a PC connection

No old PEC as it is not needed anymore,... no Handbox as it is shit in modern world with smartphones (by the way you can make GoTo commands from there),... no other shit stored on any mem card or eats processor time on the controller and that nobody is using or only a few having big service impact for nothing that cant be done on a pc easier and fast (you see I agree)... the controller should controll the motion and nothing else but this should be done in the most possible precise way.

So what I see is that we would need to work on the ASCOM driver we have on one hand (most of the things are there) to make him running all above software features now and leave LFEP behind us now! The existing driver is good enough for those who want to stay with LFEP. We should concentrate getting the existing things from LFEP Handbox to the PC and ignore the Handbox fully.
From my point the logical steps will be:
- making flip positioning (if it isnt done already)
- making Polar Alignment (storing calculation somewhere for future use and/or correct direct over the driver including drif compensation)
- making KingRate (calculated like above when hardware (presure, temp, mositure) not available using tables as a backup)
- making logical PEC (stored calculation on PC making correction over driver)
- making tracking (use only LFEP User Rate make the rest on the PC - new controller will anyhow have only a sent rate from PC)

Start to add behind:
- Encoder management
- Motor management
- Backlash management
- Programmable pullups for Heater and roof
- redo Robofocus management
- Recap and throw LFEP Handbox totaly out there

Then we would have a fully independet Driver that can be used for any controller which is ASCOM compatible and are fit for new hardware.

And then we should focus on the Hardware on the other hand having from my point Trinamic motion conroller using the following solutions:
- Trinamic TMC457 Motorcontroller including stalling and tabeling as well as encoder interface
- Trinamic TMC249 Motordriver for Mount and TMC260 for Focus (both also include stalling technology)
- Co Prozessor ATMega32 for analog encoder interpolation, output is a TTL signal to TMC457 switchable from Sin/cos to real TTL, if someone really finds a TTL with 1,2Mio ticks
- Processor ATxmega256A3U 32Bit main processor USB HOST Interface included
- Lantronix PremierWave EN and Lantronix XPort Pro (I dont see your fear on Wlan, if you think you dont need to deal with connection loss you are simply wrong anyhow I think)
- tbd USB Host HUB to LAN controller
- 1 or 2Mb shared RAM
- tbd different sensors needed (airpressure, moisture, temperatur)
- tbd switchingregulators (NO Power regulators) as they produce no heat at all and are more precise - so we get more flexible on pwoersupply side
- tbd power quard buffered for storing all informations in case of power loss
- tbd small flash memory for having stored last data in case of power loss
- tbd clock with battery

The design shematic is a module design looking like this from my point:
- Baseborad including sensors, power regulation, all connectors and RAM (two layer)
- Mainboard having the XMega housed as well as clock and flash buffer (two layer)
- Encoder Board having the ATMega housed (two layer)
- Two Motorboards with the motorcontroller and driver (must be 4 or 5 layer)
- One focusboard housing the driver (two layer)
- Lantronix board (5 layer ready to use out of the box)
- tbd USB Host HUB to LAN controller board

Logical communication:
- Controller starts up restoring mem from flash making balcklash check and encoder check, recalculates and then waiting in parked last position for the HUD.
- HUD connects gets data from controller and waits for user decision in parked position.
- User make changes or agrees and driver sends actualized information to Controller.
- Controller starts work and sends statuschanges to HUD to be reviewed or changed.
- Or HUD send changes done by software or user
- connection loss controller wait for reconnection and works with actual data and information.
- Power off all actual data and information stored on the controller.

From my point KingRate and backlash must be done on the comtroller like the encoder checks as well as the stored PE correction. PE correction should be able to be trained from Encoder, ST4 or ASCOM, Encoder can have a permanent impact or automatic refine on the PE table. Drifts and speed settings should be calculated on the PC and sent as a "User Rate" to the controller. Guide corrections should be possible from any location (Encoder, ASCOM, ST4, Motor controller) at the same time, controller sends back status after commands are performed, commands must have a kind of timestamp. However the system should work with and without encoders, we should not book on the encoders as from my expierence 80% of the members will never find one or will not be able to make the needed mounting solution precise enough. This is the reason why we need some kind of new PEC, however in this way the controller can also run independed in case of connection loss to HUD.

So this I wanted to add to my former input to make things more clear and for offering a possible new start and input here. I hope we will get a new discussion running now,... but this is only a rough proposal so take it as a basis to define what we talk about, hopefully enough precise so that we can skip the zionism at this point.

Clear skies
The King

PS: tdb = to be defined

the_lizardking:
Some expirience from my small world,... guidng speed is different to each mount,... there is different guiding you can use with direct drives or belts also some montes like to swing cant get higher guiding pulse than 0,33x,... so it should be configurable at least otherwide it will make no sense.

I know out of tests with TDM that shows that faster or longer impulses get mounts to swing very hard,... you even can let them dance! And permanent changing speed may affect a very strange rythm then :)




--- Quote from: Astroquattro on Wednesday, 18.09.13 - 23:53:16 - CEST ---
--- Quote from: Armando on Wednesday, 18.09.13 - 18:36:43 - CEST ---Hi Christian,

what I would suggest now is to overcome the outdated FIXED guiding speeds...
Calibration could be made as always (at fixed guiding speed) but then the controller should be able to switch to PID mode. The MCU should compute (according to the guiding pulse duration) the corresponding tracking error and manage it by its own to be as quicker as possible...

CS
Armando

--- End quote ---

As will have aut guiding there won't be any fixed guiding speeds but there will be accurate tracking based on siderial time where 1 second is equal to 997,269541667 milliseconds and not to 1000 which an MCU isn't capable off, too.
What's you definition of PID in this context? As we use auto guiding and a computer instead of a stand-alone version, we will be better, faster, more precise... as possible as physics laws allow. That is the point, we have to use a CPU NOT a MCU.

--- End quote ---

jfinner:
Motoren die im "Closed Loop" laufen sorgen für mehr Drehzahl und weniger Resonanzen

the_lizardking:
Naja ich denke das dancing kommt weniger von den Motoren als von den Montierung, Getriebe bzw. im Falle des Belts von diesen Komponenten. Man kann die Tolleranz der Montierungen mit dem TDM recht gut testen,... erhöht man den guiding speed fängt meine G11 bei 2x an wie ein Discostar,... bei einem Belt auf der G11 beginnt das dancing schon be 1x bzw. 1,33x. DEr TDM macht bis zu 5 Korrekturen pro Sekunde,... beim guiden wirst du auf diesen Wert nicht kommen, aber die Korrekturen werden noch größer, dh. die Masse hat mehr Schwung,... ich denke da wird es noch schneller dazu kommen.

Der Motor ist weniger das Problem, wenn wir den sboost schalten setzt er einen Offset, dh die Spule ist unter Strom und entsprechend dem Magnetfeld starr,... das ist glaube ich ähnlich was du mienst mit dem closed loop,... oder??

jfinner:
Was ich meine ist : Auszug Nanotec: Das Closed-Loop-Verfahren wird auch als Sinuskommutierung über Encoder mit feldorientierter Regelung bezeichnet. Kern der Closed Loop Technologie ist die leistungsangepasste Stromregelung sowie die Rückführung der Steuerungssignale. Über die Signale des Encoders wird die Rotorlage erfasst und es werden in den Motorwicklungen sinusförmige Phasenströme erzeugt. Durch die Vektorregelung des Magnetsfelds ist gewährleistet, dass das Statormagnetfeld immer senkrecht zum Rotormagnetfeld steht und die Feldstärke genau dem gewünschten Drehmoment entspricht. Der in den Wicklungen so gesteuerte Strom sorgt für eine gleichmäßige Motorkraft und führt so zu einem besonders ruhig laufenden Motor, der sich genau regeln lässt.
Den Unterschied kann man sich auf Youtube unter http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=video&cd=1&cad=rja&uact=8&ved=0CE4QtwIwAA&url=http%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DSjHSMpQDEQs&ei=TMZbU-nYNYnVtAbzx4DwBA&usg=AFQjCNFbyiO46LQP_xDcOA_oI-IV8sHyTA&bvm=bv.65397613,d.Yms ansehen. Die vom Schrittmotor erzeugten Schwingungen könne sehr wohl zu Problemen führen wen sich die Frequenz in Resonanz zur Montierung ist und sich aufschwingt.

Navigation

[0] Message Index

[#] Next page

[*] Previous page