Set up Elecrow TTN LoRaWAN gateway on Raspberry Pi - Pt. 2: full install and run as service

RE: Set up Elecrow TTN LoRaWAN gateway on Raspberry Pi - Pt. 2: full install and run as service

Jan Cumps — Thu, 11 Jan 2024 17:43:37 GMT

(from previous comment:) TTN's fair use budget for a thing - in the free tier - is 30 seconds of uplink airtime per day.

What time does an initial connection with data exchange take? "consumed_airtime": "1.318912s",

Activity:
Accept join-request
Successfully processed join-request
Forward join-accept message
Forward uplink data message

What time does typical data exchange take? "consumed_airtime": "0.061696s",

activity:
Forward uplink data message.

This data is not coming from my gateway. It's on the TTN application log of my TTN account.

RE: Set up Elecrow TTN LoRaWAN gateway on Raspberry Pi - Pt. 2: full install and run as service

Jan Cumps — Tue, 09 Jan 2024 21:05:41 GMT

Resource use on a Pi A+:

RE: Set up Elecrow TTN LoRaWAN gateway on Raspberry Pi - Pt. 2: full install and run as service

Jan Cumps — Mon, 08 Jan 2024 22:50:51 GMT

service log file handling on the Pi: [mention:dada28b1ad0049e68937877988197aa7:f7d226abd59f475c9d224a79e3f0ec07]

RE: Set up Elecrow TTN LoRaWAN gateway on Raspberry Pi - Pt. 2: full install and run as service

Jan Cumps — Fri, 05 Jan 2024 12:23:51 GMT

I have set up an Arduino MKR1310 as "pinger". It will send one metric every 2 hours.
TTN "sandbox fair use" asks to have no more than 12 seconds of uplink communication per 24 hours. Having 12 communications per day should keep me under that threshold.

Arduino Code:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:f2887f81-a7b4-4718-9b4e-cc1483b0e179:type=c_cpp&text=%23include%20%22arduino_secrets.h%22%0D%0A%2F%2A%20%0D%0A%20%20Sketch%20generated%20by%20the%20Arduino%20IoT%20Cloud%20Thing%20%2A%2A%2A%0D%0A%20%20https%3A%2F%2Fcreate.arduino.cc%2Fcloud%2Fthings%2F%2A%2A%2A%2A%2A%0D%0A%0D%0A%20%20Arduino%20IoT%20Cloud%20Variables%20description%0D%0A%0D%0A%20%20The%20following%20variables%20are%20automatically%20generated%20and%20updated%20when%20changes%20are%20made%20to%20the%20Thing%0D%0A%0D%0A%20%20int%20health%3B%0D%0A%0D%0A%20%20Variables%20which%20are%20marked%20as%20READ%2FWRITE%20in%20the%20Cloud%20Thing%20will%20also%20have%20functions%0D%0A%20%20which%20are%20called%20when%20their%20values%20are%20changed%20from%20the%20Dashboard.%0D%0A%20%20These%20functions%20are%20generated%20with%20the%20Thing%20and%20added%20at%20the%20end%20of%20this%20sketch.%0D%0A%2A%2F%0D%0A%0D%0A%23include%20%22thingProperties.h%22%0D%0A%0D%0Avoid%20setup%28%29%20%7B%0D%0A%20%20%2F%2F%20Initialize%20serial%20and%20wait%20for%20port%20to%20open%3A%0D%0A%20%20Serial.begin%289600%29%3B%0D%0A%20%20%2F%2F%20This%20delay%20gives%20the%20chance%20to%20wait%20for%20a%20Serial%20Monitor%20without%20blocking%20if%20none%20is%20found%0D%0A%20%20delay%285000%29%3B%20%0D%0A%20%20%0D%0A%20%20%2F%2F%20Defined%20in%20thingProperties.h%0D%0A%20%20initProperties%28%29%3B%0D%0A%0D%0A%20%20Serial.println%28APPEUI%29%3B%0D%0A%20%20Serial.println%28APPKEY%29%3B%0D%0A%2F%2A%0D%0A%20%20ArduinoCloud.enableRetry%28true%29%3B%0D%0A%20%20ArduinoCloud.setMaxRetry%285%29%3B%0D%0A%20%20ArduinoCloud.setIntervalRetry%2810000%29%3B%0D%0A%2A%2F%0D%0A%0D%0A%20%20%20%20%2F%2F%20Connect%20to%20Arduino%20IoT%20Cloud%0D%0A%20%20ArduinoCloud.begin%28ArduinoIoTPreferredConnection%29%3B%0D%0A%20%20%0D%0A%20%20%2F%2A%0D%0A%20%20%20%20%20The%20following%20function%20allows%20you%20to%20obtain%20more%20information%0D%0A%20%20%20%20%20related%20to%20the%20state%20of%20network%20and%20IoT%20Cloud%20connection%20and%20errors%0D%0A%20%20%20%20%20the%20higher%20number%20the%20more%20granular%20information%20you%E2%80%99ll%20get.%0D%0A%20%20%20%20%20The%20default%20is%200%20%28only%20errors%29.%0D%0A%20%20%20%20%20Maximum%20is%204%0D%0A%20%2A%2F%0D%0A%20%20setDebugMessageLevel%282%29%3B%0D%0A%20%20ArduinoCloud.printDebugInfo%28%29%3B%0D%0A%20%20%0D%0A%20%20pinMode%28LED_BUILTIN%2C%20OUTPUT%29%3B%0D%0A%20%20digitalWrite%28LED_BUILTIN%2C%20ArduinoCloud.connected%28%29%29%3B%0D%0A%0D%0A%0D%0A%7D%0D%0A%0D%0Avoid%20loop%28%29%20%7B%0D%0A%20%20static%20int%20loopcounter%20%3D%200%3B%0D%0A%20%20ArduinoCloud.update%28%29%3B%0D%0A%20%20%2F%2F%20Your%20code%20here%20%0D%0A%20%20digitalWrite%28LED_BUILTIN%2C%20ArduinoCloud.connected%28%29%29%3B%0D%0A%20%20if%20%28loopcounter%20%25%20%286%20%2A%2060%20%2A%202%29%20%3D%3D%200%29%20%7B%20%2F%2F%20every%202%20hours%0D%0A%20%20%20%20loopcounter%20%3D%200%3B%0D%0A%20%20%20%20health%20%3D%20health%20%2B%201%3B%0D%0A%20%20%7D%0D%0A%20%20delay%2810000%29%3B%20%0D%0A%20%20loopcounter%20%2B%2B%3B%20%0D%0A%7D%0D%0A%0D%0A%2F%2A%0D%0A%20%20Since%20Health%20is%20READ_WRITE%20variable%2C%20onHealthChange%28%29%20is%0D%0A%20%20executed%20every%20time%20a%20new%20value%20is%20received%20from%20IoT%20Cloud.%0D%0A%2A%2F%0D%0Avoid%20onHealthChange%28%29%20%20%7B%0D%0A%20%20%2F%2F%20Add%20your%20code%20here%20to%20act%20upon%20Health%20change%0D%0A%0D%0A%20%20%0D%0A%7D]

Log on the gateway:

Jan 5 11:17:09 raspberryttn lora_pkt_fwd[788]: INFO: Received pkt from mote: 2700AE9E (fcnt=0)
Jan 5 13:16:10 raspberryttn lora_pkt_fwd[788]: INFO: Received pkt from mote: 2700AE9E (fcnt=1)

RE: Set up Elecrow TTN LoRaWAN gateway on Raspberry Pi - Pt. 2: full install and run as service

Jan Cumps — Tue, 02 Jan 2024 22:36:12 GMT

2 hours of monitoring:

RE: Set up Elecrow TTN LoRaWAN gateway on Raspberry Pi - Pt. 2: full install and run as service

shabaz — Sun, 31 Dec 2023 01:38:06 GMT

Hi Jan,

I have a stretch goal; it would be nice to have a way of turning on an LED whenever LoRaWAN packets of interest arrive (and possibly when sent; could be the same LED or a different one).

I *think* this is possible by checking the logs that the system will generate, or alternatively it could be possible to modify the source code and rebuild (possibly it will be the lora_packet_forward.c file, if they are using the same source as RAK (I briefly looked into it at the time but didn't investigate much; I'd much rather put the effort in to the elecrow module now rather than RAK. It would be nicer to do it via log file changes detected I reckon, rather than source modification, assuming the logs do supply the required level of detail for that.

When I install it on the Pi 3, I'll see if I get anywhere with this idea. It could be nice for troubleshooting, seeing via big blinking light whenever activity occurs that meets a desired match term : )