If I understand this correctly, this is not true CSMA, as the transmissions are inhibited by noise and not signal. It would seem like a better idea if transmission was only inhibited by a signal matching the current LoRa modem configuration. In shared unlicensed spectrum, all "users" must accept interference. There is probably no real motivation to avoid transmitting over "foreign" signals (LoRa or other modulations) that produce some level of energy in the receiver passband of the LoRa transmitter. Furthermore, the blocking signal might act as a "hidden transmitter" and only be detectable at the LoRa transmitter's location and have no affect on the SNR at the LoRa receiver's location. I'm not sure if such an alternative mode of operation is plausible. However, I would like the option to choose whether or not the listen before transmit mode is used, either in a fashion similar to the ability to set a socket into a blocking or non-blocking mode, or as an optional parameter to the socket send() call, for raw LoRa sockets. Come to think of it, perhaps I should have suggested this as a feature on github, but I've already typed it here, so I would be interested in any thoughts on this. Update: feature request on github is here.

Just adding to the answers already here: https://docs.pycom.io/firmwareapi/pycom/network/lora#lora-stats

You can't use TOA I think with any PyCom hardware.

@burgeh As said, I did not investigate the ping-pong example further. I just used it to check, whether the devices work at all. Using the TTN gateway software was more reliable. At least messages form the node to the gateway arrive all the time. You may have a look at the non-TTN gateway example https://github.com/pycom/pycom-libraries/tree/master/examples/loraNanoGateway That one is a litte bit more elaborate and may be a better starting point. I tried it too, and it worked. The code of interest is in the respective main.py files.

@this.wiederkehr Thanks, I will try that later tonight.

@stef I've reported the same problems, but in my case I scan continuously, as the LoPy is USB-powered. https://forum.pycom.io/topic/1255/lopy-stops-detecting-ble-advertisements I very much hope it's not a hardware problem.

@pwest We've found out how. On iBeacon, when you read the data you get an Array. You need to do int(lastHexValue, 16) and then -256. This results in the set TxPower the BLE Beacon has Edit: this site explains very well how the iBeacon protocoll is built, aswell as to where to find the TxPower: http://www.warski.org/blog/2014/01/how-ibeacons-work/

Thank you. I just made a firmware upgrade and now it works as described in documentation. Thanks a lot