[neilh20]

Be interested to hear about the power measurements you make and tradeoffs in power management.

I’m including a Vbat/Coloumb counter monitor with an RS485 wingboard and optionally routing power from the LionBat. It uses the switched 3V3 and the switched 5V – but paying attention to having compatible Ioff when switched off.. https://github.com/neilh10/SensorModbusMaster/blob/release1/hardware/knh002-MayflyWingShield/rev4/knh002r4_rs485schematic.pdf

[neilh20]

Hi @mbarney  I have come across the I2C issue, and trying to remember what I did, or solution. There was an update that  could fix it, but of course that is a fork.

It might have been that a wrongly soldered I2C for a humidity device caused the problem for me. Arduino paradigm is typically normal use cases.

The Mayfly 0.5b has pullups R8 & 10 of 2K.  The ADS1115 board has its own pulls up of 10K.

https://learn.adafruit.com/assets/36145

The ADS1115 digital inputs are specified for 0-5.5V, which I think means they won’t take any current when turned off V=0. However the  boards pull down Rs would likely interfere with the operation of the pull ups R8&10

So I wonder if desoldering the  ADS115 boards I2C pull-ups would make a difference. Just a thought.

I recently used an LTC2942 directly connected on  the Mayfly I2C no pullups, it is similarly specified on inputs 0-6V.  I had no problem communicating on the I2C.

 

[neilh20]

I’d like to give my thanks to @srgdamiano for the excellent job in doing releases and also documenting them in different places including the platformio.ini . The git managed source control is core to being able to build reliable loads.  Absolutely amazing the distributed gits.

I still don’t quite follow all the release mechanisms, as they area also evolving, but just was trying to track through with examples\menu_a_la_carte\platformio.ini, which seems to pull in the latest via the latest specification of the libs through platformio

lib_deps =

    envirodiy/EnviroDIY_ModularSensors

is it actually pulling from a git on platformio, or are they pointed back to their specified links .? Many thanks again.

[neilh20]

found this

http://www.dfrobot.com/product-1073.html  TEL0073 Xbee TH BLUETOOTH 4.0  using Ti’s CC2540.  Digikey 1738-1014-ND‎

Seems to me there is a critical power issue;  how can a powered BT LE sleeping device plugged into a Mayfly,   wake a sleeping Mayfly once a remote BT LE beacon (cell phone) has been detected.  For the TEL0073 there is a mapping to an Xbee Socket Pins (Xbee9/D23,  Xbee12/D19 or  Xbee16/D20) that might work.

Ti’s CC2540 suggests sleep current is in the low 10’s uA (but not sure if this is monitoring for a beacon while asleep) .

BT LE 5.0 has 4 x longer reach at reduced data, not sure what other benefits it would have to a modular sensors configuration.

I haven’t had time to dig further into TEL0073 or HM-19. The Tel0073 looks attractive for simplicity of plugging into the Xbee socket.

 

[neilh20]

@selbig Wow thanks for sharing that. I’ve been thinking about BT for some time… and hadn’t seen how far it has come. There is also Blue Tooth Commander App  for Android  – so good for all types.

I’m just wondering how you are powering it.?

On powering, I’m really looking that it needs to be able to use low power, and then turn on when the CellPhone with BT is nearby and notify the Maylfy.  Low Power is a relative term to how much power is available.

Possibly DSD TECH HM-19 CC2640R2F has possibly more support for low power… and as BT 5.0 says could have 4times range. Haven’t looked through it yet.

The Digi Xbee LTE CAT-M1 also incorporates BTLE.

Some other resources I found

https://how2electronics.com/bluetooth-low-energy-tutorial-with-hm-10-ble-4-0-arduino/

https://how2electronics.com/nordic-nrf52840-advanced-bluetooth-5-arduino-ide/

 

 

[neilh20]

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.

 

[neilh20]

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.

[neilh20]

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 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.

 

Attachments:

1. 

   210119_TCR3F_3V35_LDO_init.jpg
   

2. 

   20210120_TCR3D_LDOann2.jpg
   

[neilh20]

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?

 

 

 

Attachments:

1. 

   210117carrierVccPulses.png
   

2. 

   210117carrierVccAfterResetA.png
   

3. 

   210117_LteCarrier-Small.jpg
   

[neilh20]

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://github.com/neilh10/ModularSensors/issues/21

The 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.

 

[Author]

Posts