Welcome to EnviroDIY, a community for do-it-yourself environmental science and monitoring. EnviroDIY is part of 
@srgdamiano
Active 1 months, 2 weeks agoForum Replies Created
-
AuthorPosts
-
2020-11-16 at 10:45 AM in reply to: DFRobot Gravity KIT0139 Depth Sensor – Routine Interference? #14824
Could it possibly be a problem with the temperature inside your logger box rather than the water temperature? Maybe Shannon can pipe in and confirm, but I remember that we used to have issues like this when we were using black boxes with clear lids facing summer sun. I think the Mayfly’s ADC starts acting up when it gets too hot. Are you recording the Mayfly’s DS3231 temperature? It might show something.
I haven’t found a way to re-temperature-correct a depth sensor that’s built-in temperature correction has gone awry.
2020-11-10 at 2:46 PM in reply to: PlatformIO not downloading all ModularSensors dependencies #14807Also, with PlatformIO version 5 you can now specify the owner along with the library name in the lib_deps section so you’re sure you get the right one.
2020-11-10 at 2:45 PM in reply to: PlatformIO not downloading all ModularSensors dependencies #14806I’m sorry for being late on this.
It’s definitely something with the newest versions of PlatformIO and the very weird part is that for me *sometimes* it works and other times it does.
What I’ve usually ended up doing is putting *everything* into the lib_deps section.
INI12345678910111213141516171819202122232425lib_deps =envirodiy/EnviroDIY_ModularSensors @ ~0.25.1envirodiy/EnviroDIY_DS3231 @ ~1.3.4arduino-libraries/RTCZero @ ~1.6.0greygnome/EnableInterrupt @ ~1.1.0greiman/SdFat @ ~1.1.4vshymanskyy/TinyGSM @ ~0.10.9knolleary/PubSubClient @ ~2.8adafruit/Adafruit BusIO @ ~1.6.0adafruit/Adafruit Unified Sensor @ ~1.1.4https://github.com/soligen2010/Adafruit_ADS1X15.gitadafruit/Adafruit AM2315 @ ~2.1.0adafruit/Adafruit BME280 Library @ ~2.1.2adafruit/DHT sensor library @ ~1.4.0adafruit/Adafruit INA219 @ ~1.0.9adafruit/Adafruit MPL115A2 @ ~1.1.2paulstoffregen/OneWire @ ~2.3.5milesburton/DallasTemperature @ ~3.9.1envirodiy/SDI-12 @ ~2.1.2northernwidget/MS5803 @ ~0.1.2https://github.com/NorthernWidget-Skunkworks/Tally_Library.git#Dev_I2Cenvirodiy/SensorModbusMaster @ ~0.6.8envirodiy/KellerModbus @ ~0.2.2envirodiy/YosemitechModbus @ ~0.2.3vshymanskyy/StreamDebugger @ ~1.0.1<!–more–>Yeah, so 99.99% of what I’ve said on this thread can be completely disregarded. Obviously the sensor and firmware work just fine and there never was any problem with them. The biggest problem was my understanding of the problem.
If everything is perfect except the 3m cable, then it’s just the 3m length that is the problem. It’s apparently too far for I2C at 3.3V. Signal doesn’t travel forever over real wires. Larger voltage differences can help signals to travel farther. An Uno or other 5V Arduino has an extra 1.7V range the Mayfly doesn’t have. The operating voltage of the Mayfly cannot be changed.
You had a working library and code this whole time.
?!?
Well I feel really, really stupid.
What code are you running to get the values? The results you shared with me based on the code I gave you didn’t have any good values at all. I thought you didn’t have any working code for communication.
I’m guessing you’ve made one of these: https://github.com/EnviroDIY/TippingBucketRainCounter
I’ve edited the code that makes it work with ModularSensors, but I haven’t ever built one. Sorry.
Does it output good value*S* or one single good value over and over? If the former, then..I just don’t know how to read this firmware. If the latter, then, no that’s what I expect.
3m is beyond the maximum expected transmission length for I2C, so, no, it’s not at all strange that it wouldn’t work over that long a distance. If you need that distance, you need to use RS485 or some other protocol. I2C is only really intended to work across very short distances. The limitation is based on the voltage ranges and the amount of signal loss over real wires. You might get lucky with some cables and configurations, but you shouldn’t expect it. RS485 can travel much farther because the voltage differences between the wires is much larger.
That’s the firmware I’ve been looking at.
You know what, I don’t think this firmware even functional. It won’t ever take a sample. Well, it should sample 1 time at the beginning, and then never again. Ugh. I wasted a lot of time parsing the I2C bits of the firmware and writing code for you and didn’t ever question that that sampling part of the firmware worked. I’m pretty sure it doesn’t.
I created an issue on GitHub for them: https://github.com/NorthernWidget-Skunkworks/Project-Walrus/issues/14. Basically, every 100ms the firmware sets a timeout value and then immediately after setting the value, checks if the same value is more than 5 seconds old. But, obviously, since it just set that value, the value will never be more than a few ticks old and the “start sampling” flag will never, ever be set to true.
So.. yeah, you need them to write and give you new firmware. And, then you need to figure out how to write said firmware onto your sensor. They have instructions on how to do that here: https://github.com/NorthernWidget-Skunkworks/Project-Walrus#upload-the-firmware, but you need an ISP of some sort. I don’t even have one of those.
It’s still not clear to me why it’s not sampling exactly one time when first booted up, but I don’t think it’s worth anyone spending any more time with it until you’ve been given new firmware and a way to program it.
You don’t need the whole firmware; actually I’d prefer not to get the firmware, but instead to get a short breakdown of the required I2C registers and commands. All I would be doing with the full firmware is trying to decode what the registers are anyway.
-
AuthorPosts
