But it worries me that this seems to be at 54V. I’d expect higher absorption voltages for a lead acid battery, 57.6V even.
But, I also see that yesterday your lowest battery voltage was 50.7V. The Multi will only go back to absorption if the battery drops 5.2V below your float voltage, which is 48.8V for you. Basically, because you cycle the battery so shallowly, it remains at the lower float for long periods. And this is actually perfectly fine, but it explains why there isn’t an absorption cycle. Usually we set up the BMV so that it only auto-syncs the SOC at a voltage higher than float, so if you spend days without a good cycle, there may be some SOC drift.
So that is probably all that is going on. Give the battery a nice punch so it drops to 48.8V and then let it recharge.
Thanks Louis. I did so and selected that XLS option.
But it seems this takes some time? 10 minutes later and I still don’t have anything. When I clicked again it says that a data download is still in progress.
Surely this can’t be more than a few megs worth of data? Wonder why its taking so long.
VRM did had a backlog this morning/yesterday. Might be still from that.
File creation is an process expensive operation in the cloud, so they tend to be put in que with all the rest of those requests. It is not related to your data being large, but rather how long the que is.
For downloads less than 24 hours, the download is immediate and takes maybe 10 seconds. For longer downloads, you will later receive an email with a link to download the file.
Long downloads is kinda heavy on VRM, always better to keep it short. I usually narrow it down to around the time period I want using the data selection tool on the Advanced page, and only then do I pull the data.
Most likely if you have moved away from that page it will not download. Unless they did something nice for us users and it will be mailed. I’m not sure what VRM will do in this instance.
This is actually a pretty neat way of doing it. We also have a cloud service and basically just have things split up between a ‘main’ queue and a ‘low priority’ queue with the statistical uploads and downloads being low priority, which sometimes mean a bit a wait before the service bus picks the job up and processes it.
It’s an entirely different market though, but in our case we have a CSV for the last 6 months (including the current) that’s readily available and updated when statistics are uploaded which makes the download quicker. This obviously won’t work here, but it’s just interesting to see the differences.
It’s using the Azure service bus for message brokering and queues. I don’t do the dev work though, but I’m guessing as it’s built as a cloud service on Azure it was easy to use that. It’s also only 0.2% of our monthly Azure bill.
