Is V3 the end for TinyLora?

TTN V2 to V3 Upgrade V3 Devices
29

I was able to get a TinyLora node to receive on all channels by adding the several frequencies in the network layer advanced section. This only worked with a newly created device (modifying an existing one didn’t work for me).

Below you can see the response in the application live view. There are no new channel requests any-more & data is received on all 8 channels. There is still a schedule for a data downlink transmission. Not sure if this can be switched off (as the device cannot receive anything).

image

1 Like
30

Newly created application or device?

31

I meant device (not application)

32

edited your post to fix that

33

@htdvisser For the sake of verification I created network layer advanced settings.
Can you please confirm or comment these? They are meant for a ABP device that works on V2 and that shall be migrated to V3.

RX1 Delay: 1
RX1 Data Rate Offset: 0
Reset frame counters: true
RX2 Data rate Index: 3 (SF9)
RX2 Frequency: 869525000
Factory preset frequencies:
  0: 868100000
  1: 868300000
  2: 868500000
  3: 867100000
  4: 867300000
  5: 867500000
  6: 867700000
  7: 867900000
  8: 868800000
1 Like
34

I think the settings mentioned are not fully correct.

  • RX1 Delay should be 5 (not 1)
  • There are only 8 channels (not 9).

I have now the following settings implemented (node with TinyLora). As mentioned this only works with a new device. Changing settings after device creation didn’t have any effect.

image

This gives the following response.

image

There are no set-up requests anymore and the device is reportig on all 8 channels. So I am happy with the result. :slightly_smiling_face:

1 Like
35

I’ve entered an Rx1 delay in to the V3 setup of an ABP device as it’s easier to do that than recompile the firmware. I appreciate that TinyLoRa doesn’t do downlinks, but many other stacks do and the V2 default is 1 second.

1 Like
36
  • RX1 Delay should be 5 (not 1)

For a new device, yes. For an existing device, the dilemma would be between trying to keep it working the way it was with a 1 second delay, vs, understanding that the longer delay was chosen because of concern that it may not be possible to get downlink packets back through more complex routing to the gateway in time to actually achieve a 1-second window.

  • There are only 8 channels (not 9).

Actually there are nine. The last one in the list you refer to, 868.8, is the FSK channel, rarely used, but it does in fact appear in the TTN bandplan. If it should be entered alongside the LoRa channels, or elsewhere or not at all is an interesting question, but it does officially exist.

37

I believe that with a 1 second RX1 delay the application will sent a downlink request to change to 5 seconds. At least that happened when I didn’t specify the RX1 value at all.

As this is for TinyLora which cannot receive/respond to the request I did change to 5 and the request was not generated (resulting in less unneeded trafic). Not sure if this will also be the case when I specifically set it to 1 (will try-out in future)

For ABP devices that can receive downlinks 1 second for RX1 is probably the way to go.

38

Wasn’t aware of a 9th channel (never to old to learn). So far haven’t seen any negative effects by not entering it in the set-up :slightly_smiling_face:

39

Which is fine, as long as the device’s stack can process the MAC command. For many devices with much older builds, this may well have been hard coded.

It’s on my todo list to check when this level of support was introduced.

40

In my case the network keeps sending downlink messages. :frowning: I updated network settings but I see no change unfortionately.

41

Updating the settings will not work. You will need to delete the device and create a new one. At creation you need to fill in the advance settings. (changing them afterwards didn’t work for me)

If done as in my settings overview (previous post) you should get the result as also posted. For me this works with TinyLora on a STM32 device + RFM95.

1 Like
42

Why would you use such an incomplete stack on an STM32? On an ATmega I could see (if disagree with) the argument, but on an STM32?

2 Likes
43

Good t know. I will try it. But this is actually very bad :anguished: why allow users to update device parameters when they cannot be put in effect. I presume this is a bug (defect) that shall be repaired.

1 Like
44

@htdvisser Is this still a consideration?

2 Likes
45

Why would you use such an incomplete stack on an STM32? On an ATmega I could see (if disagree with) the argument, but on an STM32?

This is for testing only…

Only just recently I switched over to the STM32L051 family but I have still many old devices (Atmega’s and evem Attiny84’s). They all work perfectly and some of them are running already 3 years continuesly on 1 battery (eg in the freezer, doors, PIR’s, moistsensors for plants, mailbox etc :slightly_smiling_face:).

I don’t want to scrap them because they are limited in memory or old. For what they need to do they are perfect.

But going forward I will use the STM32 and a more complete stack but I want to keep my old devices running.

3 Likes
46

That’s a nice architecture, but probably worth going for the pin compatible STM32L07x series as most using them for LoRaWan and similar are, to have a little more elbow room than the L051’s.

47

Good afternoon

I have a bit of a silly question, I’m not sure if what I’ve done has worked or not. I’ve followed the guidance in this forum post to create a new device in the v3 console, and I get the same live data as @rvdvoort , which leads me to believe that it it is working (even though it seems to be scheduling downlinks):
image
However, the downlink counter is incrementing on every uplink:
image
Is this correct or have I messed something up?

Thank you!

48

Seems to look ok for me.

A standard downlink will always be scheduled after an uplink as this is part of the Lorawan standard (at least that is how I understand it). I don’t think that this downlink can be disabled.