2019-05-16 at 8:48 AM #12897
I am trying to run an almost identical sketch “logging_to_mmw.ino” from the modular_sensor examples using a sodaq GPRSbee rev 7. If I am correct the rev.7 uses the same wake functions as the GPRSbee rev 6. So I assumed that I had to define both the sim800 and rev.6 modem in the sketch. See below:
// Wifi/Cellular Modem Main Chip Selection
// Select your modem chip – this determines the exact commands sent to it
#define TINY_GSM_MODEM_SIM800 // Select for a SIMCOM SIM800, SIM900, or variant thereof
#define SIM800_GPRSBEE_R6 // Select with SIM800 for – these use atypical sleep and wake fxns
using these settings most of the system seems to work. I have a signal strength of approximately 40% to 60%, it syncs with NIST and it goes into sleep mode after the initial setup. However, there seems to be an issue with powering up and going into sleep mode during the actual measurement runs. Every even run is successful in doing a measurement on the SIM800. It seems to me that powering on/waking takes just more time than expected (as it just stays on after the first run, and goes down in the second). I attached the entire debugging output (masking tokens with ###). Could anyone guide me in which direction I have to search for a solution.
The second thing that concerns me is the server response if a successful run was finished. The response code is 504, i.e. a gateway timeout, “the server was acting as a gateway or proxy and did not receive a timely response from the upstream server” (according to the wiki https://en.wikipedia.org/wiki/List_of_HTTP_status_codes)
Anyone familiar with this response?
2019-05-17 at 11:49 AM #12900fisherbaParticipant
Are your UUIDs all correct? If you are not sending a parameter, such as modem status, it still needs to have a full string in the “shape” of a UUID.
…first guess without more information…
2019-05-21 at 9:57 AM #12905
Thank you – appreciate the quick response. I am not sure if I understand you correctly. At least the parameters that I am sending have correct UUID’s, I double checked, and all the parameters that I listed under the variableList have a UUID. However, I do measurements, e.g. soil temperature with a soil moisture sensor, which I do not send to MMW or log to an sd-card. I assume that should not give any problems right?
2019-08-13 at 3:52 AM #13065
Dear all, a brief follow up on this issue. I have redone the same system to log to MMW. I am sending 4 measurements Bat_volt, MaximDS3231_Temp, Modem_RSSI, Modem_SignalPercent. After enabling debugging I do not get any disturbing messages about the functioning of the Sodaq GPRSbee rev7, however I am still getting the response code 504 (gateway timeout), related to the server.
The same systems does send data to ThingSpeak. I receive about 40% of the data online (so I expect the modem work correctly). After enabling debugging for logging to ThingSpeak I do not get any disturbing messages. Signal strength is about 50% and seems good enough.
Unfortunately both options (MMW and ThingSpeak) still don’t get me at the level I would like to be. If someone has the same experience or any Ideas how to improve the reliability, please let me know.
2019-08-14 at 6:43 PM #13074Sara DamianoModerator
Can 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-15 at 4:32 AM #13075
I attached two files, deep and regular debugging for the gprsbee. This in the case of sending the data to MMW. I hope you can find something.
2019-08-15 at 4:34 AM #13076
You must be logged in to reply to this topic.