Forum Replies Created
-
AuthorPosts
-
What do you mean by “does not work?” What do you see on the serial monitor and on you SD card’s file? When you say “The code itself works to display the data in the serial monitor, but it does not works when recording it into the SD card.” do you mean that you can see data on the Serial Port monitor do you mean that if you replace all instances of “sensorsdata” with “Serial” then the data is printed to the serial port monitor, or do you mean that when running the code as is you don’t see any error messages? There are nothing really obvious errors jumping out at me in your code.
Please, in the future, use the “Add Code Snippet” button to post code.
Also, I would always recommend PlatformIO over the Arduino IDE.
2019-08-14 at 6:43 PM in reply to: logging to mmw with GPRSbee rev.7, issue wake/sleep and server response 504 #13074Can you post some debugging logs? Along with the Thing Speak / MMW debugging, could you turn on the “deep” debugging for the gprsbee? You’ll need to install the StreamDebugger library.
I’m sorry. Testing with 2G is a hassle for me because the coverage is terrible is my area. It would help if I can see what is going on.
2019-08-06 at 12:28 PM in reply to: best practices enabling debugging modular sensors using platformIO #13001I found the issue with the ThingSpeakDebugger. It’s now been fixed. It might take until tomorrow before PlatformIO “sees” the new version though.
To update your libraries in your current project:
– Open a new terminal in your project in Atom or go to the Terminal pane in VSCode
– typepio lib update
– all your libraries for the project should be updated. Watch for ModularSensors to move from 0.23.3 to 0.23.4.If you’re feeling very impatient and don’t want to wait for the PlatformIO registries to catch the 0.23.4 update, you can uninstall the registered version of ModularSensors and install it from git instead:
– Open a new terminal in your project
– Uninstall ModularSensors by typing:pio lib uninstall EnviroDIY_ModularSensors
– Open your platformio.ini file in your project
– In the lib_deps section, replaceEnviroDIY_ModularSensors
with
https://github.com/EnviroDIY/ModularSensors.git
– Save the platformio.ini
– “Clean” out any pre-compiled library bits by hitting the trash can button in Atom, or going to project tasks > clean in VSCode
– Re-compile and upload your program2019-08-05 at 5:11 PM in reply to: best practices enabling debugging modular sensors using platformIO #12999I’m sorry I’ve not responded. I’m honestly baffled by the errors.
Could you show your whole ini and a shot of the contents of your .pio/libdeps/mayfly folder?
2019-08-01 at 10:40 AM in reply to: best practices enabling debugging modular sensors using platformIO #12994@fisherba – StreamDebugger is only needed if you include it in your program; it isn’t and never was a dependency of ModularSensors or TinyGSM. It’s not included in ModularSensors.
2019-08-01 at 10:24 AM in reply to: best practices enabling debugging modular sensors using platformIO #12993Oh, and just to note about those other build flags:
-DSDI12_EXTERNAL_PCINT – this tells the library that you don’t want the SDI-12 library to try to monopolize the interrupts on an AVR board, which is required to make it “play nice” with the other libraries. You absolutely must set this because the SDI-12 library is a dependency of ModularSensors (even if you’re not using any SDI-12 sensors)
-DNEOSWSERIAL_EXTERNAL_PCINT – this does the same thing to NeoSoftwareSerial. You only need this if you’re actually using that library, though it makes no difference if you define it but don’t use that library.
-DMQTT_MAX_PACKET_SIZE=240 tells the MQTT library (PubSubClient) you need a bigger buffer for the outgoing request. The ThingSpeak publisher is the only one that uses MQTT (so far). I put it at 240 characters, which should be plenty long enough to send 8 fields to ThingSpeak (the maximum that ThingSpeak accepts at once). If you’re only using a few fields you could omit this flag, which would save you a tiny big of RAM, but be cautious because the MQTT library just won’t send the if the request length exceeds the buffer length.
-DTINY_GSM_RX_BUFFER=512 – This is in the examples, but it really only matters if you’re using an ESP8266, AI Thinker, or Neoway M590. Don’t define it and save some some RAM with the GPRSBee.
2019-08-01 at 10:00 AM in reply to: best practices enabling debugging modular sensors using platformIO #12991You can also enable all of the debugging using a build flag in your platformio.ini. The result is exactly the same as if you un-comment the line in the header. You can add flags for any (or all) of the different modules.
12345678910build_flags =-DSDI12_EXTERNAL_PCINT-DNEOSWSERIAL_EXTERNAL_PCINT-DMQTT_MAX_PACKET_SIZE=240-DTINY_GSM_RX_BUFFER=512-DTINY_GSM_YIELD_MS=2-DMS_DATAPUBLISHERBASE_DEBUG-DMS_DATAPUBLISHERBASE_DEBUG-DMS_SODAQ2GBEER6_DEBUG-DMS_THINGSPEAKPUBLISHER_DEBUGThere also seems to be a bug in the very latest PlatformIO (4.0.0) when installing library dependencies. For some reason when I create a new project, add EnviroDIY_ModularSensors to my dependencies, and then try to compile, the library dependency finder doesn’t correctly find and install of of the dependencies during the first build. If I manually install the library using
pio lib install EnviroDIY_ModularSensors
before building, it finds everything perfectly.
Those settings should be right for the XBee Wifi. Are you sure the unit is connected properly to your wifi? Can you connect the unit to XCTU and try to send a test json in the console log of XCTU?
That example sketch should still work, but for anything new I would recommend you switch to using the ModularSensors library to send data to the EnviroDIY portal.
@aufdenkampe – the S6B wifi units cannot work with url’s/domain names, only IP addresses. You must use command mode to first get the IP from the domain and then change the IP. I think only the very latest firmware on some of the cellular units can accept a fully qualified domain name without first manually doing the lookup.@jkirchoff – drive the pin level with the digitalWrite(#, level) function.
If you’re using a Mayfly, the XBee’s sleep request pin is attached to the Mayfly pin 23. So to wake the bee, send data, and put it to sleep all you needs is:
digitalWrite(23, HIGH);
Serial1.print(“some text);
// more print statements as desired
digitalWrite(23, LOW);Use XCTU to set your XBee up to use pin sleep. That’s also (by far) the easiest way to test your other radio settings and connectivity before deploying. You could code all the radio setup with the Mayfly, but Digi’s program makes it much, much easier.
There’s a known bug from Digi that any of the XBee3’s with revision “B” of the primary processor, where it will become unresponsive even with very short dips or irregularities in voltage: https://www.digi.com/resources/documentation/Digidocs/90002258/#Troubleshooting/ts_brownout.htm%3FTocPath%3DTroubleshooting%7C_____7
I don’t know about the capacitors though. A manually soldered capacitor chain might create more problems than it solves. https://nimbelink.com/Documentation/Skywire/1001619_Breadboard_WhitePaper.pdf
-
AuthorPosts