[neilh20]

Hello @aufdenkampe,
Great to hear you are doing a power shield with capability to deliver to the EnviroDIY water quality data portal.
There hasn’t been a hw solution yet that I liked, that so I haven’t done anything with the Arduino libs. Maybe that will change.:)
I’m planning on doing a poster at http://calsalmon.org/conferences/36th-annual-salmonid-restoration-conference on different types of pressure sensors for “measuring low water levels accurately across a 10C diurnal change in temperature.”
If you have a solution (or a plan) to have a switchable +12V from a low cost solar powered storage source I’d be happy to reference it.
My objective is switchable +12V powered sensors, with low cost power storage, charging from ~15W solar panel, with a comms solution that can deliver the reading to an internet location and be accessed over the internet.
The assumption is that sensor depth readings are taken every 15minutes, and cellular data is pushed ~ 1-4Hrs.
The system shuts down inbetween activity and takes less than 0.5mA.
The power storage design assumes little sunlight for storms that are two weeks at a time in parts of the year.
Dynamic power issues are of course Cellphones(2G/3G) can take ~0.7A for about a 1Minute to connect and deliver to an internet location.

I did a software prototype on Nuttx(PX4)/Olimex H407, but gave up when I scoped the amount of work still needed to support some of the basic Nuttx subsystems.
It has been running for over a year on the H407 board with external +12V, reading a Keller Nanolevel over RS485 and pushing to Thingspeak/ParticileWiFi
I haven’t attempted to standardize on the modbus lib – so its probably not very useful.
See modbusm_poll_device()
https://bitbucket.org/neilh20/nuttapps/src/e4d5088e591b0f126fc0e8b6b3662f6ffd3cbfcf/examples/modbus/master1/modbusm_user.c?at=dvlp_ensy1&fileviewer=file-view-default
The results are visible through http://azonde.info/pm2/WaterDepthTempNanoLevel.htm that pulls from thingspeak.

[neilh20]

Hi @bumpersp
Great question.
Installation is what the systems needed to be built for, as it brings it all together.

I’ve been building and testing equipment for deployment in small to mediums sized streams in N California, and occasionally been out with the Hydrologists that will later on be doing the stream rating curves.
My part has been to build the equipment and test in a safe location – in the industry we call it “staging the equipment”.
It’s so much easier to verify the equipment works and is reliable by first building it in a safe location, letting it soak for a couple of days, with all the tools and cellular connectivity.

Accurate low stream depth measurements viewable on internet

For the location in the stream bed, its best to do a survey – geographical and RF – go there with a cellphone on the network you are going to use, and then see if there is a signal.

There are cell phone Apps that will help track the strength of a signal on a network as you move around. I have eneded up with two phones for ATT 2G and ATT 3G network to map where the 2G network had been removed.

Wild wireless world ~ 2G or 3G

If you are looking to deploy a 2G network, know when it is likely to be sunsetted – I even here ATT 3G sunset dates are being mentioned.
For the cellular providers, rural areas have a different cellular network installation criteria than urban networks
For the geographical instream locaiton – I imagine you are looking for a reliable place to be able to measure amongst other items stream flow. For that the hydrologists I’ve been out with look for a pool with a stable down stream riffle. The down stream riffle defines the ability to do the rating curve.
One aspect of the measurement location is that the measured depth is often impacted by the diurnal temperature cycle of the water, so its valuable also to have a temperature sensor on the depth measurement.
If you aren’t likely to be doing stream flow rating curves, it does make the installation location easier.
Perhaps people who have experience of the Decagon CTD can comment on what they have found is optimial for it – as the EC may require water flowing round it to be useful.
So on the one hand for the sensor its valuable to have a pool with a stable stream, and the RF needs to be able to find the cellular network signal – the cellular radio horizon. Cellular radio signals don’t go through the earth very well. In N california we tend to have deep ravines for the streams, and its very tricky. For other locations maybe the geography is kinder.

Then we measure the difference between the inpool measurement position and where the logger is going to – this is the length of waterproof line that sensor needs to have.

Typically we are then going to mount the logger/battery housing on a pole/tree/fence above the flood line – with a reasonable solar aspect, and run a flexible conduit down to the stream side. Sometimes this has been 100′.
The sensors cable needs to pull through the protective conduit. So the protectective conduit inner diameter must be able to take the maximium dia of the sensor cable bundle.
Typically we use a plumbers pull line, and have to figure out how to carefully attach the cable bundle (including sensors) to the plull line.

Its conceivable, depending on the sensor cable lengths that you could put one environmental housing for the sensor termination and venting, and then run a 2nd extension cable to different location where the logger/RF signal/solar panel are optimal. Then there needs to be infield cable connections.

For fixing in the stream, I recommend the active part of the measurement sensor should be kept 6″ below the surface level for where flow measurements are being made. Typically sensors don’t know where the 0 water level is (they are typically a pressure sensor of some sort), and the least accurate part of measuring is close to 0.
The hydrologists I’ve worked with have fixed the sensors firmly in the stream on roots of trees, or with a rebar post. Equally important is then the flexible conduit is well tied down, and prevented from oscillating, when water flows across it.

Finally when its all installed, its valuable to have a way of verifying that the data is flowing through to the final destination – which typically is by bringing up the website on a cellphone and checking that its reported in at least once.

All cable entries to the enclosures benefit from good down ward drip line practises.

Well hope this is useful, and good luck – send some pictures of your locations. 🙂

[neilh20]

Hello @aufdenkampe
I was just wondering, for the Modbus/Keller Acculevel, for field deployment what you are doing for powering/mechanical and pushing to your intranet. Perhaps this is a topic by itself, be interested to discuss as I’m developing some circuits for same 🙂

[neilh20]

Hi Anthony, great to see the SensorModbusMaster detail.

FYI for the Keller Acculevel I found they had the CRC16 bytes switched around. Its well documented in the manual “Keller CRC16.

Also, if you are looking for accurate measurement at low levels of stream depth with low temperature dependency I’ve found the Keller Nanolevel to be about +/-0.05% across TEB. It uses a capactive sensor rather than the piezo resistive sensor of the acculelvel series. However it only has a range of 0-11′, and wider sensor body.
When considering the accuracy of the Acculevel, in discussion with Keller, I found their base level accuracy TEB (Total Error Band) is for +/-30′ Full Scale – so specifying a sensor with a range of less than that, the TEB is still for +/-30′. Not so much of a problem if the water temperature is constant in deeper water, but becomes relevant for measuring low water levels were there can be significant temperature shifts over a day.

The Keller devices allow for a number of types of jackets – “Polyethelene for general purpose” ie water is now recommended. The early Acculevel datasheets and Instrumart techsupport recommended Hytrel jacket and these developed fissures after only 6months in the water, and had to be replaced – a lot of field work.

[neilh20]

Hi Sara.
Nice to hear someone else using Modbus/RS485. Thanks for sharing the library.
The realtime serial processing is a challange and I have got it working on different systems. The first sign to look for is whether its supported in chips UART through DTR.
One issue with the automatic flow control is that it uses a couple of mA to maintain the line state.
I hope to share more as a I get some results.
Neil

[neilh20]

Thanks for the link – I think I hadn’t figure out the right registers addresses to read, so very useful.
I’m assuming your include <ModbusMaster.h> pulls https://github.com/4-20ma/ModbusMaster

The direction I’m heading in is with the BeagleBone Green Wireless and generating Modbus 12V off 5V. Will post more when I have it tested.

[neilh20]

Hi Calvin
Nice to see the pic of the 3G logger.
I was wondering if you got the link to the LT400 working.
I’ve been attempting to access the LT500 but not had any success decoding the LT500 protocol that runs on top of the modbus/RS485.
I have had packets as per the “Insitu Modbus_Communication_Protocol_5.10.pdf” but seems there is some initialization sequence that is needed before reading the sensors. I wonder how far you got with it.
I have got Keller Nano Level device that is very accurate in low water (capactive sensors) and water temperature change polling.
My hardware arrangement is prototype with a RS485 plugin using an Olimex STM32-H407 running off a 12V source. Pic enclosed. This is of the sensor in stable jar of water so the water depth isn’t varying except for evaporation. The sensor depth reading variation is from temperature variation.

BTW – I would think that with the mayfly interfacing to an RS485 chip (sparkfun has them) – the 12V would be well isolated. But as Shannon said, the 12V will fry 3V mayfly logic should they ever meet.
One of the issues with any electronics is they often take a surge on power up. For 12V sensors this may be a problem with a boost circuit, switched the way it is on the Mayfly. Powering is always tradeoffs and it may take some characterization. https://github.com/EnviroDIY/EnviroDIY_Mayfly_Logger/issues/1

Attachments:

1. 

   KellerNanoLevelSample171220.jpg
   

[neilh20]

Hi Sedhead, thanks for sharing. I’m just heading out the door for a weekend camping, and so a quick comment.
I’m not affiliated at all with the EnviroDiy – but I wonder if you’ve looked at the Mayfly. The benefit is that there is just the type of experience on this board for that device and software. I would think the key software you want to verify is the ability to store data on a SD card with accurate time. The SD card file system can be a challenge if not verified.
A place to start with a field deployable project, how do you plan on environmentally protecting it, powering it (solar, replaceable batteries), and then testing and updating it in the field?
Also you may want to discuss the depth range you want to measure. Unfortunately pressure sensors/depth readings can be temperature dependent – so from a teaching point of view its a good idea to teach measurement traceability. For using two absolute pressure sensors, Onset Hobo propose this scenario, but it doubles the error. A colleague who has used the approach has found burying the atmospheric reference sensor keeps it in a stable temperature environment.
PublicLabs has also done a discussion on some aspects of water measuring. They have a riffle device that may be worth looking at.

https://publiclab.org/wiki/openhour-archive March 6
Back after camping.
regards
Neil

[neilh20]

Wow fantastic to see the https://github.com/EnviroDIY/ModularSensors, and the https://github.com/EnviroDIY/Libraries.

[neilh20]

So to query any piece of equipment over a protocol, there are two parts – the physical layer and the data link layer protocol.
https://en.wikipedia.org/wiki/OSI_model
For the nanolevel it specifies physical layer as RS485 (for other equipment it may be the customer SDI-12)
For Keller products the modbus binary “data link layer” there is a document “Keller comm_protocol_series 30 V3.4 2015Oct.pdf”
http://www.kelleramerica.com/manuals-and-software/manuals/series30%20comm_protocol_e.pdf
Every manufacturer that is claiming an open interface, or expects their equipment to network, should supply a description of their implementation of a protocol.
The modbus protocol concept is fairly simple one. IMHO the modbus language is fairly archaic and easier to think of it as a query /response protocol than to try and use the older language associated with register read/writes.
The manufacturers manual is the starting point for understanding what is needed to get data from the device, and there is no such thing as a standardization process for modbusm

<DevAddr> <FunctionCode> <n byte payload …> <KellerCrc16_H> <KellerCrc16_L>
For Keller a significant difference is that they switch the CRC-16 bytes around from standard modbus !!!
I process this with two functions
rs485crc16add(..) rs485crc16chk(..)
were CRC16calc() does all the magic work with a standard CRCTable
See
https://bitbucket.org/neilh20/nuttapps/src/5315c5ee8f8fcdb7d5dd69989b499194fc30a034/examples/ae/aelog/ae_mdm_phy.c?at=work_ensy1b&fileviewer=file-view-default

Now the controlling requestor “master” tx

and the device “slave” responds (looks pretty similar – but the payload is the significant part.

For the first time testing of the protocol, the objective is just to ensure the mechanics are good.
Out 01 03 00 04 00 01 C5 CB – Read Address 4, 1 registers – which is read level
Resp 1 3 2 0 0 B8 44 – Std Crc – result is 0
(or use some of the examples in the manual, though its a bit confusing they don’t all apply to every instrument)

Another example – read register 6 (temperature), 2words and interpret the two words as floating point IEEE754
Send 01 03 00 06 00 02 24 0A
Rx 01 03 04 41 88 7B 50 4C E9
Payload: 41 88 C9 48
h-schmidt.net/FloatConverter/IEEE754.html says 17.0 (and the units are C)

A Saelig Logic Analyzer trace of this is

[Author]

Posts