Forum Replies Created
-
AuthorPosts
-
OK, thanks Sara. I really like the look and layout of the new Doxygen docs. Thanks for all your efforts!
Matt
Apologies for resurrecting an old thread, but it is exactly on-topic for my situation.
I’m confused about wiring the MaxTemp. The ModularSensors documentation says to connect the red wire from MaxTemp to the MaxSonar’s pin 6 (V+). However, the MaxBotix datasheet shows no connection of the MaxTemp to V+. Likewise, @fisherba Beth’s photo above shows there are only 2 connections from MaxTemp: one to the MaxSonar’s pin 1 (via yellow Grove wire) and the other to pin 7, GND (black wire). Beth said her circuit works, so @srgdamiano, is the ModularSensors doc incorrect?
Thanks!
MattThanks, Anthony, for this informative post! It speaks to some questions we at Trout Unlimited have had about MMW, its current performance, and future direction, as we look to expand our Mayfly deployments.
Matt
(cc @jlemontu-org)
Me too. The problem seemed to be specific to the one browser tab; when I opened a second (non-incognito) tab, it worked. Never had that happen before with MMW.
Thanks again,
MattHi Robert,
Hmm looks like it is browser-related. I tried again just now and still didn’t work, but it does work in an Incognito window, so not sure what’s up. My colleague reported that it wasn’t working for him this morning, so I checked and it didn’t work for me at that time either.
Thanks for your reply,
Matt
Hi Neil,
Thanks for opening up this important topic, and for sharing your work!
This idea of scaling up one’s Mayfly installations is really coming to the fore at my organization, Trout Unlimited (TU). My colleague Jake (@jlemontu-org) has been working with Stroud for a couple of years now to deploy Mayflys with volunteer groups in Michigan, Pennsylvania, and elsewhere. Last fall I joined forces with Jake to begin making customizations to the code and building our internal capacity to assemble our own monitoring stations and conduct trainings without imposing additional load upon the time and resources of our partners at Stroud.
Once we refined our monitoring needs and began to deploy our code to multiple stations, we quickly realized that 90%+ of our stations will have the same configuration of sensors; the only differences between the stations’ firmware are the UUIDs, Station ID, etc. Using some kind of config file on the SD card would alleviate the need to rebuild the code for each new station. And if we had that capability, we would avoid the risk of inadvertently introducing changes to the binary (due to library updates and dependency changes on whichever PC the code was rebuilt).
Second, it’s not feasible for us to train a number of our folks, who are dispersed nationwide, to be proficient with the development stack (VSCode, PlatformIO, and ModularSensors). It’s not hard, per se, but there is a learning curve. So it makes a lot more sense for me to centrally manage our source code (and to document when it changes), and to build and distribute a binary (.HEX file) for installation by a local staffer or trained volunteer. That process (using avrdude to install the .hex) is a much easier lift than setting up a development environment and building from source code, for a majority of folks.
As we work to expand the use of this awesome platform among our volunteer chapters, as well as our scientists and stream restoration staff, these kinds of scalability features are critical, and I’d like to see us — the EnviroDIY community — bring them into the mainstream of the Mayfly ecosystem.
Looking forward to more discussion and idea-generation here!
Cheers all,
Matt Barney,
Trout UnlimitedToday I re-tested, using new hardware: Mayfly, modem, antenna, and LTEBee adapter. I’m still seeing the same problems: both Response Code 504 from MMW, as well as what I described above, where there was apparently(?) no attempt by the Mayfly to upload data after saving it to the SD card based on the messages it logged. I’ll attach the log file. Here is a summary (all times in MST):
- Ran from 04-08T11:48 to 04-08T16:30
- 142 samples recorded: ‘Line Saved to SD Card’
- 136 samples made it into the MMW database
- 14 received RC 504
- 123 received RC 201
- Timestamps of missing points (in MST):
- 11:52 – no attempt to send
- 14:14 – RC 504
- 15:04 – no attempt to send
- 15:10 – no attempt to send
- 15:18 – no attempt to send
- 15:30 – no attempt to send
Thanks for any insights.
Matt
Attachments:
Hi Robert,
I just now tried and am also unable to upload a CSV. In the past, I had trouble due to formatting or due to files that were too long, but once I figured that out, I saved examples of files that I’ve successfully uploaded. However, those are now failing as well. Sample csv attached, FWIW.
Matt
Attachments:
Hi again.
I ran another test overnight, again using a 2 minute sampling interval, with no code changes, but I removed the build flags for modem debugging from the platformio.ini. Here are the results:
- 427 total samples taken
- 52 sample events received a Response Code 504.
- 246 sample events received a Response Code 201.
- 155 of the samples are absent from the MMW database.
The new wrinkle here is that sometimes the Mayfly apparently didn’t attempt to send to MMW; this happened 129 times. In the log file, one of these occurrences looks like this:
123456789101112131418:06:01.802 > \/---- Line Saved to SD Card ----\/18:06:01.802 > 2020-04-02 17:06:00,25.00,4.836,-69,5,77.018:06:01.802 >18:06:01.802 >18:06:01.802 > ------------------------------------------18:06:53.812 >18:06:53.812 > ------------------------------------------18:08:01.191 >18:08:01.782 > \/---- Line Saved to SD Card ----\/… whereas a “normal” interval across consecutive samples, where the Mayfly does attempt to send, looks like this:
12345678910111213141516171819202122232425262728293031323334353618:10:01.804 > \/---- Line Saved to SD Card ----\/18:10:01.804 > 2020-04-02 17:10:00,25.25,4.836,-69,7,77.418:10:01.804 >18:10:01.804 >18:10:01.804 >18:10:53.254 > Sending data to [ 0 ] data.envirodiy.org18:10:53.255 > POST /api/data-stream/ HTTP/1.118:10:53.581 > Host: data.envirodiy.org18:10:53.581 > TOKEN: xyz18:10:53.581 > Content-Length: 31718:10:53.581 > Content-Type: application/json18:10:53.581 >18:10:53.581 > {"sampling_feature":"989b7148-d939-487e-ac47-baf41e30370d","timestamp":"2020-04-02T17:10:00-07:00","6ea18195-7d08-4cdb-9d02-2a374444b105":25.25,"b286a34a-0b48-4c35-a90e-a531a2594959":4.836,"621555d7-ebb1-4f8c-b8af-33fb35e78c3a":-69,"622b1b19-5a60-4c65-85d9-f33c80f81365":7,"6c79d6be-edd7-4bb3-836b-30b99d6b4f5d":77.4}18:10:53.581 >18:10:53.581 > -- Response Code --18:11:05.737 > 50418:11:05.737 > ------------------------------------------18:11:06.663 >18:11:06.663 > ------------------------------------------18:12:01.184 >18:12:01.805 > \/---- Line Saved to SD Card ----\/Any idea why the Mayfly didn’t send data at these times?
I’ll attach the log file and a time-series chart of when data was sent/not sent.
Thanks,
Matt
(Edit Apr6: Renaming my logfile so that it will successfully upload here.)
Hi Anthony, Thanks for that, and will keep the tracert in mind!
Hi Neil, Yep, that’s software development; I’ve got the grey hairs too! I am interested in learning more about your thoughts and approaches to reproducibility, so will start a thread on that soon. Your progressive testing approach sounds great, and is what I’m trying to work toward as our organization prepares to ramp up deployments. Just trying to find some stable baseline at the moment, and I’m not there yet. I’ll be posting a summary of my latest MMW testing shortly.
Matt
-
AuthorPosts