Need to make changes to ttn.ino to support single channel gateways - Githubissues

kizniche / ttgo-tbeam-ttn-tracker

TTGO T-Beam Tracker for TTN Mapper and TTN Tracker using US (915 MHz) and EU (868 MHz) frequencies

https://kylegabriel.com/projects/2019/04/lorawan-tracker-and-mapper.html

GNU General Public License v3.0

262 stars 140 forks source link

Need to make changes to ttn.ino to support single channel gateways #5

Closed mtbspace closed 3 years ago

mtbspace commented 4 years ago

I uncommented the appropriate LMIC_disableChannel(x) lines, but found my T-Beam still kept transmitting on different channels.

I then noticed the code for disabling the channels is enclosed in '#ifdef USE_ABP', which I thought may be a mistake. Should this '#ifdef USE_ABP' be closed before ' #if defined(CFG_eu868)'? I was thinking the channels won't get ignored if you're using OTAA to join (I'm using OTAA). However, after making this change, my t-beam was still channel hopping.

I've currently bodged it by adding the relevant ignoreChannels to be called every time in the ttn_send function and now nearly all transmissions are getting to my single-channel gateway.

I've not touched the LMIC_setupChannel calls.

I hope that all makes sense - I'm new to Arduino and lorawan! Thanks for a great project :+1:

kizniche commented 4 years ago

I'm fairly sure it's correct. Check out the examples (specifically "ttn-otaa" and ttn-abp") and you'll see that's how it's recommended for this library.

kizniche commented 4 years ago

Oops, here's the link: https://github.com/mcci-catena/arduino-lmic/tree/master/examples

kizniche commented 4 years ago

Ah, I think you may be right. If you move the LMIC_disableChannel()s past the last #endif, does it then work as expected?

mtbspace commented 4 years ago

I can't see LMIC_disableChannel()s in either the otaa or abp examples. I can see setupChannels in ttn-abp, but I think it may be coincidental that they're there.

Moving LMIC_disableChannel()s past the last #endif does not seem to fix it, but I did expect it to.

I've put LMIC_disableChannel()s at the start of the ttn_send function, so they're being called everytime I send something. I may need to check this isn't defeating anything that controls duty cycles. This has definitely fixed it.

kizniche commented 4 years ago

I found it's actually from here (one of the sources I have listed in the README): https://github.com/xoseperez/ttgo-beam-tracker/blob/master/code/src/ttn.ino

kizniche commented 4 years ago

I just committed some edits (ce145d8751f6173c1dbc7ed079f80cabaf556216) that followed this post: https://www.thethingsnetwork.org/forum/t/can-lmic-1-6-be-set-up-to-use-a-single-channel-and-sf/5207/10

There's a new variable in configuration.h, SINGLE_CHANNEL_GATEWAY, that when uncommented and set should cause only that channel to be used.

Could you test to see if this works?

mtbspace commented 4 years ago

This is working great for uplink - thank you :) If I request acks (LORAWAN_CONFIRMED_EVERY 1) it is misbehaving, but this might be a config mistake on my part (I've seen your comments about downlink channels). I'm trying to look into this now, but it's very hard to test when TTN only gives you 10 downlink messages per day!

kizniche commented 4 years ago

Thanks for testing. Glad that worked on the first try!

I believe it's 10 downlinks per device per day, so if you make a new device you should get 10 more.

I haven't explored the use of LORAWAN_CONFIRMED_EVERY, as I have thus far only used the ABP method. Once the new T-Beam board arrives, I'll go through and test a slew of different configurations with both boards and both communication methods.

mtbspace commented 4 years ago

I'm not sure how helpful this is, but the limited testing I've done so far with trying to get ACKs has shown the following:

I was receiving ACKs yesterday when I was channel hopping, but only for those message that were transmitted on the same channel as my single channel gateway (as expected)
With my single channel bodge, I do not receive any ACKs and the node stops transmitting after the 1st message
With your latest code, I do not receive any ACKs. The 1st message is sent TWICE in quick succession. No further messages are transmitted by the node. The serial console reports it is transmitting. It may have started transmitting on a different channel.

I'll let you know if I can find out any more. ACKs are not important to me at the moment, so it's not a big deal. I'm just very happy to have it transmitting reliably - thank you again!

mtbspace commented 4 years ago

It's just occurred to me that when transmitting on a single channel, you may need to be a bit more careful about regulatory duty cycles, at least here in Europe. At SF7 and 125k bandwidth, each transmission is taking 61.7ms according to the TTN console. If I've got this right, that's a duty cycle of 0.617% at the default send interval of 10 seconds. If I were to increase the spread factor without increasing the send interval, I'd be over the 1% limit.