Hello - I am experiencing unreliable communication between the RN2903 and the Multitech Conduit gateway. This has been covered on the forums here and there, but I’m not finding a solution that actually works.
-I am using a Microchip PICtail USB kit for the RN2903 chip (it’s not the RN2903A version)
-RN2903 has firmware 1.0.3
-Microchip LoRa Development Utility for testing
-ABP mode for testing (will worry about OTAA later)
-My keys are loaded in
-I am able to pass messages successfully to TTN, however 1 in approx. 10 attempts are successful only
-Using default 915Mhz Multitech Conduit configuration for TTN global_config_json
-I’ve disabled all channels on the RN2903, with the exception of: 8,9,10,11,12,13,14,15,65
-Multitech Conduit and my test project are 25 feet away from one another
-I’ve used a SDR radio, I am observing transmissions all over the band (not limited to the frequencies I enabled) - I’m convinced this is the problem.
From what I can tell, the RN2903 is not restricting it’s communication to the frequencies specified by the Multitech configuration, the RN2903 configuration as I’ve programmed via the LoRa Development Utility (Microchip software). I’ve learnt that the RN2903 can transmit on far more than 8 channels. The Multitech supports only the 8 channels. I’ve compared the channels specified in the config_json, file and the frequency list as specified: https://www.thethingsnetwork.org/wiki/LoRaWAN/Frequencies/Frequency-Plans
Would anyone have any tips / code / etc to help resolve this? I can’t explain why this is occurring. I feel I am doing everything correct - perhaps missing an important detail.
Hello - just an update: I found an RN2903A device opposed to the RN2903. I still using the LoRa Development Utility from Microchip to send commands semi manually to the RN2903A device. I am now using OTAA - The device joins relatively painlessly which was a great surprised to me !
I’ve enabled channels 8,9,10,11,12,13,14,15 and 65 on the RN2903A to match the US915 frequency plan and matching the global_config.json file in my Multitech gateway.
I still have trouble sending messages reliably (takes about 10 to 20 attempts before a message gets thru).
Noted something interesting: Whilst I monitor “GATEWAY TRAFFIC” - I see the ONLY messages that the gateway seems to be receiving are on 904.6 Mhz SF8 BW 500. I haven’t seen any BW 125 messages come thru unless they are OTAA handshake messages.
Now that I’ve found an RN2903A module, I’ve upgraded the firmware to 1.0.3.
Sending a simple unconfirmed message by entering ‘max tx uncnf 1 30313233’ - I get “ok, mac_tx_ok, We Transmitted” replies from the RN2903A. 1 in about 20 attempts makes it thru - always on 904.5 SF8 BW500 only.
Hello - yes, the frequency plan was set by the installation script for the Multitech gateway (sourced from the The Things Network site). I’ve verified the config file, it is in alignment with the TTN frequency plan for USA. I feel this is a problem with the RN2903 module. Although I’ve programmed the channels it should operate on, I suspect it’s still transmitting outside of the specification (I could be wrong however).
Just chiming in to say I’m working with the RN2903 & Conduit combination as well and am experiencing difficulty connecting to the gateway with increasing distances. Maybe outside 150 feet (ballpark) ?
I’m working within a building, and once I’ve gone past a certain distance/through a few rooms, I receive ‘denied’ messages after issuing ‘mac join otaa’ & ‘mac join abp’… I haven’t dug into the issue yet, but will be doing so over the next few days.
If anyone has any resources/suggestions, please let me know!
Just updating to let everyone know I’ve yet to come across a solution - that being said, I’ve been busy elsewhere recently (unfortunately). Kersing, I believe you originally gave me some tips on getting the Multitech gateway running originally - thank you for that. The 8 channels and the Microchip RN2903 unreliability is still a puzzle.