Forum Replies Created
-
AuthorPosts
-
Ok thanks.
An update to my stability testing, this partly makes me collect the dates and status.
A test system “tu_rc_EC” standalone EC “Stream Disconnect” monitor built on 0.25.0 has been running since the beginning of Oct very well. I plan on describing this and haven’t done so yet.
The “TUCA-NA13” remote Verizon wireless system in the wilds measuring a stream depth, with two gauges – Keller and LTC500 – built on 0.25.0, has stopped recording on MMW on March 28. It started on Jan 29<sup>th</sup> after a previous outage, so ran for 2months. It is very remote and appears to go through periods when the Verizon network has low signal or MMW is not responding, but it has always recovered. A site visit next week might restore it.
An early beta “tu_rc_test06” is in my yard, and a duplicate of the TUCA-NA13, with version0.28.3. This is from my fork, with extra features, but based on 0.28.3. It stopped running, and I have a terminal on it that caught what happened
So tu_rc_test06 started Apr 1st (it survived Apr 1st), and froze on Apr 19<sup>th</sup> . Looking at the log, the Mayfly awoke at
… zzzZZ Awake @ 2021-04-19T16:07:00-08:00
then POSTED to MMW successfully
— Response Code — 201 waited 2107 mS Timeout 5000
Going to sleep. Ram( 6127 ) ZZzzz…
Watchdog disabled. barksUntilReset 150 <–WatchDogAVRthen never woke up.
At a guess, a hypothesis, the RTC clock never woke it up.
@srgdamiano I wonder if you’ve seen anything like this?Looking at the Sodaq_DS3231 RTC it reinitializes every sleep cycle. In another life, working on a large product, we had some very occasional reliability issues with the I2C bus. When there was an issue it was spectacular, and once happened before a very visible customer. We came up with a workaround.
The I2C hardware protocol is not a guaranteed transaction, and could have noise on the line. So I’m trying a modification that does a read of the Sodaq_DS3231 registers to verify that they have been set correctly. It is a long shot, and happy to take any suggestions.
Hello @shicks ~ I’m just following up on this as I’m respinning my Modbus Board MayflyWingShield schematic.pdf
to have a SDI-12 interface, and your board got me thinking .
The Mayfly socket has +5V and +3.3V and the board can have the boosted +12V. ( I had done it from the Seeed D6-7).
So thinking of trading off the third 4pin “modbus socket” for a 3pin “SDI-12 socket”. That is 3pins screw connector and “JST PH 3-pin”. The JST PH 3pin 2mm have Adafruit mating cables.
The line interface following https://sdi-12.org/specification
The benefits are one digital interface board, with options for simplicity like 3.3V pass through interface, or plain SDI-12 instrument +5V current limiting.
So just putting it out there for a technical review if you have insights/comments ~ always appreciated before committing to copper. 🙂
Attachments:
Hello @shicks thanks for the response. I was thinking partly of the SDI-12 specification modules driving 5V back into the 3.3V ports. The Insitu LT500 that I’ve been using does respond to Mayfly driving it on 3.3V, but then drives back SDI12 specified 5V which has to be mitigated.
Do you see any issues with the level shifter and the port interfacing software interface on the Mayfly. https://github.com/EnviroDIY/Arduino-SDI-12
I guess I’ve been trying the option above, and again the LT500 seems to then not respond. A slight difference is that when Mayfly port is in tri-state, which can looks like 0V, the level shifter pulls up which then looks like a 5V. So the level shifter flips it.
Seems like that shouldn’t be a big issue – but then the LT500 didn’t respond, so became a headscratcher.
So very interested to continue the conversation and I’m happy to proto type a trial circuit. 🙂
I’ve been working on a next revision board. Details at https://github.com/neilh10/SensorModbusMaster/tree/release1/hardware/knh002-MayflyWingShield
overview at https://github.com/neilh10/SensorModbusMaster/tree/release1/hardware
I don’t have any time frame on availability due to the world wide shortage of parts, but probably third quarter this year. It will be an order before hand build so good timing if you are thinking of getting some.
I have hand built some for testing, and now have them testing on a system with a Keller Acculevel /0.28.3
I’ve got it on my list to do more write up.
I’ve created a low cost monitoring console using a Raspberry Pi and FTDI cable. This allows a release debug OUTPUT to be monitored just as if it was on the console and compared to https://monitormywatershed.org/
https://github.com/neilh10/ModularSensors/wiki/Test-monitoring-host
Thanks for the input, ~ Yup that is what did it for interfacing with the LT500. I brought in each change from Dec 1st till I found it
Doesn’t make a lot of sense to me why that impacts the protocol, but in dealing with a bug, the first stage is Detection, 2nd stage is Isolation, 3rd stage is Fixing it.
The Isolation in this case took a couple of days.
The software process is modify and test, and then integration test. In this case what is lacking (for me) is having a defined reference for the SDI-12 sensor. It also seems that working with the LT500, there are retry’s that finally work. So its a general problem with this kind of dispersed protocol testing. USB protocol testing is a lot worse, and they solve it by having plug-fests. But then there is a lot of money in selling USB devices.
I have been keeping my eyes open for a low cost reference sensor, ideally that would be open source as well, but I haven’t found one yet.
I’m thinking that for me, since SDI-12 is so fragile, and its not clear how to verify changes except by running them against reference sensors I should manage any changes happening more closely – fork the libs concerned. Just thinking out a loud.
Another low cost depth sensor, showing the problems with using “raw sensing”, and the range is very small range 0-10cm and needs recalibrating evertime there is a power cycle. – https://www.vegetronix.com/Products/AquaPlumb/ – but my experiments have shown it has
My comment
“Works pretty nicely, except after power off.
Can’t take power off while in water – then reads 0.
Seems as a capacitance based sensor, when powering up needs to baseline the capacitance – guessing on my part – that is needs to be out of the water. Once read a baseline capacitance, then it detects increase in capacitance, water crossing. If the baseline capacitiance could be read, and then programmed, maybe it could survive a power off. “Hi James,
If its the standard variable resistance then you should be able to just use the switched 3V. The ADS1115 is going to be more accurate.
FYI in case its of interest, I did some work with it and here is what I found out about the eTape; as I remember with the eTape, was that in calibration it wouldn’t register to the printed zero mark – and had an “actuation depth”, maybe it has changed. The general issue with an “elemental sensor” is that the raw sensing (in this case resistance) needs to be transformed into measurable units – in this case mm or inches, and for the eTape it is non-linear.
https://milonetech.com/products/standard-etape
They have linearizing modules, 0-5V and 4-20mA – though it requires a 6-24V stimulation
I did try the 4-20mA version, but burnt it out as it didn’t have reverse protection voltage in it.
Emails I sent, though maybe it has changed:
Subject: Configuring eTapes into a system?
Date: Thu, February 12, 2015 10:58 pmSome issues coming up
1) ‘0’ depth marking on the eTape scaling can never relate to a 0
electronic reading.
The data sheet says Actuation Depth a nominal 1″ – it seems that most of
the eTapes start recoding pressure change at about 0.2″
So where does the linearity start and to how to design to meet it?
2) For the simple eTape interface circuits, do you have any recommended
formuleas/manufacturing algorithims that translate measured Vout to a
linear depth reading that can apply to any eTape received.
<div class=”moz-cite-prefix”>On 2/19/2015 10:23 AM, chris.milone@milonetech.com wrote:</div><div>Hi Neil,</div>
<div></div>
<div>Sorry for the delayed response. Yes, a voltage divider output is a nonlinear function. We are working with another customer who has written some Arduino code that he claims automatically linearizes the output but we haven’t been able to get this to work as of yet.</div>@mbarney its a common problem with low power, sleep circuits.
Just to be clear/restate what the issue is. When in “sleep” mode and powered off, all instrument pins (and actually all other processor pins) need to be set to output low, or input with preferably pull down.
On power-up, the pins are activated output and set high within 50mS so as to not trigger the wipe.
On power-down, its a race condition which to do first, and the global control of the power, but with a min 50mS pulse I would think you are safe to make the wiper pin low and hope that the power is turned off within 50mS.
KellerParent.cpp has ::powerUp() and ::powerDown() which is where I change the pins.
You are using ::setup() for setting the port direction, which is I think is run only once, so I would think you move the wiper setup to ::powerUp
Sounds like its coming along, and I’m fascinated that you are getting 0.5mA.
BTW with my FTDI cable setup, I just found the hardway that the Ftdi Rx pin (tx pin from processor) hadn’t been clipped off and on my stability test station; the 4.4Ah battery mysteriously suddenly drained down in about 3days and then recharged from he solar. It turns out my monitoring PC Win10 did some form of automatic update and then powered down. The FTDI cable also powered down, including this unclipped Rx pin, that then drained off the battery current. I only noticed after I had restarted the PC, and the monitoring, and then two days later was checking the results and saw the battery had mysteriously drained down and come back. So the purpose of stability monitoring is check for anomalous behaviour in a secure setting, so I needed to find out what had happened.
-
AuthorPosts