Hi Jake, my take is its complex to be able to decode why MMW isn’t showing data ~ it needs a system look, location aspects (solar looks excellent) , maintenance inspection of site, reliability of hardware/battery/mechanics reliability of software on the Mayfly, reliability of software at MMW
It would be useful to know your configuration including battery capacity and make, software version upgrades, and site sensor/maintenance as well as a picture of the insides and any observations/pictures of condensation on the board or growths. As Shannon indicated for your particular station, it would be useful to compare it against the readings taken on the uSD, and look at the RSSI.
Clearly though, for all the visible parameters of good solar aspect, apparently working Mayfly – it would be nice if the data could just be available …. for maybe 5years … or how long?. A dream. 🙂 What does it take to achieve that, is pretty challenging.
However taking a download of data, see PMTU37-1_TimeSeriesResults_220517_1145.xlsx ~ and constructing a reliability story – – the system started pre-pandemic (had to throw that in) 2019 Nov 10th .. fast forwarding to 2022 Mar-1 and looking at the data – and time difference between samples, it looks to be just an occasional data loss. Then Apr 10 to Apr 20th there is a 10day loss, followed by losses that are in the range 4-13hours. Could this be what has been seen with https://github.com/ODM2/ODM2DataSharingPortal/issues/605
For your system, the dribbling losses, is that the main software does not support reliable delivery. That is the software takes a reading, attempts to deliver it to MMW and doesn’t verify its been delivered. Wireless for a specific location needs characterizing, think of the times when a cell phone doesn’t work, and then you need to shift around to find a place. As it appears cyclical, it could be that the wind changes in the afternoon, and reduces the signal strength. This might show if you could see the RSSI through the times its not reporting. Your station level of -77dBm appears to be good. The measurement is actually the measured signal strength from the last attempt, and your station numbers look reasonable once it starts up, though there are a few at -100dBm which is much worse than -77dBm
However the post 2022 Apr-28th many hours of losses are much more difficult to figure out – perhaps you could get a site visit swop out the uSD, inspect the board for visible signs of failure, and then share the uSD contents.
I do have reliable delivery working in my branch, and I have said I would submit to the main software git repository – a so called PullRequest (PR) but haven’t had the cycles to do it yet. https://github.com/neilh10/ModularSensors/releases . It also takes resources from Stroud to be able to accept it and do quality assurance testing – which is a challenging area.
There are two systems I put together that use the Mayfly 0.5b, Digi LTE on Carrier and 44000mAh, and appear very successful, except for what appears some intermittent failures on the MMW side in mid Apr, ending Apr 28th
https://monitormywatershed.org/sites/TUCA_PO03/ – it does have good signal strength of RSSI -57dbm
These data losses at MMW sorta look like your losses, so it could be intermittent MMW as whatever is causing https://github.com/ODM2/ODM2DataSharingPortal/issues/605 hasn’t been commented on.
On my system TUCA-Na13 since Apr 29th I saw one data loss on May 15, which I wouldn’t expect as it has reliable delivery and could be MMW. TUCA_PO03 has no losses since Apr 29th. Another system local to me https://monitormywatershed.org/sites/nh_LCC45/ that is over WiFi hasn’t had any data losses since Apr 29th
I am focused on a delivery of devices to a TU California project on the Russian River, and once complete in the next month hope to do the PR to the main software https://github.com/EnviroDIY/ModularSensors/issues/194 – which won’t necessarily help you, but may help future builds for more software reliability.