[neilh20]

@d_manning just wondering if you have had any insights 🙂

[neilh20]

.

[neilh20]

As you say from 2nd sept – something changed, after that it looks to me like its is triggered by the temperature changes. Its just a visual analysis, but also using the conductivity. With a rain event the conductivity also typically changes, and of course temperature can change.

For daily diurnal cycle after sept 2 the temperature starts varying by about 3C a day. before that it was about 2C a day.

The Metros_hyrdos21 Gen2 specification says “NOTE: Depth measurement accuracy assumes no abrupt temperature variations”  .

All depth sensors/piezo resistive sensors have a temperature co-efficient, and typically have some form of temperature compensation to correct for changing temperature.   For some reason something changed Sept 2 – you might have to forward the info to Metros and see if they can make any suggestions

Attachments:

1. 

   Screenshot-2024-10-14-170239.png
   

[neilh20]

Just wondering if you could post a link to where the data is being collected, and look at it as a system.

[neilh20]

Oh interesting, Thanks for sharing,   Sounds like it connected some of the time, showing that it was possible to connect.  I’ve found there are four source of failure – setup to cell tower,  TCP/IP setup, POST ack,   MMW timeout,

I found this  hardware data sheet – but it turns out there is a GM1 and GM2 – GM1 is the low power. I wonder which one you got?. https://mm.digikey.com/Volume0/opasdata/d220001/medias/docus/6378/XB3-C-GM2-UT-001.pdf

SUPPLY VOLTAGE 3.3 – 4.3 VDC
AVG TRANSMIT CURRENT (LTE-M) 1.25 A peak, 410 mA average (GM2 modules), 450 mA peak, 200 mA average (GM1 modules)

I was just wondering is the Mayfly 1.1 likely to handle the GM2 peak? though peaks are always a difficult number, as it should specify somewhere the capacitor (or pulse width) needed to handle that peak.

The XB3-C-A2-UT the data sheet .

SUPPLY VOLTAGE Standard Version: 3.3-4.3VDC;
PEAK TRANSMIT CURRENT Standard Version: 550mA;
AVG TRANSMIT CURRENT 235mA

For the low power (GM1) version of fw,

https://hub.digi.com/support/products/digi-xbee/digi-xbee-3-global-lte-mnb-iot/

and found this User Guide (I had to feed a few dragons tasty data on the way there)  https://www.digi.com/resources/documentation/digidocs/PDFs/90002420.pdf

https://www.digi.com/resources/documentation/digidocs/90002420/default.htm#containers/cont_at_cmds.htm?TocPath=AT%2520commands%257C_____0

I have had this recent email for a survey on Digikey,  (pasted below, hope it comes out ~ feel free to click on what you think)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Thank you for taking the time to participate in this survey.

Ron Konezny
President & CEO
Digi
<table border=”0″ cellpadding=”0″ align=”center”>
<tbody>
<tr>
<td>
<div>What is your overall impression of Digi?</div></td>
</tr>
<tr>
<td>
<table border=”0″ width=”100%” cellspacing=”5″ cellpadding=”0″>
<tbody>
<tr>
<td>Very favorable</td>
</tr>
<tr>
<td>Somewhat favorable</td>
</tr>
<tr>
<td>Neither favorable nor unfavorable</td>
</tr>
<tr>
<td>Somewhat unfavorable</td>
</tr>
<tr>
<td>Very unfavorable</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
 

[neilh20]

@tumayflybearriver – thanks for brining it up.  Its nuts, but  looks to me like the signature of  “thrown away data” by  ModularSensors software that runs on the Mayfly, and the ODM2  software on monitormywatershed.

I’ve raised the issue of reliable delivery in 2018, and implemented it on my systems and offered it to the mainline ModularSensors

The story   https://github.com/EnviroDIY/ModularSensors/issues/194

https://github.com/ODM2/ODM2DataSharingPortal/issues/485

At the request of some SWRC parties last year I submitted it to ModularSensors main software,  but other priorities came up and it seems it was abandoned when it was nearly integrated into the mainstream.

Otherwise, to verify for your specific node,  Shannon is right. Its looking at what is stored on the csv file and is that data on line. Might be just easier to use the .csv periodically.  If its on the .csv and not MMW – then it was collected and “thrown away” by the software.

I’ve done it with my tests systems that where local to me – and it was a lot of work to get my forked version of ModularSensors reliable. I’m very happy with the data that my systems as part of TU N california are collecting.

The story for my TU systems in N California .. https://www.envirodiy.org/n-ca-mayflys-through-the-winter-storms/

Its great that ModularSensors is open source, and I’m very happy with my fork which anybody else can use as well .. https://github.com/neilh10/ModularSensors/wiki

happy to chat about what I think it takes to improve system reliability if interested, but you can also look at my blogs on it over the years 🙂

[neilh20]

Hey thanks for the reference. I’ve also been monitoring blynk .

Do you offload the data regularly? – that seems to be the big gotcha is figuring out how often to download data.

[neilh20]

Hi @braedon-dority, my take is that the first step is to have personal documentation to be able to repeat your work, and that you can read it. Just to be basic, part of the learning is how to do documentation that you can then read your self.

Personally I find I come back to a working sensor some years later – and then want a traceable reference to what it exactly is it, and how do I a) repeat it b) modify it.     For instance I still have a sensor working that records my tipping rain gauge – totalizer raindrop counts – and posts to Thingspeak  – but was using a platform I stopped using. So I want to know what it does, but if I think of repeating it, I’m likely to try and do it differently.

So yes I find a very specific wiring list, often on a spreadsheet, but can be a document. A picture is good as its often worth a  thousand words. For me the hardest part is often slowing down enough,  to review the documentation and see what might be obvious that I am leaving out.

The fritzing I take to be away of presenting to other people to help them understand. That is so much more work to do, to become an “influencer” or teacher.

Anyway just my take 🙂

[neilh20]

Congrats – nice to see.

I guess the fundamental problem of power management is still there and can bite any time the power drops – and then likely will require a site visit to get the site restarted. Getting enough power is a band aid to enable reporting readings. So long as the power supplied exceeds the power used by a good margin it works. 🙂 I’ve found the real fix is in software using higher voltage thresholds – but it causes tradeoff

Its interesting the shape of the 2nd charging pulse – indicates lost data.  Stepping to the larger graph, its more visible.

So the next layer of reliability issues, with the fix being in software. I predicted the problem in 2018, and had a solution for it in 2020 that I’m using,

Orderly data delivery – Queue messages for later sending,

So just advertising there is a fix for it 🙂

 

 

Attachments:

1. 

   240223_1121-SpokaneR-SpkaneValley_Depth.png
   

[neilh20]

@jamesp  thanks for sharing. Interesting where the “banana skins” are to slip on.

Nice to know its got low quiescent current – end of last year I also  got the same  SanDisk Industrial MLC MicroSD SDHC UHS-I Class 10 SDSDQAF3-008G-I withs its specified Operating Temp Range: -25°C to 85°C , but haven’t measured its current 🙂

I’ve bought uSD with “white” so I can write on it to track individual cards.

I was using SanDisk Ultra SDSQUNS-016G-GN3MN 16GB (10 Pack)  for most of my systems – however it hasn’t got an outdoor temperature specification. I had a problem with some occasional resets on one of my systems, so I switched it to the above.

[Author]

Posts