Chris Rowland replied to the topic 'Bluetooth connection to mount' in the forum. 2 hours 15 minutes ago

Found indiweb was installed.

Astroberry seems to start a WiFi hotspot almost unconditionally and it was a bit of a struggle to stop it because the display was forced to a size that was bigger than my monitor so couldn't see the toolbar very well. I wouldn't use the Zero as a hotspot because it seems a lot to ask of a slow computer.

I see that it is running ModemManager, possibly three times. That explains why people were fussing so much about that. AIUI AstroPi3 removes it.

There doesn't seem to be any way to update indi to the nightly builds, trying gave me this:

astroberry@astroberry:~ $ sudo apt-add-repository ppa:mutlaqja/indinightly
Traceback (most recent call last):
File "/usr/bin/apt-add-repository", line 95, in <module>
sp = SoftwareProperties(options=options)
File "/usr/lib/python3/dist-packages/softwareproperties/SoftwareProperties.py", line 109, in __init__
self.reload_sourceslist()
File "/usr/lib/python3/dist-packages/softwareproperties/SoftwareProperties.py", line 599, in reload_sourceslist
self.distro.get_sources(self.sourceslist)
File "/usr/lib/python3/dist-packages/aptsources/distro.py", line 93, in get_sources
(self.id, self.codename))
aptsources.distro.NoDistroTemplateException: Error: could not find a distribution template for Raspbian/buster
astroberry@astroberry:~ $

Read More...

Chris Rowland replied to the topic 'Bluetooth connection to mount' in the forum. 11 hours 39 minutes ago

Thanks for the information on AstroBerry. I had gone to its git page and saw that it said
"Support for Raspberry Pi 3 and 4" as the first item and didn't pursue it any further. The Pi zero uses a different ARM

As you say you can switch between CLI and GUI easily.

Incidentally using ssh then changing to a different SD image and using ssh again generates a very alarming message about a man in the middle attack.
Deleting the .ssh\known_hosts file on my PC cleared that.

I'm running on my home broadband Wifi router with everything connect to that. It works over the distances I need. If I'm in the field I will set up my phone as a hot spot, assuming the phone can get a signal that gives me the internet - in particular a source of time.

BTW does AstroBerry start the indi-web server automatically?

Read More...

Chris Rowland replied to the topic 'Bluetooth connection to mount' in the forum. yesterday

AstroNerd wrote: You need to make sure modemmanager is un Installed before BT will work reliably, mine works flawlessly on later SM version....if you haven’t already done so that is.. :)

Yes of course. AstroPi3 does this as part of it's set up.

It's pretty clear that BT is fragile on the Pi, as part of this I found the Windows 10 IOT build for the Pi3 and this says there are problems with the hardware and they don't support it. I can understand this, it's not possible to do a good job if the underlying system can't support it.

Read More...

Chris Rowland replied to the topic 'Bluetooth connection to mount' in the forum. yesterday

stash wrote: Another solution or 2 to the "hacking script" is to just use Astroberry v2 - still slow with GUI/Desktop - but then run RASPI-CONFIG and set BOOT to CLI .

This is essentially what I ended up with. I started with a full fat Raspbian install and installed the bits of AstroPi3 that I needed, in particular Indi and indi-web.
Followed the instructions to run it as start up.
Once it was all going I set the Config to CLI.

Was able to configure it using indi-web from any browser and set indi server to start at connect.

Then connect from Ekos using the remote setup - Celestron This email address is being protected from spambots. You need JavaScript enabled to view it.

What I found was that the full fat install took about 50% CPU just idling while booting as CLI took about 6% for everything.

I'm new to this so started with a desktop but it may be better to install a headless version of Raspbian and run through the command line exclusively.

Astroberry requires a Pi 3. I'm using a Pi zero so will have to build from sources. Starting from the Raspbian install and the Astropi3 Raspbian script worked well for me particularly as I've never used AstroBerry.

Read More...

Chris Rowland replied to the topic 'Bluetooth connection to mount' in the forum. yesterday

About two feet (60 cm).

Read More...

Chris Rowland replied to the topic 'Scheduler/Capture keeps resetting to the start' in the forum. yesterday

Just checked, I do have "Remember Job Progress" checked.

I understand entirely about how complex this is. Part of my former day job was as a member of the team developing automation software for a microanalysis system. It was all very similar except that we were looking at the very small, not the very large, and were using an electron microscope, not a telescope.

Read More...

Chris Rowland replied to the topic 'Bluetooth connection to mount' in the forum. yesterday

I think I've got this sorted. I've been running for the last day with no errors or hang ups from my wireless connection to the mount.

The solution was to abandon Bluetooth entirely and use WiFi.
I now have a Pi zero loaded with Indi and the indi-web server set to start at startup. I connect to it with a remote connection. The scope is connected through USB using a FTDI adaptor.
And It Just Works! Sometims the way to succeed is to change the game. Kudos to the INDI team, it was all a lot easier than struggling with BT.

Setting up the Pi Zero was tedious because it's so slow but hacking the AstroPi3 RaspbianPi script to remove the Ekos stuff gave a good basis for getting it going. The rational way is to run headless. That's for another thread.

Chris

Read More...

You are right Wolfgang, the meridian flip slew move does not involve a meridian flip. It's possible that the flip has already happened, or that a guide command has blocked it.

The initial position is set here:
[2019-12-07T19:31:42.381 EST DEBG ][ org.kde.kstars.indi] - ISD:Telescope sending coords RA: "00h 43m 49s" ( 0.730369 ) DE: " 41° 22' 45\"" ( 41.3794 )
The mount calculates the slew delta and sends commands:
[2019-12-07T19:31:42.484 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[DEBUG] SlewTo() : deltaRA = 2537643 deltaDE = -1218500 "
[2019-12-07T19:31:42.485 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[MOUNT] SetMotion() : Axis = 1 -- dir=forward mode=goto speedmode=highspeed "
...
[2019-12-07T19:31:42.572 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[MOUNT] SetMotion() : Axis = 2 -- dir=backward mode=goto speedmode=highspeed "
This is a fairly large slew and so the motors are commanded to run at high speed.
The slew is completed with a low speed run:
[2019-12-07T19:32:26.249 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[DEBUG] IsRARunning() = false "
[2019-12-07T19:32:26.250 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[SCOPE] CheckMotorStatus() : Axis = 2 "
[2019-12-07T19:32:26.250 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[DEBUG] IsDERunning() = false "
[2019-12-07T19:32:26.259 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[DEBUG] SlewTo() : deltaRA = 4588 deltaDE = 0 "
[2019-12-07T19:32:26.259 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[MOUNT] SetMotion() : Axis = 1 -- dir=forward mode=goto speedmode=lowspeed "
And tracking is started:
[2019-12-07T19:32:28.445 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[DEBUG] IsRARunning() = false "
[2019-12-07T19:32:28.445 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[SCOPE] CheckMotorStatus() : Axis = 2 "
[2019-12-07T19:32:28.445 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[DEBUG] IsDERunning() = false "
[2019-12-07T19:32:28.451 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[MOUNT] ResetMotions() "
[2019-12-07T19:32:28.451 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[SCOPE] CheckMotorStatus() : Axis = 1 "
[2019-12-07T19:32:28.452 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] dispatch_command: \":G110\", 6 bytes written "
[2019-12-07T19:32:28.452 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read_eqmod: \"=\", 2 bytes read "
[2019-12-07T19:32:28.452 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[SCOPE] CheckMotorStatus() : Axis = 2 "
[2019-12-07T19:32:28.452 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] dispatch_command: \":G211\", 6 bytes written "
[2019-12-07T19:32:28.452 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read_eqmod: \"=\", 2 bytes read "
[2019-12-07T19:32:28.453 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[DEBUG] StartRATracking() : trackspeed = 15.0411 arcsecs/s, computed rate = 1 "
Then there's a sync:
[2019-12-07T19:33:46.563 EST DEBG ][ org.kde.kstars.indi] - ISD:Telescope: Syncing...
[2019-12-07T19:33:46.571 EST DEBG ][ org.kde.kstars.indi] - ISD:Telescope sending coords RA: "23h 51m 07s" ( 23.8521 ) DE: " 41° 22' 05\"" ( 41.3681 )
[2019-12-07T19:33:46.816 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] dispatch_command: \":j1\", 4 bytes written "
[2019-12-07T19:33:46.816 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read_eqmod: \"=A8C4A1\", 8 bytes read "
[2019-12-07T19:33:46.817 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[SCOPE] GetRAEncoder() = 10601640 "
[2019-12-07T19:33:46.817 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] dispatch_command: \":j2\", 4 bytes written "
[2019-12-07T19:33:46.817 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read_eqmod: \"=BCD38F\", 8 bytes read "
[2019-12-07T19:33:46.833 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[ALIGNMENT] New sync point Date 2458825.523439 RA 23.852100 DEC 41.368100 TDV(x 0.750013 y 0.022445 z 0.661042) "
...
[2019-12-07T19:33:46.846 EST DEBG ][ org.kde.kstars.indi] - ISD:Telescope sending coords RA: "00h 43m 51s" ( 0.731074 ) DE: " 41° 22' 45\"" ( 41.3794 )
And a slew, high speed in RA
[2019-12-07T19:33:46.959 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[DEBUG] SlewTo() : deltaRA = -330415 deltaDE = 283 "
[2019-12-07T19:33:46.959 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[MOUNT] SetMotion() : Axis = 1 -- dir=backward mode=goto speedmode=highspeed "
Then a slow slew:
[2019-12-07T19:33:57.678 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[DEBUG] IsRARunning() = false "
[2019-12-07T19:33:57.679 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[SCOPE] CheckMotorStatus() : Axis = 2 "
[2019-12-07T19:33:57.679 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[DEBUG] IsDERunning() = false "
[2019-12-07T19:33:57.689 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[DEBUG] SlewTo() : deltaRA = 1046 deltaDE = 0 "
[2019-12-07T19:33:57.689 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[MOUNT] SetMotion() : Axis = 1 -- dir=forward mode=goto speedmode=lowspeed "

There are a series of slow slews through small amounts that I guess are guiding.

Now the meridian flip 'slew'.
[2019-12-07T19:41:16.084 EST DEBG ][ org.kde.kstars.ekos.mount] - Meridian flip planned with LST= "00h 44m 31s" scope RA= "00h 43m 54s" and meridian diff= 0.01
[2019-12-07T19:41:16.084 EST DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to 1
[2019-12-07T19:41:16.701 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[SCOPE] Compute local time: lst=0.74219640 ( 0:44:31.91) - julian date=2458825.52864834 "
[2019-12-07T19:41:16.701 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] dispatch_command: \":j1\", 4 bytes written "
[2019-12-07T19:41:16.713 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read_eqmod: \"=F46F9D\", 8 bytes read "
[2019-12-07T19:41:16.714 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[SCOPE] GetRAEncoder() = 10317812 "
[2019-12-07T19:41:16.714 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] dispatch_command: \":j2\", 4 bytes written "
[2019-12-07T19:41:16.728 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read_eqmod: \"=51D98F\", 8 bytes read "
[2019-12-07T19:41:16.728 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[SCOPE] Current encoders RA=10317812 DE=9427281 "
[2019-12-07T19:41:16.729 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] dispatch_command: \":f1\", 4 bytes written "
[2019-12-07T19:41:16.754 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read_eqmod: \"=111\", 5 bytes read "
[2019-12-07T19:41:16.754 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] dispatch_command: \":f2\", 4 bytes written "
[2019-12-07T19:41:16.754 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read_eqmod: \"=101\", 5 bytes read "
[2019-12-07T19:41:17.084 EST DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to 4
[2019-12-07T19:41:17.084 EST DEBG ][ org.kde.kstars.ekos.mount] - Slewing to RA= "00h 43m 52s" DEC= " 41° 22' 45\""
[2019-12-07T19:41:17.094 EST DEBG ][ org.kde.kstars.indi] - ISD:Telescope sending coords RA: "00h 43m 52s" ( 0.731238 ) DE: " 41° 22' 45\"" ( 41.3794 )
[2019-12-07T19:41:17.179 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[DEBUG] StopRA() : calling RA StopWaitMotor "
[2019-12-07T19:41:17.179 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] dispatch_command: \":f1\", 4 bytes written "
[2019-12-07T19:41:17.186 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read_eqmod: \"=111\", 5 bytes read "
[2019-12-07T19:41:17.186 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[MOUNT] StopWaitMotor() : Axis = 1 "
[2019-12-07T19:41:17.186 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] dispatch_command: \":K1\", 4 bytes written "
[2019-12-07T19:41:17.187 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read_eqmod: \"=\", 2 bytes read "
[2019-12-07T19:41:17.187 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] dispatch_command: \":f1\", 4 bytes written "
[2019-12-07T19:41:17.187 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read_eqmod: \"=101\", 5 bytes read "
[2019-12-07T19:41:17.187 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[DEBUG] StopDE() : calling DE StopWaitMotor "
[2019-12-07T19:41:17.187 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] dispatch_command: \":f2\", 4 bytes written "
[2019-12-07T19:41:17.187 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read_eqmod: \"=101\", 5 bytes read "
[2019-12-07T19:41:17.188 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[MOUNT] StopWaitMotor() : Axis = 2 "
[2019-12-07T19:41:17.188 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] dispatch_command: \":K2\", 4 bytes written "
[2019-12-07T19:41:17.200 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read_eqmod: \"=\", 2 bytes read "
[2019-12-07T19:41:17.200 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] dispatch_command: \":f2\", 4 bytes written "
[2019-12-07T19:41:17.202 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read_eqmod: \"=101\", 5 bytes read "
[2019-12-07T19:41:17.211 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[DEBUG] SlewTo() : deltaRA = 274 deltaDE = 0 "
[2019-12-07T19:41:17.212 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[MOUNT] SetMotion() : Axis = 1 -- dir=forward mode=goto speedmode=lowspeed "

The movement is very small and is low speed only, a little later tracking is started.
And after that the log stops.

One possibility is that the meridian slew has already happened. The slew at 19:31:42 is a long one in both Ra and Dec.
As for the pier side, I woud expect that there would be more in the log about it there is very litte data other than raw data.

If someone who is more familiar with this driver might be able to get more out of the logs, in particular converting the raw axis positions to hour angle and declination to see if the flip is still needed.

Chris

Read More...

My theory is that a command is being sent to the mount which halts the slew. A log file showing the mount communication would show if this is happening.
The source of the command could be guiding or aligning. If the guiding module has not halted - or a guide function is still running when the flip starts - then the guide command could interfere with the slew that's in progress.
Similarly with alignment, there could be a sync command that is halting the slew.

@Aurneth suggests that a previous align at any time prevents the meridian flip. That's a puzzle but maybe it changes the mount state in some way. Again the mount log will show if the slew should do a meridian flip or not from the actual axis positions.

@Aurneth, log files compress very well, down to 5 to 10% of their original size.

Chris

Read More...

Chris Rowland replied to the topic 'Meridian flip interrupted on EQMOD mount - Alignment Module?' in the forum. 2 days ago

I've got a couple of ideas what could be happening. It needs verbose logging the mount driver to see exactly what commands are being sent to the mount and logging of the guider and align modules to see what they are getting up to.

If I'm right it's unlikely to happen with simulators because it needs real data. It also explains why tests when it's cloudy don't fail.

Read More...

Chris Rowland replied to the topic 'scheduler does not remember job progress' in the forum. 2 days ago

I reported something similat two days ago and got no reponse at all.

For me it seemed to be that the sheduler started from the beginning after some sort of failure.

I've tried to look through the log but I don't know what I'm looking for. It also has verbose logging on for the EQMOD and maybe other INDI components, this makes it large and the relevant material will be difficult to find. Somebody who is more familiar with the scheduler may have a better idea of what to look for.

Chris

Read More...

Chris Rowland replied to the topic 'Meridian flip interrupted on EQMOD mount - Alignment Module?' in the forum. 4 days ago

It looks as if we've got all out of those logs that we can. As you say, in your Scenario 2 the meridian flip slew takes 3 seconds which is far too short. Either the slew is being commanded before the meridian has been reached from the mount's POV or something has stopped the slew.

Finding out what is going on from the mount side is vital so enabling the INDI logging should help. Set all the options, select log to file and look in ~/.indi/logs. The driver log will show something useful. Maybe something is stopping the slew early.

The ASCOM specifiction has to work round the same issues and in addition to the SideOfPier property has a DestinationSideOfPier(rightAscension, declination) method which reports the pier side that the mount will be on if a slew to the destination coordinates is started. This would give the client a chance to decide what is likely to work. When a plip is required the client checks the DestinationSideOfPier and only starts the meridian flip process when it is different to the current pier side.

With a mount that reports pier side, which eqmod does, Ekos should be able to check, see that the pier side is still West, and leave the pier side required flag set so it tries again after another acquire.

Read More...

Chris Rowland created a new topic ' Sheduller/Cupture keeps resetting to the start' in the forum. 5 days ago

I'm trying to run a shedule and it keeps resetting to the start. What seems to be happening is that the capture module has a guide limit set and when that is exceeded not only is capture paused but the entire capture shedule is reset to the start. As a result I've got 65 frames of the first 20 and no progress past that.

I would expect that the guiding error would pause and resume capture unti the guide accuracy was reduced, or even the last frame was discarded, but it's not doing that. It seems to be restarting the whole sequence. I'm not sure if it will be the entire thing or just the set of frames, it hasn't got beyond the first set of frames.

It seems a bit extreme to keep restarting the sequence, is there a way to do what I would expect, to pause until things are OK, then continue?

Chris

Read More...

Chris Rowland replied to the topic 'Bluetooth connection to mount' in the forum. 5 days ago

Every time I post saying i seems to be workig it falls over, in this case while I was sending that last message.

I'm beginning to wonder if it's a range issue, it's easy for the two devices not to be abe to see each other, even though they are no more than a metre apart. I've adjusted things so the RasPi and the BT device are about half a metre apart and with no metal between them.

If that doesn't work maybe I'll try running the mount from a second Pi using the WiFi connection, that seems to be reliable. Perhaps a Pi Zero running an INDI server with the mount driver and nothing else.

Read More...

Chris Rowland replied to the topic 'Bluetooth connection to mount' in the forum. 6 days ago

Something my father said was "If you are in hle the first thing is to stop digging."
So I took a step back and started again, building a new version, based on Mate 18.4, the current AstroPi3, and ASTAP. I was getting communication failures until I appriled the updates mentioned earlier in this thread, then it was fine, except for an occasional communication timeout.

This wasn't helped by cloud but aligning and guiding worked in spite of that - then the clouds cleared and I got this.



No darks or flats, just 10x30 sec stacked with ASTAP Live.

It's a start.

Chris.

Read More...