Welcome to EnviroDIY, a community for do-it-yourself environmental science and monitoring. EnviroDIY is part of 
@neilh20
5 days agoForum Replies Created
-
I’ve released an expanded Modbus/RS485 Wingboard for community design review
https://github.com/EnviroDIY/Mayfly-Modbus-Wing/tree/master/knh002-MayflyWingShield/rev8
I’d welcome design comments, on https://github.com/EnviroDIY/Mayfly-Modbus-Wing/issues/3 by Monday 2022-July-20 12noon PST. Easier to correct any possible problems early on, than find them later on the PCB. As the old clothes tailor saying goes “measure three times, cut once”.
Discussion on desired Modbus usage or general questions could be made here. I should note that this is a private initiative, not funded by EnviroDIY, but I am using it as a part of a public discussion for an open source board design.
Hello Erik, hmm perhaps I’m coming from too many years of reading code,
Yes the order matters for the code, that the instance follows the the constructor.
What you are looking at I think is “// .. sensor” , and that is a comment
It does look like it may have been swopped, but its only descriptive text. Getting descriptions to match the code takes time and refinement. The “code warrior” answer; is read the code
.FYI IMHO adding a new protocol for a Modbus device is jumping into some “deep water”. Good luck!
Hello Erik, sounds like you are on the path to learning Cpp. One issue to keep in mind is that the code is what happens, the reality check, the documentation is for readability. You may want to list what gas sensor you are looking at for the max help.
So I don’t follow your question – where do you get the code snippet from the first section which says there are two power pins “nlAdapterPower” and nanolevelPower which looks reasonable.
Then in the constructor KellerNanolevel.h they map to int8_t and int8_t – the name is only descriptive, it isn’t used for anything.
Part of new code is having a plan including figuring out what you need to learn. a) can you get enough technical detail for the plan to be likely to work – ie for your case the Modbus map of the gas sensor b) The other part of coding is set up a target test bench. b1) The first part of a test bench is proving that the test bench is working, b2) typically by enabling debug and checking the message flow on a known working sensor and then b3) making modifications for your new target sensor. Do you have ANY ModularSensors modbus sensors that you could start with? Just a thought
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:
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.
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:
