Cumulus Support

A spurious radio signal gave a solar reading of SolarRad = 1662, UV=2 at 18:14 this evening. This is a point in time. The duration of the signal is <1s.
My Python script noticed this and reset the station at 18:29. Instead of the nice clean spike, rising from 0 to 1662 at 18:14 and falling back to zero at 18:29, I now have an odd curve inserted between the last non-zero reading and the spike at 18:14. The graph input returns to NULL at 18:29 when Python restarted Cumulus to clear the buffer.

A second view of the left hand side of the graph response. The graph shows solar radiation and UV, even though there is none, because the graph component needs a zero input rather than NULL to accurately portray the signal.

Charts on Wunderground are also adversely affected. The response in versions prior to the NULL default (Nov 23 bottom) compared with what was recorded today (top). It can be seen that the results, although correctly recorded by Wunderground, are far less clear.

It is kind of improper use of the software isn't it?
Th signal has nothing to do with weather phenomena.
I wonder is CMX needs to be adjusted for this.

It is a significant change in behaviour of the software due to recent updates.The effects seen are responses to the actuality of the radio environment in the vicinity of the station. These signals are not caused by me or anything I do - they are simply aspects of the environment in which my station operates. The effect demonstrated here is an artifact caused by an intermittent sensor signal. Versions b4043 and prior handled this situation very gracefully, giving nice clean graph responses which accurately represented the ambient environment. I understand the reasons for recent changes, but I also know enough about software engineering to realise that changing a default value from zero to NULL can have all sorts of counter-intuitive impacts on components which consume those values. This seems to be one such effect.

In situations where any software, not just CumulusMX, encounters unexpected values, error conditions and failures are normal. The principle is that failure should be "graceful" and until the recent changes, this was universally the case. I've always been a big fan of CumulusMX because it has been utterly reliable and consistent over many years of use. Like many users, I have routines and databases which consume outputs from CumulusMX to produce custom results. Mine might be unorthodox, but they are not very different from what others are doing and as always, I'm happy to change my own code where necessary to get the results I need. What we are looking at here, is an inconsistency within CumulusMX itself which produces a standard graph which does not represent the data in a graceful way. The graphs from Wunderground represent what I would consider a graceful handling of the data, showing values where there are values and nothing where there are none. Overall, this is an accurate representation of the ambient environment around the station. Comparing this with the response shown on the CumulusMX graph, we can see that instead of zeroing the line where no data exists, the graph draws a straight line between one data value and the next, giving what I think is an incorrect rendering of the data. I view that as undesirable because it is an artifact produced by interaction between components within CumulusMX itself - not something I can easily correct. What was previously an accurate and reliable graph, is now showing something which doesn't look right and doesn't accurately reflect the ambient conditions. I have raised the issue as a bug and ultimately will respect the author's decision about whether it needs fixing. I hope my reasoning makes sense.

Well, I am not going into a lengthy discussion here as I think Mark should, but let me be clear: you have no solar or UV equipment. So I think using those charts for a radio signal is improper use of the software and you are asking CMX to make that a formal functionality. Which it accidently had in the past.

You are saying with a lot of words, CMX should maintain that accidental functionality because you started using it.

I hope it is needless to say that I disagree with asking to maintain CMX for improper use.
But it is not to me to decide and maybe Mark sees added value here (or makes a separate radio signal occurrence chart )

Here's something worth reporting. It has now been over a week since the NULL/0 problem started to occur. This means that the RecentData table in CumulusMX contains no zeroes, just NULL where there is no data. The chart now behaves as expected showing clear peaks where there is a signal and nothing otherwise. The behaviour is perfectly acceptable now. It seems that the problem was transient and occurred only whilst there was a mixture of Zeroes and NULLs in the table. I'm guessing that now the table is flushed through, the problem is gone! Thank you everyone for your attention.

Well, lucky everybody I guess

Best not to get too excited. Let's see what happens when there are two peaks. Will the chart draw a straight line between them rather than returning the line to the axis? I will test and we will see.

EDIT: Results of the test. With two signals in the data, the graph simply draws a straight line between the peaks.

The desire to record Solar and UV for which you have no sensors doesn't quite make sense to me.

Just to be clear, these signals are received by the base station whether a sensor head is present or not. The radio signals don't affect only the solar data. They also produce spikes and anomalies in the temperature, humidity and pressure data. The graphs faithfully reproduce the signals in those cases and indeed, the solar daily chart also works very well. The update to b4063 introduced an anomaly where the Recent solar chart no longer produces a faithful representation of the data my station receives.

I have 2 questions. Firstly where do these signals emanate from, it's the first time I've heard of this? Second I do wonder what WU will think of these readings as they are impossible values for solar except perhaps on the summit of Everest!

Stuart

wurzelmac wrote: ↑Fri 13 Dec 2024 8:00 am The desire to record Solar and UV for which you have no sensors doesn't quite make sense to me.

I agree plain daft!!

All null data value types are better handled in the graph data in the next build.

That's very good news. Thank you