search

TheThingsNetwork / arduino-device-lib

Arduino Library for TTN Devices
MIT License
206 stars 96 forks source link

Class C support? #259

Closed LasaleFamine closed 4 years ago

LasaleFamine commented 4 years ago

Hi there, is Class C downlink supported by this library? If no, do you have plan to support it? Thanks for the library by the way!

johanstokking commented 4 years ago

We don't have a plan to support it, and I'd be happy to see community contributions here.

LasaleFamine commented 4 years ago

I would implement it if I had the knowledge... The library exposes really dev friendly APIs compared to other libraries, it's a pity not being able to use it for all the device types.

Do you have some useful link where I can learn more about the Class C implementation? Maybe a lib that correctly supports it and works with the TTS V3? So that I can learn and maybe try an implementation on this library.

I really need Class C devices for my project!

johanstokking commented 4 years ago

This library is basically a wrapper around the RN2xx3 commands. Please see the Microchip datasheet on all the available commands. It would be a matter of implementing those, like most of it is implemented already.

LasaleFamine commented 4 years ago

I made some tests using The Things UNO with the RN2483 updated with the 1.0.5 firmware.

What I can understand from the Microchip user guide is that you need to mac set class c and theoretically it should go in continuous receive mode after the next uplink is sent. I have done this steps:

Then:

At this point I have The Things UNO that sends an uplink every minute and tries to read a downlink every 100ms, receiving No module response as result of the readLine (not sure if this is the correct way of "listening for downlinks" during the class c mode).

What I can see is that the docs says that if you send a mac pause command during the continuous receive mode it will return 0 since it can't be stopped, but if I try to pause the mac after setting the class c type I can actually pause it since I receive the maximum value of the pause you can assign (4294967245). So, apparently, I can't actually simply set the class and wait for downlinks.

What I'm wondering is, maybe, do you have any clue for me? Maybe I'm missing something, I'm still learning a lot right now. Thanks!

johanstokking commented 4 years ago

Thanks, that sounds promising.

If you're using the passthrough example, i.e. you're using the Arduino IDE's serial monitor send and receive commands directly, what exactly is the interaction?

Can you explain what you mean with the pausing interaction exactly?

LasaleFamine commented 4 years ago

I'm going to send you an email with a small video about the current situation I'm in, hope it helps to understand better.

johanstokking commented 4 years ago

Thanks, that helps a lot.

Can you try this:

LasaleFamine commented 4 years ago

Alright:

Then after set the class C on the RN:

In attached you can find the logs of TTS (which I have restarted to make these tests) and the events from the CLI subscription.

I hope I did everything you asked!

Attachments: tts-cli-events-logs.log docker-compose-logs-tts.log

johanstokking commented 4 years ago

This all looks good;

stack_1      |  DEBUG Schedule downlink                        attempt_rx1=false attempt_rx2=true dev_addr=01E4A324 device_class=CLASS_C device_uid=banana-app.unoabpclassc downlink_class=CLASS_C downlink_priority=HIGHEST downlink_type=data frequency_plan=EU_863_870 namespace=networkserver path_count=1 rx2_data_rate=0 rx2_frequency=869525000 started_at=2020-03-09 17:08:07.503977906 +0000 UTC

I'm not seeing _TTN here in the FP ID. You need to verify if the RX2 data rate on the end device is indeed 0 (SF12).

LasaleFamine commented 4 years ago

Yeah I thought the same about the freq id, but I have changed the settings on the gateway and create a new device with the TTN freq, maybe I need to restart the stack? I will check the RX asap.

LasaleFamine commented 4 years ago

Ok that one was actually the ABP one. The following is the correct log for the current OTAA device I'm testing:

stack_1      |  DEBUG Scheduled downlink                       attempt_rx1=false attempt_rx2=true dev_addr=0144B01C device_class=CLASS_C device_uid=banana-app.uno-otaa-classc downlink_class=CLASS_C downlink_priority=HIGH downlink_type=data frequency_plan=EU_863_870_TTN namespace=networkserver rx2_data_rate=3 rx2_frequency=869525000 started_at=2020-03-09 21:09:35.54127946 +0000 UTC transmission_delay=529.985101ms transmit_at=2020-03-09 21:09:36.081468848 +0000 UTC m=+15550.174456549

I have checked the RX2 data rate on the device and it's 3 but I can see from the log above that the RX2 data rate for this OTAA device is 3 so I assume it is correct (I have tested also with RX2 0, no luck). Also with the correct schedule of the downlink I'm still unable to receive it on the end device.

For completeness, here is the initial status of the device:

EUI: 0004A30B001E6791
Battery: 3273
AppEUI: A0000000000000AA
DevEUI: 0004A30B001E6791
Data Rate: 5
RX Delay 1: 5000
RX Delay 2: 6000
Model: RN2483
Version: 1.0.5
Sending: mac set deveui 0004A30B001E6791
Sending: mac set adr off
Sending: mac set deveui 0004A30B001E6791
Sending: mac set appeui A0000000000000AA
Sending: mac set appkey A99AD6DEBF428B39C784D080174895ED
Sending: mac save 
Sending: mac set rx2 3 869525000
Sending: mac set ch drrange 1 0 6
Sending: mac set ch dcycle 0 799
Sending: mac set ch dcycle 1 799
Sending: mac set ch dcycle 2 799
Sending: mac set ch dcycle 3 799
Sending: mac set ch freq 3 867100000
Sending: mac set ch drrange 3 0 5
Sending: mac set ch status 3 on
Sending: mac set ch dcycle 4 799
Sending: mac set ch freq 4 867300000
Sending: mac set ch drrange 4 0 5
Sending: mac set ch status 4 on
Sending: mac set ch dcycle 5 799
Sending: mac set ch freq 5 867500000
Sending: mac set ch drrange 5 0 5
Sending: mac set ch status 5 on
Sending: mac set ch dcycle 6 799
Sending: mac set ch freq 6 867700000
Sending: mac set ch drrange 6 0 5
Sending: mac set ch status 6 on
Sending: mac set ch dcycle 7 799
Sending: mac set ch freq 7 867900000
Sending: mac set ch drrange 7 0 5
Sending: mac set ch status 7 on
Sending: mac set pwridx 1
Sending: mac set retx 7
Sending: mac set dr 5
Sending: mac join otaa 
Join accepted. Status: 00000819
DevAddr: 0144B01C

After this I usually send down via Serial monitor:

johanstokking commented 4 years ago

Hmm. I think your best bet is to benchmark this with another device, like any device supporting Mbed OS LoRaWAN stack (see module support) or LoRaMac-node.

LasaleFamine commented 4 years ago

That's what I wanted to avoid actually. I have no previous experience with Mbed (and actually don't need one for the project) and btw I bought two TTUNO hoping that the RN2483 would make it with Class C.

What I'm wondering is: is there someone who had successful transmit a Class C downlink from the Stack receiving on an RN2483? Or at least, using another stack. I can't find a single success example on the web about this.

I actually need Class C for avoiding latency on some specific part of my project implementation where I need an almost instant action. I hope I'm not the only one who needs this feature to work, but currently I'm finding super difficult to solve this problem using the LoRaWAN ecosystem.

johanstokking commented 4 years ago

I understand. It should work, and my impression is that you're close. Can you try to find people on the forums who are using class C with the RN2483?

LasaleFamine commented 4 years ago

I thought I was close too actually.

Anyway, I have searched already through the forum but I can't find anything relevant. Maybe it's time to open a new topic and ask if someone has updates.

I really appreciate your help and time @johanstokking. I'll be back here as soon I'll have some news. Thanks!

johanstokking commented 4 years ago

Looping in @jpmeijers as he might have an idea on this one