Wim van Berlo replied to the topic 'BUG: EKOS - PHD Guiding not configurable' in the forum. 4 months ago

For guiding to work and a guide tab to show, you need to choose a guide camera and a telescope. In your screen capture you have only an imaging camera selected.

Read More...

Wim van Berlo replied to the topic 'Indiduino MeteoStation trouble with TSL2591' in the forum. 5 months ago

porkyhttp wrote: Hi,
I am tring to build my Meteostation, but i have much problem with the TSL2591. I see that values are not stable and change to much from one to other, in the same conditions. If i compare these values with an Unihedron SQM device, the values from the Unihedron device is the same or change of 0.02 but values that came out from the TSL2591 are completily different. Wht these difference??? Someone has compared the values from a TSL2591 with an Unihedron???


I use this device for my sqm without any problems. Here are the particulars
stargazerslounge.com/topic/345219-sky-quality-meter-with-wifi/
Not arduino, bu I hope it helps anyway.

Cheers

Read More...

Wim van Berlo replied to the topic 'Internal autoguide in EKOS makes thins worse' in the forum. 5 months ago

Bart wrote: Absolutely agree with you Wim. The integral term is essential to arrive at an error of zero. Although even if there exists an error, it is static (i.e., the guide star is shifted from the 'set' position). This therefore should in principle not influence the guiding, since, once the system is settled, it is constant.
I've started to take a look at the source as well and found the same as HY. Only the P and I terms are incorporated. Does anyone here know what is the reasoning behind this?
Indeed the D term is sensitive to the slope (dT/dx) of the measured value (where x is the position in the respective control direction). I wonder if sensitivity to noise would be the reason for this.

By the way, here is a really nice explanation of a PID loop (on a microcontroller), and how to add several nifty things to make it respond better: brettbeauregard.com/blog/2011/04/improvi...rs-pid-introduction/


The internal guider is derived from lin-guider, so best try to ask the developer. My guess is, that the D term is sensitive to noise and doesn't add enough to the solution. As I mentioned before, you'd want to make sure that any combination of the PID parameters that are allowed, can't cause catastrophic behaviour of the mount. Oscillations may be cool in math, but I wouldn't like to see my mount swing. Also remember that any practical solution has to work for all possible mount and load combinations. And rather than make the D term less sensitive to noise, there are better solutions, such as the minmo parameter in phd.

Read More...

Wim van Berlo replied to the topic 'Internal autoguide in EKOS makes thins worse' in the forum. 5 months ago

Absolutely correct of course. In PID controllers, the response is determined by the effect of all three parameters together. It is a lot more difficult to get stable operation if you have more parameters to dial in. The differential part of the controller is sensitive to noise, and could create erratic operation. The integral part averages noise. It will also bring the error in the control system to 0, something which a P controller can't.

Read More...

Wim van Berlo replied to the topic 'Internal autoguide in EKOS makes thins worse' in the forum. 5 months ago

PID control loops can start oscillating if the parameters aren't set properly. You wouldn't want that to happen to your mount. That's why derivative gain in lin_guider wasn't used. But if I remember correctly, integrating gain is used.

Read More...

Wim van Berlo replied to the topic 'weather watcher cloud parameter' in the forum. 6 months ago

Isn't the situation a little more complicated?
Now that I have my weather station talking to INDI, I see five parameters in the options tab:
- rain (precip)
- temperature
- wind
- gust
- forecast

I don't use Gust, and I mapped 'Forecast' to clouds. So far, I haven't looked in the source code how this is handled.
In the Main Control and Parameters tabs I see four parameters:
- Weather
- Rain
- Temperature
- Wind

Since I don't use 'Gust' I don't expect it to turn up in Main Control
Other parameters that my meteostation reports, such as timestamp, pressure, humidity and dew point, also don't show up, because they aren't mapped in Options

Atm I have my meteostation indoors for testing, and the cloud sensor shows 100 % cloud. When I change the limits for 'Weather' to 110, and 15 % warning, the marker in Main Control turns yellow. When I set the limit to 120, it turns green. At the (for me) default value of 50, it is red.

So, according to what I find, the parameter 'Forecast' in Options, is the same as 'Weather' in the Main Control and Parameters tabs. This can be filled with a 'clouds' reading from a cloud sensor. It works the same way as any of the other parameters.
Parameter settings and labels are a bit confusing in the Weather Watcher driver, and ideally, this driver would use a skeleton file to define preset parameters. And these parameters should be called the same across the board. But the driver works, is flexible, and easy enough to work with, once you understand it.

Wim

Read More...

Wim van Berlo replied to the topic 'Weather watcher question' in the forum. 6 months ago

Your link works fine. I did some more tests. It seems that the WW driver reads the file as lines. My "web page" is output as one big chunk/line. This causes WW to only read the first keyword, which in my case was the time stamp. This time stamp isn't parsed by the driver. All subsequent text was just rejected. When I removed the timestamp and set temp= as the first piece of data, the driver reads this fine, but nothing after it.
Now I've recoded the webserver response and it works

Before:

conn, addr = s.accept()
print('Got a connection from %s' % str(addr))
request = conn.recv(1024)
conn.send('HTTP/1.1 200 OK\n')
conn.send('Content-Type: text/html\n')
conn.send('Connection: close\n\n')
conn.sendall(WebPage)
conn.close()

where 'WebPage' contained formatted html code with the data

Now:

conn, addr = s.accept()
print('Got a connection from %s' % str(addr))
request = conn.recv(1024)
conn.send('HTTP/1.1 200 OK\n')
conn.send('Content-Type: text/html\n')
conn.send('Connection: close\n\n')
conn.send('dataTime=' + strTimestamp +'\n')
conn.send('temp=' + bme_t +'\n')
conn.send('rain=0.00\n')
conn.send('pressure=' + bme_p +'\n')
conn.send('humidity=' + bme_h +'\n')
conn.send('dewpoint=' + bme_dp +'\n')
conn.send('clouds=' + ir_clouds +'\n')
conn.send('wind=1.50\n')
conn.close()

And this works fine. (Btw, don't have a rain and wind sensor installed yet)

Thanks for the help.

Wim

Read More...

Wim van Berlo replied to the topic 'Weather watcher question' in the forum. 6 months ago

Yes, I did. Made that mistake before, but not this time. There are also no subdirectories. The server code is generated by micropython code. I can see that the esp receives connections from indi, just that indi doesn't interprete what's coming back. If I connect with chrome, I get the response I should get:
temp=21.3
pressure=991
...

Read More...

Wim van Berlo created a new topic ' Weather watcher question' in the forum. 6 months ago

Does the weather watcher driver need a file to read from?
I have a diy weather station based on a esp32 wifi board. The board acts as a webserver. When I configure this to create a index.html file, it gets read into the driver all right. The problem is that this is not a long term solution, as this file resides in the esp32 flash memory, which is not intended for frequent rewrites. My other option is to create a web page response "on the fly", when a request from a client is received. But when I test this with the weather watcher driver, it doesn't work. My question is, is the latter scenario supported by the driver? If so, what would I need to make it work?
The only other options I can think of are to either invest in a sd-card hat for the esp, or to have it write to a file on the sbc that holds indi/kstars. I don't know if that's even possible.
Any help would be appreciated.

Wim

Read More...

Wim van Berlo replied to the topic 'MQTT publisher for INDI' in the forum. 8 months ago

I have a Raspberry Pi 2B, so hardware may be part of the problem. Yesterday I couldn't even upgrade to ubuntu 18.04. Maybe time to upgrade to at least a 3B+, or even a Rock Pi.

Read More...

Wim van Berlo replied to the topic 'MQTT publisher for INDI' in the forum. 8 months ago

@pch : I have Ubuntu 16.04. The RPi hasn't been used for a while. I'll do a release upgrade and try again. Thanks

Read More...