[Brian Wyld]

Ok Jason, thanks for the info.

We’ll take a look at the code but not sure if we’ll be able to do this now…

[Brian Wyld]

Hi Jason,

Does this mean that there is no way in the latest LNS to use the old functionality (it seems from the logs its still working as before)?

Or is it the new pkt-forwarder that is blocking the emission?

Is there any way for us to use a new hardware module, but have the existing functionality?

thanks

Brian

[Brian Wyld]

ok good luck!

Brian

[Brian Wyld]

Hi William,

Yes, we’re still using OpenVPN to connect our conduits (actually mLinux versions now) to our backend cloud. We’ve a collection of scripts now for install and running this with watchdogs, monitoring etc that mean its pretty reliable…

And yes, a firmware upgrade still overwrites OpenVPN. This isn’t a biggy as we dont have many firmware updates in the field… especially as we use a backend loraserver LNS these days rather than the built-in LNS…

A+

Brian

[Brian Wyld]

Hi Brandon,

No, I stil have no idea why the rssi values appear to show that the gateway hears the mdot better than the other way around…

I haven’t retested with the new gateways I received to see if they have the same behaviour…

Brian

[Brian Wyld]

Just to update this thread with my ‘final’ config.
1/ I gave up on nodeRED, the https issue was too hard and the ‘real-time’ness too little.

2/ To get the upstream lora datagrams, I listen on my remote machine (via a openVPN tunnel) for UDP on a specific port (192.168.5.7, port 16000 in this example) and run nc on the MTCT:
# nc -u -n -p 1784 -L 192.168.5.7:16000 &
[actually I incorporated a startup script into the /etc/init.d/lora-network-server start/stop script to make it come up automatically!]

3/ To send downstream datagrams, I enabled the lora-network-server listening on all IPs (add attribute”allowPublic”: true to object “udp” in the lora-network-server.conf), and then send UDP packets to the port 1786.

The UDP packets rx/tx are a very useable ascii format (MQTT?) as described in the getting started docs.

A+

[Brian Wyld]

Just to update this thread in case anyone else is wanting to use the beaconing feature (VERY useful to time sync many endpoints together even if you’re not trying to use classB)
With release 0.0.9 of the lora-network-server, you can enable beaconing by adding the following config to the lora object in the JSON (edit /var/config/lora/lora-network-server.conf for mLinux, use the http put option for AEP);
“netID”:”040000″, “beaconDelay”: 0, “beaconInterval”: 128, “beaconPower”: 26
Note:
– The netID should match the top 3 bytes of the device address range (“addressRange” object) to be consistant.
– the beacons sent are US format (even on an EU configured gateway) : should be fixed in next release I am told)
– the time at which they are sent is NOT sync’d to 1/1/1970 00:00:00 as per the spec but from the process start time (this should be fixed in next release also)
– the transmission time uses the linux clock, not a GPS input clock.

Hope this might help!

Brian

[Brian Wyld]

Hi Jason,

I opened 5067328 and 5067329 for the ‘tx’ and ‘timestamp’ issues.

Thanks

Brian

[Brian Wyld]

Hi Jason,

I’ve upgraded to 0.0.9, no particular issues, but no fixes for my problem of ‘no tx’….

My main problem is that I’m really stuck here without having the ‘time’ attribute coming through from the pkt-forwarder into the decoded /up stream. I can’t get my application to sync up its objects without this….

Is there a way to get a fast-tracked build of lora-network-server with this feature?

thanks!

Brian

[Brian Wyld]

Ok thanks! I’ll see if that fixes my ‘delayed downlink’ issue…

A+

brian

[Brian Wyld]

Ok.. Added to the requests about the management of the tx queue I guess I can make a list…

I’d like to update to 0.0.9. I see the release notes,but I can’t see the package (latest referenced on the downloads page is 0.0.8). Can you give me the good url for the package please?

thanks

Brian

[Brian Wyld]

Hi Jason,

It’d be much nicer if the network-server just passed on the ‘time’ attribute from the pkt-forwarder as the rx time : more accurate and closer to the radio reception…

I’ve been trying to use the tmst value together with the timestamp to get a more accurate timestamp, but now I’ve discovered that the drift in the tmst value is very high : something like 15-25ms per minute! I was trying to use this to sync my objects to 1-2ms precision, but this kind of drift makes that impossible…

Any ideas on how to get a 1 or 2ms precision rx timestamp on these packets?

thanks

Brian

[Brian Wyld]

Hi,

In fact I’m not sure that its really the duty cycle being exceeded. I understand that a gateway is allowed up to 10% utilisation on the RX2, but often the data doesn’t get send until the 3rd uplink packet!

How can we debug this?

thanks

Brian
PS. our lora-network-server is version 0.0.7, I’ll try updating it also.
PPS. I’d really like it if the ‘timestamp’ attribute as send up by the network-server was just copied from the ‘time’ attribute in the pkt-forwrder json : this give a ms precision value and closer to the actual radio reception time! Any chance of this?

[Brian Wyld]

Hi Jason,

This seems to be ok. However, I note (using tcpdump on the ports 1780-1786) that on occasion the lora-network-server gets a downlink packet from my application ‘in-time’ to send it to the pkt-forwarder for transmission in RX1/RX2, but that it doesn’t send it on to the pkt-forwarder (no UDP packet on port 1782)… and that it can take another couple of uplink packets before it decides to send it to the radio…

What could be the reason for this? Is the gateway also held to limited channel usage, or is there something else? Any logs that I can look at to see why the downlink packet doesn’t get sent?

thanks

Brian

[Brian Wyld]

Thanks Jason, config ok!

[Brian Wyld]

Thanks Jason for the confirmation. I hadn’t seen your response before posting my own conclusion!

This is ok for us now…

[Brian Wyld]

Ok, thanks Jason. I’ll give that a go.
For the future, having a “queueFlush”:true attribute in the downlink data message to force flush of the existing queue would do the job for me…

thanks

Brian

[Brian Wyld]

I see in the lora-network-server config field called “nodeQueueSize” which is set to 16. Is this the queue for the downlink messages waiting for the node?
If I set it to 1 will that mean that only the most recent downlink message will be kept?
Can I set a flag in the downlink json (like for the port, ack etc) to flush or control this queue?

thanks

Brian

[Brian Wyld]

So.

Finally, it seems like:
– the value for the rx2Datarate configured in the lora network server is ONLY for the RX2 window for responses to uplink packets. It is NOT used for the JOIN response.
– there is no means to configure the channel/SPF used for the RX2 window for the join response (its set to the default in the LoraWAN spec and is not changable.

So, setting my reception of the join response for RX2 to be always SPF12, and that for the rx2 for the data packet reception to be the value returned in the join response, all is OK…. just a bit confusing….

Brian

[Brian Wyld]

The ‘long block’ is because the response is encoded as SF12 which has a much lower bit rate than the SF9 (the other responses) and which also explains the ‘spread’.
[and which obviously explains why my endpoint doesn’t see the join response : its waiting for a SF9 encoding!]

So my question for support : why is the MTCT (sometimes) using SF12 for responses in the RX2 window, when in the AEP configuration I have explicitly specified SF9?

Is this a bug in the lora-network-server? Seems like this would explain a few of the problems I see on the forum about not receiving join responses….

thanks

Brian

[Brian Wyld]

Ok, thanks.
Looking at the code of the pkt_forwarder, it seems that it creates a timestamp to ms precision (‘time’) in the packet it forwards. However, the lora-network-server doesn’t pass this data on after it has processed the packet?

thanks

Brian

[Brian Wyld]

Hi Jason,

I’m trying to use the tmst value : what units is it? ms? uS?
The ‘info’ for the lora rx object in nodeRED says just
“Internal timestamp of “RX finished” event (32b unsigned)”

thanks for any info on this…

Brian

[Brian Wyld]

Hi,

Ok… Any reason why the tmst value is not just ms since epoch? Any chance it could be?

Brian

[Brian Wyld]

Can’t find a pre-built package with socat (hint hint)…

Using nc works but isn’t very stable (as nc tends to exit if there is any network up/down type activity…) ie:
# nohup nc –udp –listen –local-port 6227 | nc –udp localhost 1786 > /tmp/maas_pkts_down.log 2>&1 &
# nohup nc –udp –listen –local-port 1784 | nc –udp 192.168.5.7 16227 > /tmp/maas_pkts_up.log 2>&1 &

(this listens for downstream packets arriving on 6227 from my server, and sends it upstream packets to 192.168.5.7:16227…)

Anyone got anything better? Any way to configure the lora-network-server to accept/sendto an IP other than 127.0.0.1?

thanks!

Brian

[Brian Wyld]

Ok… could do C++ but its a pain…

Is there a package containing the utility ‘socat’ for the Conduit?
(coz then I can just bridge the lora UDP packets to/from the lora network server out to my remote cloud…)

Supplementary question : does nodeRED attach to the Lora subsystem by listening on the ‘appPortUp’ and sending to ‘appPortDown’? ie if I bind a UDP listener to appPortUp (1784) will this break the connection to nodeRED?

thx

Brian

[Brian Wyld]

Hi,

I think I’m going down the ‘bridge mosquitto to my MQ’ route.
I think this means creating a MQTT client on my Conduit, that connects to my central server (handling the inevitable ppp downtimes…) and sends the messages, rather than a multi-mqtt client on the central server that connects to all my Conduits…

I’m thinking of creating this mqtt client in java to be able to run it on the Conduit – any reason not to do this?

cheers
Brian

[Brian Wyld]

Ok…. I also unscrewwed and re-screwed the antenna : this boosted the signal from around -13 to -5 (as seen by conduit):
at+ping
-13,7.2
at+rssi
-40, -84, -17, -36

at+ping
-5,6.8
at+rssi
-19, -84, -17, -33

at+ping
-5,6.5
at+rssi
-20, -84, -17, -31

at+ping
-3,7.5
at+rssi
-22, -84, -17, -30
at+ping
-4,7.8
at+rssi
-20, -84, -17, -29

at+ping
-5,6.2
at+rssi
-13, -84, -13, -28

at+ping
-5,6.2
at+rssi
-20, -84, -13, -27

at+ping
-13,9.0
at+rssi
-40, -84, -13, -28

As you can see, the Conduit still ALWAYS see the mdot with a better DB than the other way! Also, the db does seem to change for no apparent reason (the change from -5 to -13 had no change to the physical conditions….)

I also tried without the Conduit’s antenna at all:
AT+PING
-67,8.0
AT+RSSI
-84, -84, -17, -51

Same inversion of the powers…

Not sure what’s going on here….

Brian

[Brian Wyld]

Hola,

Got my replacement gateway lora card today. No problems to replace the old one.

However… not sure how to interpret the results of retesting with AT+PING/AT+RSSI…
—-
at+ping
-15,5.5

OK
at+rssi
-25, -26, -23, -25

OK
—-
This appears to still say that the gateway is seeing the mDot packet better (-15db) than the mDot sees the gateway’s packet (-25db)…. but both have the same antenna, and the mDot is at 20 power, gateway at 26!

ze mdot config:
Tx Frequency: 0
Tx Data Rate: SF_12
Tx Power: 20
Tx Wait: on
Tx Inverted Signal: off
Rx Frequency: 869525000
Rx Data Rate: SF_9
Rx Inverted Signal: on

any ideas?

[Brian Wyld]

Well,
# run-parts /etc/ppp/ip-up.d
ran my openvpn-start script when invoked by hand (once ppp was up)
But it hadn’t been run automatically when the ppp came up!

Where should the run-parts call be happening? I am probably a bit thick here, but when I look at the ip-up script (/etc/ppp/ip-up) I see no call to run-parts!
Or does pppd do it directly?

thanks

[Brian Wyld]

AH yes, and the reason to start/stop the openvpn tunnel in sync with ppp, is to be able to run the iptables command in the openvpn script to allow in/out traffic thru it!
iptables -A INPUT -i tun0 -j ACCEPT
(in start_vpn())

Brian

[Author]

Posts