Sorry, as Hi pointed out, I was mislead by the EKOS guiding log, I thought it was a PHD log.

Read More...

Hi Magnus,
there is one thing that looks strange in your logs from the night where the internal guider seem to send no correction signals to the mount: how did you manage it having both running PHD2 AND the internal guider between 22:50 and 22:58? Did you run EKOS with the internal guider and have PHD2 running in parallel?

I haven't tried that, but I would not be surprised if that causes trouble.

Wolfgang

Read More...

What was the reason that guiding hangs? Does it really hang or does each starting attempt fail?

The Scheduler has an error strategy, but it handles only the cases when aligning, capturing etc. really fail. As long as the Capture module waits for guiding to start, the Scheduler does not step in and might leave the Capture module wait for ever.

In any cast: it would be great if you provide a log file of last night.

HTH
Wolfgang

Read More...

It's really awkward. What about shifting our communication to PN?

I would set a breakpoint at line 42 of wr_rrd_update.py and step through carefully.

HTH
Wolfgang

Read More...

And what happens without the "-v" flag? Try running

python -m pdb /usr/share/weatherradio/bin/wr_rrd_update.py


Read More...

weatherradio.html and sensordata.html have different RRD files as data source.

Read More...

That's OK. The RRD file contains columns for all supported sensors, not only for the used ones.

Regarding the problem above with the -v flag - hm, strange, never seen. Try to use the debugger pdb.

Read More...

Replace

// return (mlxData.status);


Read More...

Hm, but that's syntactically problematic, since you do not return a value although the function is declared as boolean. What happens if you add a "return(true);" ?

Read More...

and what happens if you comment out the begin/endTransmission additionally?

Read More...

Many thanks for your feedback. I resolved it slightly different. The main bug was that the status was never updated once the initialization was successful:

/**    mlx.begin() always returns true, hence we need to check the I2C adress */
bool isMLX90614Present() {
  Wire.beginTransmission(MLX90614_I2CADDR);
  byte error = Wire.endTransmission();
  mlx.begin();
  mlxData.status = (error == 0);
  return (mlxData.status);
}

void updateMLX() {
 if (mlxData.status || (mlxData.status = isMLX90614Present())) {
   mlxData.ambient_t = mlx.readAmbientTempC();
   mlxData.object_t  = mlx.readObjectTempC();
 }
}

Could you please check if this works for you?

Read More...

That’s awkward, there must be something special in your setup. What board do you use?
I think the only way is to add debugging messages into the mlx code of weather radio, especially around mlx.begin(). Maybe out of a strange reason this part never gets reached.

Read More...

Hm. strange. The only problem I remember was having a wire clock set too high. But the wire clock is only changed if the OLED module is activated in weather radio.

Check the configuration of OLED_WIRE_CLOCK_SPEED in config.h. I noticed that it should not be higher than 100kHz:

#define OLED_WIRE_CLOCK_SPEED 100000L // set to 100kHz if using in combination with MLX90614


Read More...