Ultrasonic and LoRaWAN - timing incompatibility on a cubecell

#1

Has anybody run into clock/timing issues while lora is being used?

We are trying to get an ultrasonic sensor working and if we run a basic sketch to get a reading from the ultrasonic - no issues.

We have combined it with a LoRaWAN sketch, so it wakes up, takes a reading and sends.

But it seems as if the clock/timing usage of the LoRa library is messing with the ultrasonic reading timing, getting wild and inconsistent figures from the sensor.

Has anybody encountered this and overcome it?

Would it be possible to

  1. Wake up from sleep
  2. keep LoRa off
  3. Take a reading from the ultrasonic
  4. wake up Lora and send the payload reading

cheers
Paul

2 Likes
#2

Same here, using esp32 lorawan it just stop to work after a while, and using cube cell doesnt work.

#3

I imagine the LoRa stack state will get a bit upset, but you could definitely disable interrupts for a while during the sensor reads as that’s probably what’s causing the variance in timing.

I imagine you’ll get a response from Heltec too, but in the mean time try surrounding your sensor code with noInterrupts(); / interrupts(); (I’m not totally convinced it suppresses all interrupts, but worth a shot).

#4

Thanks, we’ll give it a try and let you know how it goes

edit: unfortunately didn’t make a difference

#5

Okay, if it’s using the microseconds on the CubeCell as part of the calculations then there is a known problem for the micros that would be throwing it off.

Got a link to the sensor code? Is it this?

I don’t have a good suggestion here - either an external atTiny just for this or a different sensor with its own processing. As I said, not good suggestions. No I don’t know why we have an example that doesn’t work.

#6

Thanks Bruce, no I havent tried that example as it looks overcomplicated when other libraries were available.

I think we have tried one called Newping (very broad compatibility with lots of boards and sensor types) and an adafruit ultrasonic library.

I will cobble together the lorawan example with the example you linked to above and see how it goes.

cheers
Paul

#7

Newping uses micros() a heap too, I expect the same results (but will be interesting regardless). Did you try not sleeping? The reset to 0 all the time will also bugger it up if it’s between you sending the ping and getting the results (although that’s not a long time, so I’m questioning if this is a problem, but maybe when it does multiple reads and averages?)

as @Aaron said

Another problem is the system ticker can’t run during the deep sleep period, wake up from deep sleep will make the micros back to 0.

You can avoid sleeping, as a test, by replacing
LoRaWAN.sleep(); with Radio.IrqProcess( ); in the loop SLEEP section. Longer term doing something in the code to cope with it returning to zero, or just not sleeping while a read was in progress, would be better of course, but this is just a guess at the underlying problem so far.

#8

thanks again

yes that allowed us to read the ultrasonic just fine

but not ideal for long term on batteries - it uses around 16ma instead of in the microamps when asleep

#9

I am running into the exact same problem, reading from the sensor only is perfectly fine. But when combined with LoRa functionality it starts misbehaving.

@mutton Did you get a walk around/ solve the problem?

#10

no not yet unfortunately, the above works but uses too much power for my requirements - the beauty of the cubecell is its super low power usage when sleeping.

any ideas @wasn?

#11

I may have found a solution, but cannot try myself waiting for a board to arrive, drop me a PM when you like to test …

#12

@mutton If it’s the sleeping that’s doing it, just set a variable to not sleep while you’re doing reads? You’re only reading periodically? That gets you 99% of your low power requirements e.g.

if (sensorReading) {
      Radio.IrqProcess();
 } else {
      LoRaWAN.sleep();
 }
#13

thanks @bwooce will give that a go tomorrow

#14

No, it is an issue with returning from deep sleep. I have filed a report to Heltec. For those of you who cannot wait, I can also provide a working work-around.

1 Like
#15

Can you send me the solution? Same problem after come back from deep sleep. My email is aluiz.martins@vallourec.com

Could you measure your current consumption and will still got something around uA ?

#16

Could you please send me the solution as I’m running into the same issue and I can’t send it using the LORWAN gateway? @ hammamikbel@gmail.com