LoPy4 433Mhz
-
I've gotten my nano gateway and a node working on 868Mhz, but I want to run this on 433 Mhz. I can seem to put the gateway in 433Mhz but the node just refuses to connect when I set its frequency to 433. Does the firmware support that yet? I only see EU868 region and the docs don't seem to cover using 433 at all.
If anyone has gotten this working I'd love to see an example of the OTAA node.
-
@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.
-
@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.
-
@robert-hh I still don't understand where the delay is coming from. 30ms is an awful lot for a task switch.
-
@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 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.
-
@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!
-
@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 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 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.
-
LORIOT public LoRaWAN server do supports EU433 band plan. Registration is free, no credit card:
-
@jmarcelino No I was trying to use the things network server but it also only has EU868 plan currently.
I switched the standard NanoGateway frequency over to 433 and it claimed it was using that. I could also see intermittent spikes from the gateway ping on my scope 125khz down from the center. It seemed only the node had no obvious means to select 433.
I will look around for some alternatives to the Things Network servers and do some more reading about how the protocol selects its frequency.
-
@colinza
Do you mean you have a 433Mhz gateway? I don’t think you can just change a 868Mhz unit to run in 433, the front end chips are different.For 433Mhz you also need a network server with a 433 bandplan. Which network server are you using?
