LoRaWAN - Return downlink destination port
-
Please make destination port of LoRaWAN downlink message available for the applications. One possible way to introduce a new method. e.g.
socket.recvto(bufsize)
which return a tuple (port, data)
-
I think I prefer to add the recvfrom method and return the port there, seems more natural. The stats() method doesn't feel like the right place as it's meant for low level info of the LoRa stack.
-
@jmarcelino said in LoRaWAN - Return downlink destination port:
@bmarkus
Sure it's useful to show it as part of the protocol, I'm just questioning if it's as "mission critical" for applications and worthy of comprising the socket abstraction ideal..How about adding it to the tuple returned by lora.stats() as @jcaron suggested?
Return a named tuple with useful information from the last received LoRa or LoRaWAN packet. The named tuple has the following form: (rx_timestamp, rssi, snr, sftx, sfrx, tx_trials)Seems like a good fit?
It can work also...
-
@jcaron said in LoRaWAN - Return downlink destination port:
@bmarkus given the limitations for downlink messages in LoRaWAN (at least in the ETSI region) I haven't played with it yet, but shouldn't you simply open several sockets, each bound to a different port?
I expect using multiple ports would consume more RAM and not too much sense to use it for a feature used once in a day or week.
-
@bmarkus given the limitations for downlink messages in LoRaWAN (at least in the ETSI region) I haven't played with it yet, but shouldn't you simply open several sockets, each bound to a different port?
Though I agree with @jmarcelino : I'm not quite sure what scenarios would benefit from multiple ports in a single script.
-
@bmarkus
Sure it's useful to show it as part of the protocol, I'm just questioning if it's as "mission critical" for applications and worthy of comprising the socket abstraction ideal..How about adding it to the tuple returned by lora.stats() as @jcaron suggested?
Return a named tuple with useful information from the last received LoRa or LoRaWAN packet. The named tuple has the following form: (rx_timestamp, rssi, snr, sftx, sfrx, tx_trials)Seems like a good fit?
-
Well, there is always a workaround. But if it is part of the LoRaWAN Specification, available using other LoRaWAN modules but not in LoPy it makes LoPy less attractive. Isn't it better to make it available?
We don't have to find a way how to hack it, as the developers of LoPy are here.
-
@bmarkus said in LoRaWAN - Return downlink destination port:
but applications need to know destination port, otherwise LoPy is limited in use.
Excuse my ignorance, but is there a benefit to using LoRaWAN Frame Port numbers in an application ( i.e. other than 0) versus sending something equivalent as part of the payload (for example first byte)?
Yes it wastes one byte but on the the other hand data sent inside the payload is encrypted while the header/Frame Port isn't so you could be exposing application functionality patterns by using it.
-
Guys, it has nothing to do with debugging, port is used on the similar way as for IP/UDP e.g. We have sensors where applications are controlling different processes and parameters of the sensor similar to TCP/IP where port 22 is assigned to SSH, 21 to FTP, 22 to TELNET, etc.
Compatibility and portability is a great goal, but LPWAN is so different to other networks with special characteristics. Now the question is how to get it. In the ordinary environment socket is bind to a destination port but it doesn't fit to the current API. Closest is the socket.recvfrom() which returns data and source IP/port.
Anyhow, it can be implemented on a different way, but applications need to know destination port, otherwise LoPy is limited in use.
-
@jmarcelino I think it also goes against the traditional use of sockets which are bound to a port before sending/receiving.
However, I understand there could be a use case for this (especially for debug purposes -- given @bmarkus previous posts I would not be surprised if that were his motivation).
One thing that would probably help a lot would be a flag to enable debug info to be displayed. Another option could be a "raw" socket which delivers the whole packet rather than just the payload (a bit like what is used for tcpdump). Another option still would be to add the port in the data returned by the
stats()call?
-
It is a good idea but feel the whole point we have a sockets abstraction is to make the code as interchangeable as possible between WiFi, LoRa, Sigfox, NB-IOT.
Ideally you'd take the code for one network and - within reason, for example if you keep within some maximum common denominator re packet sizes and fixed connection setup stuff - it would work on another network.
If we start "polluting" basic functionality like send and receive with LoRa specific attributes we might as well get rid of the socket abstraction altogether as a LoRa specific class would do a better, cleaner, job.
But this is just my (current) opinion of course and open for discussion :-)
