[neilh20]

For  powering I am using the new Solar2 connector.

It requires a very precise diameter solid core wire – and took me some time to find it as old fashioned “Bell Wire” 20AWG, which I got from local Lowes store.

The needs to be – 20-26 AWG solid core. It also needs exactly matched wire strippers. If the wire strippers are too small a dia, its likely to nick the solid core wire, making it more prone to failure.

The connector  is

“Phoenix 1778832″,”TERM BLOCK PLUG 2POS STR 2.5MM” and requires

or digikey https://www.digikey.com/en/products/detail/phoenix-contact/1778832/2625556

 

Another nifty new feature I found with Mayfly1.x is soldering the SJ17 LED10 Blue “- which at least for Digi modules is “network connection”.   It activates when the module comes out of sleep, then when the device is connecting to the network it flashes. And finally when it disconnects from the network it turns off.  A good help in checking operations, and slight waste of power for normal operation.  Normally I like to have a LED activate when there is maintenance activity – (say for 10minutes after reset,  or on a maintenance wake button press operation) but that has to be designed in at system level, either sw or hw and not figured that out yet.

 

 

[neilh20]

An update on measuring battery voltage. I’ve purchased a number of Mayfly1.1 for a project. And on testing one of this batch, the noise level of measuring LiPo is better – which is great.  The noise level of resistors is part of their  specification, or it might be just luck in this case.  Often a batch of noisy resistors is because the manufacture has selected out the low noise resistors.

The testing is at my office desk  – which as I am finding out, is also electrically a noisy environment.

For release testing I’ve moved it to an outside environment and the noise level is even better, which is soooo nice.

Here is the graph of the lower noise measurement, where there is a cutoff of transmitting data at LiPo=3.8V (measured from A6 Blue line) with a more accurate 12bit measurement (black line).

This is 4 days of testing, with accelerated 2min readings and if the LiPo V was above 3.8V immediately transmitted to MMW.  When it dropped below 3.8V it queued the readings. Then when the solar came back, charged the battery and the readings went up 3.8V, it transmitted the data.   The black line is the more accurate 12bit reading, which in this specific Mayfly the blue line A6 is fairly accurate.

Graph with Mayfly A6 and more accurate 12bit

Attachments:

1. 

   tu_rc_test_Sa01_220515_1758.jpeg
   

[neilh20]

Hi Jake, my take is its complex to be able to decode why MMW isn’t showing data ~ it needs a system look, location aspects (solar looks excellent) ,  maintenance inspection of site,  reliability of hardware/battery/mechanics reliability of software on the Mayfly, reliability of software at MMW

It would be useful to know your configuration including battery capacity and make, software version upgrades, and site sensor/maintenance as well as a picture of the insides and any observations/pictures of condensation on the board or growths.  As Shannon indicated for your particular station, it would be useful to compare it against the readings taken on the uSD, and look at the RSSI.

Clearly though, for all the visible parameters of good solar aspect, apparently working Mayfly – it would be nice if  the data could just be available …. for maybe 5years … or how long?.   A dream.  🙂  What does it take to achieve that, is pretty challenging.

However taking a download of data, see PMTU37-1_TimeSeriesResults_220517_1145.xlsx ~ and constructing a reliability story  –  – the system started pre-pandemic (had to throw that in) 2019 Nov 10th  .. fast forwarding to 2022 Mar-1 and looking at the data – and time difference between samples, it looks to be just an occasional data loss. Then Apr 10 to Apr 20th there is a 10day loss,  followed by losses that are in the range 4-13hours. Could this be what has been seen with https://github.com/ODM2/ODM2DataSharingPortal/issues/605

For your system, the dribbling losses, is that the main software does not support reliable delivery.  That is the software takes a reading, attempts to deliver it to MMW and doesn’t verify its been delivered. Wireless for a specific location needs characterizing, think of the times when a cell phone doesn’t work, and then you need to shift around to find a place.   As it appears cyclical, it could be that the wind changes in the afternoon, and reduces the signal strength.  This might show if you could see the RSSI through the times its not reporting.  Your station level of -77dBm  appears to be good. The measurement is actually the measured signal strength from the last attempt, and your station numbers look reasonable once it starts up, though there are a few at -100dBm which is much worse than -77dBm

However the post 2022 Apr-28th many hours of losses are much more difficult to figure out – perhaps you could get a site visit swop out the uSD,  inspect the board for visible signs of failure, and then share the uSD contents.

I do have reliable delivery working in my branch, and I have said I would submit to the main software git repository – a so called PullRequest (PR) but haven’t had the cycles to do it yet. https://github.com/neilh10/ModularSensors/releases . It also takes resources from Stroud to be able to accept it and do quality assurance testing – which is a challenging area.

There are two systems I put together that use the Mayfly 0.5b, Digi LTE on Carrier and 44000mAh,  and  appear very successful, except for what appears some intermittent failures on the MMW side  in mid Apr, ending Apr 28th

https://monitormywatershed.org/sites/TUCA_PO03/  – it does have good signal strength of RSSI  -57dbm

 

These data losses at MMW sorta look like your losses, so it could be intermittent MMW as whatever is causing https://github.com/ODM2/ODM2DataSharingPortal/issues/605 hasn’t been commented on.

On my system TUCA-Na13 since Apr 29th  I saw one data loss on May 15, which I wouldn’t expect as it has reliable delivery and could be MMW.    TUCA_PO03 has no losses since Apr 29th. Another system local to me https://monitormywatershed.org/sites/nh_LCC45/ that is over WiFi hasn’t had any data losses since Apr 29th

I am focused on a delivery of devices to a TU California  project on the Russian River, and once complete in the next month hope to do the PR to the main software https://github.com/EnviroDIY/ModularSensors/issues/194 – which won’t necessarily help you, but may help future builds for more software reliability.

 

Attachments:

1. PMTU37-1_TimeSeriesResults_220517_1145-from-220301.xlsx

[neilh20]

@James_NZ  – I’m curious, just wondering how many RS485’s stations are you looking at and your planning project timeline.

What sort of instruments/powering are you looking to connect to.

There is a forward looking discussion on issues here, though the timeline for anything being built, I’m guessing is really dependent on specific project drivers.  https://github.com/EnviroDIY/Mayfly-Modbus-Wing/issues/3

[neilh20]

For the solar connecter, I colour the socket and the jack in an acrylic orange so that there is a visual match. The LiIon battery in a cooler blue.   Of course have to be careful to only get the acrylic paint on the outside of the jack and not have leak inside. Its not perfect, but provides a little clue.

Attachments:

1. 

   PO03_EnclosureVert_20210604-Power-Connectors.jpg
   

[neilh20]

Suspect Mayfly1.1

The cable I was using also went bad and I’ve marked it as suspect – its a distinctive pink cable.  I’ve inspected the Mayfly USB c on Mayfly1.1 with an Eye Loupe, and it is hard to inspect but nothing jumps out, seems OK.

I did have a USB current monitor in the testing before hand, and the current had gone up to 1.2A while charging a 2.2Ahr battery – but difficult to know if it was related. However the Mayfly options are not set to do a high charge, just 0.5A.

I switched to Linux Ubuntu to get more details, and a sturdy USB-C interface and I get with working White Cable into Mayfly1.0

dmesg

[20236.503620] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3

[20236.503624] usb 5-1: Product: EnviroDIY Mayfly USB to UART Controller

[20236.503627] usb 5-1: Manufacturer: Silicon Labs

[20236.503630] usb 5-1: SerialNumber: 0001

[20236.565048] usbcore: registered new interface driver usbserial_generic

[20236.565911] usbserial: USB Serial support registered for generic

[20236.586585] usbcore: registered new interface driver cp210x

[20236.586749] usbserial: USB Serial support registered for cp210x

[20236.586863] cp210x 5-1:1.0: cp210x converter detected

[20236.594710] usb 5-1: cp210x converter now attached to ttyUSB0

 

but then insert into Mayfly1.1 it  doesn’t respond on the USB. It does get powered,

I think I have all the switches right, but here is a video https://photos.app.goo.gl/2n43i7qjLGmwbiQz7

 

 

[neilh20]

My USB connect to a rev1.1 board appears to be failing.

It was working, and now its stop connecting to the PC, stops even causing an audible ding.

If I take the same USB C cable and plug it in to the USB C of a Rev1.0A3 it sometimes works. Usually causes an audible ding, but sometimes doesn’t appear as a com port.

I’ve rebooted my PC twice, and left the Rev1.1 board powered off overnight to see if it might recover.

Just wondering any suggestions  for what might be the issue, or way of checking the driver.

I am seeing the boards work through the FTDI connector.

[neilh20]

One aspect of measurements the Mayfly does manage is the time. If the small battery gets used up, then it will reset to a default time. Another way of checking time is roughly accurate (+/ couple hours)  is when the peak temperature occurs.

[neilh20]

I’ve been chewing and reading about LoRa for some time, and just recently been reviewing as part of student engineering project the data flow for LoRa  and LoRaWan to TTN (The Things Network) and then to ubidots.

LoRa is designed as a long distance wireless protocol, however its also has constrained packet size.

So it seems to me, at this stage LoRaWan/TTN  is incompatible with MMW, as the POST to MMW use UUIDs for variables, which is a lot of overhead.

https://lora-developers.semtech.com/documentation/tech-papers-and-guides/the-book/data-packet-transmissions

So for LoRaWan/TTN to MMW, it would need some form of COAP support on the TTN gateway. A way of associating the KEYs and UUID, on the Mayfly, to be transmitted and stored on the TTN gateway.

To phrase it simply, the LoRa packet are small, to allow them to be delivered wirelessly over a long distance. To do that the variable need to be encode into the packet, and then on the TTN gateway decoded from the packet into a JSON format.

The Arduino.Cc offering has some good explanations https://docs.arduino.cc/learn/communication/lorawan-101

Though maybe somebody has figured it out, and we’ll all be pleasantly surprised  and amazed 🙂

[neilh20]

Here are some graphs of measured Vbat(10bit) with a software filtering that I’ve just completed. Its using a 2minute reading sample time – the electronic noise is hopefully similar when used on 15minute sampling intervals.
For the Mayfly 1.1 & Adafruit PkCell 4400mAh, I’ve run it for 4days interfacing over Modbus/RS485 in a critical voltage range of 3.85V dropping 0.2V to 3.65V.
Vbat is under reading the LiIon Voltage by 0.1V, and still having some noise break through during this period of 0.1V, but much better than unfiltered.
The two graphs are of the same period, one is from MMW that is a little easier to understand and annotated however has different scales for the Vbat/LiIonV. The second is from an xls graph, using the same scale, and has the quantization more visible.

My conclusion is when using Vbat for determing energy available – use a filtered version of Vbat, and be conservative with the estimated low battery voltage.

I can submit my Vbat software filtering if it would be useful.
neilh10/ModularSensors/blob/release1/src/sensors/ProcessorStats.cpp #175 only for AVR.

I use the Vbat threshold for determing when to cease reliable wireless transmission, and only store readings locally, ready for when battery energy is restored, and then bulk upload of readings.
neilh10/ModularSensors/blob/release1/src/BatteryManagement.h #192

Of course your specific LiIon battery may be different, the Pkcell 4400 is designed for cycle life > 500 charge/discharges (not specified for a daily partial discharge/recharge). Once working, the depth of the battery discharge could indicate when the battery needs replacing.

Attachments:

1. 

   Test08-Apr4-4daysMmwAnnotated.png
   

2. 

   Test08-Apr4-4days.png
   

3. 

   Mayfly11_reportedVbat.png
   

[Author]

Posts