Hi, anyone experienced issues with the Browan Pico Next Gateway not transmitting CLASS C downlinks, when I replace this gateway with the TTIG gateway the CLASS C downlinks get transmitted so the fault lies with the Pico Next Gateway. The log in the live data field indicates that the gateway has transmitted the packet but this is not the case.
Thanks
As Browan are the OEM for both what did they say when asked? - WHilst TTIGs common with TTN Forumites I suspect Pico Next rather less so so experience will be limited - Brown should be able to inidicate if an issue known. Please share if you get a response. It could be a PF/JIT queue issue or backhaul timing but one would expect both impacted the same…
Remember always that in the Community context downlinks are to be avoided/limited where possible and minimised under FUP when they are are a must have 'cause (forum search).
How do you know? Are there any error messages?
I have sent a request through and will post any replies.
The problem was fist reported by a client. I set up a test environment within our lab and reliably repeated the fault with the Browan Pico Next. Powered down the Browan Pico Next and powered up the TTIG, and the downlinks were received by the end node.
The extract from the live data logs are identical:
“data”: {
“@type”: “type.googleapis.com/ttn.lorawan.v3.DownlinkMessage”,
“raw_payload”: “YHMtCCYAAwAKCTdge6FnAi/mDoWL”,
“payload”: {
“m_hdr”: {
“m_type”: “UNCONFIRMED_DOWN”
},
“mic”: “5g6Fiw==”,
“mac_payload”: {
“f_hdr”: {
“dev_addr”: “26082D73”,
“f_ctrl”: {},
“f_cnt”: 3
},
“f_port”: 10,
“frm_payload”: “CTdge6FnAi8=”,
“full_f_cnt”: 3
}
},
“request”: {
“class”: “CLASS_C”,
“downlink_paths”: [
{
“uplink_token”: “CiIKIAoUYXVzLTU4YTBjYmZmZmU4MDM0ZGMSCFigy//+gDTcEPSnv6AFGgwI+eT/oAYQ6pnu+gEgoOLP7oUp”
}
],
“rx2_data_rate”: {
“lora”: {
“bandwidth”: 125000,
“spreading_factor”: 9,
“coding_rate”: “4/5”
}
},
“rx2_frequency”: “869525000”,
“frequency_plan_id”: “EU_863_870_TTN”
},
Hi Jeff - initial recommendation from Browan has been to update the firmware - will keep you posted.
Hi Jeff - upgraded the firmware in the Pico Next gateway to the latest (1.1.65) with no resolution to the problem. I then tested the class C downlinks with a Mikrotik gateway and these worked perfectly, even if I routed the downlinks via the packet broker.
I then configured a Browan TTOG gateway and it results in the same symptoms as the Pico Next gateway. So the problem seems to lie with the two Browan gateways - maybe they are using the same core software.
I have sent the latest results together with log files to Browan. Awaiting further feedback.
Hi Jeff - the image below is an extract from the log, looks like the downlink is using a data rate of SF12BW125 when it should be SF9BW125. If this is the case it would explain everything. I have sent my findings off to the manufacturer and await their feedback, they are closed this week.
Too tiny for my poor eyes! BUT can make out the RSSI values you have highlighted as single digit - these are FAR too high!!! Is node sitting on the GW?! 
Especially for US or AU users who are allowed stupidly high TX power values…
Get them seperated and RSSI’s down to managable levels (Form search is your friend - we end up calling this out atleast weekly!) SHOUTING + CHannel bleed + front end saturation/distortion etc. not a good recipe for reliable comms…
Yes, the gateway and node were within a few meters of each other in our lab. I did initially think this was the problem and moved the gateway away a respectable distance and had typical RSSI values in the region of -70 and SNR around 10 without resolving the problem. I definitely believe that the Browan gateways are defaulting to SF12BW125 for RX2 instead of using SF9BW125 with respect to Class C downlinks and that this is the cause of the problem. Still awaiting feedback from the manufacturer.
Zoomed in on the data rate section of the downlink in the image.
Gateways do not determine which SF to use. The back-end instructs the gateway what SF to use,
How do you have the GW registered, which freq plan/sub bands etc?
Hi, fully agree. The backend is instructing the gateway to use SF9BW125, however I believe there may be a fault in the software where the gateway is defaulting RX2 to SF12BW125.
Hi Jeff, all gateways I have used in this troubleshooting exercise have been set to Europe 863-870 MHz (SF9 for RX2 - recommended).
If the backend instructs the gateway to use SF9 and the gateway uses SF12 the packet forwarder on the gateway most definitely has a bug.
Manufacturer has requested that I perform a factory reset on the gateway and redo the tests. Will do so and post results.
Tried the factory reset and this did not help. Generated log files for the TTIG, Mikrotic, and BROWAN PICO NEXT gateways for the following scenarios:
The TTIG and Mikrotik gateways operated perfectly, BROWAN did not. 2 days of going over the log files I found a single entry in one of the join processes for the BROWAN reporting a DROP JOIN REQUEST - UPLINK CHANNEL NOT FOUND. Examination of the join request found that the frequency was 867.5. I then went and added all 8 channels as factory-preset frequencies for the end node and viola, all three gateways now operate perfectly.
Can anyone shed light on why the provision of factory-preset frequencies would change the behaviour of one specific gateway, namely the BROWAN PICO NEXT?
Update: setup customer’s end node as per test scenario by adding the 8 channel factory-preset frequencies but this did not help. Suspect that the customer’s Browan Pico Next Gateway still running the original firmware is a problem.
Solution seems to lie in a combination of upgrading Gateway firmware and adding the 8 factory-preset frequencies.
Continuing to investigate.
Hi Steve
Did you manage to solve the issue? We’re struggeling with the same problem. CLASS C Downlinks get transmitted using a Dragino and Advantech Gateway but with the Browan Pico Next Gateway it won’t work.
Thanks