Welcome to EnviroDIY, a community for do-it-yourself environmental science and monitoring. EnviroDIY is part of 
@srgdamiano
Active 1 months, 1 weeks agoForum Replies Created
-
AuthorPosts
-
I don’t remember exactly which models we’ve tested or which seems to be the best; maybe Shannon can pipe in.
No matter which you’re using, definitely do get the MaxTemp.
Did the modification I suggested get your board to go back to sleep and stay asleep?
I’m sorry I haven’t responded. My family is finally finished with a fun round of stomach bugs.
Were you by chance talking with @neilh or did you just happen to get to the same place at almost the same time coincidentally? Neil wrote up a fix for this in the SensorModbusMaster library, which I just accepted. If you update that library, you should be getting the fix. It might take 24 hours or so for the PlatformIO registry to catch the update on the library; if you’re ready to get the fix NOW you can uninstall and reinstall SensorModbusMaster using the github link instead of the library name.
With the fix in SensorModbusMaster, is it finally working for you?
I”m sorry for not being more helpful sooner!
Oops. I’d meant to cut the code using NeoSWSerial and SoftwareSerial from that particular example but apparently cut it only from the example platformio.ini file.
Can you post your platformio.ini file? Are you using Atom or VSCode? It shouldn’t make a difference for the code; I’m just asking so I can help you better. What versions of all libraries do you have installed? Did you install any manually or let PlatformIO do the install? Are you sure you haven’t installed any twice? In your project’s folder, navigate to the .pio/libdeps/mayfly subfolder and look at all the folders within it. Do you see any library names in there twice (with a different suffix tagged onto the end of the folder name). If you see any repeats, the easiest solution is to delete everything and let PlatformIO reinstall just one version of each. Then update all your libraries and your platforms if you haven’t already. To do this, open a new terminal in PlatformIO with either the button or the menu. On Atom you can use the + icon on the bottom; on VSCode there should be a button on the very bottom left that looks like this: [> ]. In the terminal first update the platforms with the command “pio update”. Then update your project specific libraries with the command “pio lib update.” PlatformIO itself hasn’t been updated in a while, but you can verify that you’re running the lastest version with the command “pio upgrade.” After updating everything, make sure you clean out any older pre-compiled files by hitting the trashcan icon.
When you say the board restarts, does it restart instantly or does it hang for 15 minutes and then restart? Please add these defines to your platformio.ini file and then post the output when the board is running. It might be very long; you can post it or attach it as a text file.
INI1234567891011121314151617181920212223242526272829303132333435363738; PlatformIO Project Configuration File;; Build options: build flags, source filter; Upload options: custom upload port, speed and extra flags; Library options: dependencies, extra library storages; Advanced options: extra scripting;; Please visit documentation for the other options and examples; http://docs.platformio.org/page/projectconf.html[platformio]description = ModularSensors example using two "loggers" to save cellular data[env:mayfly]monitor_speed = 115200board = mayflyplatform = atmelavrframework = arduinolib_ldf_mode = deep+lib_ignore = RTCZerobuild_flags =-DSDI12_EXTERNAL_PCINT-DNEOSWSERIAL_EXTERNAL_PCINT-DMQTT_MAX_PACKET_SIZE=240-DTINY_GSM_RX_BUFFER=64-DTINY_GSM_YIELD_MS=2-DMS_YOSEMITECHPARENT_DEBUG-DMS_YOSEMITECHPARENT_DEBUG_DEEP-DMS_LOGGERBASE_DEBUG-DMS_VARIABLEBASE_DEBUG-DMS_SENSORBASE_DEBUG-DMS_VARIABLEARRAY_DEBUG-DMS_VARIABLEARRAY_DEBUG_DEEPlib_deps =EnviroDIY_ModularSensors@0.23.16https://github.com/PaulStoffregen/AltSoftSerial.githttps://github.com/EnviroDIY/SoftwareSerial_ExternalInts.githttps://github.com/SRGDamia1/NeoSWSerial.gitYeah, it’s a known issue.
I was feeling cocky after the LTC1480 worked and pulled out the Max485 and level shifters. Zero success with communication, but I didn’t have any problems with the program crashing.
Ok, I broke out the 3.3V RS485 chip I have (an LTC1480) from the “someday I’ll test this” box. I’d bought the chip ages ago to try out in place of the (5V) MAX485 that I couldn’t ever get to work. But since the automatic flow control always worked nicely, I threw the LT1480 onto a shelf unopened.
Anyway, it worked for me. I made some very small tweaks to the SensorModbusMaster library to see if I could get the timing better, which helped a little, but it worked even without. I didn’t have any issues with the board restarting or anything.
Hm.. In my test I used AltSoftSerial (pins 5&6) as my serial and tried the RE_/DE on both pins 4 and A2. What exactly are your connections and what code exactly are you running?
Also, I’m really surprised you couldn’t find an adapter with automatic flow control. Where were you looking? There are a bunch on Amazon. This is one brand I’ve bought: https://www.amazon.com/SMAKN%C2%AE-Adapter-Serial-Converter-Module/dp/B010723BCE
I have never gotten the communication to work correctly using manual flow control, but it should not be causing your board to restart. I’ll look into it.
When using manual flow control, you have to set the direction pin high or low to change directions. The library does this, but I think there is a timing issue or something because my attempts at using it with a max485 and level shifters compeletely failed.
Well, actually, I forgot about the internal data filter. Leaving the sensor always powered will give time for that to come into play. I don’t know if it will help any, though.
Some thing else I thought about in your code: Even though you’re delaying for a second between calls to the
SonarRead()function, you were actually parsing and keeping the first 10 readings the sensor took after power on (about 166ms apart) and just processing them 1 second apart. That’s because as long as the sonar is sending data (which is continuously while it is powered) and you’re listening to it with SoftwareSerial, the characters are being stored in the buffer. Once the buffer is full, they just get thrown away. Nothing comes out of the buffer until youread()it. When you do read it, you’re reading out in the order they were placed into the buffer, even if they were placed there a while ago. The fix I suggested for the sleep will also fix this because the end() will dump the buffer and it will be re-created empty at the begin().I doubt going up to 25 attempts will make much of a difference.
-
AuthorPosts
