Welcome to EnviroDIY, a community for do-it-yourself environmental science and monitoring. EnviroDIY is part of 
@neilh20
Active 1 days, 22 hours agoForum Replies Created
-
AuthorPosts
-
Hi @selbig an interesting idea.
I’ve been thinking about unattended access (of just equipment monitoring) and BT (low power) would be pretty nice. However as you are seeing there is a lot of co
Hi @selbig an interesting idea.I’ve been thinking about unattended access (of just equipment monitoring) and BT (low power) would be pretty nice. However as you are seeing there is a lot of complexity and some history with BT protocol versions that makes a simple concept a bit challenging. Sounds like for some reason BT is not associating with your phone. That of course becomes the issue if you have a logger device with BT how do you get it to associate with the right device, and from a canoe.
So I’m guessing from your description that you have a Mayfly logger above the water, in an environmental enclosure (IP65) and are powering it in some way.
Perhaps another idea that is almost as simple, is to use a USB cable
So you would like to paddle up to the enclosure, plug into it, and receive the readings.
There are some USB connectors that can be water tight, and sit on the bottom of the enclosure, assuming the water never rises as high as the enclosure.
The act of plugging in to the USB cause it to reset from a computer, (and might also do it from a phone App Android “USB Serial Terminal Pro” ~ I haven’t tried it) and you could do a test in software in setup() that if there is USB link ( with a time out of 10seconds to allow for a regular reset), to dump the contents of the data file.
One item to consider with an isolated unattended device is to be able to verify the “wall time” when collecting data from the logger. That is when getting to look at the data if the time series has “funny time” how do you connect the readings with what we think of us “wall time”.
One answer is that you may need to check it manually when collecting the data, and have the person collecting the data note the time they downloaded.
However if you have a USB cable connected, the time on download could be checked, and then if off, set through with a cmd line date/time setting.
Hi Sara, the short answer is no ~ which is a good.I’ve had some other urgent issues that have come up, and so have had to leave it for a while. In my test bench trial above over a couple o
Hi Sara, the short answer is no ~ which is a good.I’ve had some other urgent issues that have come up, and so have had to leave it for a while. In my test bench trial above over a couple of days with 2minute sleep/wake – 3 runs from reset – all failed after #1~5hrs #2 4.5+7.5 #3-4Hrs – so something happening after 100+ sleep/wake events.
Its seems like it must be software tickling the S6B in some way that it doesn’t like and something changed but not sure when. I’m still thinking about it.
I do have a system that I want to deploy using WiFi but its not a high priority.
At the same time another system 0.27.5, with fixed SDI-12, using Verizon/LTE CAT-M1 , has been stable. Its using a 15minute sensor reporting, and 2hour update schedule.
The WiFi S6B Vcc spec is very tight at 3.14-3.46V and the earlier trace showed that when the WiFi comes out of sleep, the current demand on the Vcc could be pulling it out of specification. In orderThe WiFi S6B Vcc spec is very tight at 3.14-3.46V and the earlier trace showed that when the WiFi comes out of sleep, the current demand on the Vcc could be pulling it out of specification. In order to check if the Vcc is causing the Xbee S6B WiFi modem a problem, I’ve put together a separate regulator based on the TCR3DF335,LM which regulates to 3.35V and can pulse to 400mA, with a normal spec of 300mA.SMT is so nice when you have the right parts. The TCR3D fits on a SC74 prototyping board with 1uF decoupling, and can fit between the LiIon bat at 4.2V and the LTE Adapter board that carries the X6B and plugs into the Mayfly.
Looking at the trace the Vcc power is much smoother and now well within specification. The Salaea Vcc probe on S6B Vcc, measures close to 3.35 (3.26V), then when S6B turns on drops to 3.31V. When the S6B has a power draws, it drops to 3.28V for up 1.5mS. All within good headroom from the lower 3.14V.
Trace of when the S6B initialization sequence below.
So now just need to let it run for a few days to see if it makes a difference.
I’m testing the stability of the Mayfly with the Digi WiFi S6B with software using the 0.27.5 base., running off the LiPo battery.Some of the the WiFi S6B hybrids initially connect to the WiFi
I’m testing the stability of the Mayfly with the Digi WiFi S6B with software using the 0.27.5 base., running off the LiPo battery.Some of the the WiFi S6B hybrids initially connect to the WiFi network, get NIST time, and then later after a couple of cycles of sleeping/waking will no longer connect to the wifi. I’ve connected a Salaea Logic Analyzer (8 Channels) to a number of pins on the WiFi S6B, and its showing problems with the power rail. The S6B hybrid has a tight specification for Vcc of 3.14 to 3.46V
With power supplied from the USB +5V rail(500mA)+LiIon, the Salaea Analog channel shows the Vcc at 3.266V, and when sleep req is activated, there is a 20uS glitch to 3.118V.
RF devices require good decoupling, and the LTE adapter has this decoupling. I’ve modified an LTE adapter to take power from the Mayfly Vcc ~ nominally 3.3V – and feed it into the LTE adapter’s power socket. I’ve also added a large capacitor 680uF with Low Series ESR 68mOhms to the 2pin power socket. (Wurth 860080274013)
I expect this to smooth any power surges from the S6B.
With Battery Power LiIon nominally 4.2V, and this carrier board, on power up, after reset there are some extended power spikes of 4mS, that dips from 3.229V to 3.06V.
After running for over 8hours on an speedy soak test cycle of sleeping/waking taking readings and POSTing to MMW every 2minutes successfully – it starts failing to connect to the local WiFi. Its left running for the next 48hours over the weekend, and fails to reconnect.
Just wondering if there are any suggestions?
I’ve received more “LTE Bee Adapter” cards, and looking to experiment using it to investigate why the Xbee WiFi S6B is not reliably connecting to the local wifi network. https://giI’ve received more “LTE Bee Adapter” cards, and looking to experiment using it to investigate why the Xbee WiFi S6B is not reliably connecting to the local wifi network. https://github.com/neilh10/ModularSensors/issues/21The LTE Bee Adapter card provides power directly from the LiIon battery, control of the Xbee reset, and potentially also an Xbee power OFF capability.
The WiFi S6B is specified for 3.14 to 3.46V so this isn’t a good long term solution. The LiIon Battery can be up to 4.2V.
Part of my tests are to let the LiIon battery discharge, as might be expected in the field with little sun, and then incrementally charge it back up, as solar is available, possibly over days. This is one of the most difficult parts of powering (and testing), slowly varying power availability. This appears to be causing some unreliability, and I haven’t yet been able to identify if it is something in my setup or something else.
Part of LiIon battery discharge characteristic, is its voltage drops and internal impedance rises. The priority is to keep the Mayfly running, with good traceable wall time, taking sensor readings (with wall time) and then transmit (when power available) to the internet. The rate of voltage drop, and impedance rise, is dependent on the capacity of the LiIon battery. I’m standardizing on a 4AHR outdoor (-10C?) rated battery. LiIon impedance also rises as temperature drops. So there is a narrow window of when the battery, as measured by its voltage, can support the highest dynamic power demand – typically when using RF power. For the real world, discharging a 4AHR battery can take a week, which is a good thing normally, but for testing I’m having to be creative.
So the first part of the test with WiFi S6B/LTE Bee Adapter was to see if it would get into the state of not connect to the WiFi network -~ and if did, would the RESET bring it out. However in overnight/24hrs it has connected to the WiFi every time as expected. So that’s a good thing. (Though MMW POSTs gave my a “201” in 500mS about 1-in-5 times, with the more typical no response timeout being 3000mS)
So going to go to back to standard powering WiFi, but with logic sensors on the WiFi S6B, and also add 0.1uF ceramic decoupling capacitance directly to the WiFi module pins, which will allow me to monitor the Vcc as well as logic sensor.
Well after running for some time with the WiFi S6B, and still having problems after it has been running for a couple of hours,
I’ve switched to one my target field internet comms of Digi XBee3 LWell after running for some time with the WiFi S6B, and still having problems after it has been running for a couple of hours,
I’ve switched to one my target field internet comms of Digi XBee3 LTE-M over Verizon.Very interesting the Digikey RevXsystems https://dataplans.digikey.com (thanks to @mbarney for the suggestion) has a new low cost 50M/month CAT-M1 plan.
Wow this is excellent!. Based on some recent past experience with a marginal/failing system this is going to be worthwhile.Since this was a new Xbee3 LTE, I have upgraded the Xbee3 to the latest software using the Digi “TH Development” board. Then with on the LTE adapter on the Mayfly, I plugged in the battery. At its core the sw is @srgdamiano hard sweat with DigiXBeeCellularTransparent.cpp, though I have modified it to show the connecting process to the cell network.
Since connecting for the first time over LTE and Verizon is such an occasional event, I thought I would paste in the trace.
It connected first time… (whew!)
Attempting to connect to the internet and synchronize RTC with NIST
This may take up to two minutes!
Lte internet comms with Digi XBee3 Cellular LTE-M IMEI OK HwVer 4B48 FwVer 11417
Loop=Sec] rx db : Status ‘ Operator ‘ #Polled Cell Status every 1sec
0=7.89] 0:0x22 ‘OK’
1=8.91] 0:0x22 ‘OK’
2=9.93] 0:0xff ‘OK’
WATCHDOG ISR barksUntilReset 149 <–WatchDogAVR
3=10.95] 0:0xff ‘OK’
4=11.97] 0:0xff ‘OK’
5=12.99] 0:0xff ‘OK’
6=14.01] 0:0xff ‘OK’
7=15.04] 0:0x22 ‘OK’
8=16.06] 0:0x22 ‘OK’
9=17.08] 0:0x22 ‘OK’
10=18.10] 0:0x22 ‘OK’
Try +CREG ‘
11=19.13] 0:0xe ’22’
WATCHDOG ISR barksUntilReset 148 <–WatchDogAVR
12=20.15] 0:0x0 ’22’ Cnt=1
13=21.17] 0:0x0 ’22’ Cnt=2
14=22.19] 0:0x0 ’22’ Cnt=3
Digi Xbee3 setup Sucess. Registration ‘ 0 ‘
mdmIP[ 1 / 16 ] ‘ 0.0.0.0 ‘= 7
mdmIP[ 2 / 16 ] ‘ 0.0.0.0 ‘= 7
WATCHDOG ISR barksUntilReset 147 <–WatchDogAVR
mdmIP[ 3 / 16 ] ‘ 0.0.0.0 ‘= 7
mdmIP[ 4 / 16 ] ‘ 0.0.0.0 ‘= 7
mdmIP[ 5 / 16 ] ‘ 100.104.156.99 ‘= 14
XbeeWLTE IP# [ 100.104.156.99 ]
0 ] Connect time.nist.gov
WATCHDOG ISR barksUntilReset 146 <–WatchDogAVR
WATCHDOG ISR barksUntilReset 145 <–WatchDogAVR
1 ] Connect time.nist.gov
WATCHDOG ISR barksUntilReset 144 <–WatchDogAVR
NIST responded after 2562 ms
Internal Clock within 5 seconds of NIST.
Putting modem to sleepSome status – the periodic Mayfly RESETs turned out, I think, to be happening when polling the Insitu LT500 gauge over SDI12. https://github.com/EnviroDIY/ModularSensors/issues/344The new code bre
Some status – the periodic Mayfly RESETs turned out, I think, to be happening when polling the Insitu LT500 gauge over SDI12. https://github.com/EnviroDIY/ModularSensors/issues/344The new code breaks the polling of the Insitu LT500, I’m doing debug under various scenarios to try and under stand it.
https://github.com/EnviroDIY/ModularSensors/issues/346I’m seeing instability on the WiFi S6B hybrid that I didn’t see on the 0.25.0 release. It is repeatable, but doesn’t make a lot of sense to me at this point – so maybe its driver error. https://github.com/EnviroDIY/ModularSensors/issues/347
My next step is to try and do a poweroff of the WiFi S6B instead of Sleep using the LTE Bee Adapter.The latest release of ModularSensors 0.27.0 has a new simple electrical conductivity sensors ~ AnalogElecConductivity.h/.cppThanks to Sara for accepting it as a MS sensor and formatting it to th
The latest release of ModularSensors 0.27.0 has a new simple electrical conductivity sensors ~ AnalogElecConductivity.h/.cppThanks to Sara for accepting it as a MS sensor and formatting it to the latest documentation style. See the amazing Doxygen generated https://envirodiy.github.io/ModularSensors/group__sensor__analog__cond.html
Sara has also added to example/menu_a_la_carte.ino
See Variable* analogEc_condIts a “simple sensor” ~ meaning low cost low resolution using the Mayfly mega1284’s ADC 10bit.I should emphasize as released, all calibration and determination of fitness for purpose. safety analysis for specific usage, is on the user.Its based on a standalone Mayfly sensor I built for monitoring “Stream Disconnect”.The purpose is to measure when a stream’s level hydrograph is dropping, and to be able to determine approximately when the stream’s flows “disconnect”. In recent studies for streams in the dry Mediterranean Western USA this is a significant event for the streams biology.I hope to do a separate discussion on the full unit I built, including a separate interface board but that will have to be for later. The wip is at https://github.com/neilh10/ModularSensors/wiki/Stream-Disconnect-EC-MonitorHi Matt – well been watching the output of the LC709203F with some other testing. It does work for the accurate battery voltage measurement.However the LC709203F “%” capaci
Hi Matt – well been watching the output of the LC709203F with some other testing. It does work for the accurate battery voltage measurement.However the LC709203F “%” capacity could be challenging to use. There is a lot of technical discussion about battery fuel gauges and what works and doesn’t. Another device that I got was the Seeed LTC2941 which only measures coulombs/mAHrs .
https://www.seeedstudio.com/Grove-Coulomb-Counter-3-3V-to-5V-LTC2941.html
I’m figuring out it needs to be accurate battery voltage ~ for basic battery “gauge” status, and also measure mAhrs to be able to characterize activity (or field monitor) while awake. My test system with Xbee S6, periodically goes into some sort of lock up and consumes current, and the only way to recover is to unplug the battery. For the Xbee LTE carrier board it can be turned off if this happened.
The LTC2942 does coulombs and battery voltage – except no cheap board with it that I’ve found.
An fun link about “orchestrating power” from some work being done at CMU on dealing with power – https://youtu.be/eAhVdSCdv08
Wishing you a good safe thanksgiving – great time of year for giving thanks 🙂
My experience is that its not capable of that.I have been doing a lot of testing in pushing up readings to test Mayfly reliable data delivery algorithms I have evolved. I have in some cases had 60
My experience is that its not capable of that.I have been doing a lot of testing in pushing up readings to test Mayfly reliable data delivery algorithms I have evolved. I have in some cases had 6000 points to push (ie 60days of unreported readings at 15minutes per reading), and MMW has been very slow, often after a small number (~10) of POSTs it will timeout – no response after 5seconds.
An observation I would make is that fast data – 1second pushes – is a different type of data collection .
My guess from looking at the MMW POST is that traceability and security of the readings has been prioritized over speed. ThinkSpeak and other servers discuss fast posts and have less data on each POST https://thingspeak.com/prices/thingspeak_standard
So for anybody needing fast post, ThingSpeak supported by ModularSensors would be the way to start.
A MMW post looks like this – which has a lot of text overheads – from a fast post architecture, the core data is in bold.
POST /api/data-stream/ HTTP/1.1
Host: data.envirodiy.org
TOKEN: 7ff7ae1b-9274-4376-afa8-8bf5a64f9b4f
Content-Length: 370
Content-Type: application/json{“sampling_feature”:”42c01940-952e-4a68-9d34-f8203cd0dd18“,”timestamp”:”2020-11-13T15:00:00-08:00″,”737aacd2-0259-4be1-9190-07308b9fdae4″:1,”479f16f0-1e46-4d3e-8a80-286b7997608e”:4.079,”2d2b543e-a721-4393-8a9f-f3f928d04ac3″:-9999.00,”d81f73a0-5c02-4b19-8280-13514bd6b4bf”:-9999.0000,”ec937dc1-a40e-41e3-946f-443f3af680ba”:-25}
-
AuthorPosts
