We have some 70 devices all over The Netherlands measuring Air Quality. These all have an Adafruit 32u4 Feather. All are defined as ABP in TTN V2.
I migrated one at home from V2 to V3 keeping the same Device Address, NwkSKey and AppSKey. So I did not load another sketch.
At home I have a V3 gateway. I see data coming in. So that looks succesful.
But the other 69 are all spread over the country. I just migrated one in Utrecht. Deleting it from the V2 and adding it to V3. Same way as the first one.
Only difference is that this second one will not reach my V3-gateway.
I don’t see data coming in. Could it mean that no V3-gateway is available? How can I check that?
Maybe I just don’t understand the migration-policy?
V3 is more critical regarding LoRaWAN compliance.
I assume an older LMIC library version is used for the devices. A version that doesn’t support MAC commands used by V3.
Another cause may be the RX delay in V3 which is now 5 seconds instead of one second.
TTN device settings can be adjusted (via the command line tool), e.g. set RX delay from the default 5s to 1s. But that IIRC is not guaranteed to work for all situations.
I remember something about certain deveceid ranges used on V2 not being valid on V3 because V3 uses different ranges but I don’t remember the exact details. Other users can probably give more accurate info on this.
It would be most preferred (and more future proof) to use a recent LMIC version, OTAA and upload new firmware to the devices.
I understand it will be difficult to update all devices in the field.
ATmega32u4 has limited memory (ram and flash) resources and is actually not preferred for use with recent versions of MCCI LMIC (which are preferred/needed for V3) due to the memory constraints.
It will depend on the complexity/size of the application running on your nodes whether this will still fit on a Feather 32u4 together with a recent LMIC version.
If you provide more details about your situation that will enable others to provide more useful answers.
As well as the information above, ff you need to recycle the nodes (and why not), let me know what sensors are on them and I can see if I can work my LMIC magic to bring you up to a reasonable level of compliance on the stack.
That is, of course, if you can retrieve them. Or if you need to replace them, we may be able to suggest ways of re-using the sensors & other parts as you swap them over.
Hm, it automagically started to send data. Days after I first created the device.
Yes, I use an older LMIC-version and the RX1-delay was already at 1s.
The frequency of successful data-transfer is not what I expect. It should be every 3 minutes. But is way less. Approx once every 30 minutes. But sometimes it is every 3 minutes. Is there a way I can check where the missing data is stuck? I am afraid not…
I remember to have read to define 5 extra Factory Preset Frequencies. Apart from 3 (868100000, 868300000, 868500000). What is it for?
Thanks in advance.
Every 3 mins is high considering the TTN FUP depending on what SF you are using and size of payload. Can you check the received signal strength (RSSI) and noise level (SNR) for the messages you do see as it sounds like you may be in a area with marginal coverage which may keep dropping out, chance of lost packets, esp if SNR poor (depending on SF), once you get into RSSI values <-115/116 db range gets quite high…
1 Like
Is this useful info:
"rx_metadata":[{"gateway_ids":{"gateway_id":"rabobank-utrecht","eui":"0000024B080E0FFD"},"time":"2021-10-07T10:02:14.506121Z","timestamp":1188544987,"rssi":-109,"channel_rssi":-109,"snr":6,"uplink_token":"Ch4KHAoQcmFib2JhbmstdXRyZWNodBIIAAACSwgOD/0Q24PftgQaDAimi/uKBhDm1o/+ASD4/rTWy7+dAQ=="},{"gateway_ids":{"gateway_id":"tabs-noork","eui":"58A0CBFFFE800549"},"time":"2021-10-07T10:02:14.505342006Z","timestamp":2302502051,"rssi":-114,"channel_rssi":-114,"snr":-3.75,"location":{"latitude":52.070279619689224,"longitude":5.123664071930953,"altitude":6,"source":"SOURCE_REGISTRY"},"uplink_token":"ChgKFgoKdGFicy1ub29yaxIIWKDL//6ABUkQo8n1yQgaDAimi/uKBhDnz/qTAiC4ucS+gUM="}],"settings":{"data_rate":{"lora":{"bandwidth":125000,"spreading_factor":7}},"data_rate_index":5,"coding_rate":"4/5","frequency":"868100000","timestamp":1188544987,"time":"2021-10-07T10:02:14.506121Z"},"received_at":"2021-10-07T10:02:14.534672328Z","consumed_airtime":"0.071936s","network_ids":{"net_id":"000013","tenant_id":"ttn","cluster_id":"ttn-eu1"}
The V3 stack/console by default assumes that for a device (both OTAA and ABP) only three basic (EU868) channel frequencies are known/programmed upfront.
For OTAA the additional 5 channel frequencies (5 of the 8 channels) are automatically configured during the join.
I’m not sure how this would go for ABP, probably also dynamic via MAC commands but I have no experience with this.
In V2 the network server assumes all 8 EU868 channel frequencies are known to / programmed into an EU ABP device in advance.
V3 assumes only the three basic channel frequencies and you need to explicitly tell in the device configuration that all 8 channel frequencies are programmed into the device upfront.
That is what it is for.