Welcome to the Pycom forum Forum
    • \[\[global:header.categories\]\]
    • \[\[global:header.recent\]\]
    • \[\[global:header.tags\]\]
    • \[\[global:header.popular\]\]
    • Login

    Explore Pybytes | Official Documentation | Report a Firmware Bug/Issue | GitHub

    Pycom does not transmit when noise floor is too high.

    Scheduled Pinned Locked Moved Discussion
    pycomnoisesx1272rssisnr
    6 Posts 4 Posters 408 Views 5 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • R Offline
      researcher
      last edited by

      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

      R 1 Reply Last reply Reply Quote 1
      • R Offline
        River @researcher
        last edited by

        @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

        1 Reply Last reply Reply Quote 0
        • E Offline
          Eric73
          last edited by

          @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
          
          R 1 Reply Last reply Reply Quote 1
          • R Offline
            researcher @Eric73
            last edited by

            @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

            E 1 Reply Last reply Reply Quote 0
            • E Offline
              Eric73 @researcher
              last edited by

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

              1 Reply Last reply Reply Quote 1
              • G Offline
                g0hww
                last edited by 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.

                1 Reply Last reply Reply Quote 1

                Hello! It looks like you're interested in this conversation, but you don't have an account yet.

                Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.

                With your input, this post could be even better 💗

                Register Login
                • 1 / 1
                • First post
                  Last post

                Pycom on Twitter

                Pycom