I'm trying to use nano-gateway with loraserver.io but I can not downstream messages just upstream. Can you share if you had the same problem?

@eric24 Aha... ok. Longer term eg 6 months horizon, Pycom will be offering connectivity services. For obvious reasons I cannot go into detail at this stage but we will make announcements soon. In the meant time, I take onboard your requirements and will ensure we publish some practical steps for short term supply. Leave that with me... Thanks Fred

@brunos ! With s.setblocking (True) before s.send(), it's OK !!

So this should do it, acknowledging that no channel willever use AS923 data rate 0 or 1? for channel in range(0, 15): lora.remove_channel(channel) lora.add_channel(0, frequency=923200000, dr_min=0, dr_max=3) lora.add_channel(1, frequency=923400000, dr_min=0, dr_max=3) lora.add_channel(2, frequency=922200000, dr_min=0, dr_max=3) lora.add_channel(3, frequency=922400000, dr_min=0, dr_max=3) lora.add_channel(4, frequency=922600000, dr_min=0, dr_max=3) lora.add_channel(5, frequency=922800000, dr_min=0, dr_max=3) lora.add_channel(6, frequency=922000000, dr_min=0, dr_max=3)

@az311 OK thanks, that Payload Data is definitely from one of our examples (the ASCII codes spell "PKT # ..." ) so your node did join and is sending the data correctly. It's not a problem to see some "Not joined yet..." messages at the beginning - that's how it works - but they should stop once it joined. If you want to see what's happening you can add a message print("Connected!") on line 42 and then and a print("Sent") on 56

Thanks, that makes sense and yes we are concerned with Gateway time on air. So a confirmed uplink which feeds back into my join code if it doesn't get an ack might be sensible and we could have this repeat over a fairly large timeframe, as the scenario I am thinking about is really a DR situation where we somehow lost the database behind our LoRaWAN server and how we'd get nodes talking again.

Excellent @lsoria , so happy you got it working! I'll gladly add the [SOLVED] if you're satisfied :) By the way - just a bit of LoRa trivia - the code really just sends one join attempt, you see the "Not yet joined..." message several times because OTAA joins by the LoRaWAN standard take at least 5 seconds from sending the join request to receiving a join accept reply (+ a bit extra extra processing time), this is called JOIN_ACCEPT_DELAY1 and JOIN_ACCEPT_DELAY2 in the spec. But this is really not that important so feel free to ignore it :-)

@crumble Thanks for the info. I've subsequently acquired the Particle Boron LTE boards which can actually accomplish my live streaming requirement over LTE with MQTT - and they are way lower power usage than Pycom boards, and it only takes 12 seconds to connect to the network, and it's cheaper. Currently looks like I'll be switching to Particle because of the LTE deficiencies with Pycom, unfortunately. The Cortex M4 power consumption situation (down to 17ma/5V WHILE connected to LTE, idle, zero sleep modes active) blows the Pycom ESP-32 out of the water anyways. Yes, ESP32 is at 240Hz and the Particle Boron is 64Hz. But I will never in a million years need beyond even 24Mhz, and Pycom doesn't give me a way to underclock and match the current consumption. Kind of frustrating/suprising that I can accomplish my task by radio-ing to a cell-tower and back with Particle, but with Pycom short-range LoRa, no-can-do.

Yesterday i was testing ADR on LoPy with confirmed packets. I achieved that LoPy change to a SF8BW125 but no more, the communication range was the same. I forced the LoPy to transmit at SF12 in the socket configuration, and the range is the same too... I looked from lora.tx_power() and the value is 13, i think 13 dBm. About 100 meters in line vision, the gateway measured SNR = 8 dB and RSSI = -78 dB ... it is OK?

I think you are right. I don't know how it was stuck in my mind that I could not change the join DR. Maybe by older topics of the forum. Thank you!

@rachelsimida I gave up. I have my LoPy for 1 year and I cannot find a single working code that reads a sensor (dht22 for example) and sends it to the things network.

@aris This topic looks quite old, and I really do hope that you have found the solution by now, but if not: To hardcode SF12 when joining this works for us: when joining: self.lora.join(activation=LoRa.OTAA, auth=(self.dev_eui, self.app_eui, self.app_key), timeout=0, dr=0) After setting up the socket: self.s.setsockopt(socket.SOL_LORA, socket.SO_DR, 0)

OK I managed to spend a little time this weekend tackling the LORA issue @jmarcelino . After a bit of travel and lots of outdoor testing I can confirm the issue was gateway related...! The code you recommended worked fine. As @jcaron mentioned, if the gateway is indoors you have to be really, really close to get a connection. As I can't get a connection near my home, I need to either persuade the local gateways to put up an external antenna, or go and buy myself a gateway!! Many thanks @jmarcelino and @jcaron for your advice.

@jmarcelino said in LoPy as a gateway send packet under TCP/IP: don’t recommend running TCP over LoRa itself. Sir, can you please elaborate more on how to change the lora packet data into tcp/ip format?

@dan Well, don't understand why it is like that. Due to a research project I have had to "hack" the libraries to allow changing the transmission power. Should anyone need it, send me a PM (I have just programmed a "dirty" workaround so not even daring to push a change to github or something like that!)

@daniel @bucknall Ping! This is the same issue as: https://github.com/pycom/pycom-micropython-sigfox/issues/68

@gas hello Gas, loraserver and mainflux is installed in your Pi or in your computer did you use postgres? thank you in adavnce Maamar