[Matt Barney]

Oh, now I see the Mayfly protoshield: https://www.envirodiy.org/mayfly/hardware/accessories/. It happens to be out of stock at Amazon at the moment, but that’s OK, I don’t have an immediate need. It would work, but would also require adding/moving the Grove sockets to the protoshield if one still needed those.

I was implementing a TTL-based sensor using a software serial port, and initially it seemed like it would be easiest to connect to the Mayfly’s digital pins via the 20-pin header, but I realized that I could instead use one of the Grove ports and a Grove to screw terminal adapter, so that’s what I did. In the future, if I need access to additional/different Mayfly pins, I’ll either get a protoshield or make my own.

Thanks!

Matt

[Matt Barney]

Thanks Neil.

Initially I thought I could use screw terminals but soon realized that the male pins that protrude from them are not long enough to provide a secure plug-in to the 20-pin headers. Perhaps my best solution will be to solder screw terminals to a small perfboard or proto board, along with male headers which would plug into the 20-pin females on the Mayfly.

Matt

[Matt Barney]

Yep, that was it. When I didn’t find the library in EnviroDIY, I just grabbed it from slashdevin’s original. Now that I have your fork of NeoSWSerial, it works. Thanks!

[Matt Barney]

Any ideas why AltSoftSerial works here, but NeoSWSerial doesn’t?

[Matt Barney]

Do people just use individual jumper wires to the Mayfly pins on these headers? Or is there a modular cable of some type that works with them?

[Matt Barney]

I repeated my test for another ~48 hour run, sampling every 5 minutes, but this time using WiFi instead of XBee3 cellular. All of my 548 sample points made it to the MMW database, and all POST messages sent by the Mayfly received successful response code 201. So data upload via cellular appears to be significantly less reliable, even when cell signal is good.

[Matt Barney]

Great news, @aufdenkampe! Thanks to you and your team.

I ran a test overnight, with a Mayfly sampling every 5 minutes. Out of 179 samples sent to MMW, only one received Response Code 504, at 04:30 MST, Aug 7th. All other POST messages received successful response codes (201). The 04:30 point did not get saved to the MMW database. What I’ve observed in the past was that the ‘504’ points still got saved in the database. In any case, this appears to be an improvement compared to my previous tracking of 504 errors.

There were 4 other sample points during my test which the Mayfly saved to the SD card but apparently never attempted to send to MMW, as there were no “Sending data” nor “POST” messages in the log at those times. I believe this is a Mayfly/Xbee3 issue, not a MMW issue. I’ve only seen it when using an LTE modem, not when using WiFi.

Best,

Matt

Trout Unimited

[Matt Barney]

I’m not an expert, but based on the Mayfly schematic (see pins 19 and 20 on the ATMega1284P, upper left), it looks like SDA and SCL are pulled high via external resistors on the board, so there is no way to disable them in code.

Reading a tutorial at Adafruit, it looks like that is an inherent part of the design of the I2C protocol:

The I2C clock and data lines need pull-up resistors to prevent from floating to random values. Since many different devices can share these lines the I2C protocol requires that each device ‘give up’ or stop driving the lines when not in use. If no device is driving the lines then the pull-up resistors ensure they go up to a high logic level instead of floating at random values.

Matt

[Matt Barney]

I think my code must not be catching the interrupt properly. It doesn’t get beyond this line in MaxBotixSonar.cpp:

result = _stream->parseInt();

1	result = _stream->parseInt();

I am able to get it working by using AltSoftSerial (Rx on pin 6), but am unable to get NeoSWSerial to read from the MaxBotix sensor.

Any help is appreciated.

Thanks,
Matt

[Matt Barney]

I’ve probably done something dumb in my code, but can’t see what it is, so I could use another set of eyes on it…

I’ve got a MaxBotix MB7589 SCXL-MaxSonar-WRMT and have it communicating via NeoSWSerial on pin 7. Using the single_sensor.ino example, it works fine. Now I’m trying to integrate it a logging sketch, based on DRWI_NoCellular.ino, and I never get any readings displayed nor written to the SD card. Code is attached. If I comment the sonar_range variable out of the variableList, it works, and the remaining variables get successfully logged.

Here is the debug output after turning on the debug flag in MaxBotixSonar.h:

C++

Now running DRWI_NoCellular.ino on Logger XXXXX Using ModularSensors Library version 0.25.1 Logger timezone is set to UTC -5 RTC timezone is set to UTC Current RTC time is: 2020-07-31T11:46:29-05:00 SonarRange has a non-unique UUID! Battery has a non-unique UUID! 12345678-abcd-1234-ef00-1234567890ab -> SonarRange 12345678-abcd-1234-ef00-1234567890ab -> Battery 12345678-abcd-1234-ef00-1234567890ab -> BoardTemp This logger has a variable array with 3 variables, of which 3 come from 3 sensors and 0 are calculated. Sampling feature UUID is: 12345678-abcd-1234-ef00-1234567890ab Logger portion of setup finished. Setting up sensors... Setting up file on SD card Data will be saved as XXXXX_2020-07-31.csv Putting processor to sleep ------------------------------------------ Dumping Header Lines from MaxBotix on sonarStream_trigger-1 <--MaxBotixSonar 0 - SCXL-MaxSonar-WRMT <--MaxBotixSonar 1 - MB7589-1XX <--MaxBotixSonar 2 - Copr. 2011-2019 <--MaxBotixSonar 3 - MaxBotix Inc. <--MaxBotixSonar 4 - R71 0819 <--MaxBotixSonar 5 - TempE <--MaxBotixSonar Dumping 6 characters from MaxBotix stream buffer: <--MaxBotixSonar 824857495713 MaxBotixMaxSonar at sonarStream_trigger-1 is reporting: <--MaxBotixSonar

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

Now running DRWI_NoCellular.ino on Logger XXXXX   Using ModularSensors Library version 0.25.1     Logger timezone is set to UTC -5 RTC timezone is set to UTC       Current RTC time is: 2020-07-31T11:46:29-05:00 SonarRange has a non-unique UUID! Battery has a non-unique UUID! 12345678-abcd-1234-ef00-1234567890ab -> SonarRange 12345678-abcd-1234-ef00-1234567890ab -> Battery 12345678-abcd-1234-ef00-1234567890ab -> BoardTemp   This logger has a variable array with 3 variables, of which 3 come from 3 sensors and 0 are calculated. Sampling feature UUID is: 12345678-abcd-1234-ef00-1234567890ab Logger portion of setup finished.   Setting up sensors... Setting up file on SD card Data will be saved as XXXXX_2020-07-31.csv Putting processor to sleep   ------------------------------------------ Dumping Header Lines from MaxBotix on sonarStream_trigger-1 <--MaxBotixSonar 0 - SCXL-MaxSonar-WRMT   <--MaxBotixSonar 1 - MB7589-1XX <--MaxBotixSonar 2 - Copr. 2011-2019 <--MaxBotixSonar 3 - MaxBotix Inc. <--MaxBotixSonar 4 - R71 0819  <--MaxBotixSonar 5 - TempE <--MaxBotixSonar Dumping 6 characters from MaxBotix stream buffer: <--MaxBotixSonar       824857495713 MaxBotixMaxSonar at sonarStream_trigger-1 is reporting: <--MaxBotixSonar

Thanks,
Matt

Attachments:

1. DRWI_NoCellular.ino.txt

[Author]

Posts