What does the command line command LSUSB (lowercase) produce when all your hardware is connected - doesn't have to be running any software just powered on.
Look thru the "system" logs - filter errors which have anything to do with USB - does anything stand out?
Just to add that many Ard Nano are clones which use CH340G /Prolific and other cheap chips which all have the same problem - They do not have a unique serial number so if you have 2 or more chips of the same type it is impossible (other than position) to write Udev rules for such devices. You can see this if you do a lsusb
. However as Eric has said this is something "not for the faint hearted" and i would suggest you the changes on a copy of your SD card (or take a backup first) and takes a little time to get your head around. Of course after doing the "udev by position" you will ALWAYS have to plug the device into the same port/hub.
Simpler way,if this is the problem, buy an genuine FDTI chiped device that has a unique serial number - for the Ard Nano the code will of course not need to be altered but most likely you will need the Autoreset /cap trick - I did and the problem went totally away
Glad you getting there
As to the failed solve when in object is in full view - I too get this now and again but I also have had this with Platesolve2 and ASPS on Windows - never got the bottom of the problem but put it down to changing "Sky quality" (improved - so too many stars = timeout or deteriatored sky since previous image) .
I have already stated I use CCDCIEL which allows automatic Platesolving backup (use ASTAP first but if it fails it uses Astrometry version to retry platesolvong on that image) so its not a major problem for me and this process works well for me especially on a Sequencer type run.
But without sending images to someone like Han it would be unfair to say what the problem was (me or the software) and impossible for a developer to solve
I guess thats why ASTAP now has the "slow" solve tick box. This is because, IMO , local Astrometry versions(Linux,Windows orothers OS) solve 99% of the time but are generally a lot slower on the same type of hardware. Whereas ASTAP and the like "cut corners" (sorry could think of a better phrase ) to improve speed - the later comment is not a critisim and I accept the fact "faster" this could be less reliable (even says this in the manual and on screen) - "swings and roundabouts"
Clear skies and reliable platesolving
Never used the flats as part of platesolving so I just ignore the "warning" and use it normally.
I would suggest you send some of the images to Han and see what he makes of it - he is the expert as the author.
Once you have the basic settings correct ASATP works 95% of the time and very very fast. Luckily I use CCDCIEL which enables me to automatically switch to another platesolver during the platesolving phase. This I do in live mode and using the excellent Sequencer that CCDCIEL provides - so its simple ,quick ,effective and 99.99% fool proof - subject to sky quality of course. I hardly ever have to change anything except when I change harwdare, which is only to be expected.
In the end,rightly,you go with the process that you feel happiest with and suits you .
like ALL platesolving having the correct parameters help.
If you have trouble start ASTAP as stand alone and load the image.
Click the "stack" menu so the Stack window appears.
Choose Alignment tab is not already selected.
Set the correct FOV height - it should set this automatically after a sucessful solve - if not or its not working use Astrometry.net upload to get the correct value or set Auto (but this takes a long time first time)
Use the Down sampling and Max stars to maximise speed but setting a too small a value will cause Platesolving to fail on occasions. suggest default 500 stars and auto for first run - but it will change depending on the image - as with ALL Platesolving
Tick "calibrate prior solving" - this will help with "noisey" images
Obviously "blind solving" will take longer so for testing set the RA,dec of the object so that platesolving is "near" not "blind" - do this via the RA/Dec on the first Window by double clicking the mouse in either Dec or RA area. And yes I didn't know what the signs were - Come on Hans it should be for all not just experts in Greek
As you can see times vary but it can vbe very fast 2.3 secs to 106+ for blind solving - on my example I used m81 via double click object name for M31 and it rook 106secs on images that were not great.
If all else fails post image to Hans he will help after reading the manual - which of course we all read dont we LOL
ASTAP is the only Platesolver,I know of, to work across the board natively on Windows,Linux and MacOS and doesn't require index's to be loaded per FOV.
But I admit it can be "fussy" - but the latest version can do "slow" plateslving (tick box) for most images that it didm't solve before.
64bit Raspbian beta released too!
Note hardware layout changes - "which doesn't effect anything" - Famous last words - perhaps the USB3/Wifi etc is finally sorted on these boards. Just have to see what the new ones are if any. £24 extra for 4gb isn't that bad !
Cant say I am expecting much improvement until software catches up!
Should also mean 64bit Raspbian is released !
Scottish been around 20+yrs
Alternative to waiting for Sky Watcher prodcuct and as long as you trust the pin outs (which are 99% ok) then you could just but a ready made EQMOD ( name is irrelant in this case it should work with anything) like this $12 inc del to USA
and just splice the mount end and put you own connector wired to the correct pin outs. The spec for EQMOD (e.g. AZEQ6GT) wiring is online on EQMOD so just a case of making sure you have connected to your new pin outs. Plus you of course can get the same cable in the USA
anyway I presume so only a couple of days waiting for delivery!
The SW product is, I am told, a Prolific Chip device where as the above is an FTDI which means no clash on USB ports (FTDI have a unique serial number) an in Linux Udev can be used to make that device a perm mount connection with appropriate name in /dev.
"The AZ-GTI driver was already mentioned in this thread." - yes I know (KNRO * 2,me once) ) but your answer was unclear if you had tried it or not Yes you did say about some annoying bits of Alt-GTI which seems to imply you have but I wasn't clear.
Plus the AZ-GTI is going to be nearer what you are looking for than Synscan or EQMOD especially if you are going to write a "new" Indi driver .
Just saying Last time promise
Just remembered this on SGL -
- no coding involved
Silly question but have you tried the AZ-GTI device which has Wifi support built in and as its based on the EQMOD which will talk to MOST SW mount motors directly so is using the corrent "SW protocol" already. If nothing else its not a bad place to start looking at the coding
Forgive me in saying SW aren't going to create new boards/motor protocols for the newer GoTo Dobs as it doesn't make commercial sense - IMHO.
If nothing else no wiring (get it wrong and its bye bye board - e.g. 12v onto 3.3v = bang) - and do not trust wiring colours (color) - I have found that they dont match across the same cables - the pins do so follow the pin outs IMO.
But if you love "fiddling" thats great and good luck