[neilh20]

@dan-wachusett Gosh just seeing this – seems like you got that Keller CTD.

Just wondering did you follow the advice given from https://www.envirodiy.org/topic/keller-ctd-sensor/#post-16332

Partly its decoding the layers of software. The keller protocol is used to access the Keller CTD map. I find it most helpful to compare and trace how different keller instruments are handled by the enviroDIY keller. If you only have one Keller Instrument on your line, then you are getting a response from that instrument  – you may need to interpret the data that is coming back and find a path to getting working readings.

 

[neilh20]

Some recent posts here explain the current difficult environment for calculating power usage on the mayfly as its dependent on a fast response from the server.

https://github.com/ODM2/ODM2DataSharingPortal/issues/649#issuecomment-1561690674

My implementation is to ensure that there is sufficient reservoir of power in the battery for taking sensor readings, and when the battery power is “low” (3.8V) not to use it for Modem Communications. My reliable delivery algorithm POSTs the reading to MMW,  and if it gets a bad (not a  201)  then stores it to a queue on the uSD. Only if it gets a good 201 ACK from the server, it then attempts to POST all the historical queued readings.

On experiencing a recent virtual month long outage on the MonitorMyWatershed the voltage response on the battery can be seen here

https://monitormywatershed.org/tsv/TUCA_PO03/4805/

as it attempts to push the historical queued data to MMW  however the biggest user of power is the 504 timeouts of ten seconds while waiting for a non response from MMW.

 

 

Attachments:

1. 

   TUCA_PO3_battery-voltage_droop-230524_1246.png
   

[neilh20]

Well, I’m back at my desk, with a Mayfly and powered it up, and I’m posting to

Host: monitormywatershed.org

and getting

— Response Code — 301 waited  326 mS Timeout 8000

If I change it to

Host: data.envirodiy.org

— Response Code — 201 waited  577 mS Timeout 8000

From   https://github.com/ODM2/ODM2DataSharingPortal/issues/542

aufdenkampe commented on Dec 20, 2021

so, the main host URL that you should be using on devices is monitormywatershed.org. For a couple of years now, data.enviroDIY.org is just a DNS alias that will get redirected to monitormywatershed.org, even for POST requests from devices.

However it seems I got out on the “bleeding edge”  because somehow
https://github.com/EnviroDIY/ModularSensors/blob/master/src/publishers/EnviroDIYPublisher.cpp#L21

const char* EnviroDIYPublisher::enviroDIYHost       = “data.envirodiy.org”;

Also seems discussed here

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

@aufdenkampe @heather @srgdamiano – just wondering where the source of truth is for this URL. ?
https://github.com/ODM2/ODM2DataSharingPortal/issues/658

[neilh20]

@rogers1313  gosh its all depends on the software you are using – what’s the version of software and the source. Since its open source software and hardware, and you can look at the software – its possible to guestimate those answers. Then since its software that causes the most power usage, it needs testing.

For a turnkey system, assembled off the shelf, those are reasonable questions to ask (and have tech support pay for).

For the solar  being unavailable due to a storm – I use a target  figure of two weeks.

I’m a fan of ModularSensors software and also a critic, with ways of solving the problems. I believe i’m one of the few people to publish the power usage I’ve got..

The Mayfly 1.1 is better at battery voltage measurement than the 0.5, but read some of my blogs on measuring battery voltage.

The standard release  transmission software doesn’t have reliable message delivery built in, and the standard software is also IHMO really really really bad at managing power.

The simplest way of answering your question – build the system you want, delivering readings to MMW, put in a voltage measurement off the battery, and then let it run for 1week or 2 weeks and see how the voltage drops on the battery. If possible share the results here as well.

From my measurements, the biggest user of power is posting to MMW. MMW in my experience has a wide range of of how long it will take to respond, including no response.   I default to a timeout of about 20seconds for a no response, but it can respond with successful POST ‘201’ in as little as 0.4Secs.

I have shared  multiple postings of my power usage measurements, and what I’ve done to make the power usage more efficient – and in the end it depends on your application and how reliable you need it to be –

Just my 2cents.

[neilh20]

I  wonder if there has been further insight.?

It seems a real challenge to phrase how to have real world reliability. It seems to be such a hard concept to discuss and define how to get there. Its a standard Computer Engineering problem, and it typically requires a commitment to make it happen, and a reference model to test the implementation.

[neilh20]

Thanks for looking into it.

I’m in the UK for my Uncle who had a stroke, and I took off very quickly from California,  and not likely to get back before the end of May after his funeral. I haven’t brought any tools to see what the response are from the server.

It seems very unlikely that 5 systems would all stop transmitting by themselves. My three systems, for power saving, only transmit every two hours, and then they transmit 8 readings with 1second pacing between readings. So they would typically  attempted to transmit  2hours after the  last readings all successfully received. However if the server only responded with a 201 to the first of the  8 and then no response to the other 7- then technically in wall time terms they could be trying 3hrs 45min later.

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

I have seen blocking issues that have come up in the past, and wonder what could cause them

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

 

 

[neilh20]

Hope it works  – be fascinating to get an overview of the project when you have time 🙂

[neilh20]

@ckillen sorry to hear about the problems  – I make the assumption that a sub-module can always lockup, and may need a hard reset/power cycle to bring it back. Internal modem software can only be as good as its tested, sub-modules  comms software is complicated and its very difficult to test for all cases.

The Maylfy1.1 now supports a power off capability as well as reset. I treat lab found conditions like you are talking about as a golden opportunity to build in simple reliability – repower, reset. Intermittent field problems are too hard to figure out.

I find it really doesn’t work to give field technicians (or even PhD hydrologist) a training in how to remove a 20pin modem and reinsert it in hot and sweaty field  conditions, and also how to have a u.fl antenna stay affixed. “You want what!”

It could also be that the modem power has been turned off, and the device is not working.

I have it such that the modem stream monitor can be enabled from the build command line (or platformio.ini).

I should note it probably is only able  to work with the modem UART stream Serial1 running at a slow 9600baud and the SerialTerminal running at faster 115Kbaud

C++

HardwareSerial& modemSerial = Serial1; // library! https://github.com/vshymanskyy/StreamDebugger #if defined STREAMDEBUGGER_DBG #include <StreamDebugger.h> StreamDebugger modemDebugger(modemSerial, STANDARD_SERIAL_OUTPUT); #define modemSerHw modemDebugger #else #define modemSerHw modemSerial #endif // STREAMDEBUGGER_DBG

1 2 3 4 5 6 7 8 9

HardwareSerial& modemSerial = Serial1;   // library! https://github.com/vshymanskyy/StreamDebugger #if defined STREAMDEBUGGER_DBG #include <StreamDebugger.h> StreamDebugger modemDebugger(modemSerial, STANDARD_SERIAL_OUTPUT); #define modemSerHw modemDebugger #else #define modemSerHw modemSerial #endif  // STREAMDEBUGGER_DBG

I haven’t yet tried the SIM7080, still using the Digi LTE modem (I  fortunately got enough stock).

In the extreme, last year  I used the IP protocol monitor stream debugger WireShark to actually see what was going on the line, and to check for  the HTTP response. However this is a pretty difficult setup to get right.

 

[neilh20]

Great @ldecicco  – one area to note with “pio pkg install” is how it becomes part of your build process.  I like to have a development build environment tree.  Then a final “release” environment – and attempt to take a full snapshot of all libs used. I encapsulate the difference in text instructions and operation of the platformio.ini.

[neilh20]

@rogers1313 interesting question, and I’ve been mulling over possible solutions as it seems very attractive.

The area undefined , is power,  cost of the cellular gateway, and reliability of the connection.

Its possible to do the individual elements easily – 900Mhz point to point –  and cellular – but then introduce a packet with the “readings in JSON”, that has to be pushed between the two, and also manage the resultant handshake ACK to ensure reliability of delivery.

One way to think of it might be with LoRa 900Mhz to a LoRa Gateway on Cellular. The power usage for a cellular gateway may become an issue if its solar powered.  With the physical layer and the output on a say ThingsSpeak LoRa WAN, now  the readings needs to be pushed to a server. MonitorMyWatershed doesn’t easily support that interface, but there are other servers that might be turnkey, and there is then the need to configure the server interface.    Be interested to see if other people have ideas 🙂

[Author]

Posts