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
-
You set pin 22 high in whatever program/sketch you’re using.
I don’t have a uBee with the R410M, but I’ve updated a whole bunch of the Digi boards with the u-blox “Easy Flash” software and direct USB to the SARA chip. You should be able to use the same firmware and software to update. You may even be able to do the update through the serial port without soldering a USB connection on. (Sodaq breaks the pins out to J1, but that’s it.)
You can get the most recent u-blox firmware and Easy Flash here: ftp://ftp1.digi.com/support/firmware/u-blox_EasyFlash_10.02_SARA-R410M-02B-01_IP.zip
Are you still using ModularSensors or TinyGSM on your boards? I was thinking about it and remembered that TinyGSM had previously used “CEREG” to check registration but a while ago I changed it to “CREG” to query both EPS and GPRS registration to support 2G fallback on the R412 chip. That change might be why older code was having less trouble. I’ve modified TinyGSM (which ModularSensors uses) to use “CEREG” again – so that may help.
These 4G chips just seem to be so much more finicky about connecting than the 2G ones were. I don’t know how much of it is the u-blox chip vs the SIMCom (SIM800) that we used to use in the GPRSBee and how much is the network itself, but I miss having 2G service.
Do you have the latest u-blox firmware?
Yes, I’ve seen this sort of thing.
Well, not precisely, but similar. The Digi LTE XBee3’s have the same chip and I’ve seen it happen several times that the XBee refused to register, then I put it in bypass to check the registration, got it to register, then it magically stayed registered when I went back. I haven’t seen it consistently, though, just occasionally.
You’re missing some rows of your header. That file will definitely not work.
At minimum, you need the text “Sampling Feature UUID: ” before that UUID and another row that specifies the UTC offset with the text “Date and Time in UTC-#” where # is your offset. You can put all the result UUID’s on the row with the feature UUID as you’ve done, as long as the text “Sampling Feature UUID: ” is before that first UUID. See section 4.3: Uploading CSV Sensor Data # in https://wikiwatershed.org/help/sensor-help/sharing-sensor-data/ for more detail on the upload format.
Any boards programmed with current ModularSensors code (as yours were, unless you reprogrammed them) should be drag-and-drop ready for upload. You should not need to make any modifications to the file, unless it is too big. At this time, files over ~5000 rows need to be spliced into multiple shorter files, each with the same header. That size limit will be increased (hopefully) soon.
Since we are not using the screen any longer, I2C is also no longer being used.
No. If you are using either the DS3231 real time clock or the TI1115 analog-to-digital converter built into the Mayfly, you are using I2C. Both of those are I2C chips.
It’s possible that there is a short-circuit in the Mayfly, but this sounds more like a problem with your code or sensors.
When you’re posting code, please use the “Add Code Snippet” button. It adds coloring and formatting which makes the code much easier to read.
When you’re troubleshooting the boards, make sure to check the position of all of your switches and jumpers. If the small switch at the top of the board is set to “4-12V” instead of LiPo, the board will not be powered by the computer and thus will not respond when plugged into the computer. Also check all the settings of the jumpers near your Grove ports. Most of then can be changed between 3.3V switched and 5V switched power and the I2C can be changed between 3.3V switched and 3.3V continuous power. Some I2C devices have internal pull-up resistors which can cause the I2C bus to go low if the power is switched off. If the I2C bus is held low for any reason, the Arduino core I2C (Wire) library will crash and the board will completely stop responding. Both the RTC and the auxiliary ADC use I2C to communicate, so the crash might happen when you’re talking to one of them instead of when you’re talking to a sensor.
I am not familiar with the particular OLED screen you are using, but I wouldn’t recommend any screen for field deployments because they require a fair amount of power. If you do not have one attached, you should probably remove the code for it to help make troubleshooting easier.
You can also try dropping the minimum battery voltage for the modem to ~3.5. Shannon has suggested that, especially if the battery voltage is going down at night but is likely to be recharged once the sun comes out.
It doesn’t send the data from the gap because the ModularSensors library simply doesn’t have that functionality. It doesn’t attempt to re-send data. The data should be on the SD card, as long as the battery was still high enough to log.
I would really love to have that functionality in ModularSensors, but it’s not simple to implement and I just haven’t had time. If you do have time, I’d welcome a pull request!
You’ve included both “SD.h” and “SdFat.h”. Did you try including only one of those? They might not conflict for the compiler, but they have very similar functionality and shouldn’t be included together. Your code is written for SD. SdFat is better, but for what you’re doing it shouldn’t matter.
-
AuthorPosts
