Pycom does not transmit when noise floor is too high.

[researcher]

Hello everyone

I was testing on a single channel the effect of having two signals with the same or different "chirp rate", this is in order to check the BER when orthogonal or non-orthogonal Lora signals collide.

In order to re-create a very long LoRa radiolink, I connected a 60dB attenuator array on the Rx antenna, so the LoRa signals get to the receiver at the level of -110dBm, and also I raised up the noise floor using a USRP B210 and some GNURadio blocks to generate gaussian noise. The USRP B210 Tx antenna was very close to the Pycom Rx node, in such way that the SNR of the arriving signal decreased down to -10dB level, or lower.

A very strange thing I noticed is that when the Pycom Tx node was very closed to the Gaussian noise generator, it didn't send any signal. I noticed that the Pycom Tx node seems to "hold on" the signal and it only transmitted after I decreased the Tx Gain on the USRP, which by consequence decreased the noise floor.

I want to confirm if the Pycom devices are sensing the channel and if they sense some energy on the channel (which in this case would be only Gaussian noise) they stop sending signals ... Is this programmed on their LoRa libraries?.

Thanks in advance

[g0hww]

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.

[Eric73]

@researcher You have to build a custom firmware version of pycom firmware and flash it to your board, and comment this line in C file for your test. You have to follow step by step documentation https://github.com/pycom/pycom-micropython-sigfox
The build process can be done under windows or linux without trouble.
I suppose this line is for pymesh usage of lora, Lbt is not used in LoraWan, so comment this will not have other impact other than alllow you to do your test if you dont plan to use pycom loramesh netxwork.

[researcher]

@Eric73

Thanks for your answer.
Is it possible to modify this lines¿? I mean I don't know the implicances but I wonder if there is some way that using a python editor I can't "comment" those lines ... or these files are embeded on the pycom module?

Thanks

[Eric73]

@River said in Pycom does not transmit when noise floor is too high.:

Is this programmed on their LoRa libraries?.

Yes, line 974 in file https://github.com/pycom/pycom-micropython-sigfox/blob/Dev/esp32/mods/modlora.c

               case E_LORA_CMD_TX:
// implement Listen-before-Talk LBT, only for LoRa RAW (not LoRaWAN)
                   if (lora_lbt_is_free()) {
                       // no activity detected on Lora, so send the pack now

[River]

@researcher I'm not an expertise but maybe the problems you're having are because LBT (Listen before talk).
It's possible that this feature is integrated in Lora stack