How to check operation of LoRa-EndDevice?

Newbie question
Have been experimenting exactly 1 month with (MARVIN+SHT31)+KPNDevPortal+MendixDashboard,
with some sidesteps trying sketches on the MARVIN for connection to TTN.
After latest trial in direction of TTN returned to KPN-configuration, but no contact visible with KPN.
Sketches load well to MARVIN, and all settings in sketch, DevPortal and Dashboard seem correct (= unchanged rel. to successful experiments).
Then elementary question is: is EndDevice communicating to network?
What is simple(st) test (if KPNDevPortal not showing signs)?

Why are you asking here, rather than at KPN?

2 Likes

For me the use of KPN is just start of the learning curve, because KPN comes with MARVIN:
it works, with limitations (both functionally and in time).
Looking at KPN’s forum have the feeling that TTN’s forummembers are more active, and have more/wider practical experience related to DIY-setups, and therefore could better answer this kind of practical/technical question.
Because my goal is anyway to shift to TTN as soon as possible, the idea is that I could better try to proceed now with MARVIN&TTN, instead of putting more effort in MARVIN&KPN.

‘The miss of communication’ is a nagging challenge, because the Marvin-with-same-sketch has worked stand-alone for weeks with power supply by USB-powerpack.
Today have checked the Marvin again connected to USB-port of the PC running the Arduino-IDE.
Looking with Arduino-IDE/ Tools/ Serial Monitor the Marvin starts up, and is in business again …
But only when that sequence is performed:
Arduino-IDE out = Marvin communication out
The sketch includes print-commands to console feeding the Serial Monitor.

;-( Just leaves one flabbergasted (why has it worked stand-alone?), or is there something unnoticed for a newbie like me related to the serial interface?

What does the Serial initialization code look like for your sketch? I believe the Leonardo is like the 32u4 devices and has somewhat different behavior when the USB serial interface is initialized. The USB Arduino devices don’t reset when you open the serial monitor, unlike the Uno etc devices. Many sketches tend to contain while(!Serial) statements which hang the device until a serial connection is detected. I do this on my 32u4 to be able to bypass the wait after 15 seconds.

char waitloop=0;
Serial.begin(115200);
while (waitloop++ < 15) {
  delay(1000);
  if(Serial) waitloop = 15;  
}

This gives me 15 seconds to open the serial monitor so that I don’t miss the initial output messages. If it’s not connected, the sketch moves on after 15 seconds. If I do open the monitor, the loop terminates immediately.

I find the device to be quite annoying to work with. The comm port number switches back and forth depending upon if the bootloader is running or the sketch is running. This makes uploading sketches a chore as you have to hit the reset button at just the right time or Windows 10 gets an error.

@Afremont

The experience you describe gives support to my ‘suspicions’.
Will try to implement your solution, starting with replacement of the single appearance in the sketch of

while(!Serial)

Insertion of

if (Serial.available())

should (?) also help in various other scriptlines to check the presence of the Console’s serial interface.
But no success yet …

after you uploaded your sketch the board resets and probably get another port (32U4) So to use the serial interface set that new port in the ide.

Following the suggestion of Afremont, I changed the Setup as shown below, and it seems to work, however with some side-effects:

  • startup is possible without PC connected

  • with PC connected, then failing commands serial.print and serial.println

      void setup() 
      {  
      InitializeSerials(defaultBaudRate);
        initializeRN2483(RN2483_power_port, reset_port);
        pinMode(led_port, OUTPUT); // Initialize LED port  
        blinky();
        start = 120000; //Start counter at 2 minutes for immediate package send after setup
    
     char waitloop=0;
     Serial.begin(9600);
     while (waitloop++ < 15) {
        delay(1000);
        if(Serial) waitloop = 15;  
     }
    //   while(!Serial) {
       if (Serial.available()) {
         Serial.println("begin...");
       }  
    
     sht31.begin(0x44);
    }
    

;-( Surprises of the learning-curve …

I normally use, also on 32u4, the following:

Serial.begin(9600);
while (!Serial && millis() < 10000);

and it is always sufficient to guarantee serial availability.
Then I just use print and println with no check for availability. When PC is not connected, I do not have problems at throwing bytes towards a closed port :slight_smile: (although when I feel smart I define a DEBUG flag and enclose all printing in #ifdef directives :wink: , for when I am happy with the code)
And yes, sometimes I have to press reset at the right time, that is, just after having started compilation.

1 Like

I wonder if the following from the Arduino if(Serial) documentation could affect some of us, emphasis mine:

Indicates if the specified Serial port is ready.

On the boards with native USB, if (Serial) (or if(SerialUSB) on the Due) indicates whether or not the USB CDC serial connection is open. For all other boards, and the non-USB CDC ports, this will always return true.

And, if it could affect some, whether using Serial.available() (in the while to suspend starting up) would help:

Get the number of bytes (characters) available for reading from the serial port. This is data that’s already arrived and stored in the serial receive buffer (which holds 64 bytes).


What does “failing” mean here? Your code is just not executed? Like quoted from the documentation above: I’d say that your code would not print anything if something has not been received from the computer at that point. Like @UdLoRa wrote: remove the if.

@arjanvanb
‘Failing’ = no visible execution of any print-command to the Serial-interface

Next experiment will be the insertion of @UdLoRa 's suggestion":

   Serial.begin(9600);
   while (!Serial && millis() < 10000);

in combination with deletion of all those ‘if (Serial.available())’.

:wink: Not unlikely that I tried ‘too much’ and should return to KISS.

February 26, Result of change: it works, flawless!!!

:wink: Now back to the main question (with the twist of now connection to TTN as testcase):
if no visible signs of incoming messages at the TTN-Console, what ‘local’ signs are available (besides the LEDs) that the end-device is operational?

Honestly I never checked whether it was always true or not… the main aim is to avoid stopping when not connected and not be sure I see also the very first characters. Anyway, good to know :slight_smile:

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.