Firebeetle with RFM95

End Devices (Nodes) Hardware
1

I’m pretty new to TTN, LoRa, and electronics in general — so please bear with me. There’s a lot of possible points I might be going wrong and I’m struggling a bit to narrow it down to be able to debug. Trying to learn too many new things at once, I suppose.

I’m using a Firebeetle ESP32 (ESP-WROOM-32) with an HopeRF RFM95 module.

There seems to be no other gateways in my area so I followed the instructions here and built my own using an RPI and a iMST iC880a board (EUI: B827EBFFFE742512). Based on the output I’m seeing on the console it seems to be working fine?

With the MCU I’m using the LMIC library (mcci-catena/MCCI LoRaWAN LMIC library@^4.0.0), following the ABP example provided. The pin map looks as follows — the wiring should be done accordingly :crossed_fingers: :

const lmic_pinmap lmic_pins = {
    .nss = 5,                       
    .rxtx = LMIC_UNUSED_PIN,
    .rst = 14,                       
    .dio = {/*dio0*/ 26, /*dio1*/ 25, /*dio2*/ 27}
};

The output from the serial monitor looks as follows:

Starting
8501: EV_TXSTART
Packet queued
139673: EV_TXCOMPLETE (includes waiting for RX windows)
3889698: EV_TXSTART
Packet queued
...

A join event never seems to take place. I have double checked the NwKsKey as well as the AppSKey. I’m unclear on whether my wiring is incorrect or if I’ve gone wrong somewhere else.

Any recommendations on which thread to pull first would be very much appreciated.

2

Do you see any activity in live data on console?

3

Yes, I am. This is from the console for the node — Screenshot 2021-11-04 at 22.49.46.

Is this what you were after?

4

And never will - ABP doesn’t join.

Doesn’t matter, as the console shows the application is receiving uplinks just fine.

TL;DR - it’s working

1 Like
5

It’s definitely off to a good start with the uplink path working.

Key question now will be if it gets those configuration downlinks and responds to them, so that they stop being sent.

Or if it doesn’t get them and so they keep wastefully being sent over and over.

1 Like
6

as @descartes said… i also never had success with ABP, try OTA.
But if you receive some payload did you decode it? Go to Payload parser. (uplink)

1 Like
7

You may also find the LMIC-node example useful.

The Firebeetle ESP32 is not directly supported in LMIC-node but you can select the NodeMCU-32S board as alternative. This should also work for the Firebeetle ESP32.
See the board support file for the NodeMCU-32S (included with LMIC-node) for which connections are used to connect the RFM95 LoRa module.

The only difference between the NodeMCU-32S and the Firebeetle ESP32 is that some of the Ax (A0, A1 etc) pin names have different pin number values (which is defined in the ESP32 Arduino Core) but these are not used in LMIC-node (and you can always use the correct numbers instead of names).

8

Thanks Nick, sounds promising! I will keep at it!

9

That’s not what I meant. No one will ever have success with finding a join request / accept with ABP.

The console log shows that the payload was received.

What is this Payload parser?

10

You guys are absolutely correct — I was looking for the wrong thing. :pray:

The payload is received and upon manual decryption is what I expected it to be. I understand that I generally shouldn’t decrypt the payload on TTN, correct? However, for testing purpose — am I able to do convert Base64 to text using the JS parser?

11

Thanks a lot, I will definitely check this out @bluejedi!

12

As it just turns out I did, yes. I used NodeJS to convert from Base64 and the content is what I expected:

new Buffer('SGVsbG8sIHdvcmxkIQ==', 'base64').toString('ascii')

13

My node stopped working after taking it offline last night so it might be a while before I can test this but would you be able to advise what to look for to confirm this, @cslorabox? — Thanks so much!

14

Many do, I do for testing / development but not for deployment, as it is the first thing to be dropped if the application server is under load as each formatter only gets 100ms to run and if the servers are working hard, the PFs tend to timeout. So you can go weeks with all your uplinks being decoded and then have a day where 1 in 10 come through un-decoded.

So if you really want all your data, plan for decoding at your end, which is also good for TTS CE as it’s one (or more) less decoders running.

I’d setup a data sink - a webhook that records everything - so you can always revisit any data processing, for which I’d use this tried & tested starter: https://github.com/descartes/TheThingsStack-Integration-Starters/tree/main/WebHook-to-Tab-PHP

No at two levels, there is no JS parser** but there is a JS Payload Formatter and no you can’t do a convert from Base64 to text because no one here sends text ever because it’s highly inefficient. If you are really lucky no one else will notice and you’ll be able to change your code before you get found out and 10,000 Forumites will tell you how bad it is & how bad you are.

See this for helpful hints: https://www.thethingsnetwork.org/docs/devices/bytes/

But also, no, you can’t convert the payload from Base64 to a byte array (which may or may not read something in the language of your choice), because TTI do that for you, you can read all the details on how the Payload Formatter gives you the payload & port number here:

https://www.thethingsindustries.com/docs/integrations/payload-formatters/javascript/

But before you do that, as you have achieved Jedi LoRaWAN Apprentice level, you can go straight to Practitioner level by scanning through the bulk of the main docs:

https://www.thethingsindustries.com/docs/

and then the reference:

https://www.thethingsindustries.com/docs/reference/

so that you know what’s in the cupboard for when you get to a point where you go “I wonder …”

** I appreciate that I’m splitting hairs here, but nomenclature is important - lots of time gets used up when people type one thing but mean another. That and there’s my rampant CDO (normally called OCD, but that’s not alphabetical).

15

No worries about splitting hairs at all :pray: — this is very useful and much appreciated. Thanks a lot, @descartes!