Which Arduino LoRaWAN library will talk to the ESP-1ch-Gateway?

[nigelorr]

This post on the MCCI forum suggests the LMIC stack on Arduino can't be used with the 1 channel gateway as it's not fully compliant with the standard

I guess others are using Arduino framework with the ESP-1ch-Gateway, what Arduino libraries can be used with it?

I am trying to connect two TTGO-Lora-V2 boards, one using Esp-!ch-Gateway as a gateway to The Things Network and the other as a TTN node.

The gateway seems to be up and connected, but I don't get any response (TTN console shows an uplink message with JOIN EUI etc, device shows EV_JOINING and EV_TXSTART).

Is there another LoRaWAN node library I should be using instead of "MCCI LoRaWAN LMIC library" to try out the 1-ch-Gateway?

[IoTThinks]

I tried the old IBM LMIC last time with this library and it worked. https://github.com/matthijskooijman/arduino-lmic

However, MCCI LMIC is more up-to-date.

[nigelorr]

Thanks for the quick reply.

I have now tried the IBM version at V1.5.1 but I get the same results. I tested the pair of boards with simple LoRa connection to verify the radio part, but when I program them with the gateway and node (based on the IBM OTAA example with my keys) connect to TTN I only get 'Receive uplink message' and nothing after that.

So it looks like a JOIN message is being passed from the node through the gateway to TTN, but then nothing else happens.

What should happen next, in a working connection? I have three new components (Node, Gateway, using TTN console) and could have made mistakes on any of them, or one of them could be incompatible, it's hard to get started :-)

[IoTThinks]

Triple check of the frequencies.

Can try ABP first.

[nigelorr]

Thanks, I will try to do that again, have set everything I can find to EU frequency plan.

The above message only seems to occur when I reprogram the node device, resetting it or power cycling it doesn't produce an update on the 1ch-Gateway or a further JOIN message.

Shouldn't there be a TTN-generated response appearing in the gateway data log as above? I thought there would be a join response from TTN, with a corresponding message on the gateway going through to the node, but I may have misunderstood?

I did try ABP previously (with similar results and no successful 'hello world' data), but reverted to OTAA as the 'better' or more standard option, but I'll try it again.

Which version of the LoRaWAN MAC did you use with the IBM LMIC library? I've been setting 1.0.3 as supported by the MCCI library, but is the IBM one a lower version? I can't see a version specified.

[nigelorr]

With ABP, I get a single message as below (between gateway 'ticks'). Should there be responses to that, or does it suggest where the problem lies?

One difference is that the message is sent each time I reset the node, which I guess is some sort of progress :-)

[IoTThinks]

Received uplink => The node is able to upload to server.

[nigelorr]

OK, that's encouraging, thanks.

However, the above 'success' is only seen in the gateway live data, nothing appears in the application where I defined the device (it shows last seen time as unknown). I've copied and pasted the ABP keys across from the TTN console (as-is for the Device address, as big-endian strings for NwkSKey and AppSKey as below) but if the above successful uplink doesn't appear in the application, what have I missed?

The MAC payload reported in the Gateway and "data.payload.mac_payload.frm_payload" in the expanded JSON view of the gateway both change in length if I change the message, so I can believe the payload is sent.

If I use the data.raw_payload displayed by TTN, and the keys from the application console at this handy online LoRaWAN packet decoder, the calculated MIC is valid and the data decodes correctly to (the hex-encoded version of) my "hello world" message.

However, it still doesn't appear in the application / device view. I've also tried creating a new application and device and verifying the new device address and keys with the above decoder and it looks like the data is valid.

But nothing appears in the application, and the device is not 'seen' although the packet seen by the gateway decodes correctly with the device parameters.

Thanks for your help so far, it seems to be very close to working, I hope the above helps someone to help me get it completed!

[nigelorr]

I added the devices to The Things Network V2 console, and the data appears in the V2 application.

But the V3 console is still as above, data appears in the gateway but not in the application.

As V2 is being switched off at the end of 2021, that doesn't help so much, but at least it's progress.

The node won't send additional data as it is in OP_TXRXPEND, so I'm still stuck and not sure if the problem is in the node or the ESP-1ch-gateway

[IoTThinks]

You must remove all stuffs from old TTN before joining new TTI.

There are differences between old TTN and new TTI. Can check for old issues in this library.

Normally the LoRaWAN stack is at the node. Just make sure the node is only active at one frequency.

[nigelorr]

Thanks again @IoTThinks , I have done that:

• I didn't have any old TTN configuration (I just added it before my last comment above to check if it was the same and have tried with it removed)
• I've followed the device migration guide at TTN, but with the same result.
• The node is only active at a single frequency, all others disabled.

I've found the issue with TXRXPEND and fixed it (the TTGO board I am using brings the DIO1 and DIO2 out on separate pins, and I've now connected them to IO32/IO33 so I do get TXCOMPLETE).

I now get data and response shown in the v2 console, but something is still not working on v3 (I still only see the gateway message but it doesn't make it to the v3 application). At least that gives me a solution for this hardware combination until December...

I'll recheck old issues in case I missed anything first time around on the V3 transition. Any other things I can check?

[IoTThinks]

Of course, dio0, dio1 and dio2 are different.

Check the downlink. No downlink then the node can not join via OTAA.

The downlink is more tricky. You may need to force the node to listen on 1 channel. Else it will jump the channels.

[nigelorr]

I am joining by ABP, to keep that simple (it appears OTAA is 'better' but ABP has less unknowns to get things working initially). The device is set to the same as channel 0 on the gateway 868.1MHz.

If I create an ABP device on the V2 console and configure my device accordingly, the gateway console shows traffic from the V2 device and the application shows data for it.

If I create an ABP device on the V3 console and configure my device accordingly, the gateway console shows traffic from the V3 device but the application shows no data and the device is never reported as 'seen'.

I have switched back and forth between the two above routes, V2 always works, V3 is only shown on the gateway console but never in the application.

I have also tried registering the gateway on the V2 console. The behaviour is exactly the same. However the gateway is configured, the device never gets data to a V3 application, but appears reliably on the V2 application.

I've gone back through all the other issues on this repo (both open and closed ones) and can't see any other issue with similar symptoms. It's quite frustrating, so I very much appreciate your patient assistance.

[IoTThinks]

I will try my own this weekend. From the forums, I see there are differences between TTN and TTI.

A lot of people hit problem when moving to TTI too.

[nigelorr]

Thanks, I'd be grateful for anything you discover.

I've also posted on TTN forum for suggestions on what could be stopping the data getting to the V3 Device console when it appears correctly in the gateway.

[Edit - but they immediately closed and unlisted my post, and chastised me for connecting a non-compliant device to TTS and even from polluting the local RF environment by using it, requesting I disconnect it from TTN immediately. I didn't expect that :-(

It doesn't entirely make sense either, at worst it's no worse than other point to point LoRa connections which aren't being managed by TTN, is it?

So maybe there's not a future for this project? That would be a shame, it's always good for beginners to have a low cost and simple way in to evaluate a new technology.]

[IoTThinks]

I highly doubt TTN/TTI forum will support Single channel gateway.

[nigelorr]

I didn't expect them to support the gateway (they say it's not a gateway), but it's starting to look like the problem is at their end, so I didn't want to waste your effort as the data seemed to have passed the gateway and got to their console, but the response was

This is what we call a Single Channel Packet Forwarder or SCPF - they are not a gateway which is what your device is expecting to communicate via. Please disconnect it from TTS immediately. You do not know for a fact that there are not other users in the area, there is no mapping for TTS and even then others may not be making their gateways public, so as well as causing yourself problems, you may be causing issues for others.

I've now found a clear notification that these devices are now on 'the naughty list'. I don't want to be causing problems for others, so have disconnected it as requested.

[nigelorr]

Thanks for the help, I've moved the project across to use Meshtastic, which will also work for the potential end application. The community around that is at an earlier stage than TTN and seems more welcoming of experimentation.

Really appreciate the effort that's gone in to ESP-1ch-Gateway, and the patient support of the project here, I will doubtless be back to LoRaWAN for future projects, and if it doesn't need TTS this is a great place to start.