[Sara Damiano]

I hate trying to read any detailed explanations of cellular network architecture because there are a truly ridiculous number of acronyms used and I don’t use any of them enough to remember what they mean. It feels like 3/4 of the explanations of network architecture forget to define 3/4 of the acronyms so I’m always floundering back and forth between different articles trying to get it straight.

[Sara Damiano]

What manual are you using? CREG, CGREG, and CEREG are all in the AT commands manual for the SARA R4: https://www.u-blox.com/sites/default/files/SARA-R4_ATCommands_%28UBX-17003787%29.pdf

CREG = Network (circuit-switching) registration status
CGREG = GPRS (packet-switching/General Packet Radio Service) network registration status
CEREG = EPS (Evolved Packet System) network registration status

This page has some nice diagrams explaining the “levels” of the network architecture: https://www.3gpp.org/technologies/keywords-acronyms/100-the-evolved-packet-core, but I’d guess you understand it better than I do.

I had thought that if you had any connection with the network at all, it would be visible in CREG. Rather, I’d thought of CREG as “any connection at all” not specifically circuit switching connection. Now that I’m looking harder, I think it might be possible to have the EPS connection without a CS connection since EPS doesn’t have any circuit switching. That would explain the issue with seeing nothing in CREG and but getting connection quickly with CEREG. The R410M doesn’t support GPRS, so I believe CGREG should always return unregistered for it. The R412 does have GPRS fallback, so at the request of a TinyGSM user I changed the code from checking CEREG to CREG. I’ve since changed it back, though, so if you have the latest version you should see CEREG being queried.

[Sara Damiano]

I’m sorry I haven’t been responding on this. I’ve been working on other data projects and haven’t had a chance to look into this at all yet.

[Sara Damiano]

Where is the extra red (5V?) wire in your pictures from September connected? It looks like you have the Yosemetich connected to one 12V power supply (red line at the bottom), the Mayfly powered by second 5V power supply (the black/red twisted pair?) and then the Mayfly also connected to the computer’s USB. But then I can’t figure out the extra wire. You’re sure everyone’s sharing a ground? (I know you already checked, but it’s worth checking again.)

Do you have an RS485 adapter that isn’t attached to a “WingShield” that you could test with? I don’t expect that the wing is the problem, but using the raw adapter would completely eliminate it from suspicion.

If you can use an RS485 adapter that hasn’t been built into a wing, connect it to Serial1. The hardware serial port is *always* better than any software version and using it eliminates any questions the serial libraries. We’ve had some sensors that absolutely refused to talk over anything but hardware serial.

AltSoftSerial should not (generally) conflict with much else. It uses timer capture interrupts rather than pin change interrupts that other software serial libraries use. But using too many libraries that define interrupts of any type can cause some headaches with serial communication because the timing is really important and even well written interrupt routines can throw the timing off enough to cause it to be garbled. In my experience AltSoftSerial *is* the very best alternative to hardware serial. I don’t think I ever succeed in communicating with the Yosemitech’s over the version of SoftwareSerial that’s been modified to play with the rest of ModularSensors – it’s just not accurate enough. I’m really surprised your experience has been the opposite.

Once you can get the GetValues example to run smoothly, try running modular sensors with the build flags for the variable array turned on. (MS_VARIABLEARRAY_DEBUG and MS_VARIABLEARRAY_DEBUG_DEEP) that might give me a better idea of where ModularSensors is crashing.

[Sara Damiano]

The status of the communication between the Yosemitech’s and the Mayfly hasn’t changed since May.

The library for communicating with the Yosemitech’s is here: https://github.com/EnviroDIY/YosemitechModbus

It depends on the SensorModbusMaster library here: https://github.com/EnviroDIY/SensorModbusMaster

If you want to use the Yosemitech in combination with a OBS3+ and log the data, you can use the ModularSensors library here that supports both: https://github.com/EnviroDIY/ModularSensors

[Sara Damiano]

That looks like the converter I have. If you’re sure you have the right A & B wires, your doppler is powered, and the lights on the adapter are flashing, but you’re still not getting anything on the Mayfly, try flipping the Tx and Rx wires. Different people have different opinions on whether Tx means “the pin I’m sending out data on” or it means “the pin to connect the other guy’s outgoing data pin”.

The A & B from your ADCP are red and black? That’s not a problem; I’m just surprised. Often red and black are used for power and ground, but each manufacturer does their own thing, so you have to check that in your manual. Also, if your manual labels those wire as “to” and “from” it’s not using RS485. You should be using wires labeled A and B (or sometimes Y/Z or D+/D-.)

RS485 communication requires two wires for communication in each direction, which is why they’re usually labeled A & B and not Tx and Rx. The high and low “bits” in RS485 are counted by checking the difference in voltage between the two wires. This means an RS485 signal can make it through longer wires, but it also means that communication usually only goes in one direction at a time. TTL on the other hand reads high and low “bits” on a single wire by checking the difference between the voltage on that wire and system ground. There are often two wires used, one wire for incoming data and one wire for outgoing data, so you can be talking and listening at exactly the same time (aka full duplex). To get full duplex in RS485 you need 4 wires. The adapter translates between the RS485’s two wires and the TTL wires, with some magic circuity to get the direction right (and also some fuses and other magic to make it all less likely to blow up).

While you’re still testing out your communication, program your Mayfly with a really simple sketch that will echo everything it hears from Serial1 to Serial so you can see it on the serial port monitor:

C++

#include <Arduino.h> setup() { Serial.begin(115200); Serial1.begin(9600); Serial.println("Passing through data from Serial1"); } loop() { while(Serial1.available()) { Serial.print(Serial1.read()); } }

1 2 3 4 5 6 7 8 9 10 11 12 13

#include <Arduino.h>   setup() {     Serial.begin(115200);     Serial1.begin(9600);     Serial.println("Passing through data from Serial1"); }   loop() {     while(Serial1.available()) {         Serial.print(Serial1.read());     } }

[Sara Damiano]

I don’t think there’s any sort of built-in antenna on the LTE XBee3. I was under the impression that the external antenna is absolutely required. I’ve never gotten it to connect without one.

We’ve bought ours from Digi Key. I think we’ve tried a couple of different models and haven’t had any problems with any of them. We’ve even put the 2G antennas on and had those work. https://www.digikey.com/products/en/rf-if-and-rfid/rf-antennas/875?FV=93404c3%2C1d6c0003%2Cffe0036b&quantity=0&ColumnSort=0&page=1&k=lte+antenna&pageSize=25&pkeyword=lte+antenna

[Sara Damiano]

Hardware-wise, do you have an antenna attached to the “cellular” uFL connector? You’ll never connect without an antenna.

But.. these LTE boards are just more finicky than 2G, so…

You’re using the example from ModularSensors, right? https://github.com/EnviroDIY/ModularSensors/tree/master/examples/logging_to_MMW That example should work with the LTE adapter as written; just change the APN. I usually use “hologram” as the APN, but I think that “apn.konekt.io” works too.

Have you ever connected this XBee3 or SIM card to the internet before. Occasionally with a new sim card or new module or new location it can take a very, very long time (>20 minutes!) for the module to register. I think Shannon’s been getting most of the new cards to connect within the two minutes the program waits, but I know last week she had a long argument with a few SIMs that took hours of fiddling before registering.

What versions of ModularSensors and TinyGSM do you have installed? If you’re not running ModularSensors 0.26.16 and TinyGSM 0.9.19, then you should update.

What output are you getting? Can you paste it in? Are you using PlatformIO or the Arduino IDE? If you’re using PlatformIO, can you add these flags to your platformio.ini flag to turn on some extra debugging printouts and then share the log: (It might be very long.)

INI

build_flags = -DTINY_GSM_DEBUG=Serial -DMS_LOGGERMODEM_DEBUG -DMS_LOGGERMODEM_DEBUG_DEEP -DMS_DIGIXBEE_DEBUG -DMS_DIGIXBEECELLULARTRANSPARENT_DEBUG -DMS_DIGIXBEECELLULARTRANSPARENT_DEBUG_DEEP -DMS_DIGIXBEELTEBYPASS_DEBUG -DMS_DIGIXBEELTEBYPASS_DEBUG_DEEP

1 2 3 4 5 6 7 8 9

build_flags =     -DTINY_GSM_DEBUG=Serial     -DMS_LOGGERMODEM_DEBUG     -DMS_LOGGERMODEM_DEBUG_DEEP     -DMS_DIGIXBEE_DEBUG     -DMS_DIGIXBEECELLULARTRANSPARENT_DEBUG     -DMS_DIGIXBEECELLULARTRANSPARENT_DEBUG_DEEP     -DMS_DIGIXBEELTEBYPASS_DEBUG     -DMS_DIGIXBEELTEBYPASS_DEBUG_DEEP

If you can’t get the XBee3 to connect in transparent mode, try switching to bypass. Both Shannon and I have seen it suddenly connect when it’s put into bypass. https://www.envirodiy.org/topic/trouble-registering-with-lte-m-network-on-hologram/ All you have to do to change that example to use bypass instead of transparent is replace the text “DigiXBeeCellularTransparent” in lines 101, 106, and 111 with “DigiXBeeLTEBypass” The library will take care of changing the modes for you. Digi warns all over in their literature that bypass mode is deprecated, but my experience has been that it connects to the network much faster and more consistently when using bypass. I do get occasional freeze ups when using bypass mode that lock everything up until the watchdog reset kicks in (~15 minutes), so once you get it to connect to the network you may want to switch back to transparent for a long term deployment. @Aufdenkampe, NeilH and I have some discussion of the different modes here: https://github.com/EnviroDIY/ModularSensors/issues/277

[Sara Damiano]

You’ll need an RS485 to 3.3V TTL adapter. I *strongly* recommend getting one with built-in flow control. I also highly recommend hooking your doppler up to the Mayfly’s Serial1 unless you have good reason not to.

Once you have the connector you should be able to transfer data from the doppler to an SD card using a library like SdFat and a simple sequence like:
while (Serial1.available())
{
SdFile.print(Serial1.read());
}

[Sara Damiano]

Do you have the FTDI VCP drivers installed? https://www.ftdichip.com/Drivers/CDM/CDM%20v2.12.28%20WHQL%20Certified.zip That’s the chip on the Mayfly that handles the USB communication.

[Author]

Posts