CubeCell LoRa+reading PWM from sensor

Hi everyone!

I am facing some problems reading data from mb1040 ultrasonic sensor (see link below) and send it using LoRa.

I managed to read the distance reading in its own script, without sending data via LoRa. I also managed to send random data via LoRa. But, when I combine both I does not read the sensor.

Reading data only:
`#include “Arduino.h”

//const int pwPin1 = 2;
long pulse1, sensor1;

void setup() {
Serial.begin(115200); // sets the serial port to 9600
// pinMode(pwPin1, INPUT);
pinMode(PWM1,INPUT);
}

void loop() {

pulse1 = pulseIn(PWM1, HIGH);
sensor1 = pulse1/147;

Serial.print(sensor1);
Serial.print(" “);
Serial.print(“inch from PWM”);
Serial.println(” ");

delay(500);
}`

Reading data and sending via LoRa in the same script, I include my code in the prepareTxFrame() function. Unfortunately, it does not read the data.

Any suggestion is greatly appreciated.
Thanks very much in advance!

Sensor: https://www.maxbotix.com/Ultrasonic_Sensors/MB1040.htm

What does prepareTxFrame() look like, how do you send the data, there is too much detail lacking to come with an answer.

Thanks @weradis for you prompt reply. I am using the same example as the LoRaWAN example. I just adjusted the prepareTxFrame() function as follows:

    static void prepareTxFrame
( uint8_t port )
{
  
  pinMode(PWM1,INPUT);

  
   pulse1 = pulseIn(PWM1, HIGH);
  sensor1 = pulse1/147;
  

    appDataSize = 4;
    appData[0] = 0x00;
    appData[1] = 0x01;
    appData[2] = 0x02;
    appData[3] = 0x03;
     Serial.print(sensor1);
  Serial.print(" ");
  Serial.print("inch from PWM");
  Serial.println(" ");
}

I am not yet sending it but trying to print it to serial to see the readings. But what I am getting is just 0 inches (should not output 0 at any case, lowest is 5 inches), compared to what I get from the other script (real readings depending on range)

Do you do both tests on the same board? I was thinking maybe PWM1 is used by the LoRa board

Yes. I am using the same board and I used both PWM (1&2) pins as denoted in the picture in the link below. I get the same result, works in its own script, but not with LoRa

https://heltec.org/project/htcc-ab01/

OK include the LoraCode, make a small function which reads reads and displays the MB140 output. Insert it into various places in the code (begin in setup()) and examine when it stops to work. I guess it is related to the LoraCode which perhaps uses the PWM or changes the settings. Once we know where it stops you can dive into the library to understand why … or you can ask your supplier about PWM availability using LoRA code …

BTW some pieces of the library are .S files for some reason they are making it hard to understand …

Not ideal, but it’s to do with the licensing of the chipset - you have to register to get an unlock code. I wouldn’t point a finger at that just yet.

Can you print the value for pulse1 to see if the pulse duration is working?

I printed the readings in the setup() and loop() functions. Readings are normal until I get to DEVICE_STATE_SEND it starts printing zeros and abnormal values. Loop function is below, denoted the last place where data is normal.

    void loop()
{
  switch( deviceState )
  {
    case DEVICE_STATE_INIT:
    {
#if(AT_SUPPORT)
      getDevParam();
#endif
      printDevParam();
      LoRaWAN.init(loraWanClass,loraWanRegion);
      deviceState = DEVICE_STATE_JOIN;
      break;
    }
    case DEVICE_STATE_JOIN:
    {
      LoRaWAN.join();
       ///////////////////////////// here is the last place where data is normal ////////////////
      break;
    }
    case DEVICE_STATE_SEND:
    {
    //////////////////////////////////////////////// here it outputs zeros and weird values ///////////////
       pinMode(PWM2,INPUT);
   pulse1 = pulseIn(PWM2, HIGH);
  sensor1 = pulse1/147;
  printReadings();
      prepareTxFrame( appPort );
      LoRaWAN.send();
      deviceState = DEVICE_STATE_CYCLE;
      break;
    }
    case DEVICE_STATE_CYCLE:
    {
      // Schedule next packet transmission
      txDutyCycleTime = appTxDutyCycle + randr( 0, APP_TX_DUTYCYCLE_RND );
      LoRaWAN.cycle(txDutyCycleTime);
      deviceState = DEVICE_STATE_SLEEP;
      break;
    }
    case DEVICE_STATE_SLEEP:
    {
      LoRaWAN.sleep();
      break;
    }
    default:
    {
      deviceState = DEVICE_STATE_INIT;
      break;
    }
  }
}

What are you referring to?

The only assembly code in ASR650x-Arduino is two (sorry, four) small files of MCU-specific specific helper routines that are well commented and do about what you’d expect an MCU project to need to do in assembly.

They have nothing to do with LoRa.

AFAIK the only thing in this realm you may have (once?) needed to register and get a code for is (was?) decoding gateway chip fine timestamps.

@descartes see my reply about printing the readings (sensor’s data), the same applies to pulse duration, it cuts off just after joining

To use the supplied LoRaWAN library, Heltec require a registration code that is tied to the ESP32 chip id:

which is obtained from here: https://resource.heltec.cn/search/

I failed to find where the code was referenced in the C source code, the modules worked OK that the client supplied so I wasn’t incentivised to read the assembly.

The question concerns a PSoC based board, not an ESP32

https://heltec.org/project/htcc-ab01/

Ah, a new chipset for the Arduino IDE - my bad.

Try and see if the LoRaWAN.sleep() (replace with a delay(5000) is causing the issue, i.e. prevent the board from going to sleep, maybe the PWM settings are lost in the sleep function,

@weradis It fails joining, (joining fail, try after 30s) and keeps doing this. I also looked at the execution order. Once it executes the join function it goes to sleep, then gets triggered and prints joined! after that it enters the loop of (send -> cycle -> sleep -> send …etc)

Ok but does the data output remain stable or does it still turn to zero.?

I kept printing data inside the loop() function as the prepareTxFrame() is not executed any more after the join fails. The data looks normal inside the loop() even though joining fails every 30s trial…

what do you think? is it something to do with the join() being successful and then PWM gets disable/used?

even though joining fails every 30s trial…

Why do you keep re-joining? Joining is supposed to be extremely rare, really you should be saving session details across restarts of the firmware (LoRaWAN is not a protocol that is easy to use correctly).

If the device is not joined, there’s no point in preparing a TX frame since you can’t useful send application traffic without a joined session or ABP credentials instead.

Yes We know that, we are trying to find where things get messed up … unless you know the solution