-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Continue refactor and testing of the code #15
Comments
Good to re-sync files. Receiver still not working, I will check that I am getting interrupts from the RFM96W. |
|
Getting interrupts from the RFM96W. The callback doesn't seem to be triggered. |
Possibly in this section: if packet_len >= 4:
header_to = packet[0]
header_from = packet[1]
header_id = packet[2]
header_flags = packet[3]
message = bytes(packet[4:]) if packet_len > 4 else b''
if (self._this_address != header_to) and ((header_to != BROADCAST_ADDRESS) or (self._receive_all is False)):
return
if self.crypto and len(message) % 16 == 0:
message = self._decrypt(message)
if self._acks and header_to == self._this_address and not header_flags & 0x80: # FLAGS_ACK = 0x80
self.send_ack(header_from, header_id)
self.set_mode(MODE_RXCONT)
self._last_payload = namedtuple("Payload",
['message', 'header_to', 'header_from', 'header_id', 'header_flags', 'rssi', 'snr']
)(message, header_to, header_from, header_id, header_flags, rssi, snr)
if not header_flags & FLAGS_ACK:
self.on_recv(self._last_payload) |
I see logic changes on lines 273 and 279, so over to you! |
with from utime import sleep
from lora_rfm95 import LoRa
from umachine import Pin
MODE_RXCONT = const(0x05)
# Lora Parameters
LORA_POW = 12
CLIENT_ADDRESS = 1
SERVER_ADDRESS = 2
# This is our callback function that runs when a message is received
def on_recv(payload):
print("From:", payload.header_from)
print("Received:", payload.message)
print("RSSI: {}; SNR: {}".format(payload.rssi, payload.snr))
# WeAct Blackpill STM32F411: We use SPI2 with (NSS, SCK, MISO, MOSI) = (Y5, Y6, Y7, Y8) = (PB12, PB13, PB14, PB15)
from pyb import SPI
spi = SPI(2, SPI.MASTER, baudrate=500_000, polarity=0, phase=0) # SCK=PB13, MISO=PB14, MOSI=PB15
# WeAct Blackpill STM32F411: We use SoftSPI
# from umachine import SoftSPI
# spi = SoftSPI(baudrate=100_000, polarity=0, phase=0, sck=Pin('PB13'), mosi=Pin('PB15'), miso=Pin('PB14'))
cs=Pin('PB12', Pin.OUT, value=1)
pirq=Pin('PA8', Pin.IN)
res=Pin('PA9', Pin.OUT, value=1)
led=Pin('PC13', Pin.OUT, value=0)
lora = LoRa(spi, cs=cs, pirq=pirq, res=res, addr=SERVER_ADDRESS, modem_config=LoRa.Bw125Cr45Sf128, tx_power=LORA_POW)
# set callback
lora.on_recv = on_recv
# set to listen continuously
lora.set_mode(MODE_RXCONT)
# loop and wait for data
while True:
sleep(0.1) and not only the |
If the client script has while True:
led(1) # led off
lora.send('Test msg', SERVER_ADDRESS)
# lora.send_to_wait("This is a test message", SERVER_ADDRESS)
print("sent")
sleep(1)
led(0) # led off
sleep(1) in the loop then I get the received message every time the message is sent. |
changed Every second time ... maybe as per Barry Hunter's comments change to |
Is normal operation for it to return? if (self._this_address != header_to) and ((header_to != BROADCAST_ADDRESS) or (self._receive_all is False)):
return |
With the original |
I put the driver and server and client file here: Note some cosmetic: Now the modes # Operating modes
MODE_SLEEP = const(0x00)
MODE_STDBY = const(0x01)
MODE_TX = const(0x03)
MODE_RXCONT = const(0x05)
MODE_CAD = const(0x07)
LONG_RANGE_MODE = const(0x80) may be used from outside as in Hope you have success with that. |
One coding question, what does: |
These are two instructions (may be on two lines without the separating |
Barry Hunters changes are all in already. |
Ah, I had to comment-out the assert for the transmitter to work. |
Should not be necessary any longer. I feel I have to start learning about LoRa by now ... |
O dear, had to comment-out the assert in the receiver and also not seeing any interrupts. |
In line 260 If you have to comment out the assert to avoid the "LoRa initialization failed" message, then there is a SPI communication problem. That may also be responsible for the receiving not happening. ??? |
Sorry, I need to modify lora_rfm95.py to 433MHz. I am barely keeping-up! |
No problem, but how about the SPI issue? That will not change. |
I needed to re-assign the pins in server and client to what I was actually using! Also, changed to SoftSPI and "wahoo" the signal appears at the receiver!!! I believe I have the latest version out of the .zip file. I must get rid of the hundreds of unwanted "ulora" file around. Assert statement back-in and all seems good. Stress-testing underway while I relax! Because of strange SNR readings at low signal levels I put this in the server: def on_recv(payload):
if payload.rssi < -120:
print('RSSI is below -120dBm')
else:
print('From:', payload.header_from)
print('Received:', payload.message)
print('RSSI: {}; SNR: {}'.format(payload.rssi, payload.snr)) Did you read through https://github.com/micropython/micropython-lib/tree/master/micropython/lora |
I still think that there is some critical timing issue before the |
Congratulations. I will have to go to sleep now. |
For 800MHz I would use a 1/10 or 1/4 watt 47 or 56 Ohm resistor with leads about 3mm long, ie as short as possible. |
We can start testing more functionality tomorrow. I have the feeling the requesting acknowledgements does not work. |
If I guess there is an error due to it happening from within the RX interrupt callback while needing another TX interrupt. If you want to investigate: here are the files with many debugging print statements. |
I noticed both of his examples had The comment about longer My testing with sf=2048 has been rock-solid. Unfortunately, I am left wondering why your code runs on both platforms and yet the original ulora failed on one platform. I will have a look but interrupts are not one of my strengths. |
This is because the SPI configuration is outside the class/module as it should be. |
I only have one USB cable that will plug into a WeAct dev board :( So, I can't run two terminal programs. Will try to make-up a cable. Can you explain why SPI fails when it is in the class? Is the rule: send() with no acks and send_to_wait() with acks. No other combinations possible? |
Got it connected, modified pin assignments and have both RX and TX running. Things appear to be working to the untrained eye. I see acks sometimes on the first send_to_wait() but mostly on the 2nd send_to_wait(). I see a lot of `no cad detected' |
TX sent 112
int_cad_done: no cad detected
send_to_wait attempt 1
int_tx_done
int_cad_done: no cad detected
send_to_wait attempt 2
int_tx_done
int_rxcont packet id:113 from:2 to:1 req_ack:False ack:True
got ack RX: int_rxcont packet id:23 from:1 to:2 req_ack:True ack:False
wait_ack_packet_sent: timeout at id 23
From 1:
Received: b'Test message with ack 23'
RSSI: -102.13; SNR: 9.25 |
An observation ... I forgot to change to 433MHz in lora_rfm95.py and the transmitter initialises and appears to send data to who knows where. Maybe, having |
Same here. |
Just an idea to test with: And in client maybe increase the time between sends: while True:
led(0) # led on
# Here we send just a test message. Packets ar>
# lora.send('Test message {}'.format(i), SERVE>
# Here we send a test message with request for>
lora.send_to_wait('Test message with ack {}'.f>
print('sent {}'.format(i))
i += 1
sleep(1)
led(1) # led off
sleep(4) # to allow for 4 retries In testing with Wei's LoRa code https://github.com/Wei1234c/SX127x_driver_for_MicroPython_on_ESP8266/tree/master I found that I had to put say a 1 second delay between sends to allow the receiver to process the message. Maybe, that is what the whole retry timeout thing is for. Good luck. |
Updated a comment on the original thread about using a resistor for the antenna load. What I showed in the picture is barely appropriate even for 433MHz, Suggest a 47 to 56Ohm 0805 SMD resistor soldered between the ANT and adjacent ground pin. Also, run the TX power at minimum until you get a good antenna on the unit. I use this cable cutting off the IPEX connector. Drop this into Aliexpress search: |
This video shows what I will probabably try in the end. |
That is one way. I cut off about 5-6mm of the outer telfon off, flow solder on the braid, then cut off say 3mm of braid, wrap thin copper wire around the braid (instead of making pig-tails), solder it, and then cut 1-2mm of the inner Teflon off to expose the inner wire and "tin" that. The braid (with the wire wrapped around it) is soldered directly to ground. I have been running send_to_wait() most of day and seems to work for me. I have 1 second timeouts and using Sf=2048. If you are sending a long message at a high Sf do you not need longer timeouts?
|
If you give me a screenshot of the unwanted behaviour that you are seeing it would help to focus my attention. Testing down near the -120dBm level with As per question 2)
My typical use case is sending brief messages, say once an hour and over long distances. Power source 1 * 18650 cell and 1W PV panel. 1-4seconds every hour with the STM32F411 going to deepsleep seems a good solution. |
There is a lot of processing in |
Tomorrow I will give a description. Also my feeling is now that systematic testing is needed. All this is about Here is the new version, also with little cosmetics/renaming. Hope you get a grip on the different reports and the problem. |
Wow, I can see you have put a lot of work into this. Are you wanting to use send_to_wait () to get higher message reliability? I have managed with just testing the received message at the server, even for messages with small value changes in them. Here is what I see: Client: set CAD mode
int_cad_done: no cad detected
send_to_wait attempt 1
int_tx_done
int_rxcont packet id:165 from:2 to:1 req_ack:False ack:True
got ack
sent 165 Server: other interrupt: mode: 3, irq_flags: 0x4
int_tx_done
int_rxcont packet id:165 from:1 to:2 req_ack:True ack:False
send ack to 1 at id 165
set CAD mode
wait_cad: timeout
From 1:
Received: b'Test message with ack 165'
RSSI: -105.33; SNR: 8.25 So, the problem is the I am off to the "Big city" for a few days so things will be quiet from my end. |
Is the real problem: |
Also, the server setting CAD mode after sending an ACK doesn't seem right. CAD mode is only set when doing a send. I am confused. Does the server need to send a dummy TX to get it into CAD-mode? |
Thanks, this may be the solution. Although in principle this should be possible with WAIT_CAD too.--Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.Am 29.10.23, 07:55 schrieb Dave Festing ***@***.***>:
Also, the server setting CAD mode after sending an ACK doesn't seem right.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>
|
My current understanding ... a point to point link returning an |
I just tried the micropython-lib SX1276 version of reliable sending and receiving. Got sender and receiver to run, but there was no communication. I will have to repeat this with the SX1276 boards that I got yesterday (another run of soldering). |
I found when testing Wei's send/receive that I had to put a short delay after a tx. I think 250ms was OK, but I put in 1 second delays. |
Just an observation ... The timeouts (wait_packet_sent_timeout_ms, retry_timeout_ms and maybe cad_timeout_ms) seem to need tweaking depending on MODEM_CONFIG. Maybe message length is another variable. I see in the micropython-lib lora that there is some timeout adjustment around line 729 |
@rkompass The main issue I am facing is that my sensor links using Wei's code may send a corrupted message, but at least an hour later it tries again ... so the odd missed data is not a problem. On a LoRa control link "missed messages" are a problem. In Have you made any further progress? |
@davefes I saw that you posted the same observation on MP discussions. Cannot solve it at the moment, but will solve it later. |
Appears that any "PA switching " that takes place is turning the whole TX on/off, as well as any possible antenna port selection. |
@davefes: I continue here from our micropython discussion:
I got the module connected. No SPI problems. Had to correct my code again (still little flaws:)
lora_rfm95.py
:and
As it seems I have to solder another module (got 5) for receiving.
The text was updated successfully, but these errors were encountered: