Sara Damiano

In asking about “your other thread” I meant this: https://www.envirodiy.org/topic/sd-card-recording-data-issue/

You need to make the modifications I mentioned above. You also need to pick a file name that is less than 8 characters, ie, “cond.txt” instead of conductivity.txt. I’d forgotten about the filename issue.

Your new code would be:…[Read more]

Did you get a chance to do any more troubleshooting on this?

It sounds like what you’re really after is a good LIMS system to help your technicians ties measurements to the correct sites and then visualize them all together on a map. The MontitorMW portal can only really help with the visualization part.

Yay! That’s more like it.

There are several posts and GitHub issues comparing the two but here’s a quick summary:

Bypass:
+ connects to the network faster
+ near 100% success in sending data if a network connection is made
– every transmission uses very slightly more data (in uncontrollable overhead – unsure why)
– Digi strongly discourages use…[Read more]

Select “All” as the manufacturer and “Calculated” as the sensor model.

Oops. So, it never tried for longer than 15 minutes with that sketch because the watchdog doesn’t get “fed” while it’s waiting for the internet and it “bites” (ie, forces the board to reset) after 15 minutes. But 15 minutes is still a pretty long time to wait.

After the first connection in a new location, it should connect much faster in…[Read more]

Hm. I’m not quite sure I follow you.

It sounds like you have a sensor package that you deploy at one spot for a while, then you stop it, pack it up, and move it somewhere else. After some time, you move the sensor package back to the original site. Is there ever data being collected while it’s moving, or is the GPS data only being collected to…[Read more]

I think

File Conductivity1 = SD.open(“Conductivity.txt”,FILE_WRITE);

should be

Conductivity1 = SD.open(“Conductivity.txt”,FILE_WRITE);

You also should have a

Conductivity1.close()

before the last delay.

Are you using a Mayfly? Are you using the built-in microSD card slot or the vertical adapter? What output do you get?

Did you ever ge…[Read more]

@ensign – yup, it’s a nice video. But… creating a video like that automatically for every set of uploaded trajectory data is just a little bit more difficult than making a simple plot with time on the x axis.

The WinRiverII software for the moving acoustic Doppler current profilers that we use to take discharge measurements has some nice…[Read more]

Hm. You have the LiPo plugged in in addition to the USB, right?

Are you sure you have service and the antenna is well connected? Don’t yank the antenna off unless you really have to; those u.Fl connectors are fragile and after 3 or 4 times of being disconnected and reconnected they stop working.

Have you ever gotten your XBee3 to connect?…[Read more]

Scott Ensign, formerly of Planktos Instruments, is now at Stroud. (He’s @ensign.)

I don’t know how “unusual” trajectory data is, but, at least in long term stream monitoring, it’s definitely far less common than fixed station monitoring. That type of data is also harder to manage, visualize, or conceptualize. I’d guess if others don’t support…[Read more]

@ensign has done some work with a moving/drifting sensor stations: https://www.fondriest.com/news/hydrosphere-drifter-brings-lagrangian-sampling-freshwater.htm

The way Monitor My Watershed’s data portal is set up right now is very “site-centric” – the web pages are just not set up to accept moving sensor data like you would generate. The…[Read more]

Well it’s certainly not intended that less than 100% of the data makes it online, if that’s what your asking.

Beyond that I can’t really help without a lot more information. So, here goes:

Do you know where in the chain the data is being lost? Are you using a Mayfly? What code are you running? If ModularSensors, what version of both…[Read more]

https://github.com/ODM2/ODM2DataSharingPortal/issues/443

I’m stumped. I have no idea why it’s failing. Your format is correct, your UUID is correct and in the right place… I have no idea. I’ll report it as a bug.

Delete them.

If you don’t have a CTD attached, you should remove all the lines for the CTD. If you don’t remove them, your logger will waste time trying to communicate with a sensor that doesn’t exist and you’ll be wasting bandwidth sending empty values to the data portal.

I’m sorry the directions for that example are confusing – it was originally written for people directly working with Stroud and being assigned loggers by us. If you’re making your own logger outside of Stroud, you don’t have to worry about Stroud assigning your logger a number.

If you’re not working with Stroud, you get to assign your logger any ID you want it to have. We often use the Mayfly serial number or a numeric count of it being the nth logger we’ve deployed. You might also want to put your site name in the logger id, since it will end up as your file name. You could also call it “Bob” if you’d prefer. 🙂

The Digi documents don’t tell you what commands are exchanged between the u-blox chip – I don’t if the response the XBee3 gives to the “ATAI” command is based on CREG, CEREG, or some combination of those and any other commands that Digi found to be useful – and I doubt Digi is going to tell us. I suspect that it is a combination of commands.

If…[Read more]