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
-
It’s awesome that you’ve created your own publisher! I’m really excited you’ve been able to pick up and modify this library to be useful for something new!
Ok. I see what’s happening. The R410M takes a *really* long time to close sockets (like 2 minutes). To speed things up, I call the socket close “asynchronously” – that is, tell it to close and move on. But what I think is happening here is that I’m telling the socket to close before opening a new one, just to be safe. (
AT+USOCL=0,1is close sock 0 with async flag) So the ‘close’ command goes out and the u-blox either spits out a not allowed error if the socket in question wasn’t open or says ok and starts doing whatever it is that takes it ages to do it to close a socket. In your case, it must believe the socket is open (it said ok). Then without waiting for that socket to finish closing, we ask the ublox to open a new socket (AT+USOCR=6– open socket, 6=TCP, don’t tell it the number), which it does. But, idiotically, it assigns us the new socket as socket 0+USOCR: 0which it is supposed to be in the process of closing. It even happily sets socket options (USOSO) and connects (USOCO), but, low and behold, somewhere in there the socket close command finally took effect and when you try to write to the socket.. you’re not allowed. Why the chip isn’t smart enough to assign a new socket number when we try to create the new socket after asynchronously closing the old one, I do not know. I also don’t understand why it didn’t return an error when asked to close the socket. Based on your log, it shouldn’t have been open in the first place. I don’t think I’ve ever seen it do that before.Enough babble; how to fix it. Unfortunately, I think you’re going to have to do it within the TinyGSM library. In that library, open up the TinyGsmClientSaraR4.h file and scroll down to line 97ish. Un-comment the chunk for “synchronous close” and comment out the chunk for “faster asynchronous close”. It will slow you connecting down (by up to 2 minutes..) but hopefully it won’t reassign you a new socket overlapping a closing one.
C++12345678910111213141516virtual void stop(uint32_t maxWaitMs) {TINY_GSM_CLIENT_DUMP_MODEM_BUFFER()// synchronous close <----------------------------------------------------------------- enable this chunkat->sendAT(GF("+USOCL="), mux);// NOTE: can take up to 120s to get a responseat->waitResponse((maxWaitMs - (millis() - startMillis)));sock_connected = false;// // faster asynchronous close <------------------------------------------------------ and disable this chunk// // NOT supported on SARA-R404M / SARA-R410M-01B// at->sendAT(GF("+USOCL="), mux, GF(",1"));// // NOTE: can take up to 120s to get a response// at->waitResponse((maxWaitMs - (millis() - startMillis)));// sock_connected = false;}The double AT commands are because echo is being turned on by default every time the board powers up. I think the echo settings are *supposed* to be stored, but like the baud rate, are not. It isn’t a problem; the repeated commands get tossed. If you want to turn it off to save yourself some scrolling, you can find the modemWakeFxn in SodaqUbeeR410M and modify it to turn off the echo:
C++12345678910111213#if F_CPU == 8000000Lif (_powerPin >= 0){MS_DBG(F("Waiting for UART to become active and requesting a slower baud rate."));delay(R410M_ATRESPONSE_TIME_MS + 250); // Must wait for UART port to become active_modemSerial->begin(115200);gsmModem.setBaud(9600);_modemSerial->end();_modemSerial->begin(9600);gsmModem.sendAT(GF("E0")); // <--- Add this line to turn off the echogsmModem.waitResponse(); // <--- listen for OK}#endifDoh. Yes, I thought of that as I was driving home. Do add the lines setting the wake pin high.
Do you know what version of the firmware you’re running? To check, you can either hook it up to the u-blox m-center on your computer, run a pass through sketch and send it the commands AT+CGMR? and AT+GMR?, or tack these lines in after the modem setup:
C++12345modem.setup(); // add after this line in the setupmodem.gsmModem.sendAT(GF("+CGMR?")); // firmware version identificationmodem.gsmModem.waitResponse();modem.gsmModem.sendAT(GF("+GMR?")); // firmware version identificationmodem.gsmModem.waitResponse();The
AT+USOWR=0,##commands are attempting to write data over an TCP socket. Usually when I’ve seen the “operation not allowed” it’s either because either the socket was already closed somehow or it was never open in the first place. All those other commands that are failing are trying to check the socket status or get data from it. They’ll also spit out that “not allowed” error if the socket they’re asking about isn’t live. What happened in your log before that first failure? Were there anyUSOWRcommands that got ok back? Was there a+UUSOCLin there (that means that the socket was closed externally)? What was the result of the+USOCRcommand (opening the socket)?The reason I asked about the firmware is mostly curiosity. One of the “improvements” in the latest version was related to it locking up and I have noticed improvements with the newer firmware, but it should be able to get through with the older version
a. We saw no evidence that the sensor had any issue related to condensation during the tests given that there was a hydrophobic coating on the sensor face and that the bad data occurred at random temperatures as opposed to only when the temperatures were low.
That’s good to know. What was the fluoropolymer grease you used?
b. Reading out the serial data with a pause between digits rather than at normal speed seemed to help eliminate bad data when the weather was warm. But, this did not solve the problem when cooler weather arrived in the fall.
I’m not quite sure what your code looked like, but this doesn’t make sense, so of course it doesn’t make a difference. The Maxbotix talks to your Mayfly at 9600baud sending an R####\r every cycle (150ms-ish). That is exactly the rate that the Mayfly listens and records the data in. That’s not a changeable setting. Any “pause” you add in your code is just a pause in reading out from the buffer that whatever underlying serial library you’re using already stored the characters in. No matter the rate you read your data out from the buffer at, the input rate doesn’t change. The only caveat to that is that SoftwareSerial is just pretending to be a serial port and so it’s possible to throw off the character accuracy if the processor is doing too much when the characters come in. The result of the SoftwareSerial errors would be total garbage though (as in not even printable characters), not readings like “R0300\r”.
c. There was no bad data during the testing of the sensor with continuously power independent of the Mayfly, including at temperatures well below freezing.
Good to know it works. Good to know. Assuming you’re not manually triggering the sonar every time, that’s the internal range filtering doing its job. I’d guess you could get similar results by powering up the sonar just 5-10 seconds before taking a reading. Based on the spec sheet, it takes 5 readings for the filtering to take effect. It doesn’t specify the maximum number of readings the filtering considers, but the sonar “boots” up in ~160ms and, as long as pin 4 is left floating, completes a reading every ~148ms. So if you power up the Maxbotix for even 10s before you accept readings (10s before opening your serial port that is) it will have already had a chance to take over 60 readings which is probably plenty for good filtering.
Yes, it’s probably related to the same issues that @acgold had. These ublox modules just seem to be so much more finicky than the 2G SIM800’s were.
Could you try switching to the “ModemLast” branch? That’s where the most recent work is and I’d prefer to do more of the troubleshooting on that branch since it’s mostly modifications to the setup of the modem.
sensors/YosemitechY504.his part of the ModularSensors library, not part of the Yosemitech library.You need to post more details of what exactly you’re trying to do and exactly what error messages you’re getting before I can help more.
I’ve attached some annotations showing what’s happening in your logs.
Attachments:
Ugh. I should just get one of these R410 uBee’s just to help other people out.
It looks like it’s powering down when it’s supposed to be waking up and visa-versa.
I could babble at length about it, but my first suggestion to try and make it work it is to add a ~500ms delay [
delay(500);] after themodemPowerUp()and another matching delay after themodem.wake();in your setup function. Just see if that works.The OBS3+ treats the low range and high range turbidity as if they’re two completely different things. So on Monitor My Watershed you actually have to create two different variables, one for each of the high and low range, just like you would separate temperature and depth from a CTD. I *strongly* recommend you add something to the notes field for each to remind you which is which. Once you’ve create two different variables on Monitor My Watershed, it will give you two different UUID’s.
Here’s another site with the turbidity set up for both high and low range: http://data.envirodiy.org/sites/PKCV7S/
If you really want to have only one turbidity field streaming, you can either pick one of the two or create a calculated variable that picks between the two depending on the turbidity. For most of our sites, we’ve decided to just stream the two separately.
In what way does it “not see it?”. You mean a program won’t compile? Or you cannot see the examples in the library drop downs? What does you library folder look like? Your program? Do you also have SensorModbusMaster installed and include that in your sketch? The Yosemitech library depends on it.
Is this what you’re looking for: https://github.com/EnviroDIY/YosemitechModbus
Did you download all of the libraries in this “Libraries” repository (https://github.com/EnviroDIY/Libraries)? I know there’s a big, green, inviting “download” button on the GitHub page, but because of the way the libraries are in linked repositories, if you download them that way all you will get is a bunch of empty folders. You have to download from this link (https://github.com/EnviroDIY/Libraries/blob/master/libraries.zip?raw=true) and then follow the instructions here: https://github.com/EnviroDIY/Libraries#installing-libraries-in-the-arduinocc-ide and here: https://www.arduino.cc/en/Guide/Libraries#toc5.
-
AuthorPosts
