1003 replies to this topic

[decep]

I rebuilt as suggested, and the results were the same. On the off-chance that the Argon One extender case and SSD were the problem, I removed the RPi4 from the case, booted it from the SD card and built INDI and INDI-ALLSKY from scratch and then restarted indi-allsky. The IMX477 is no longer listed (new database I guess), but it still shows no other cameras available, although I have an ASI294 plugged in. Changed to the ASI120 and rebooted, but the web page still shows zero cameras available. I did notice that some of the downloads for the INDI service were from a Debian repository, but the script seemed to do that all by itself. I'm kind of stumped.

John

 

edit -what's kind of odd is that prior to the RPis camera port dying (on both Pi4s using the Argon One SSD case), Indi-allsky worked fine with the imx477. So I've just been trying to get it to work with the ASI cameras with no luck.

John

Well... I am kind of stumped.  Have you tried switching ports on the Pi4?  Maybe switching between the USB3 and USB2 ports?

[Broz22]

Aaron,

  My last post evaporated (maybe I didn't hit post?), but I think you are on to something with the USB ports. As I mentioned above, the 120, which had not been recognized, and no pictures taken, started working during the hour I was away at dinner. When I came back the camera had been recognized, all info correct, and it was taking pictures every 15 sec. This was on a USB 3.0 port on the Pi and it had been sitting there for an hour or so previously, not recognizing the camera. I switched it to a 2.0 port and the camera was recognized immediately. The RPi USB ports are notoriously unable to source much power so the 3.0 port might be on the ragged edge for the camera. I may try a powered USB hub to see if that helps, but on the other hand, the ASI294 (12v external power) was not recognized on the 3.0 port either - maybe a flaky port? I'm using a 4A 5V power supply for the Pi so the cpu voltage should be ok. I'll probably try the Argon One case again to see if it will work. The SSD makes booting and other disk operations a lot faster as well as having a ton of storage.

  My only remaining issue seems to be pretty bad banding on the 120 images, but that may be a factor of gain and exposure used during the indoor testing. I'll see how it does outside tomorrow night.

  Thanks for all of your help and providing such an amazing piece of software.

John

 

edit - making the exposure longer and the gain lower got rid of the banding.

Edited by Broz22, 09 April 2024 - 11:11 PM.

[Broz22]

I've done some measurements and experimenting and I'm pretty sure my problem with indi-allsky seeing the ASI120mm was a power issue. It is well known that RPis work best with "official" power supplies, and I think I have tracked the problem down to not necessarily the power supply itself, but the USB cable from the power supply to the RPI for the 5v.  A 3 amp 5v supply is supposed to be necessary for an RPI4, but many of the usb cables from generic supplies are made with thin wire (unknown and unstated AWG). I want my allsky camera to be on the outside of my ro-ro shed, about 15' from the available 110v, so I opted to run a 3.5 a, 12 v power supply (~ 40 watts compared to the ~ 15 watts needed for the RPi) to the camera through large gauge wire to the enclosure where I use a buck converter to reduce the 12 v to 5 v. I tried 2 different converters rated 4 and 5 amps respectively, both have a hard-wired usb-c connector on the 5v side. Current measurement between the usb connector on the buck side and the RPi side never exceeded 1.0 amps with either converter, and I got periodic low-voltage warnings from the RPi. Core voltage was down to ~ .8v (it should be ~1.3v). Of course the voltage drop depends on the wire length, but each of these was < 1', so length should not be the issue. I've ordered an adjustable buck converter and a bare, 2-wire, 20 AWG usb-c connector to hook it to the RPi. I'll report the results if that cures the low-voltage warnings and the difficulty in the all-sky recognizing the ASI120mm.

  The RPi5 uses PD supplies and should negotiate the voltage, but I have not been able to find out whether the RPi4 uses PD supplies. If so, the non-adjustable buck converters probably won't work since I have not been able to find one with PD capability (they probably exist). The adjustable converter may help tell the story. The RPi5 also allows you to set the max_usb_current to 1amp through the config.txt file, but again, I don't know if that works or helps with the RPi4. Cruising the internet for this info indicates a lot of confusion on the RPi power issue.

  One other possibility is the Argon One case and SSD causing power problems. The SSD is powered from one of the USB 3 ports on the RPi. It is likely to be the problem if the heavy 5v power cable and adjustable buck converter do not do the trick. Someone on the Argon forum suggested a powered USB3 hub between the case and SSD. I have a hub laying around and will test this if the other stuff fails.

John

Edited by Broz22, 13 April 2024 - 09:38 AM.

[decep]

I appreciate the detailed investigation.  It is almost never power issues with a camera like the ASI120, but your SSD configuration is not typical (in an allsky camera) and might be pushing your power usage over the limit (combined with the camera and any fans you have).

 

My investigation of the Pi4 says it does NOT support PD and the 5v line from the USB connector is directly connected to the 5v rail of the Pi4.

[Broz22]

Thanks Aaron for the power supply info. And I believe you are right, that it is the SSD case at the root of the problem. I have 1 more test (waiting on some parts for the powered hub), but that seems to be the issue. The Pi4 works fine, no throttling or low power msgs if I use the adjustable buck converter and 20 awg wire usb connector. But even with this setup it throttles and warns when the camera is plugged in. The larger converter goes up to about 1354 amps during boot, and then settles to ~ 1.1 amp steady state and does not increase when the camera is plugged in. Odd, since it can pull extra current, probably for the SSD, during boot, but not afterwards. And setting max_usb_current to 1 (used for the RPI5) seems to have no beneficial effect. So the total USB current may be limited to .6a. If the hub does't help I'll drop back to just using the SD card.

John

[gordtulloch]

Hi there - I am getting the following error on SyncAPI

 

Apr 14 21:18:33 spao-pc [ERROR] MainProcess-4789/Upload-2 uploader.processUpload() [441]: Transfer failure: Sync error: 500

 

Whats it mean? Thanks!

[decep]

Hi there - I am getting the following error on SyncAPI

 

Apr 14 21:18:33 spao-pc [ERROR] MainProcess-4789/Upload-2 uploader.processUpload() [441]: Transfer failure: Sync error: 500

 

Whats it mean? Thanks!

You will have to check the logs on the remote web server.  This is just a generic 500 error from the client perspective.

[gordtulloch]

Oh doh of course. This is the remote side. Not sure why a CaptureWorker is trying to start at all? This just keeps repeating over and over. No indication of a SyncAPI connection.

Apr 14 23:09:47 racknerd-ac3ea3 [INFO] MainProcess-1755/MainThread allsky._queueManualTasks() [1113]: Checking for manually submitted tasks
Apr 14 23:09:47 racknerd-ac3ea3 [INFO] MainProcess-1755/MainThread allsky._startCaptureWorker() [290]: Starting Capture-504 worker
Apr 14 23:09:47 racknerd-ac3ea3 [ERROR] MainProcess-1755/MainThread allsky._startCaptureWorker() [283]: Capture worker exception: 
Apr 14 23:09:47 racknerd-ac3ea3 [ERROR] MainProcess-1755/MainThread allsky._startCaptureWorker() [283]: Capture worker exception: AttributeError: 'NoneType' object has no attribute 'getNumber'
Apr 14 23:09:47 racknerd-ac3ea3 [ERROR] MainProcess-1755/MainThread allsky._startCaptureWorker() [283]: Capture worker exception:     ctl = getattr(device, attr)(name)
Apr 14 23:09:47 racknerd-ac3ea3 [ERROR] MainProcess-1755/MainThread allsky._startCaptureWorker() [283]: Capture worker exception:   File "/home/gtulloch/indi-allsky/indi_allsky/camera/indi.py", line 1320, in get_control
Apr 14 23:09:47 racknerd-ac3ea3 [ERROR] MainProcess-1755/MainThread allsky._startCaptureWorker() [283]: Capture worker exception:     ccd_temperature = self.get_control(self.ccd_device, 'CCD_TEMPERATURE', 'number', timeout=0.2)
Apr 14 23:09:47 racknerd-ac3ea3 [ERROR] MainProcess-1755/MainThread allsky._startCaptureWorker() [283]: Capture worker exception:   File "/home/gtulloch/indi-allsky/indi_allsky/camera/indi.py", line 876, in getCcdTemperature
Apr 14 23:09:47 racknerd-ac3ea3 [ERROR] MainProcess-1755/MainThread allsky._startCaptureWorker() [283]: Capture worker exception:     temp_val = self.indiclient.getCcdTemperature()
Apr 14 23:09:47 racknerd-ac3ea3 [ERROR] MainProcess-1755/MainThread allsky._startCaptureWorker() [283]: Capture worker exception:   File "/home/gtulloch/indi-allsky/indi_allsky/capture.py", line 945, in getSensorTemperature
Apr 14 23:09:47 racknerd-ac3ea3 [ERROR] MainProcess-1755/MainThread allsky._startCaptureWorker() [283]: Capture worker exception:     self.getSensorTemperature()
Apr 14 23:09:47 racknerd-ac3ea3 [ERROR] MainProcess-1755/MainThread allsky._startCaptureWorker() [283]: Capture worker exception:   File "/home/gtulloch/indi-allsky/indi_allsky/capture.py", line 270, in saferun
Apr 14 23:09:47 racknerd-ac3ea3 [ERROR] MainProcess-1755/MainThread allsky._startCaptureWorker() [283]: Capture worker exception:     self.saferun()
Apr 14 23:09:47 racknerd-ac3ea3 [ERROR] MainProcess-1755/MainThread allsky._startCaptureWorker() [283]: Capture worker exception:   File "/home/gtulloch/indi-allsky/indi_allsky/capture.py", line 180, in run
Apr 14 23:09:47 racknerd-ac3ea3 [ERROR] MainProcess-1755/MainThread allsky._startCaptureWorker() [283]: Capture worker exception: Traceback (most recent call last):
Apr 14 23:09:34 racknerd-ac3ea3 [INFO] Capture-503-5868/MainThread capture.detectMoonMode() [1225]: Moon Mode conditions detected
Apr 14 23:09:34 racknerd-ac3ea3 [INFO] Capture-503-5868/MainThread capture.detectMoonMode() [1221]: Moon altitude: 28:25:09.3, phase 44.0%
Apr 14 23:09:34 racknerd-ac3ea3 [INFO] Capture-503-5868/MainThread capture.detectNight() [1203]: Sun altitude: -42:23:29.6
Apr 14 23:09:34 racknerd-ac3ea3 [INFO] Capture-503-5868/MainThread capture.saferun() [215]: Exposure state: unset
Apr 14 23:09:34 racknerd-ac3ea3 [INFO] Capture-503-5868/MainThread capture.saferun() [214]: Camera last ready: 0.0s
Apr 14 23:09:34 racknerd-ac3ea3 [WARNING] Capture-503-5868/MainThread miscDb.addNotification() [857]: Not adding existing notification
Apr 14 23:09:34 racknerd-ac3ea3 [ERROR] Capture-503-5868/MainThread capture._initialize() [493]: No indiserver available at localhost:7624
Apr 14 23:09:34 racknerd-ac3ea3 [INFO] Capture-503-5868/MainThread capture._initialize() [488]: Connecting to indiserver
Apr 14 23:09:34 racknerd-ac3ea3 [INFO] Capture-503-5868/MainThread indi.__init__() [138]: PyIndi version: 2.0.3
Apr 14 23:09:34 racknerd-ac3ea3 [INFO] Capture-503-5868/MainThread indi.__init__() [131]: creating an instance of IndiClient

 

[decep]

The error in this case is that no camera is connected/detected.  I have made this error condition reporting better in recent updates.

[gordtulloch]

Yes, no camera is connected as it's the remote side?

[decep]

Yes, no camera is connected as it's the remote side?

Ah, yes.  I missed the "racknerd" hostname.  You can just stop the indi-allsky service and disable the indi-allsky.timer.  I have a new script "./misc/web_only_setup.sh" for managing a remote-only install so these services do not get setup.

systemctl --user stop indi-allsky.service
systemctl --user disable indi-allsky.timer

 

 

As for the 500 error, check in the / var/log/indi-allsky/webapp-indi-allsky.log (remove the space) for the reason behind the 500 error.

Edited by decep, 15 April 2024 - 10:32 AM.

[gordtulloch]

Yup I disabled those services first thing, I'll make sure they are disabled. I've run the ./misc/web_only_upgrade.sh on the remote server to do updates so it's wierd this is happening all of a sudden. The only major change on the server lately was adding cert based authentication on ssh and beefing up the firewall rules.

 

Here's the error out of the log in var - some sort of key error? 

Apr 15 10:47:56 racknerd-ac3ea3 [ERROR] MainProcess-1701 app.log_exception() [828]: Exception on /indi-allsky/sync/v1/thumbnail [PUT]#012Traceback (most recent call last):#012  File "/home/gtulloch/indi-allsky/virtualenv/indi-allsky/lib/python3.10/site-packages/flask/app.py", line 1463, in wsgi_app#012    response = self.full_dispatch_request()#012  File "/home/gtulloch/indi-allsky/virtualenv/indi-allsky/lib/python3.10/site-packages/flask/app.py", line 872, in full_dispatch_request#012    rv = self.handle_user_exception(e)#012  File "/home/gtulloch/indi-allsky/virtualenv/indi-allsky/lib/python3.10/site-packages/flask/app.py", line 870, in full_dispatch_request#012    rv = self.dispatch_request()#012  File "/home/gtulloch/indi-allsky/virtualenv/indi-allsky/lib/python3.10/site-packages/flask/app.py", line 855, in dispatch_request#012    return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)  # type: ignore[no-any-return]#012  File "/home/gtulloch/indi-allsky/virtualenv/indi-allsky/lib/python3.10/site-packages/flask/views.py", line 110, in view#012    return current_app.ensure_sync(self.dispatch_request)(**kwargs)  # type: ignore[no-any-return]#012  File "/home/gtulloch/indi-allsky/indi_allsky/flask/syncapi_views.py", line 82, in dispatch_request#012    return self.put()#012  File "/home/gtulloch/indi-allsky/indi_allsky/flask/syncapi_views.py", line 127, in put#012    return self.post(overwrite=overwrite)#012  File "/home/gtulloch/indi-allsky/indi_allsky/flask/syncapi_views.py", line 108, in post#012    camera = self.getCamera(metadata)#012  File "/home/gtulloch/indi-allsky/indi_allsky/flask/syncapi_views.py", line 383, in getCamera#012    if camera.utc_offset != metadata['utc_offset']:#012KeyError: 'utc_offset'

[decep]

 

Yup I disabled those services first thing, I'll make sure they are disabled. I've run the ./misc/web_only_upgrade.sh on the remote server to do updates so it's wierd this is happening all of a sudden. The only major change on the server lately was adding cert based authentication on ssh and beefing up the firewall rules.

 

Here's the error out of the log in var - some sort of key error? 

Apr 15 10:47:56 racknerd-ac3ea3 [ERROR] MainProcess-1701 app.log_exception() [828]: Exception on /indi-allsky/sync/v1/thumbnail [PUT]#012Traceback (most recent call last):#012  File "/home/gtulloch/indi-allsky/virtualenv/indi-allsky/lib/python3.10/site-packages/flask/app.py", line 1463, in wsgi_app#012    response = self.full_dispatch_request()#012  File "/home/gtulloch/indi-allsky/virtualenv/indi-allsky/lib/python3.10/site-packages/flask/app.py", line 872, in full_dispatch_request#012    rv = self.handle_user_exception(e)#012  File "/home/gtulloch/indi-allsky/virtualenv/indi-allsky/lib/python3.10/site-packages/flask/app.py", line 870, in full_dispatch_request#012    rv = self.dispatch_request()#012  File "/home/gtulloch/indi-allsky/virtualenv/indi-allsky/lib/python3.10/site-packages/flask/app.py", line 855, in dispatch_request#012    return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)  # type: ignore[no-any-return]#012  File "/home/gtulloch/indi-allsky/virtualenv/indi-allsky/lib/python3.10/site-packages/flask/views.py", line 110, in view#012    return current_app.ensure_sync(self.dispatch_request)(**kwargs)  # type: ignore[no-any-return]#012  File "/home/gtulloch/indi-allsky/indi_allsky/flask/syncapi_views.py", line 82, in dispatch_request#012    return self.put()#012  File "/home/gtulloch/indi-allsky/indi_allsky/flask/syncapi_views.py", line 127, in put#012    return self.post(overwrite=overwrite)#012  File "/home/gtulloch/indi-allsky/indi_allsky/flask/syncapi_views.py", line 108, in post#012    camera = self.getCamera(metadata)#012  File "/home/gtulloch/indi-allsky/indi_allsky/flask/syncapi_views.py", line 383, in getCamera#012    if camera.utc_offset != metadata['utc_offset']:#012KeyError: 'utc_offset'

I think you just need to upgrade the code to both your local and remote systems.  The remote side is expecting some data that is not being sent.

[decep]

A little more background on this additional data... One of the initial design decisions I made with the database was storing dates in the local time zone.  This can make most things easier, especially since most cameras are just local systems.

 

However, with the SyncAPI, I ran into an unexpected problem.  Using local times works fine as long as the local and remote systems are running with the same timezone settings.  If they are in different timezones, the remote system will have the wrong dates on files.  In Python, the JSON module cannot serialize datetime objects natively, so I serialized date/times using [non-UTC] timestamps, which do not translate across timezones.  I resorted to sending the UTC offset with the data so that the timestamp could be correctly translated to the localtime.  This way, 8am in the local system will also be rendered as 8am in the remote system, regardless of the timezone settings.

 

I discovered this issue after finally deploying my own remote system (also using Racknerd ).  I am now located in Central time, but my VPS is in Eastern time.

 

https://allsky.aarmor.net/indi-allsky/

Edited by decep, 15 April 2024 - 12:17 PM.

[gordtulloch]

Ok I thought I'd done both (I definitely updated the remote system as soon as I started having this issue) but I'll confirm the local was updated as well.

 

Gratz on the remote system! Interesting your allsky has a relatively narrow FOV? That Summer Milky Way wheeling into view at the end of the night sure looks nice

Edited by gordtulloch, 15 April 2024 - 04:09 PM.

[Broz22]

Aaron,

  As you mentioned, using the Argon One case and SATA SSD drive is an unusual setup. But I think I've got it working now, and it is a nice setup for a faster boot and larger storage if someone has a SATA SSD lying around and wants to try it. What made things work was dialing the buck converter up to 5.15v, using the 20 awg USB-c power cable, and plugging the USB camera into one of the USB2 ports (not the remaining 3.0 port). No more throttling or low-voltage msgs. I've also got a  thermostatically controlled12v PC fan that is designed to fit as an exhaust fan attached as an add-on I/O board for the PC tapping into the 12v before the buck converter. So the fan will run in the summer, and hopefully the RPi and converter heat will defrost the dome in winter. We'll see. Next project might be to get Gord's cloud recognition software running. Thanks,

John

[decep]

Ok I thought I'd done both (I definitely updated the remote system as soon as I started having this issue) but I'll confirm the local was updated as well.

 

Gratz on the remote system! Interesting your allsky has a relatively narrow FOV? That Summer Milky Way wheeling into view at the end of the night sure looks nice

My last home had quite a few trees and did not really permit a wide FOV anyway.  My new location, while not perfect, could support a little wider view.

 

Now that I am moved, I have been working toward building a very high-end all sky camera.  I am still testing, but I have a new system I am planning that will run an APS-C IMX571 with a lens that will provide an appropriate image circle for such a large sensor.  I am very excited about this.

[Broz22]

Aaron, sorry to bother you, but now that I've got the camera working properly and sending pictures to my omputer from the shed I'd like to collect dark frames. I tried to follow the directions but got the errors below:

 

john@pi4-4g:~ $ source virtualenv /indi-allsky/bin/activate
bash: import: command not found
bash: import: command not found
bash: from: command not found
bash: /usr/bin/virtualenv: line 7: syntax error near unexpected token `('
bash: /usr/bin/virtualenv: line 7: `    sys.argv[0] = re.sub(r"(-script\.pyw|\.exe)?$", "", sys.argv[0])'
john@pi4-4g:~ $ source virtualenv/indi-allsky/bin/activate
bash: virtualenv/indi-allsky/bin/activate: No such file or directory
john@pi4-4g:~ $ source virtualenv /indi-allsky/bin/activate
bash: import: command not found
bash: import: command not found
bash: from: command not found
bash: /usr/bin/virtualenv: line 7: syntax error near unexpected token `('
bash: /usr/bin/virtualenv: line 7: `    sys.argv[0] = re.sub(r"(-script\.pyw|\.exe)?$", "", sys.argv[0])'
john@pi4-4g:~ $ pwd
/home/john
john@pi4-4g:~ $ cd indi-allsky/
john@pi4-4g:~/indi-allsky $ source virtualenv /indi-allsky/bin/activate
bash: import: command not found
bash: import: command not found
bash: from: command not found
bash: /usr/bin/virtualenv: line 7: syntax error near unexpected token `('
bash: /usr/bin/virtualenv: line 7: `    sys.argv[0] = re.sub(r"(-script\.pyw|\.exe)?$", "", sys.argv[0])'
john@pi4-4g:~/indi-allsky $ ./darks.py sigmaclip
Traceback (most recent call last):
  File "/home/john/indi-allsky/./darks.py", line 6, in <module>
    from indi_allsky.darks import IndiAllSkyDarks
  File "/home/john/indi-allsky/indi_allsky/darks.py", line 24, in <module>
    from .config import IndiAllSkyConfig
  File "/home/john/indi-allsky/indi_allsky/config.py", line 10, in <module>
    from prettytable import PrettyTable
ModuleNotFoundError: No module named 'prettytable'

 

 

Any thoughts?

Thanks,

John

[decep]

Aaron, sorry to bother you, but now that I've got the camera working properly and sending pictures to my omputer from the shed I'd like to collect dark frames. I tried to follow the directions but got the errors below:

 

john@pi4-4g:~ $ source virtualenv /indi-allsky/bin/activate
bash: import: command not found
bash: import: command not found
bash: from: command not found
bash: /usr/bin/virtualenv: line 7: syntax error near unexpected token `('
bash: /usr/bin/virtualenv: line 7: `    sys.argv[0] = re.sub(r"(-script\.pyw|\.exe)?$", "", sys.argv[0])'
john@pi4-4g:~ $ source virtualenv/indi-allsky/bin/activate
bash: virtualenv/indi-allsky/bin/activate: No such file or directory
john@pi4-4g:~ $ source virtualenv /indi-allsky/bin/activate
bash: import: command not found
bash: import: command not found
bash: from: command not found
bash: /usr/bin/virtualenv: line 7: syntax error near unexpected token `('
bash: /usr/bin/virtualenv: line 7: `    sys.argv[0] = re.sub(r"(-script\.pyw|\.exe)?$", "", sys.argv[0])'
john@pi4-4g:~ $ pwd
/home/john
john@pi4-4g:~ $ cd indi-allsky/
john@pi4-4g:~/indi-allsky $ source virtualenv /indi-allsky/bin/activate
bash: import: command not found
bash: import: command not found
bash: from: command not found
bash: /usr/bin/virtualenv: line 7: syntax error near unexpected token `('
bash: /usr/bin/virtualenv: line 7: `    sys.argv[0] = re.sub(r"(-script\.pyw|\.exe)?$", "", sys.argv[0])'
john@pi4-4g:~/indi-allsky $ ./darks.py sigmaclip
Traceback (most recent call last):
  File "/home/john/indi-allsky/./darks.py", line 6, in <module>
    from indi_allsky.darks import IndiAllSkyDarks
  File "/home/john/indi-allsky/indi_allsky/darks.py", line 24, in <module>
    from .config import IndiAllSkyConfig
  File "/home/john/indi-allsky/indi_allsky/config.py", line 10, in <module>
    from prettytable import PrettyTable
ModuleNotFoundError: No module named 'prettytable'

 

 

Any thoughts?

Thanks,

John

It looks like you just have an extra space between "virtualenv" and "/indi-allsky/bin/activate".  Remove that space and it should work.
 

source virtualenv/indi-allsky/bin/activate

 

[gordtulloch]

Ok I thought I'd done both (I definitely updated the remote system as soon as I started having this issue) but I'll confirm the local was updated as well.

 

Gratz on the remote system! Interesting your allsky has a relatively narrow FOV? That Summer Milky Way wheeling into view at the end of the night sure looks nice

Working now, clearly I neglected to update the local server. Thanks!! -- gt

[Broz22]

Aaron, you were right of course - removing the extra space fixed it. But this brings up another question - I am trying a different 150 degree lens and also a 6mm FL (?? FOV) lens since the original fisheye only seems to be able to be properly focused over about half of the FOV. I assume I will need new darks with a different lens, so how do you remove the existing ones so I can rerun the acquisition script? And I see lens data in the camera info tab, but haven't found where this comes from and how to change it. And finally, is there any way to access the data stream that goes into the charts (number of stars etc)? It would be useful as part of my automated system for terminating the NINA session and closing my ro-ro roof. I currently use an RG-11 for rain detection into a Dragonfly, but do not have a cloud coverage system. Gord's AI system looks great, but may be beyond my level of programming skill to implement. And I can't begin to say how cool the indi-allsky system is, and it has been a blast putting it all together. Many thanks,

John

Edited by Broz22, 17 April 2024 - 11:10 AM.

[decep]

Aaron, you were right f course - removing the extra space fixed it. But this brings up another question - I am trying a different 150 degree lens and also a 6mm FL (?? FOV) lens since the original fisheye only seems to be able to be properly focused over about half of the FOV. I assume I will need new darks with a different lens, so how do you remove the existing ones so I can rerun the acquisition script? And I see lens data in the camera info tab, but haven't found where this comes from and how to change it. And finally, is there any way to access the data stream that goes into the charts (number of stars etc)? It would be useful as part of my automated system for terminating the NINA session and closing my ro-ro roof. I currently use an RG-11 for rain detection into a Dragonfly, but do not have a cloud coverage system. Gord's AI system looks great, but may be beyond my level of programming skill to implement. And I can't begin to say how cool the indi-allsky system is, and it has been a blast putting it all together. Many thanks,

John

There is no need to regenerate dark calibration frames if you change the lens.  Darks are independent of the lens.  However, if you want to remove the darks, you may use the "flush" option with darks.py .

 

The data for the charts is just pulled from the SQLite database.  You can find the model for the DB at "./indi_allsky/flask/model.py" .  indi-allsky uses the SqlAlchemy ORM internally so I deal with the database programmatically, but it is a standard schema that may be queried by anything supporting sqlite (Python, PHP, etc).  I have documented some example queries in the wiki.  One of the examples is basically the same SQL used for the charts view.

https://github.com/a...iki/SQL-queries

[Broz22]

Thank you. I was thinking of flats, not darks when I thought new darks would be needed with a change in lens. Any thoughts on how to enter lens info such as focal length etc  in the database?

John

Edited by Broz22, 17 April 2024 - 05:41 PM.

[Broz22]

Aaron, nevermind about the lens info request. I found it in the location tab. Things are working beautifully, and I can monitor the images in the house without heading out to the shed. VNC is also great for accessing the RPI since I don't have a monitor or keyboard hooked up to the RPi. I used it this morning to increase the size of the swap file. Thanks,

John

[decep]

Thank you. I was thinking of flats, not darks when I thought new darks would be needed with a change in lens. Any thoughts on how to enter lens info such as focal length etc  in the database?

John

Sorry, I missed this.  You already found it, but in case someone else goes looking, this is all under the Location tab.