# ProMini/RFM95 node downlink error on V3 **URL:** \ **Category:** Migrating Devices to V3\ **Created:** [December 27, 2021, 3:27pm UTC](https://www.thethingsnetwork.org/forum/t/promini-rfm95-node-downlink-error-on-v3/54094 "2021-12-27T15:27:04Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![peerv](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/peerv/32/35697_2.png) [@peerv](https://www.thethingsnetwork.org/forum/u/peerv)\ **Post date:** [December 27, 2021, 3:27pm UTC](https://www.thethingsnetwork.org/forum/t/promini-rfm95-node-downlink-error-on-v3/54094/1 "2021-12-27T15:27:04Z")
I have a ProMini/RFM95 node that worked fine for years on TTNV2 with OTAA I manually defined an end device in TTNV3 and recompiled the sketch with MCCI\_LMIC 4.1.0 OTAA Join works OK and messages arrive in the TTN Console. Always after exactly Fcnt 19 the transmission stops with: _Schedule data downlink for transmission on Gateway Server_ My TTIG gateway also stops receiving messages while the node is still sending messages It looks my node is not receiving messages. Could there be something wrong with my end device definition in the TTN console? ```auto arrow_downward 15:50:32 eui-70b3d57ed004a696 Schedule data downlink for transmission on Gateway Server Rx1 Delay 5 arrow_upward 15:50:31 eui-70b3d57ed004a696 Forward uplink data message MAC payload 010099 FPort 1 Data rate SF7BW125 SNR -7.5 RSSI -123 arrow_upward 15:50:31 eui-70b3d57ed004a696 Successfully processed data message DevAddr 260BEE92 FCnt 19 FPort 1 Data rate SF7BW125 SNR -7.5 RSSI -123 arrow_upward 15:49:22 eui-70b3d57ed004a696 Forward uplink data message MAC payload 010098 FPort 1 Data rate SF7BW125 SNR 8 RSSI -71 arrow_upward 15:49:22 eui-70b3d57ed004a696 Successfully processed data message DevAddr 260BEE92 FCnt 18 FPort 1 Data rate SF7BW125 SNR 8 RSSI -71 arrow_upward 15:48:14 eui-70b3d57ed004a696 Forward uplink data message MAC payload 010098 FPort 1 Data rate SF7BW125 SNR 9.25 RSSI -71 ``` ---
**Author:** ![cslorabox](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/cslorabox/32/35697_2.png) [@cslorabox](https://www.thethingsnetwork.org/forum/u/cslorabox)\ **Post date:** [December 27, 2021, 11:59pm UTC](https://www.thethingsnetwork.org/forum/t/promini-rfm95-node-downlink-error-on-v3/54094/2 "2021-12-27T23:59:31Z")
How many downlinks are you trying to send, in what amount of time? LoRaWAN is an “uplink mostly” network - downlinks are supposed to be extremely rare. ---
**Author:** ![peerv](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/peerv/32/35697_2.png) [@peerv](https://www.thethingsnetwork.org/forum/u/peerv)\ **Post date:** [December 28, 2021, 10:30am UTC](https://www.thethingsnetwork.org/forum/t/promini-rfm95-node-downlink-error-on-v3/54094/3 "2021-12-28T10:30:10Z")
I don’t send downlinks at all. It is just a sensor sketch sending measurements uplink. I have no idea what is trying to start a downlink. Is it part of the protocol because of settings in the TTN end device definition? In the end device General settings/Network layer/Advanced MAC settings I already did set the “Status count periodicity” and the “Status time periodicity” to zero in the idea to prevent downlink messages. However the “Status count periodicity” gets automaticly set back to 200 ??!! ---
**Author:** ![peerv](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/peerv/32/35697_2.png) [@peerv](https://www.thethingsnetwork.org/forum/u/peerv)\ **Post date:** [December 30, 2021, 2:22pm UTC](https://www.thethingsnetwork.org/forum/t/promini-rfm95-node-downlink-error-on-v3/54094/4 "2021-12-30T14:22:25Z")
This is the first time the node is connected to the V3 stack. The node has the mcci-lmic library 4.1 so should be fully compliant. Join is ok! See the app console screenshot below After one or more uplink messages TTS sends a downlink message (The application does not send downlinks) From that moment on the GW and the App console don’t show uplink messages anymore. (The node keeps on sending!) I am including the GW and App Event details for the downlink. Sorry, I don’t have the skill to interpret the event details. Searching the forum also was without result. Anybody having a clou what is happening here? **Console log** ![GWConsole 2021-12-30 144625](https://www.thethingsnetwork.org/forum/uploads/default/original/3X/6/9/69d92bed7e580fdcc883c4f83c45365fb9b7c63c.jpeg) **Application log** ![AppConsole 2021-12-30 144455](https://www.thethingsnetwork.org/forum/uploads/default/original/3X/f/5/f5d34622cfb1fae611b0e19fc146b15fb7abe855.jpeg) **Gateway Console Event detail for the downlink** ```auto "name": "gs.down.send", "time": "2021-12-30T13:43:18.735781335Z", "identifiers": [ { "gateway_ids": { "gateway_id": "eui-58a0cbfffe800f41" } }, { "gateway_ids": { "gateway_id": "eui-58a0cbfffe800f41", "eui": "58A0CBFFFE800F41" } } ], "data": { "@type": "type.googleapis.com/ttn.lorawan.v3.DownlinkMessage", "raw_payload": "IHbT5nHODERCYOpXJ9eYEoI8o2yzn5K+BVu5e4x3FJ8i", "request": { "downlink_paths": [ { "uplink_token": "CiIKIAoUZXVpLTU4YTBjYmZmZmU4MDBmNDESCFigy//+gA9BEMPnrqoJGgwI9O62jgYQmrfuuQMguOPY/fKqCioMCPTuto4GEPSot4gD" } ], "rx1_delay": 5, "rx1_data_rate": { "lora": { "bandwidth": 125000, "spreading_factor": 7 } }, "rx1_frequency": "868300000", "rx2_data_rate": { "lora": { "bandwidth": 125000, "spreading_factor": 12 } }, "rx2_frequency": "869525000", "priority": "HIGHEST", "frequency_plan_id": "EU_863_870_TTN" }, "correlation_ids": [ "gs:conn:01FR4DY1W1SXBKY7ZF82X7Q4NS", "gs:up:host:01FR4DY1WD3MTEFDRAQM930VW9", "gs:uplink:01FR5S985YMNA1Y9WMS8FN4ZRS", "ns:downlink:01FR5S99YFG9Q7W9TADS3C9PXX", "ns:uplink:01FR5S9861TP2HAS839HXSGV9A", "rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01FR5S98614JX1YFJ8THWNNGGQ", "gs:conn:01FR4DY1W1SXBKY7ZF82X7Q4NS", "rpc:/ttn.lorawan.v3.NsGs/ScheduleDownlink:01FR5S99YFKY65X06DRC0HD8WX" ] }, "correlation_ids": [ "gs:conn:01FR4DY1W1SXBKY7ZF82X7Q4NS", "rpc:/ttn.lorawan.v3.NsGs/ScheduleDownlink:01FR5S99YFKY65X06DRC0HD8WX" ], "origin": "ip-10-100-15-245.eu-west-1.compute.internal", "context": { "tenant-id": "CgN0dG4=" }, "visibility": { "rights": [ "RIGHT_GATEWAY_TRAFFIC_READ", "RIGHT_GATEWAY_TRAFFIC_READ" ] }, "unique_id": "01FR5S99YF21NSVTFEN9Y0SHXD" } ``` **Application Console Event Detail for the downlink** ```auto "name": "ns.down.data.schedule.attempt", "time": "2021-12-30T13:43:22.526830168Z", "identifiers": [ { "device_ids": { "device_id": "mcci-sonar-otaa", "application_ids": { "application_id": "sonar-hcsr04" } } }, { "device_ids": { "device_id": "mcci-sonar-otaa", "application_ids": { "application_id": "sonar-hcsr04" }, "dev_eui": "70B3D57ED004AA39", "join_eui": "0000000000000000", "dev_addr": "260B674B" } } ], "data": { "@type": "type.googleapis.com/ttn.lorawan.v3.DownlinkMessage", "raw_payload": "YEtnCyaBAAAGhYjJfg==", "payload": { "m_hdr": { "m_type": "UNCONFIRMED_DOWN" }, "mic": "hYjJfg==", "mac_payload": { "f_hdr": { "dev_addr": "260B674B", "f_ctrl": { "adr": true }, "f_opts": "Bg==" } } }, "request": { "downlink_paths": [ { "uplink_token": "CiIKIAoUZXVpLTU4YTBjYmZmZmU4MDBmNDESCFigy//+gA9BEJOt6qwJGgsI+u62jgYQtJH6NSC43PCehqsKKgsI+u62jgYQ19H6BA==" } ], "rx1_delay": 5, "rx1_data_rate": { "lora": { "bandwidth": 125000, "spreading_factor": 7 } }, "rx1_frequency": "868100000", "rx2_data_rate": { "lora": { "bandwidth": 125000, "spreading_factor": 9 } }, "rx2_frequency": "869525000", "priority": "HIGHEST", "frequency_plan_id": "EU_863_870_TTN" }, "correlation_ids": [ "gs:conn:01FR4DY1W1SXBKY7ZF82X7Q4NS", "gs:up:host:01FR4DY1WD3MTEFDRAQM930VW9", "gs:uplink:01FR5S9D819W581TJEYVE5A9EN", "ns:downlink:01FR5S9DMYPJ5TA1A6PNVNYWJA", "ns:uplink:01FR5S9D83W6GWJ7MCSTYN2HPT", "rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01FR5S9D83ZFTQS2ZXN1HSPHSQ" ] }, "correlation_ids": [ "gs:conn:01FR4DY1W1SXBKY7ZF82X7Q4NS", "gs:up:host:01FR4DY1WD3MTEFDRAQM930VW9", "gs:uplink:01FR5S9D819W581TJEYVE5A9EN", "ns:downlink:01FR5S9DMYPJ5TA1A6PNVNYWJA", "ns:uplink:01FR5S9D83W6GWJ7MCSTYN2HPT", "rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01FR5S9D83ZFTQS2ZXN1HSPHSQ" ], "origin": "ip-10-100-12-30.eu-west-1.compute.internal", "context": { "tenant-id": "CgN0dG4=" }, "visibility": { "rights": [ "RIGHT_APPLICATION_TRAFFIC_READ", "RIGHT_APPLICATION_TRAFFIC_READ" ] }, "unique_id": "01FR5S9DMYP55Q6FYGP383K1GN" } ``` ---
**Author:** ![cslorabox](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/cslorabox/32/35697_2.png) [@cslorabox](https://www.thethingsnetwork.org/forum/u/cslorabox)\ **Post date:** [December 30, 2021, 4:10pm UTC](https://www.thethingsnetwork.org/forum/t/promini-rfm95-node-downlink-error-on-v3/54094/5 "2021-12-30T16:10:21Z")
That “downlink” > [@peerv](#): > > `IHbT5nHODERCYOpXJ9eYEoI8o2yzn5K+BVu5e4x3FJ8i` is your join accept. ---
**Author:** ![descartes](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/descartes/32/47220_2.png) [@descartes](https://www.thethingsnetwork.org/forum/u/descartes)\ **Post date:** [December 30, 2021, 4:39pm UTC](https://www.thethingsnetwork.org/forum/t/promini-rfm95-node-downlink-error-on-v3/54094/6 "2021-12-30T16:39:49Z")
> [@peerv](#): > > After one or more uplink messages TTS sends a downlink message (The application does not send downlinks) From that moment on the GW and the App console don’t show uplink messages anymore. (The node keeps on sending!) Probably run out of memory aa stack overflow so overwritten some key data if you haven’t turned off Class B and other bits. ---
**Author:** ![peerv](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/peerv/32/35697_2.png) [@peerv](https://www.thethingsnetwork.org/forum/u/peerv)\ **Post date:** [December 31, 2021, 10:52am UTC](https://www.thethingsnetwork.org/forum/t/promini-rfm95-node-downlink-error-on-v3/54094/7 "2021-12-31T10:52:30Z")
In the end device General settings/Network layer/Advanced MAC settings If I set the “Status count periodicity” and the “Status time periodicity” to zero the node is sending Fcnt 19 uplink messages before a downlink message stops the uplink transmissions. When I do that then there is no downlink message directly after the Join. I am using the documented settings of the manually registered end device with the - recommended Europe 863-870Mhz (RF9 for RX2) - MAC V1.0.2 - PHY V1.0.2 REV B This is my first TTS V3 node so any setting could be wrong! Any suggestions? ---
**Author:** ![cslorabox](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/cslorabox/32/35697_2.png) [@cslorabox](https://www.thethingsnetwork.org/forum/u/cslorabox)\ **Post date:** [December 31, 2021, 2:03pm UTC](https://www.thethingsnetwork.org/forum/t/promini-rfm95-node-downlink-error-on-v3/54094/8 "2021-12-31T14:03:35Z")
> [@peerv](#): > > If I set the “Status count periodicity” and the “Status time periodicity” to zero the node is sending Fcnt 19 uplink messages before a downlink message stops the uplink transmissions. That “triggering” downlink is the one we need to see the raw packet (or else broken out MAC command contents) of. What you share before was just the (subsequent?) join accept downlink. ---
**Author:** ![descartes](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/descartes/32/47220_2.png) [@descartes](https://www.thethingsnetwork.org/forum/u/descartes)\ **Post date:** [December 31, 2021, 2:55pm UTC](https://www.thethingsnetwork.org/forum/t/promini-rfm95-node-downlink-error-on-v3/54094/9 "2021-12-31T14:55:25Z")
> [@peerv](#): > > Any suggestions? Answer my question? Particularly as it will speak to your review of the instructions which will then lead to the choice of LoRaWAN version as well. The status periodicity, which you already mentioned, would cut in after 200 uplinks or one day - so if you are bench testing with a 5 minute uplink schedule for instance, it’s irrelevant.