[neilh20]

James, gosh nice to see systems up and going, seems like the TSA interface is being rebuilt
https://github.com/ODM2/ODM2DataSharingPortal/issues/512

[neilh20]

For my fork https://github.com/neilh10/ModularSensors/releases/tag/v0.30.0.release1_211023
I got the WiFi S6 communicating reliably, and its been testing for over a couple of weeks.
It seems on going to sleep, it really wasn’t doing what was necessary to be able to sleep. It seemed to be leaving TCP/IP links setup. Which then depending on network timers, might be there when it wakes up. If the sleep time was short enough it would still have the link available. Since it used to work, probably what happened was a timer somewhere else (MMW) was reduced. The cure in the end was on sleep, change the destination IP to local:, and then sw reset the device. Then when it wakes up, it reconnects to the SSID, and then setups up the TCP/IP to the remote MMW.
https://github.com/EnviroDIY/ModularSensors/issues/347 describes the issue

[neilh20]

Thanks for sharing. Great project and good to hear benefits of low cost networking.:) Good luck with it.

[neilh20]

Always a lot of work getting a new revision out and running compatibility tests. I’ve admired the way
Paul Stoffregen of PRJC created a fishbowl for the releases, one I remember with the Teensy had a process of managing/advertising the release and being clear about it being in beta https://forum.pjrc.com/threads/27689-Teensy-LC-Beta-Testing

@shicks (and sarad) I wonder if that would work to help?. I’m sure some people don’t want to touch it until the kinks are ironed out, and others happy to volunteer to be on the cutting edge (hopefully not too much of a bleeding edge).
Of course, with a fish bowl, and keen interest in the hardware, its always nice to see the list of tasks to be completed before releasing, and how far through them, and then don’t have to ask every two weeks how its going 🙂

[neilh20]

Sara captures all the libs specified as part of the release procedure https://github.com/EnviroDIY/ModularSensors/releases/tag/v0.30.0 look for ModularSensors_Dependencies_v0.30.0.zip

I’ve not had any issue with 0.30.0.. The tests are heavily utilizing the SD for reliable web delivery, storing them to uSD, before a POST.
I do a build from scratch including pulling all the libs when I do a release.
https://github.com/neilh10/ModularSensors/releases/tag/v0.30.0.release1_210831

Building 210831_1234
Dependency Graph

|– <EnviroDIY_ModularSensors> 0.30.0+sha.bc3dd0e
| |– <EnableInterrupt> 1.1.0
| |– <SdFat> 2.0.7
| | |– <SPI> 1.0
| |– <TinyGSM> 0.11.4

[neilh20]

What’s the battery size (maHr)  and solar panel (W)?.  Also which port do you plug the solar panel into?

I’m wondering though, you are also sampling every 5minutes, do you need it to be that frequent? Would 15minutes work?

Interesting, it does seem to be a sudden V drop. Looking at the raw readings on the downloaded csv it is also oscillating from 4.1V to 3.6V a couple of times, which seems very unlikely in real life. Time snip at UST 2021-08-25 14:00
<table width=”344″>
<tbody>
<tr>
<td width=”140″>time</td>
<td width=”140″> time diff</td>
<td width=”64″>V</td>
</tr>
<tr>
<td>2021-08-25 14:00</td>
<td>0:05</td>
<td>4.094</td>
</tr>
<tr>
<td>2021-08-25 14:05</td>
<td>0:05</td>
<td>3.563</td>
</tr>
<tr>
<td>2021-08-25 14:10</td>
<td>0:05</td>
<td>4.094</td>
</tr>
<tr>
<td>2021-08-25 14:15</td>
<td>0:05</td>
<td>4.094</td>
</tr>
<tr>
<td>2021-08-25 14:20</td>
<td>0:05</td>
<td>3.563</td>
</tr>
<tr>
<td>2021-08-25 14:25</td>
<td>0:05</td>
<td>3.563</td>
</tr>
<tr>
<td>2021-08-25 14:30</td>
<td>0:05</td>
<td>4.154</td>
</tr>
<tr>
<td>2021-08-25 14:35</td>
<td>0:05</td>
<td>4.139</td>
</tr>
<tr>
<td>2021-08-25 14:40</td>
<td>0:05</td>
<td>3.563</td>
</tr>
<tr>
<td>2021-08-25 14:45</td>
<td>0:05</td>
<td>3.563</td>
</tr>
<tr>
<td>2021-08-25 14:50</td>
<td>0:05</td>
<td>3.563</td>
</tr>
</tbody>
</table>

[neilh20]

Just an observation, once the hardware is working nicely, it often takes more software to manage that hardware 🙂  – it’s a broad subject when talking about power   –  the battery voltage encodes  battery type , solar panel sizing, solar aspect and vegetation  coverage, and when is the power used – all to get the readings to show reliably on the web through all the seasons!!

I include a “sample number” or sequence number in my recording, so I can easily validate the data (missing sequences) and processor resetting. (sample number goes to zero) . A sample number might help show happens when the dates jump.  Its ProcessorStats_SampleNumber() part of  ProcessorStats()

I also found in early testing,  I was getting resets at sunset (!) with small batteries, and standardized on using a 4.4Ahr battery. With a good solar aspect on a 2.5W solar panel, it charges in 8hours . Of course winter may not have that good a solar aspect, and typically has less sunshine unless its on the equator !! so I oversize the panel a little if I can, eg 3~5W

One thing for sure is that if the battery runs down completely, its a software issue on how it powers up  and recharges the battery, one of the challenges in a remote solar powered logger.   The “sample number” does help understand what is going on.

For my systems, it would take half a day to go and replace with a fully recharged battery (and who pays for all that time)  – I upgraded the software to better manage the voltage. I also use  “reliable delivery” of readings to the web, so when the voltage is low ( I use 3.8V on 4.4Ahr) the rest of the power is reserved for just reading the instruments. This can keep it working during a two week storm with no solar. Then when the sun comes out (and the solar panel hasn’t blow over) the  battery charges back up, and it transmits all the stored readings.  The software is on my fork, (which anybody is welcome to use) and or could be migrated back into the main.

 

[neilh20]

Also seems to me the core issue is you lost charging /solar about the end of May.

Possibly the panels got over grown, or shaded out.

I have a separate LiIon charger ~ https://www.adafruit.com/product/1905 – but a spare mayfly also works.

Attachments:

1. 

   Screenshot-2021-09-24-1232_Ivy_Creek.jpg
   

[neilh20]

Good to hear that the gauges survived, and delivered the data.!!

Many thanks for the refresh on status  and  (target) date :). Very helpful.

[neilh20]

Just wondering any visibility on a timeline for new Mayfly, and what the new goodies are :).

I am looking at recommending it in an SSU Engineering project.

The first projection on availability was early August,  just wondering if there is anything that can be shared about the difficulties in them becoming available. I know some of these issues are challenging, and I appreciate tested boards,  visibility really helps in planning projects and alternatives. Many thanks.

 

[Author]

Posts