Activity

Also, I’m really surprised you couldn’t find an adapter with automatic flow control. Where were you looking? There are a bunch on Amazon. This is one brand I’ve bought: https://www.amazon.com/SMAKN%C2%AE-Adapter-Serial-Converter-Module/dp/B010723BCE

I have never gotten the communication to work correctly using manual flow control, but it should not be causing your board to restart. I’ll look into it.

When using manual flow control, you have to set the direction pin high or low to change directions. The library does this, but I think there is a timing issue or something because my attempts at…[Read more]

Well, actually, I forgot about the internal data filter. Leaving the sensor always powered will give time for that to come into play. I don’t know if it will help any, though.

Some thing else I thought about in your code: Even though you’re delaying for a second between calls to the SonarRead() function, you were actually parsing and keeping…[Read more]

I put your code into a “code snippet” to make it easier to read.

You’re listening to the sonar via SoftwareSerial. SoftwareSerial works by means of pin change interrupts. Pin change interrupts wake the board up. While the sonar is powered, it will continuously send out data. So if your sonar is continuously powered and continuously sending…[Read more]

#include <SoftwareSerial_PCINT12.h>

#include <Sodaq_PcInt_PCINT0.h>

//sketch to log sonar data on Mayfly
//this one uses either board power or a battery pack to continuously power Maxbotix
#include <Wire.h>
#include <avr/sleep.h>
#include <avr/wdt.h>

#include <SPI.h>
#include <SdFat.h>
SdFat SD;

#include <RTCTimer.h>
#include…[Read more]

Sensor works much better in open air suspended over water on a boom. We are now testing taking 10 separate reads at each time interval- for trouble shooting information. Although occasional intervals give 300 for all 10 reads, most of the time bad data occurs in only the first 2 or 3 reads at any interval. We are seeing intervals with some bad…[Read more]

Can you post your code? I can’t help much with the sleeping issue without seeing your code.

The issue with getting those 300mm values back from the sonar is an issue with the sensor/installation itself not the code. The sonar will report its blanking distance (300 or 500 depending on the model) anytime something is too close to it to get a real…[Read more]

Thanks for the additional information, I appreciate you helping us out with this. I’ll send you a PM about what to do next.

I had the board powered with the 2500 mah LiPo battery and a 2w Voltaic solar panel and I was monitoring battery life when I saw the sudden drop in voltage.
I am using a XBEE S6B wifi module for telemetery.
Current draw on the battery is between 100ma and 120ma when reading sensors and transmitting
Current draw is not measurable when…[Read more]

Sara is probably the best one to comment on the code aspect of your question, but hardware-wise, you might want to try a different pair of pins for connecting the sensor. D19 is used as the status pin of the Xbee socket, and is used in all of the code examples we use for radio, wifi, and cellular telemetry. D18 is kind of reserved for being used…[Read more]

Yes, this is a known issue that I’ve seen with only a very few boards recently where we see those exact same incorrect voltage readings around the Q1 mosfet. I haven’t tried replacing parts to see whether it’s the mosfet or the D3 diode, but it’s definitely either one of those, or possibly both of them. I’ll see if I can experiment with some bad…[Read more]

We’ve completely run out of them because of all the requests for starter kits lately, plus our own flurry of logger assembly and deployment this fall, but as soon as we get more in stock we will be listing them for sale on Amazon as a separate item by themselves.