Hi Gunter - I'm afraid I can't help debug. As above, I don't use the website, instead I feed all the data into my weather station and visualise it that way, so I have no experience with the rrd files. -Mark

Read More...

My setup has evolved and looks roughly like this now...

I've had weatherradio running for a long while now using xbee units to talk back to a raspberry pi over serial. The raspberry pi is my weatherstation running weewx and processes the data (my main headache is I still can't find good values for the model constants to get cloud cover accurate % enough for my liking). I then chuck the data back out from weewx to mqtt using the weewx-mqtt plugin.

This is where I diverge slightly. Instead of using wolfgang's driver to connect directly to the weatheradio over http, I now use github.com/rkaczorek/indi-weather-mqtt to pull the weather data from mqtt. This allows me to fill in more data than wolfgang's driver (and I can pull data in from anywhere that can throw it on mqtt) which is useful to fill out the fields on the new weather tab in ekos that aren't covered in the driver.

One other advantage of this is that weewx is good at massaging weather data. So I can use unit conversion functions or build other calculations in weewx before dropping the data onto the queue in the format that indi will want it.

-Mark

Read More...

Up until last night I was guiding using an ST80 and ASI224mc. My usual experience was guiding errors in the internal guider drift plot were equally scattered around the plot with equal distribution, on good nights in the green circle

Last night I switched guiding to a asi533mc on a redcat since I had this configuration to hand. The guide plot looked very different:

Personally, I have lots of unos and xbees lying around so I'm just trying to use them rather than buying new kit. There's something nice too about using minimal kit - the easy option for these kind of projects is always to use another raspberry pi and wireless - the cost isn't too much, but where's the fun in that?

Read More...

This is the best description I found of how to use the library: arduinojson.org/v6/how-to/determine-the-...of-the-jsondocument/ My reading of this was that if all strings used for keys are const char* then we won't need extra space, otherwise serialisation needs space to copy all the strings.

-Mark

Read More...

Adrian, I've been trying to diagnose similar issues as I've been adding in my dew heater code. I haven't solved this but my thoughts are that it could be:

1. Hardware problem - I'm not that neat with my soldering etc and the problems sometimes seem intermittent so I wonder whether it's just something particularly on the i2c bus. I've been gradually redoing my setup, but not sure whether this is the problem.

2. JsonDocument issue - I've been trying to understand JsonDocument to understand whether enough space is being allocated because of string usage and whether we're hitting the memory limit of StaticJsonDocument as more sensors are added. It's a confusing library, but I think the answer here is it's okay.

3. Code problems - I've been through the code in detail, whilst there are some issues in the new update like the missing preprocessor lines you identified, and some missing allocation of space in JsonDocuments, everything looks fine and practically I see similar problems with older versions of the code. So I don't think it's anything that's been recently added.

4. Memory limits of the microcontroller - I notice you're using an Uno same as me. My dew heater code is including math.h as does the Davis library, and I've wondered whether that means there's just not enough left with an Uno when it comes round to allocating memory for the Json strings.

It's been very difficult to narrow it down as it's not particularly repeatable and removing code in various places seems to fix the issue. My guess is it's probably memory, but I'm not an experienced C programmer. It's good to know though that it's not just me

-Mark

Read More...

Yeah, it's the dewcontrol.com resistor heater ring that I have - I'm also in the process of building an allsky camera so picked one up for the SQM box at the same time as they're quite cheap and pretty.

So far I haven't needed to cover the cloud sensor. The component should be fine as it's stated it's sealed. I drilled the ABS box and surrounded it in gorilla clear silicone to make the box watertight - we'll see if it lasts. I've also seen people buy the raw component instead of the mounted version, and using a cable gland to house it which is a pretty cool idea.

As far as other sensors go, might help to describe my current setup so far (I'll probably post more detail with pictures when everything's completed):

* I have a Watson weather station which is a common cheap one with humidity, temp, rainfall, wind. Communicates with an inside unit which is USB connected to a raspberry pi (weatherstationpi) running weewx which captures the data.
* I have a Weather Radio SQM consisting of lum sensor, cloud sensor, water sensor, DHT sensor, dew heater. An arduino uno runs Weather Radio and I have some extra code which calculates the dew point from the DHT sensor and turns on or off the dew heater via a relay (I'll do a pull request on that soon). I've also got a lightning detector on order from bangood to add next
* The SQM uses XBee wireless units to send its data to weatherstationpi where I've built a weewx service which adds it to the Watson station data (another pull request when I've cleaned it up so that the weewx integration can run as either a weather station driver or a secondary service adding data)
* weatherstationpi runs indi_weatherradio permanently and when my scope comes online for an observing session (astropi) it connects as a distributed indi network
* weatherstationpi is running the weewx_mqtt extension which publishes all the combined weather data over MQTT
* On another pi Telegraf catches the MQTT stream and pumps it into an Influx time series database
* Grafana is used to create a dashboard for the whole setup
* My allsky camera pulls the weather station data from MQTT to know whether to turn it's own dew heater on and a weewx skin generates a plain text file which is included on the allsky image as the red overlay showing sky quality and cloud cover percentage.

Here's a shot of the dashboard from when I was debugging (don't look at the data too closely).

-Mark

I have this for the luminance sensor. I'm working on some code to control this at the moment. Here's an image - on the left is the TLS2591 with a 15 degree lens and an acrylic dome and the dew heater ring, right is the rain resistance sensor, and bottom right is the MLX cloud sensor.

Wolfgang,

I've added support for simple rain sensors. Saw you were working on something similar so wrapped my code up in a pull request: github.com/indilib/indi-3rdparty/pull/278

-Mark

Read More...

Hi Wolfgang,

Thanks for your great work with Weather Radio. I submitted a pull request here to add some basic support for Weewx: github.com/indilib/indi-3rdparty/pull/254

The reason I added this is so that I can use Weather Radio as a more generic weather station input to Weewx which can then augment the data, produce dashboards, and also push it upstream other places like Weather Underground. I added some simple support for allowing the indi driver to get its information from weewx - this isn't an ideal implementation, in the long run a indi_weewx driver would be better to take full advantage of the other information weewx might provide as well as the data sourced from WR, but for now it works.

-Mark

Read More...

My solving works fine in normal operation. But when trying to solve the attached file I don't get a solve. The command line I'm using is copied from kstars as:

<code>/Applications/KStars.app/Contents/MacOS/astrometry/bin/solve-field -O reference.fits --config /Applications/KStars.app/Contents/MacOS/astrometry/bin/astrometry.cfg --no-plots --no-verify --resort -u app --downsample 6</code>

Turns out when I remove the --downsample 6 it works. This is set from the astrometry settings in ekos where it's set to Auto which works fine when Aligning.

Not sure how to handle this - if I turn off downsampling then my file solving will work for 'load and slew' but I'll have slowed down the working plate solving in kstars when I'm doing alignment. Any suggestions why file solving would be different here?

-Mark

Yep, that's definitely the issue. My question was more why, when doing a load and slew, ekos decides to use 6 when downsample is set to Auto causing the failed solve.

-Mark

Read More...