LoPy4 433Mhz
-
LORIOT public LoRaWAN server do supports EU433 band plan. Registration is free, no credit card:
-
@bmarkus Hello, there is an indication that you have an active role in the Loriot network. I just tried the node/nanogateway pair at EU433 in the Loriot net. It worked instantly, at least for abp_join and uplink messages. I did not try OTAA yet. I've observed two things with Loriot:
- for everey uplink message there is a downlink message, which is however not reported by the node. Should it, or does it just contain management data?
- When trying to use the RX2 window, the server supplied the wrong frequency, 869525000 Hz instead of 434665000 Hz
b.t.w.: With some tweaking of the nanogateway (setting the downlink frequency manually), I could get it also working with TTN, including downlink messages.
-
@robert-hh said in LoPy4 433Mhz:
@bmarkus Hello, there is an indication that you have an active role in the Loriot network. I just tried the node/nanogateway pair at EU433 in the Loriot net. It worked instantly, at least for abp_join and uplink messages. I did not try OTAA yet. I've observed two things with Loriot:
- for everey uplink message there is a downlink message, which is however not reported by the node. Should it, or does it just contain management data?
- When trying to use the RX2 window, the server supplied the wrong frequency, 869525000 Hz instead of 434665000 Hz
b.t.w.: With some tweaking of the nanogateway (setting the downlink frequency manually), I could get it also working with TTN, including downlink messages.
Hi Robert
your observation is right, I'm a LORIOT person. I see you have an active account on the EU1 server, thank you for using 433MHz, there are not many users for this band.
I can confirm wrong RX2 downlink frequency, will fix it. Thank you for reporting.
If your uplink is not asking ACK, there are two reasons for downlink MAC commands
- ADR is enabled at the device and Network Server is sending ADR settings, but ADR is disabled in your device
- Network Servers is polling device for Battery level and Device SNR
Regards... Béla
-
@bmarkus It seems that the RX2 window at the Loriot server is now configured with the right parameters. Both RX1 and RX2 setting work.
The problem which remains is the unreliable timing of the LoPy4 and other xxPy device. I see a delay variation of up to 30 ms between the scheduled time and the time the transmission actually starts. I assumes earlier that this is a constant delay, but is is not. So working with RX2 and slow data rate is more reliable, since the receive window is much longer, at least 160 ms. At faster data rates like DR5 the receive window ist just about 10ms long.
The reason for that sloppy timing is the communication between the LoRa API frontend and the LoRa Task, which is through a message queue. I do not know how its timing can be made dependable. -
@robert-hh said in LoPy4 433Mhz:
@bmarkus It seems that the RX2 window at the Loriot server is now configured with the right parameters. Both RX1 and RX2 setting work.
Thanks for the confirmation!
-
@robert-hh said in LoPy4 433Mhz:
The reason for that sloppy timing is the communication between the LoRa API frontend and the LoRa Task, which is through a message queue. I do not know how its timing can be made dependable.
Just an idea: Would it be possible to schedule the response earlier and busy wait until the right time? Additionally the LoRa task priority could be raised during this time to prevent other tasks from interrupting.
It would not be optimal, because the device would be somewhat unresponsive for this time period, but as far as I understand it, it is pretty much unusable at the moment. -
@sympatron This early scheduling is already done at the Python level, but not in the LoPy thread. And then, the time of intended transmission has to be put into the queue too (less of a problem), and the queue has to be ordered by the time of transmission. I did not look into the queue mechanism about whether that is possible.
In my tests it was only one message in the queue, so ordering is not an issue. So it's more the task switch which causes the non-deterministic delay. It should be noted, that LoPy 1 seems more deterministic. The difference is a sempahore handling which is part of the LoPy4/FiPy software, but not in LoPy. That may be related to avoid collisions between Flash/SPIRAM access. -
@robert-hh I still don't understand where the delay is coming from. 30ms is an awful lot for a task switch.
-
@sympatron Se also my tests on that issue 4 months ago.
https://forum.pycom.io/topic/2924/solved-lora-timing-of-lopy-and-fipy
It should be noted that at this time I did no test it with a LoPy4, just with a FiPy. But the code sections in question are the same. -
@bmarkus Hello Bèla. I now tested OTAA join. Due to the timing jitter of the gateway, I wanted to use RX2 for the join response. So Ive set that in the device parameters of the Loriot server. But that did not work. The join response appeared in the RX1 window.
Did I expected something wrong from the settings, or just looked at the wrong place?
P.S.: After a few attempts, join also worked at the RX1 window.
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