Page 1 of 1
One way to cause 'not downloading data' & a fix
Posted: Thu 09 Jun 2011 7:27 pm
by robinh
Using Cumulus 1.9.0 with Davis VP2 and USB->Serial.
My W7 died and I ended up having to pull all USBs to get it going again. In replugging the USB, I happened to use a different USB port and hence ( with Prolific USB-Serial) a different COM port number.
With Weatherlink, I just updated the config to change from COM5 (say) to COM6 and I immediately had the current and historic data.
Using Cumulus, I guess I just ran it once without thinking to much. Then I realised I needed to change the COM port from 5 to 6 and did so. I then ran Cumulus again, expecting I would now see the history download as I had the correct port....
.. instead, I get the 'Cumulus does not download data' problem.
What I think happens is that Cumulus had tried to get the data from the non-existent port, got none, but then updated its today.ini file saying last fetch Timestamp was 'now'. Then when I fixed the COM port number, Cumulus does a fetch on the new and correct port but uses the 'now' date-time as the starting point and of course does not see the missing data history.
I seem to have fixed it by editing today.ini to and setting Timestamp to the value at the start of the missing history and the running Cumulus again so it starts the download with the first missing data sample. Now I can graph the formerly missing history.
Other posts suggest I should also be manually fixing alltime.ini and perhaps other ini files, but I didn't get around to that and some of my cumulative values may be wrong ...
I am a Cumulus greenhorn, so maybe some expert can confirm that this can happen and this is the best fix. Real serial ports are becoming rare so USB implementations must be common and it is easy to mix USB ports.
Cumulus suggestion:
It seems to me that Cumulus would work better if it did not use Timestamp at all from today.ini and instead just searched for the most recent sample in the data files and then looked for the oldest sample in the Weather station and tried to fill the gap in the data files. It would be more robust.
USB notes:
1. I use USB-Serial instead of pure USB so I can run long wires from Davis to the PC ( and also hints of bugs in Davis USB implementations).
2. I believe some USB-Serial implementations allow the COM port number to be fixed, but I don't have that kind.
Re: One way to cause 'not downloading data' & a fix
Posted: Thu 09 Jun 2011 7:37 pm
by steve
robinh wrote:Cumulus suggestion:
It seems to me that Cumulus would work better if it did not use Timestamp at all from today.ini and instead just searched for the most recent sample in the data files and then looked for the oldest sample in the Weather station and tried to fill the gap in the data files. It would be more robust.
That is effectively what it does. The timestamp in today.ini is the last time that it wrote to the data files.
If it can't connect to the station because it's been given the wrong COM port, then it should know that it can't (it gets an error back from the Davis DLL), and it should put up an error dialogue to tell you that it hasn't been able to connect, and it shouldn't then write to the data logs or update the timestamp in today.ini.
You should try to avoid changing the timestamp in today.ini and instead, where possible, use the files from one of the backups; then all of your data is consistent.
If you zip up the diags folder and attach it, I may be able to see why it didn't catch up using the logger data.
Re: One way to cause 'not downloading data' & a fix
Posted: Fri 10 Jun 2011 5:47 pm
by robinh
Again today I shuffled COM ports, yesterday was COM6 and today it is COM7. I noted more carfully what I was doing today.
First ran Weatherlink and changed it to COM7. All OK.
Ran Cumulus knowing port has changed. Got popup with error because COM port does not exist. I see line in log:
10/06/2011 13:10:45.062 : VP2: OpenCommPort_V, port = 6 res = -32701.
Then I switched Cumulus from COM6 to COM7. I see in log:
10/06/2011 13:11:04.055 : begin updating station settings
10/06/2011 13:11:04.070 : Writing cumulus.ini file
then I see:
10/06/2011 13:11:04.621 : VP2: OpenCommPort_V, port = 7 res = 0
I presume 0 means no error.
...
then
10/06/2011 13:11:09.070 : Writing todayfile, LastUpdateTime = 09/06/2011 3:30:00 PM raindaystart = 203.453994750977
The time is the time of the last yesterday record in the log and would seem to be correct.
And then the next line:
10/06/2011 13:11:09.079 : VP2: End of history download
But somehow, I don't get the history. I just have the last few records following a multi-hour gap. The graph just has a straight line segment.
If I look in Jun11log.txt, I see
...
09/06/11,15:25,21.3,79,17.5,4.8,17.7,323,0.0,0.0,1011.52,203.5,25.4,60,4.8,21.3,21.3,1.3,156
09/06/11,15:30,21.2,79,17.4,6.4,17.7,322,0.0,0.0,1011.55,203.5,25.3,59,12.9,21.2,21.2,1.3,171
10/06/11,13:15,22.9,37,7.4,1.6,4.8,287,0.0,0.0,1021.14,203.5,25.9,40,1.6,22.9,22.9,6.4,872
10/06/11,13:20,22.6,44,9.7,1.6,8.0,285,0.0,0.0,1021.14,203.5,25.9,39,4.8,22.6,22.6,6.6,858
...
From what you say, this should not happen.
The diag file is attached.
What am I doing wrong?
Re: One way to cause 'not downloading data' & a fix
Posted: Fri 10 Jun 2011 5:58 pm
by steve
Well, OK, fair enough, that's a bug. It only tries to fetch logger data at start up, so if you start it up with an incorrect port number when there's logger data to be downloaded, and then change the port to the correct one, it doesn't attempt to fetch the logger data. Not a very common situation, and one that you can work around by closing down and starting up again using the backup data that was created when you started it up with the wrong port number.
Re: One way to cause 'not downloading data' & a fix
Posted: Fri 10 Jun 2011 10:14 pm
by robinh
Thanks for your help.
I copied yesterday's backup to the data directory and restarted. Now I have a continuous log.
I am using six USB ports and all the USB plugs/connectors all look the same. For me, it is too much trouble to try to sort out which USB is which ( some go into the drywall!). Most USBs don't care which port they plug into, but (my) USB-Serial (somehow) takes the USB port and creates a serial port number from the USB port position.
Perhaps the best way to live with this if the situation happens again would be to edit cumulus.ini when I know the port has changed and set the correct port BEFORE starting Cumulus. I can look in W7-ControlPanel-System-SerialPorts to find the new port number before I run Cumulus - I need to do that anyway.
What do you think?
Re: One way to cause 'not downloading data' & a fix
Posted: Fri 10 Jun 2011 10:38 pm
by mcrossley
When the USB device allocates a new COM port number you can change back to the required setting in the device advanced settings. It will warn you that the port number is already in use, but that is OK, you can still allocate it.
So, you plug the adapter in each port in turn, reset the port number, move it to the next, rest the port etc.
Once Windows has set the Com port number for a particular USB port it will remember it.
The problem arises because for cheapness the USB serial adapters do not have a unique serial number burnt into them, so Windows cannot get the COM port number to follow the device. The best it can do is allocate the same com port to that generic device when it is plugged into a particular USB port.
Re: One way to cause 'not downloading data' & a fix
Posted: Sat 11 Jun 2011 9:38 am
by steve
robinh wrote:Perhaps the best way to live with this if the situation happens again would be to edit cumulus.ini when I know the port has changed and set the correct port BEFORE starting Cumulus. I can look in W7-ControlPanel-System-SerialPorts to find the new port number before I run Cumulus - I need to do that anyway.
Yes, that would avoid the problem. Or you could use Mark's suggestion, which you would only need to do once, if I understand it correctly.
I've never come across this issue before; I guess everyone else plugs their station into the same port every time, or leaves it plugged in permanently.
Re: One way to cause 'not downloading data' & a fix
Posted: Sat 11 Jun 2011 10:51 am
by mcrossley
steve wrote: Or you could use Mark's suggestion, which you would only need to do once, if I understand it correctly.
Yes, it only needs to be done once. We get this problem all the time with computer controller telescopes. Be aware though that if you use an external hub, plugging the hub into a different port on the computer also remaps all the hubs ports! Nightmare.
You will see lots of moans about Windows on this one, but the fault lies in the USB/serial devices not Windows.
Re: One way to cause 'not downloading data' & a fix
Posted: Sat 11 Jun 2011 10:17 pm
by robinh
Yes, I will try Mark's suggestion next time.
As I recall, when looking for a USB-Serial device, there are some manufacturer's devices in which the port number is more sticky. I have forgotten the details. Perhaps they have some flash memory and remember the initial assignment. But I made a choice on which USB-Serial by looking on forums (fori?) for reports of good device driver behaviour with W7 and had no hassle with my choice.
I know it might sound simpler to always pick the same USB port, but when lying on my stomach under my desk with a flashlight and seven black USB cords all hanging from the desk underside, and more USBs plugged into my monitor, it is still easier to just plug them in where ever there is an empty USB slot and then use Windows to tell me the serial port assignment. Again, Mark's suggestion or editing .ini both sound to be about the same effort.
Now I could get into why I need to unplug everything on the back of my PC just to get it to boot ...
... but that is a story for another day and another place.
Thanks for all the help.
Just now, I am not dedicated enough to experiment further.
But next time I fight these battles, I will be prepared!