Weird LoPy behavior observed with Spectrum Analyzer
Today I have did some testing: Node: FiPy ABP transmitting a byte, blink immediately led for debugging after sending, listening for receiving, repeat every 10 seconds.
Both connected end to end with a coaxial wire (no antenna) and the wire also connected to an spectrum analyzer for sniffing with a T connector.
What I observed is strange:
- There are some 8 seconds between the node blinks (sending) and some activity is observed on Spectrum Analyzer.
- There are some 10 seconds between the activity observed on Spectrum Analyzer and the gateway shows that the package was received on internal web-interface.
- Even with direct connection through the coaxial wire, there are wide values of RSSI from -6 to -117.
- Even that, there are some packages that never are received (or shown as received) on gateway web interface.
Help! I need somebody....
Dear @robert-hh ,
Thank you so much for your continue help! All your advice have been very useful for me. I hope this thread helps somebody else to save time.
With best regards
@barillaro That's very good. Any my comment was also directed at the community, if someone notices a similar behavior.
B.T.W: It shows the "batch" processing of the human (or at least my) brain, that some question still stick in background and sometimes a result pops up.
I want to confirm that I have perfect connection between node FiPy and Gateway. As @jmarcelino said, the cause of weird behavior is due channel mismatch.
I tried @jmarcelino's code https://forum.pycom.io/topic/3216/weird-lopy-behavior-observed-with-spectrum-analyzer but it hangs on send() function.
I worked around this deleting all those channels in the node that my gateway is unable to receive. After that, it has been working quote well. When the node is in same room, 6 m distance with L.O.S., RSSI is -23. I can transmit from one building to another with no problems. Of course, RSSI is lower (from -60 to -108). In outdoor, I received packets sent by my node 1 mile away from gateway. 3x further than before.
I still don't know why the code break when I add channels. Also, I haven't checked again with spectrum analyzer. I can confirm that It takes a couple of seconds since the node blinks and the packet is shown in website. I don't know who is the lazy one.
As always, thank you so much for all your support and help!!
With best regards
@barillaro Not that it helps with your initial questions, but I have an explanation for the messages received at a very low level (-117db). That could happen if the node is sending a message on a channel next to one the receiver is listening too. Lets say, the receiver listens at channel 7, but not on channel 8, and the node sends at channel 8. Then still some energy would be picked up at the channel 7 frequency, although at a low level, depending on the channel separation property.
Here is an update of this topic. I found some documentation 1 about frequency used by gateway:
CH0-------------902.3------------- DR0 ~ DR3
CH1-------------902.5-------------DR0 ~ DR3
CH2-------------902.7-------------DR0 ~ DR3
CH3-------------902.9-------------DR0 ~ DR3
CH4-------------903.1-------------DR0 ~ DR3
CH5-------------903.3-------------DR0 ~ DR3
CH6-------------903.5-------------DR0 ~ DR3
CH7-------------903.7-------------DR0 ~ DR3
It also match with the packages received by my gateway. It has received packets in all frequency but 903.0. Although I am not sure that the node is transmitting in that channel.
Anyway, I update the code with @jmarcelino suggestions. It blocks forever at send(msg) function. Any help about it will be appreciated. Here is the source code.
lora = LoRa(mode=LoRa.LORAWAN, region=LoRa.US915,device_class=LoRa.CLASS_C) subband = 1 for channel in range(0, 72): lora.remove_channel(channel) print("[select_subband] Removing channel: ", channel) print("[select_subband] Channels from 0 to 72 removed ") for channel in range((subband-1)*8, ((subband-1)*8)+8): lora.add_channel(channel, frequency=902300000+channel*200000, dr_min=0, dr_max=3) print("[select_subband] Adding channel: ", channel, " freq: ", 902300000+channel*200000) print("[select_subband] Channels added: ") lora.add_channel(63+subband, frequency=903000000+((subband-1)*1600000), dr_min=4, dr_max=4) print("[select_subband] 63+subband Channel added") #lora.join(activation=LoRa.ABP, auth=(dev_addr, nwk_swkey, app_swkey), dr=0) lora.join(activation=LoRa.ABP, auth=(dev_addr, nwk_swkey, app_swkey)) print('Network joined!') blinkDebug(0x00FF00,0.1,5) import socket s = socket.socket(socket.AF_LORA, socket.SOCK_RAW) s.setsockopt(socket.SOL_LORA, socket.SO_DR, 0) cycle = 0 while True: print("Cycle: " , cycle) s.setblocking(True) msg = bytes([0x03]) print("sending ", len(msg),": ", msg ) s.send(msg) blinkDebug(0x111111,0.2,len(msg)) time.sleep(1.0) # make the socket non-blocking # (because if there's no data received it will block forever...) s.setblocking(False) # get any data received (if any...) data = s.recv(64) if len(data) > 0: print ("received ", len(data),": ", data) print(data) blinkDebug(0x0000FF,1.0,len(data)) else: print ("nothing received") stat = lora.stat() print(stat) print("delay 10") time.sleep(10.0) cycle = cycle + 1
@jcaron , I am using RisingHF packet forwarder and web interface. They show valid packets only. Do you know how to see if any invalid packet arrives? I would love to capture everything it sees, even if not valid.
Thank you guys for all your help and support. I really appreciate it.
With best regards.
Or it could be some other distant device you're picking up... Of course it depends what (gateway / network server) is doing the logging, and whether it logs only valid packets or everything it sees (even if not valid).
@barillaro Some note:
I have also a IC880A/RPi gateway running. On that, I receive about 100 packets/hour at -120 to -130 db level with bad CRC. That is just noise, which by chance is detected as being a valie preamble.
I have seen same wide variability of values from -20 to -121 in both scenarios: connecting with antenna 2 to 6 meters and connecting with coaxial wire (without attenuator).
I haven't measured the level on Spectrum Analyzer. I will do it definitely.
Thank you again @robert-hh
@barillaro a rrsi at -121 is close to the noise level. That should not happen with a wire. With two simple antennas at 2.-3 m distance, I see rssi levels around -30 dBi. So I still think there is something wrong with the cabling or connections. What is the level you see at the spectrum analyzer?. That one is expected to be precise.
Thankyou so much for your following up about it.
Yes, I have to set-up the testing environment properly. Also, modify transmitter software as @jmarcelino recommended.
I still wonder why RSSI is so variable, and why RSSI is so low (-121) when it is connected with wire.
But maybe most of these questioning change after second test.
Thank you again for your time and wisdom!
@barillaro At least I believe to understand some of your observations fro the initial post:
a) your test code is sending a message about every 10 seconds
b) the node is set up to send at >> 8 channels, which are randomly chosen by the Lora WAN stack.
c) the HFRising gateway is listening at 8 channels.
d) the spectrum analyzer is set to frequency sweep mode with a suitable frequency range.
- the gateway will miss messages sent on a channel it is not listening on. The average ratio is detects 8 / (number of tx channels). That can be fixed with the method @jmarcelino told.
- the spectrum analyzer will miss quite a few transmissions, because at the the time frame of the transmission it scans a different frequency. That can be fixed by making the sweep time shorter than the message time. You could also send longer messages. You should also synchronizing it with the message sending by creating pulse at an GPIO pin before sending and using that to trigger the spectrum analyzer.
These two effects are not correlated. So what you see is something like one transmitted message at the spectrum analyzer at a frequency, the gateway does not listen too, and 10 seconds later a packet, which is received by the gateways, but skipped by the spectrum analyzer.
So nothing magic, just trouble with the test set-up. Still, direct coupling node and gateway with a coax cable is not good. You will need an attenuation for proper receive levels.
@barillaro 2 Meters shoul dbe OK. With the metal wall, you may have strange effects with reflections. That results in major changes of the rssi level when moving one antenna just a few cm.
I was told than 6 meters were not enough for testing a long range technology and possibly that short distance could be the cause of loosing package. That's why I am asking.
I will try again, every 30 seconds and without waiting for ABP joining.
This places is weird. They have metal rooms for reconfiguring rooms layout.
Thank you again for all your help!
jmarcelino last edited by jmarcelino
Even that, there are some packages that never are received (or shown as received) on gateway web interface.
For US915 and with a RisingHF gateway (and with almost all gateways other than very expensive ones) you need to tell the FiPy to only send on a subgroup of frequencies - usually called the sub-band and set in your gateway configuration.
This is because these gateways can only listen on 8 frequency channels while the LoRaWAN spec for US915 has 72 of them. If you don't you'll lose packets where the FiPy sends on valid frequencies the gateway isn't listening on.
Please add this function and call it appropriately with the subband you have set on the gateway:
def select_subband(lora, subband): if (type(subband) is int): if ((subband<1) or (subband>8)): raise ValueError("subband out of range (1-8)") else: raise TypeError("subband must be 1-8") for channel in range(0, 72): lora.remove_channel(channel) for channel in range((subband-1)*8, ((subband-1)*8)+8): lora.add_channel(channel, frequency=902300000+channel*200000, dr_min=0, dr_max=3) lora.add_channel(63+subband, frequency=903000000+((subband-1)*1600000), dr_min=4, dr_max=4)
@barillaro Yes, 2 meters. I said antennas to avoid overdriving the receiver, and that is the recommendation of Semtech. So that should work also inside your room, if both antennas are inside.
Metal walls? Interesting.
When you said in Weird LoPy behavior observed with Spectrum Analyzer:
Anyway, better use antennas and a distance of at least 2 between sender and receiver.
At least 2... what? meters?
I have a room with metal walls. Do you recommend to try outdoor?
Thank you again.
@barillaro Join with ABP does not require any feedback from the host. It joins always, and the gateway should see the message you send. After sending, you can wait longer than 1 second. The Lora stack will receive the message anyhow.
About the RF set-up: it looks not good in my eyes. At least it should include a reasonable attentuation between sender and receiver. And seeing a 20ms RF burst in the spectrum analyzer could also be tricky. In my tests that only work with triggering the sweep.
First at all: Thank you guys for your faster response.
I can't answer about impedance. I am asking to the RF Guy who helped me to make the test. I can confirm that the T-connector was in the middle of the wire between node and gateway
Node ========TT======Gateway || SA
Here is the source code running on my FiPy. blinkDebug is a function that blink onboard led according to color, repeatance and delay parameters.
lora = LoRa(mode=LoRa.LORAWAN, region=LoRa.US915,device_class=LoRa.CLASS_C) lora.join(activation=LoRa.ABP, auth=(dev_addr, nwk_swkey, app_swkey), dr=0) # wait until the module has joined the network while not lora.has_joined(): blinkDebug(0x110000,0.1,2) time.sleep(7) print('Not joined yet...') print('Network joined!') blinkDebug(0x00FF00,0.1,5) import socket s = socket.socket(socket.AF_LORA, socket.SOCK_RAW) s.setsockopt(socket.SOL_LORA, socket.SO_DR, 0) while True: s.setblocking(True) msg = bytes([0x03]) s.send(msg) print("sending ", len(msg),": ", msg ) blinkDebug(0x111111,0.2,len(msg)) time.sleep(1.0) # make the socket non-blocking # (because if there's no data received it will block forever...) s.setblocking(False) # get any data received (if any...) data = s.recv(64) if len(data) > 0: print ("received ", len(data),": ", data) print(data) blinkDebug(0x0000FF,1.0,len(data)) else: print ("nothing received") print("delay 10") time.sleep(10.0)
Thank you again for your time and help!!
With best regards
@barillaro Additional note: You cannot simply use a T-coonector. That will mess up with the ipedances, assuming that both the Spectrum Analyzer and the RisingHF receiver have a 50 ohm input impedance. If you can set the spektrum analyzer to high impedance, then you may use a T-connector in the path between sender and receiver, but not at an end beyond each of them.
Anyway, better use antennas and a distance of at least 2 between sender and receiver.