@john You need to register a LoRa callback to work with the acknowledgements, i.e.: lora.callback(LoRa.TX_FAILED_EVENT, handler=YourHandlerFunction, arg=None) "If the ack is not received LoRa.TX_FAILED_EVENT will be raised after the number of tx_retries configured have been performed."

@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.

I have not had too many issues with the PyMakr plugin for atom. But I can understand if you do not like that setup. At least with more recent version of the plugin (November is the last I used it heavily), I did not have problems. What I remember annoying me the most was not being able to copy from the REPL. rshell is also a good option when you have a physical serial connection https://github.com/dhylands/rshell

@livius Thanks, that is now working. I am getting [] while everything is working, and it seems to say "None" just before a "Board not detected" error. No change on anything when receiving an I2C bus error message. @ledbelly2142 what do you mean by checking the pins? I've gone as far as removing the LoPy from the Pytrack and having a look haha, but it looks like normal pins to me. Hope everyone had a good Christmas and New Years

@rcolistete thanks for the clarification :D

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 :-)

This looks like the example from 5.3.6 rather than 5.3.4 You can get the most up2date version from our GitHub repository. The easiest way is to download an archive of the most recent version and then open the directory examples/lorawan-nano-gateway/ in either Visual Studio Code or Atom, modify config.py and upload the code to the board.

I'm registering my interest in AS923 support. Many of the telcos in AU and NZ are implementing AS923 and will not support devices based on LoPy in its current state of affairs. We're going to have to ditch the LoPy and go with muRata or Multitech modules unless the firmware is updated to give more control. Is this on the cards?

Thanks @daniel and @robert-hh and thank you for the offer of support and potential of modifying code base. I decided to use a PCA8575 16 bit I2C I/O expander as it solved the I/O problem without adding too much to the bill of materials, so I left the SPI pins for the Lora/Sigfox radio not connected.

@seb thank you

@gertjanvanhethof I find rshell even easier to than ampy. Once rshell has launched, connect with: > connect serial /dev/ttyACM0 115200 By the way, ACM stands for «asynchronous communication mechanism».

Problem..solved due to your suggestion!

@iber That's normal because it's not really a buffer, Bluetooth LE characteristics are usually restricted to 20 bytes by the protocol - it's what fits in the BLE packet - so unless you negotiate a larger MTU (larger packets than standard) between peers or use Long attributes you are restricted to that amount. Neither of those extended techniques are currently supported.

@jeromemaquoi yes, you got 'done' if on the destination side port is open and something is listen