[neilh20]

@vogelrnws I had been looking at porting it to another processor and been using it and digging into the code. I’ve looked at some of the RP2040, but I’m cautious about its ability to go into low power – but haven’t looked at it in depth.

The SDI-12 lib uses a software based UART – running at 1200Baud, so 1200Baud is pretty slow and it does handle it. It needs to have a timer generated to be able to look for the changes in the data stream.

Unfortunately, IMHO, I’ve found it to be quite fragile.   Also the software timing has made debugging fragile.  In 2021 I had also found it worked with some Insitu LT500 sensors and not others. I tried to put a “test station” together, against a traceable SDI-12 test setup using https://www.vegetronix.com/Products/SDI-12 and it failed on the basic physical test.

So I’m thinking about how to 1) +5V buffer  possibly this solution https://github.com/EnviroDIY/Arduino-SDI-12/issues/87

2) hardware timing. Possibly emulate the UART with with either DMA or Timer/Capture.

So maybe the hardware interface could be done with a simple 4 wire Seeed plugin with an off-board buffer and boost to +12V, and software modified.

So just IMHO a heads up on some of the possible issues to consider.

[neilh20]

@hannahlb if I understand you – you have 4 geographically distributed ISCO samplers (say more than 100m apart) and you would like to trigger them  when a threshold is exceeded from a Solinst level sensor.  The trigger would be communicated via messages on the telemetry NB-iot?

Probably the best way to think about it is in stages

1) figure if this can be just done from one controller – both Solinst and ISCO

2) Then when you have got it working with one controller, can you communicate that through an mqtt message over NBIot to a remote server

3) then have the three or four other remotes subscribe through mqtt NB Iot  to the notification.

While this could be sketched on a whiteboard quite easily – ModularSensors only does north bound (one way into the cloud) comms through an mqtt host.

However, looking at the ISCO 6712 manual, the issue may be how to trigger the ISCO 6712 to start.  If there is an external connection it could work. Or program it to run just once when powered up – and then manage the power application as the trigger.  Another way might be to stimulate an SDI-12 instrument – create a dummy instrument as a trigger method.   All of it is probably a lot of software work, which can take a lot of time and also trial and error having extra equipment.

 

 

[neilh20]

@khaase  interesting getting the LiSOCL2  activated.

My 2Cents is it would be good to characterize the 350mA  pulse – and isolate it from the mega1284’s  high impedance LiSOCL2.   That could mean that for the “high impedance” (for a battery)  LiSOCL2,   the current draw has to be kept below a threshold, treated as a constant current source.

Then the issue is also how to detect when the LiSOCL2 is running out of energy, and can’t take more high current pulses, can it gracefully manage the power situation.  Unfortunately its not a trivial problem.

 

[neilh20]

Mostly the cables we put in are armored –  3/4″ flexible and can be joined easly – something like https://www.lowes.com/pd/HydroMaxx-3-4-in-x-50-ft-Black-Flexible-PVC-Pipe/1002884464

Also seen cables chewed by squirrels .

[neilh20]

Hi @khaase I haven’t figured out what the source of the reset is, as the AVR1284 Arduino code discards it – very frustrating.

I have used low ESR capacitors – something like Digikey 732-9079-1-ND CAP ALUM 680UF 20% 10V THRU HOLE LOW ESR

Whenever I have longer wires, a power switch, or current measurement, with the LiIon battery, I get some resets. I’ve also standardized on using 4400mAh LiIon battery.

My EC circuit has low dynamic power demand.  Are you looking to add larger dynamic power demand with radios?  The LiSoCL2  has a relative high impedance,

Managing power demand is challenging, not taking too much power when its not available. Using Vbat to estimate power is tricky. Vbat measurement is noisy and is referenced to the Vcc, and is only theoretically  accurate when Vcc=3.3V . So the LiSoCl2 3.6V is pretty close to the design limits of the regulators (though far improved than the Mayfly 0.5 regulators)

[neilh20]

Maybe of interest https://www.envirodiy.org/topic/primary-powering-in-cold-settings/

[neilh20]

@davem great topic.  I was at a SSU Eng Presentation yesterday by Enphase   a leading solar equipment provider and they use LiPo4 in their battery 3.3Kwh/10Kwh systems.  All about safety.  LiPo4 slightly less power density — but that isn’t a problem with stationary systems.  No temperature stability. Fire issues are a big deal. A recent newspaper report on a local house fire referenced a device that had been left on charge and caught fire.

I’ve got some largish PO4 tube batteries designed for electric bikes.  However the challenge is as you point out is different charging regime and management.  At the present my guess it can be a system block at 5V or 12V.  However it would be nice for SBC (single board computers) like the Mayfly to have the LiPO4 interface.   I seemdd to remember Rocket used to with SAMD21 LoRa + LiPO4

There was also a rPi powering system that used LiP04 – I think this is,

https://hackaday.io/project/13260-lifepo4weredsolar1

One way of minimizing power consumption with fast sampling is to queue the reading,  and then upload every 4-12hours, which is what I do, but is a lot of software work. When I have some time I plan to post it for the Mayfly, but haven’t heard a lot of people asking for it.

Also to minimize cellular power, use a cloud host that can encode the data and suck the data up fast. However subscriptions are quite costly. So great topic

[neilh20]

Hello Dave, thanks for sharing.

I had thought of getting the device, because of the price, so interesting.

The issues I saw is that it has two sources of analog error and unquantified temperature coeffocient  for each source of error.

Every “analog” device typically has a temperature dependency, This would be the depth sensor itself, which will vary the reported depth based on the varying temperature of the water. Typically small if the temperature is stable as in  underground water measurement.

The second analog error  – which is the current transformed to the voltage. This resistance will vary based on the air temperature.  Resistor need to be selected and stated for the their temperature variation. There are resistors that have a low temperature coefficient. So the device from Seeed should state what its temperature coefficient is, but I couldn’t find it.

So just an observation, and thanks again for sharing.

 

[neilh20]

Hi James, if you have the spare jumper cable sockets you could try it and it probably will work.

The challenge is the Mayfly doesn’t have a lot of capacitive buffering and the LiIon battery performs that function.  It might be more reliable to have a battery on each Mayfly and run the solar panel to both.  Of course the boards need to be kept physically isolated so they don’t connect electrically.

My  node is using a LT500/SDI-12 and a Keller Acculevel/Modbus on Mayfly 0.5B https://monitormywatershed.org/sites/TUCA-Na13/

Its using a release based on 0.28.5 ~ https://github.com/neilh10/ModularSensors/releases/tag/v0.28.5.release1_210711  and it is built as a working release in https://github.com/neilh10/ModularSensors/tree/v0.28.5.release1_210711/examples/tu_xx01 with src/ms_cfg.h_LT5KA_lte copied to ms_cfg.h

 

[neilh20]

Wow thanks so much for sharing, and no problem with your English.  I’ve been in that situation where its difficult to debug ModularSensors/Mayfly as the software implementation using time loops is so time sensitive.

Are you planning on using a git to store the programs with an open source license? Its very nice if you do and gives some confidence in being able to do crowd sourced testing and feeding back how it works. 

Just wondering if you are using your program with the Mayfly implementation?

One issue to keep in mind if using the Mayfly, is that the SDI-12 is specified electrically as 0V to +5V, and the Mayfly as SDI-12 recorder/host/server implementation has a reduced electrical interface to only do 0V to +3.3V. This makes it easy to implement.  However it can mean that the SDI-12 sensor equipment doesn’t detect the incoming packet. I’ve seen this for the Insitu LT500 equipment   ~ or at least I got a non-response from some older equipment and assumed that was the reason. Similarly with the Vegetronix SDI-12 analog sensor that has been tested to the SDI-12 specification, it doesn’t respond. An earlier version of the Vegetronix SDI-12 analog sensor does respond, but that version didn’t have the CRC implementation.

You solve the electrical interface by using the TekBox TBS03 (or at least hopefully it covers it), though I wonder if it also reports packets that are out of electrical specification?

[Author]

Posts