[Sara Damiano]

Yes, that’s what the streamdebugger is supposed to do.

Hmm.. try forcing a reset to all default values. The TinyGSM library drops the timeouts for xbee communication really low, which is great for the mayfly sending commands, but not as good for human typists.

C++

#include <Arduino.h> #include <StreamDebugger.h> StreamDebugger StreamDbg(Serial1, Serial); void setup(){ Serial.begin(115200); delay(50); Serial1.begin(9600); delay(50); pinMode(23, OUTPUT); digitalWrite(23, LOW); pinMode(19, INPUT); delay(1500); StreamDbg.print("+++"); while (Serial1.available < 2) {} // wait for ok StreamDbg.print("ATRE"); // Restore device parameters to factory defaults. while (Serial1.available < 2) {} // wait for ok StreamDbg.print("ATWR"); // write the new (default) values while (Serial1.available < 2) {} // wait for ok StreamDbg.print("ATAC"); // apply changes while (Serial1.available < 2) {} // wait for ok } void loop() { // Start direct-access from Serial to Serial1 StreamDbg.directAccess(); }

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

#include <Arduino.h> #include <StreamDebugger.h> StreamDebugger StreamDbg(Serial1, Serial); void setup(){   Serial.begin(115200);   delay(50);   Serial1.begin(9600);   delay(50);   pinMode(23, OUTPUT);   digitalWrite(23, LOW);   pinMode(19, INPUT);   delay(1500);   StreamDbg.print("+++");   while (Serial1.available < 2) {}  // wait for ok   StreamDbg.print("ATRE");  // Restore device parameters to factory defaults.   while (Serial1.available < 2) {}  // wait for ok   StreamDbg.print("ATWR");  // write the new (default) values   while (Serial1.available < 2) {}  // wait for ok   StreamDbg.print("ATAC");  // apply changes   while (Serial1.available < 2) {}  // wait for ok   } void loop() {     // Start direct-access from Serial to Serial1     StreamDbg.directAccess(); }

[Sara Damiano]

ModularSensors doesn’t support the teensy at all and it’s very unlikely that I’ll ever be able write in the support for it there. Your have to switch to an AVR or SAMD based board to use it.

[Sara Damiano]

I’m not familiar with the Teensy at all, but based on my <5 minutes of google research:

– They’re ARM Cortex-M4 boards – totally different processor style
– But the core libraries support the same attachInterrupt() routine that I use to support interrupts on the SAMD boards – good – you can just copy the SAMD interrupt includes
– google isn’t telling me how timers work on the teensy – bad – In order to do a better job of reading the (slow) sdi-12 communication without wasting a huge (relative to processor speed) amount of time delaying in the the interrupt routines, I’ve re-written the library to check what time bits changed based on the processor timers. To get it to work on the teensy, you’d need to figure out how the timers work on the teensy and then write out the correct timer-checking information into the sdi12_boards file

Unless you have a 2.0, then it’s basically a Leonardo and should work fine.

Unfortunately, I don’t have any time at all to help you with this. I might be able to glance at pull requests or give you quick guidance on how the timers are integrated, but I can’t do much more than that.

[Sara Damiano]

Get StreamDebugger here: https://github.com/vshymanskyy/StreamDebugger

[Sara Damiano]

My first guess would be that you put it to sleep and it won’t wake up.

Can run a really simple script just to hold the pins to wake it up and allow you to type in commands from your serial port monitor?

C++

#include <Arduino.h> #include <StreamDebugger.h> StreamDebugger StreamDbg(Serial1, Serial); void setup(){ Serial.begin(115200); delay(50); Serial1.begin(9600); delay(50); pinMode(23, OUTPUT); digitalWrite(23, LOW); pinMode(19, INPUT); delay(1500); StreamDbg.print("+++"); } void loop() { // Start direct-access from Serial to Serial1 StreamDbg.directAccess(); }

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

#include <Arduino.h> #include <StreamDebugger.h> StreamDebugger StreamDbg(Serial1, Serial);   void setup(){   Serial.begin(115200);   delay(50);     Serial1.begin(9600);   delay(50);     pinMode(23, OUTPUT);   digitalWrite(23, LOW);   pinMode(19, INPUT);     delay(1500);   StreamDbg.print("+++");   }   void loop() {     // Start direct-access from Serial to Serial1     StreamDbg.directAccess(); }

[Sara Damiano]

I’ve spent more time fiddling with the LTE-M XBee and I’m seeing the same results.

It’s a hardware problem, not software; the modem really does stop responding. I wonder if it’s that there’s not enough capacitance along the power line causing very short voltage drops even when it’s tied right to the battery. The user guide for the LTE-M XBee specifically warns that the main control board on the XBee can become unresponsive after power dips and will need a full power-cycle to get it back. Oddly, though, I’m having it start responding again without actually power cycling it.

I have a Skywire development board that has more capacitance on the power line. I’ll fiddle with it and see if I’m having the same issues.

@shicks?

[Sara Damiano]

I’ve made an Arduino library for communicating with the Yosemitech sensors: https://github.com/EnviroDIY/YosemitechModbus

It’s built on top of my modbus library: https://github.com/EnviroDIY/SensorModbusMaster

In the modbus library there’s a hardware folder with the plans for a little “wing” board to more easily connect a Yosemitech sensor to a Mayfly.

I can’t actually say very much about the data quality, though. The probe Anthony mentioned ended up bounced between desks for over a year before I got the library to communicate with it working. When we ran a calibration on it after that, it didn’t seem as stable as the YSI sondes we have. Since the sensing cap only has a listed life of a year, we couldn’t really say if that was because the sensor wasn’t as good or the cap was just too old. And we still didn’t have a good case set up to actually put it anywhere, so it just sat on a desk for several more months. About a month ago I attached it to a group of Yosemitech sensors I have running downstairs in one of our artificial flumes. We are running those sensors to watch how the turbidity compares, but I threw the DO probe on because it was looking lonely on my desk. If you want to look at the data from it: https://data.envirodiy.org/sites/SWRCWetLab/

[Sara Damiano]

Oh dear. That definitely *is* a problem. And that’s entirely my fault; I hadn’t error-checked that json in a long time. It should be fixed now.

Just FYI, there’s a lot in that library bundle.

[Sara Damiano]

I’ve usually seen that “no response” pattern with the 3G XBee’s without the solder jumper. I’ve assumed it was them “browning out” as they tried to connect to the internet. With those, switching the solder jumper seemed to fix the problem. Have you been able to connect to the internet at all with the LTE-M XBee? Is it working attached to a computer with XCTU?

[Sara Damiano]

We’ve bought these ones from Oregon Rule: https://oregonrule.com/product/superior-staff-gauges/ They don’t rust like the WaterMark ones eventually do. And, at least in the US, they’re cheaper.

[Author]

Posts