WiFi LoRa 32 V3: Send sensor data via LoRa, then go back to deep sleep

#121

Gentlemen, here are some test results:

Test 1: Keeping the sensor code in the main code and just plugging off all sensors from the board but leaving the power supply on for the sensors.
Result: The re-joins keep happening.

Test 2: Removing the entire sensor code, just sending some dummy values and using an LED as the indicator for the enable pin.
Result: Runs smoothly. The dummy values keep coming every minute, no re-joins at all, and I’m running it for 20 minutes already.

What will I do next?

  • Keep the dummy circuit and payload, just add the sensor code back in. → Goal: Finding out if the sensor code causes the issues.
  • Add sensors back in individually, and only have the “active” sensor plugged to the breadboard. → Goal: Finding out if a sensor is causing the re-joins.

Will update this reply with my findings.

By the way, once the custom PCB our university has ordered arrives, the communication will be done via a LORA RA-01H(SX1276) chip and an ESP32-S3-WROOM-1 … so if anyone has a good code for sending data to TTN with that, I’d be more than delighted to try that.

Update 1: The temperature sensor (GPIO7) is not the one causing problems (neither is its code).
Update 2: With the pH sensor (GPIO6), I got one re-join in ten minutes. That one is causing problems.
Update 3: The TDS sensor (GPIO5) sent for 8 minutes before re-joining again.

#122

My suggestion would be: put back in the regulator with the LED connected to it, keep all the same dummy code, then just connect sensors one by one. Still dummy code. That way you can check if the power circuitry isn’t causing problems. Once all sensors are back in the circuit without problems, add the analog sensor code back. And finally the DS thingy.

1 Like
#123

Just to be clear: To remove the sensor code, you removed this code block for the pH sensor?

// PH VALUE
pinMode(phPin,INPUT); // get the pH output
static float pHValue,voltage;
Value = analogRead(phPin);
voltage = Value * (5.0/6144.0); // 6306.0; 4095.0
pHValue = 3.5*voltage;
pHvoltage = voltage / 327.68;
pHcorr = pHValue - Alpha * (T + tempC) * pHvoltage;

And did you get the re-join simply by adding this code? Or just after you connected the physical sensor? Beacuse this code would also kind of work without connecting the sensor. It just results in nonsense values.

#124

I removed the code and just plugged in the sensor. I had the 5V from the controller and the GND from the board connected to the breadboard.

#125

So, it is not the code that make the whole thing go haywire, it is the fact that you physically connect the sensor, right? So there must be something going on with the power supply hardware. Do you have a bench power supply or some other 5 V power source? Because my next test would be to power just the sensors from an external power supply. Do do so, you would connect the GND from your board to the GND of the power supply and the GND of the sensors. The 5 V from the power supply would then be connected just to the Vcc of the sensors. If you are able to do it this way, the program could stay the same, go to sleep, whatever. But the sensors would be powered from the external supply all the time. What I expect would be that there should be no more re-join attempts. Just to be clear: The only thing going to Vcc of the sensors would be the 5 V from the external power supply, nothing else, no boost converter, no MOSFET, nothing.

#126

Okay, I did the following connection:

The board is powered via battery (from Sunny Buddy Load + and -), and from GPIO47 I have a cable to the En pin of the controller. The Vin and GND of the controller are connected to Load + and - of the Sunny Buddy. The breadboard with the sensors is connected to Load - on the Sunny Buddy and 5V on the controller.

I will first let this run a bit without any sensor output connected (right now, the Vin and GND of the temperature sensor are connected to the breadboard, but not its output), and then slowly add in the sensors. Basically going: sensor 1 power → add output → add sensor 2 power → add sensor 2 output → and so forth.

Will let you know what that does.

Finished testing all the sensors. It’s certainly not the sensors causing any issues with the re-joins. Given that the code that just sends dummy payload doesn’t cause re-joins either, I’d say the issue lies within some sensor specific code.

I’ll slowly add the sensor specific code back in and watch closely how it affects sending behavior. The temperature sensor code is already back in and running.

#127

Between your test 1 & 2 from post #121, assuming that your test 2 was without the power supply, it continues to point to the power switching which may just be too aggressive for the Heltec board to filter out.

@jsteiwer, can you confirm if your test 2 was without the power board?

And in your more immediate test above, did you use the power board when you added the sensors back?

As for @bns trying to blow smoke up places, I’m sure we’ll have something sane for the custom PCB although I’d better get on to adding in some diagnostics!

In the meanwhile, a table of results would improve clarity. And I’ll take a squint at the sensor code to see if there are any divide by zero or some such errors.

#128

I am somewhat confused now. I do not completely understand what your conclusion is.

  • Connecting all sensors physically does not cause any re-join when you do not include the code for reading the sensors in your program?
  • Once you include the code to read the sensors, you get re-joins?
  • What happens if you include all code to read the sensors except for all code for the DS18B20? And by removing all code for the DS18B20 I mean that you do not even include OneWire.h and DallasTemperature.h and remove the instances of OneWire and DallasTemperature. Do you then still get re-joins? I would try this once with all sensors connected and once while no sensor is connected. This will work, just with non-sensical values as long as your code otherwise closely resembles your “working code” on github.
#129

Hi Nick, the second test was with power supply. The LED was connected to the controller, and the controller got Vin and GND from the Heltec board, which was powered by USB during that test.

Right now, the sensors are supplied with 5V from the controller, but the controller’s Vin and GND are connected directly to the Sunny Buddy, and not connected to pins on the Heltec board. The only connection going to that board is that of the Enable pin.

Could you specify what you mean with table of results? What I did and what it led to? Or what is visible in the TTN console? If you could clarify what you need I’d appreciate it a lot.

@ksjh Connecting the sensors physically without the sensor code works fine and does not cause re-joins, correct. I have to test what happens when I add the sensor codes back in. The temperature code is running for 20 minutes now and so far no re-joins.

#130

It would be of benefit if we clarify the names. For me “power supply” could be the SunnyBuddy or it could be MrBoost, the 3->5V convertor (which I think is the main suspect). I’m assuming that “controller” is MrBoost and not MsHeltec.

It’s also not clear if there is a common ground (0V) between SunnyBuddy, Mr Boost and the MsHeltec - if not then the ground path for MrBoost will be via the sensors which can induce all sorts of signals.

It is so useful to see what MsHeltec is saying, so I’m loath to remove the USB from the mix. If you have a spare USB cable we could do some surgery on it to remove the power line so that the computer isn’t powering some or all of the setup. That would eliminate any issues with the computer’s USB being overtaxed.

But to simplify things for now, I’d remove SunnyBuddy, put MrBoost on to the 5V & and pins of MsHeltec so it’s permanently on and see what happens. Next post will have a table for you to copy & edit as you do tests.

#131

Copy me in to a post you can edit:

# Boost OneWire pH TDS EC DO Turbo Note ----Result----
1 N N N N N N N Just USB + Heltec
3 Y N N N N N N Add Boost with LED to 5V and Gnd
4 Y Y N N N N N Added DS18B20
5 Y Y Y N N N N etc
6 Y Y Y Y N N N
7 Y Y Y Y Y N N
8 Y Y Y Y Y Y N
9 Y Y Y Y Y Y Y
#132

Regarding the power supply: The Sunny Buddy (SB) currently powers the Heltec Board (HB) and the controller (the xV to 5V converter). The controller powers the sensors. Right now, I’m using the GND of the SB as the common ground.

Now for the results: The connection is from Load + of SB to Vin of controller, from Load - to GND of controller and to - of breadboard (BB), from controller 5V to + on the BB, and from HB to En of the controller. So the boost is always on, and I’m powering via battery on the SB instead of using USB.

# Boost OneWire pH TDS EC DO Turbidity Notes Result
1 Y Y N N N N N BB not powered via HB but SB. HB powered via SB. Works smooth without re-joins.
2 Y Y Y N N N N see above see above
3 Y Y Y Y N N N see above see above; the LEDs on the sensors blink weirdly when they are supposed to be off, but the data is coming in without re-joins (*)
4 Y Y Y Y Y N N see above Works smooth without re-joins. LED issue was fixed. (**)
5 Y Y Y Y Y Y N see above Works smooth without re-joins
6 Y Y Y Y Y Y Y see above see above

Y: code is present and sensor is physically connected
N: code is not present but sensor is physically connected

All tests with physically connecting the sensors without their specific code were successful, meaning no re-joins happened.

(*): Measuring the voltage, the GPIO47 remains at ~ 0.5V during sleep when it should be at 0V. This keeps the sensors on.
(**) Needs a 10kOhm resistor between GND and En because the “left-over voltage” of the MOSFETs keeps the enable signal high.

#133

To clarify: A “Y” means physically present and code included, right?

1 Like
#134

Keeping the sensors physically connected and switching the external 5 V supply (boost coverter) off and on again worked without re-joins. The sensor code just reads an analog signal, the GPIO pins are defined as INPUT. Then it does some maths, nothing hardware-related. This cannot change anything, except for the only digital sensor, the DS18B20. To communicate with this sensor, you need to send some data and wait, this is why this was my primary suspect. Another reasonable explanation would be some kind of timing error. But everything happens so fast, you are not waiting for anything when reading your analog sensors. It makes no sense that your program does something completely different when you just do an A-D conversion and some maths. But the results also do not sound like a power supply issue at all. Switching the sensors on and off and the program still works, but reading them causes re-joins? The analog sensors should not care if their output is measured or not.

#135

I have no idea why all this is behaving so weirdly. Right now, for example, the Enable pin GPIO47 continuously produces values above 0V, leaving the sensor LEDs on, which is exactly the opposite of what I want. The input voltages from the battery are however within the range of what the Heltec board and the controller can take. It just sucks.

#136

We are still talking about the Tindie converter @bns suggested? In post 106 he mentioned to place an additional resistor between the EN pin of the boost converter and GND. Is this resistor still in place? In post 93, I linked the datasheet for the chip on the boost converter. This datasheet states that the minimum voltage on the EN pin to enable the converter is 0.96 V, the maximum shutdown voltage of the EN pin is 0.6 V. So, at 0.5V, the converter needs to be off in any case.

#137

Yes. Right now, the resistor is not in place. But it worked fine without it the whole day, it’s been behaving weirdly for like not even half an hour now? The voltage is slightly above 0.5V, so 0.55V. The LEDs on the sensors just twitch weirdly like they want to be off but cannot be. Even when I remove power from the Heltec Board, which should result in 0V on the enable pin, the sensors remain on. It’s so weird. And even if I go back to previous code versions, where the error originally did not occur, the error remains. So it’s not the code, not the connections, and I’m at my wits end for what could cause this behavior. Maybe it’s the board itself? I am confused.

#138

Even tough @bns mentioned that you do not need to set GPIO47 to LOW before going to sleep, I highly recommend doing this anyway, especially when no resistors are present. A lot of modern boost converters use MOSFETs internally. And these MOSFETs have a small internal capacitance, they store a little bit of charge (voltage) that might keep the MOSFET turned on. So, either a resistor to pull EN to GND (10 kOhm to 100 kOhm), or discharge the capacitor by pulling the EN pin to GND by explicitly setting GPIO47 to LOW before sleep or when you are done reading your sensors, or, even better, both the resistor and setting the GPIO to LOW.

#139

Okay, put a 10kOhm between GND and En, now it works again. Thank you so much for the reminder. Will also set the GPIO to LOW in the code just to be extra safe. Where in the code should I best place it? Right before LoRaWAN.sleep(loraWanClass); did nothing besides causing nonsense values.

Anyway, anyone up to starting a discord support group server for victims of electronics, hardware, and software? :sweat_smile:

#140

This would also be my best guess. If this does not work, just leave it out for now, the resistor is enough.

1 Like