Cumulus Support

I have a relatively new fine offset WS3083 station which I purchased to replace my ageing WM-918 which is on it's last legs. I know it is not a top line WS but unfortunately funds do not allow me to consider a better option. (retired on fixed income..)

I am currently having issues with the console locking up and not uploading readings to cumulusMX. The console itself continues to display current conditions but nothing is sent to Cumulus. The message on the cumulusmx.exe DOS screen says something to the effect that a reboot may be required (sorry, forgot to write down the exact phrase. ). Disconnecting the USB from my computer does not solve the problem, I have to remove the battery from the console and do a 'hard' reboot/reset console before it will again handshake with the cumulusmx.exe command.

I now suspect it is caused by widows10 doing one of it's unsolicited upgrades which somehow freezes the console as it definitely occurred on the last 2 occasions directly after a windows10 self-upgrade... just wonder if anyone has had the same experience or am I imagining things???? Is it simply that the WS is actually a piece of junk..?

The main problem I have is that, once it reboots and I start CumulusMX, when cumulusmx extracts the historical data from the console, it somehow finds the monthly rainfall data and loads it as daily rainfall. This obviously trashes my historical rainfall data as it puts a huge spike in my daily/monthly rainfall totals and those I send to weatherunderground.

Despite my best efforts in stopping CumulusMX, amending the data for all places I find the spike, then rebooting, it simply reinserts the monthly total as daily rainfall. I even did a total reset of the console (delete ALL saved/historical data from the storage), but it still finds/swaps this rainfall data. What am I doing wrong? Where is this rogue figure hiding where I can't find it to amend/delete it?

The USB lockup problem is very common with Fine Offset stations, a significant number of threads in the forum are about this. This is why Cumulus has a facility to try to avoid one way that the problem can occur - reading memory while the station is writing to it. See the 'Synchronise Fine Offset reads' setting. It does appear that for some reason this avoidance strategy is not as successful with the stations which have solar sensors.

Unfortunately a side effect of having to reset the console is that Cumulus can then get invalid data from the station. The best way to resolve the rainfall isssue is to use the editor in Cumulus to correct today's rainfall, then wait until the next log entry has been written and restart Cumulus. This should correct the daily, monthly, and annual totals. If any records have been invalidly broken, you will then need to stop MX and edit the relevant ini files. There is a lot of information about this in the FAQ and the wiki, but note that MX has no built in editors as with Cumulus 1, so the process is more manual.

Thanks Steve.

I had read about the issue with the fine offset stations and set the 'synchronise fine offset reads' to on from the get-go. I made the comment about windows10 as I know that the last 3 definitely happened alongside a windows10 upgrade so though it might have sent something down the usb system to cause the console to freeze its data saving. I will make sure I note if/when it does it again, and if alongside a windows10 upgrade, I will dig out an old box I have here which runs XP and try that to see if it cures the problem.

I know the editing of data is manual. I have tried to go through all the files under data folder (.ini and .txt) and amend the false rainfall figure. When doing this I refer back to the last 'uncorrupted' backup file in the MXdiags folder and copy that data across into the data folder into the respective file. However, I am obviously missing one of these erroneous data points somewhere as, when I then restart cumulusmx, the error of listing the monthly rainfall total as daily rainfall reappears in the dashboard and is most obvious in the rainfall chart.

My question is: which files under the data folder is daily rainfall saved? I have edited all the ones I can find but obviously one is evading my intensive searching and it is driving me to drink right now.. (I have not tried to get into the .db files though).

I really appreciate your time spent here!

Have you checked that your USB hubs are not in Power Saving mode as if they are that maybe the cause of the lockup as W10 does the update.

To check open Device Manager open Universal Serial Bus controllers and then right click and select Properties on anything that has HUB in its title. In the window that opens if the hub has Power Management you should see a tab saying exactly that. Click on the tab and remove the tick (if it has one) from "Allow the computer to switch of this device to save power" and then press OK. Make sure you check all the HUBs.

Checked this and, yes, they were set to power saving mode. Have unchecked that option now. Hopefully this will help towards stopping the lockups..?!

A tip: you feed the console from the USB port, remove the batteries. I've found it beneficial.

Thanks for that

I have just had another lockup and had to reboot the console.

Restarting CumulusMX again loaded the monthly rainfall total as 147mm at 17:28 under daily rainfall so I have a huge spike in the daily rainfall graph and in wunderground.

I have opened the files under data and am trying to remove this spike as it reloads despite removing it from the places where I find it in the various files under data, so it is obviously hiding somewhere in one of the files and re-inserting it when I reboot CumulusMX.

I have gone through the WIKI and FAQ and tried to follow the information given there, but it seems very focused on Cumulus1 rather than MX, in particular insofar as what the columns in the file Nov16log.txt represent after loading the file into excel as comma delineated columns. I have been able to deduce what a lot of them represent, but some of them are a mystery to me.

Is it possible to get a list of what each column represents in this file (nov16log.txt), and the other .txt files (dayfileamended.txt, dayfile.txt) so I can be more confident in amending figures to try to remove this monster spike ( and a few others from previous reboots) which currently refuse to be removed?

The monthly log files and dayfile.txt are exactly the same in MX as in Cumulus 1, so the information in the wiki describing the format (and giving the Excel column identifiers) applies to both. The information in the FAQ about correcting rainfall also applies equally to MX, with the exception that MX only has one built-in editor, for today's rain. If your high total is for today, the way to correct that is to use that editor, allow MX to write a log entry, and then restart (as I mentioned above).