[Chris Friedel]

Just wanted to say thanks for all your help on this. It was extremely helpful, and very appreciated.

Have a great weekend.

[Chris Friedel]

Aha! Thanks Jason, I missed that the wider bandwidth for NA downlinks (we are primarily operating in NA, so those are the numbers more interesting to us). I see that in the spec now as well.

Sorry to beat this dead horse, but 7.2.6 lists SF12BW500 (DR8) with a max payload as 33 bytes. (This is suspiciously half of the 66 you mentioned)… 7.2.6 also says you can increase this size to 53 bytes if you will never use a repeater. But I can’t figure out how to get that value to 66. Can you add any other insight into how I can get to that 66 byte number?

Thank you so much for your patience; you have been extremely helpful and informative.

[Chris Friedel]

Jason, sorry, I have one more clarification please.

You mentioned downlinks of 51 bytes for EU and 66 bytes for North America are always possible.

Looking through section 7 of the spec, I can’t figure out where those numbers come from. At SF9BW125 I’d expect EU at 115 Bytes, and NA is 53 Bytes.

Is the downlink being handled in a special way by the conduit that allows for these special sizes? Or am I just misunderstanding the spec?

Sorry for the questions – we want to make sure we get the downlinks right before we ship! Thank you yet again!

[Chris Friedel]

Excellent, that all makes a lot of sense. Thank you.

If I may ask one last question – where / how is the Rx2 datarate configured in the conduit?

Thanks again!

[Chris Friedel]

Hi Jason,
Thanks for the answer above. I’m trying to understand the implications of that answer.

According to LoRaWAN specification:

“The RX2 receive window uses a fixed frequency and data rate. The default parameters are 869.525 MHz / DR0 (SF12, 125 kHz).”

It sounds like Multitech is instead using SF9BW125 by default for the receive window by default? Or do downlink messages have a completely different set of configuration and constraints from uplink?

(Out of curiosity, is this controlled by the network server or the packet forwarder? )

I think the specific concern we’re trying to address is, if a remote device at long distance is only able to uplink at SF10, and SF9 is not enough to send the downlink to the remote, then
a) does that not mean the downlink will never reach a very distant device in this case?
b) if so, then how do we force the network server to use SF10BW125 for the this specific downlink (or if that granularity isn’t possible, downlinks for this remote device).

I’ve found precious little on any of the nuances of downlinks on LoRaWan (in general, or on the network server multitech uses) – do you have any links to documentation or similar that might help us find some of this?

Thank you so much for the help!

[Chris Friedel]

Hi Jeff,

Sorry, things got a little hectic here as well 🙂 I hadn’t been back on the board for a couple of weeks. My apologies.

You’re correct that we can fix this on the user’s PC. However, we were looking more for a solution that was enforced on the Conduit’s side so that someone (either maliciously or accidentally) couldn’t bypass the behavior.

We really haven’t made too much progress with this. If there isn’t anything jumping out to anyone here, I guess it is something that for now we will just put on the back burner.

Cheers,
Chris

[Chris Friedel]

Best answer of the day! Thank you very much 🙂

[Chris Friedel]

Hi Jeff,

Here is a pasteboard of what we’d like to do
http://pasteboard.co/ajW31Efgt.png
(on old IE, you might need to use http://cdn.pbrd.co/images/ajW31Efgt.png)

Forward Filter Rules have been what we’ve been trying to use to accomplish this.

We created a rule:
Source ANY, Destination ANY (CELLULAR interface only), Chain FORWARD, Target DROP

And while this did block forwarding, it also prevented the laptop from accessing anything on the conduit, and it also prevented the conduit from accessing the internet (such as checking into Device HQ, or calling our IoT platform). We ended up having to restore to factory defaults to gain access to the conduit again.

Our assumption was that this filter would only be checked when packets were forwarded from one interface (like ETH0) to the cellular (PPP) interface. But it looks like that is not how IPTABLES works on the conduit 🙂 .

• This reply was modified 7 years, 9 months ago by Chris Friedel.

[Chris Friedel]

Actually, something that came to mind. I believe the AEP presents a restful web API, is that correct? If so, is there a command(s) that can be issued over this api to enable WAN connection to the admin console? This would be an ideal implementation I believe.

[Chris Friedel]

Hi Jeff,

Thanks for the reply.

We went through the DHCP setup as per your suggestion, but I don’t believe the control we are looking for is there.

Essentially, the current issue is that while a contractor / installer (or really anyone with physical access to the conduit) is connected to the conduit, then that person will start using the conduit’s cell data for internet traffic (assuming A, that the cell sim provides a public address, and B, that the Conduit is acting as the DHCP server, as it will tell all of its connected clients to use itself as their default gateway).

I believe you are correct that only the firewall rules will correctly enforce this. But I think this would be a worthwhile thing for the community to figure out how to enforce, because as it stands right now I believe this will be a common issue for anyone with a conduit acting as a DHCP server, with a public IP address. Unfortunately, my Linux networking skills are weak and I’ve made little progress with the correct settings over the last months.

Any further guidance you or anyone can provide would really be appreciated.

Thanks!
Chris

[Chris Friedel]

Hey Jeff,

Thanks for the reply. I think I actually was mistaken when I made this post. It appeared that on first boot up, the Conduit was dynamically changing its behavior between having a static IP while providing DHCP services, and obtaining a DHCP lease as a client (depending on if it was connected to a network that already had a DHCP server or not).

After a bit more testing, we’ve confirmed that this actually was not the case.

My apologies for the mistake – sorry about that.

Chris

[Chris Friedel]

Thanks for the offer Jeff! I’ll try with one of our Linux guys first and see if they can’t solve the issue for us. You guys have better things to worry about 🙂

If they do come up with a clean solution to implement this I’ll make sure to post it here for others.

Cheers,
Chris

[Chris Friedel]

Alright, solved my own issue here.

Looks like the firewall exposed by the web console is just IP tables.

A quick
iptables -F
iptables –policy INPUT ACCEPT
iptables –policy OUTPUT ACCEPT
iptables –policy FORWARD ACCEPT

got me back in no problem.

I would still be interested in knowing if there is a better (safer?) way of blocking the conduit’s cellular wan from being used by members of the Ethernet LAN, if anyone knows what is best for this.

Thanks,
Chris

[Chris Friedel]

I should add that I do have access to linux console via the usb debug port

[Chris Friedel]

Thanks Jeff.

I’ve added a credential json file into /etc which does the trick (and we cache these credentials in the global node-red context)

There is still one little snag in that there doesn’t seem to be a way through node-js flow to change the topic for the incoming MQTT messages (there is no input into this node of course).

I think possibly we will try and have the flow make an http request to the node-red admin ui, and dynamically update that mqtt listener node with the correct topic (since the device identifier is part of the topic).

I’ll let you know how that goes.

Thanks again for the help.

Chris

[Chris Friedel]

Hey, I’ve added a barebones example of this to devhq.

Please see our app:
“LoRa Dev Board to JSON Example”

[Chris Friedel]

Thanks Jason

Total brain fart on the spreading factor… my understand was what you’ve indicated. I’m not sure why my fingers typed the numbers I did! lol

As for a way to maintain state, (1a) I had tried node globals, but was getting undefined exceptions on the global object. I assumed that it wasn’t implemented on your the conduits instance of node. I will investigate that again, thank you!

Cheers,
Chris

[Chris Friedel]

Hey Patrick!

I realize this is an ancient request, but I wanted to fill this out for anyone who might come after looking for this.

The definition of this packet is found at

http://www.multitech.net/developer/software/dot-box-and-evb-software/data-packet-format/

Essentially, there is a byte that identifies what the next X bytes will represent, and then this repeats.

Each set of bytes after the identifier represents *one ore more* signed integers of some length. You’ll need to read that packet format above.

In node red, msg.payload from a LoRa node is a node.js buffer object. This object has easy byte[] to integer methods. HOWEVER, node.js buffers do not have an easy mechanism for reading 24 bit integers (which the dev board uses), so I ended up writing my own simple function.


msg.bitConverter = {
toSignedInt: function(bytes) {
var value = 0;

var signBitMask = 128;
var fullBitMask = 255;
var noBitMask = 0;
var activeBitMask = noBitMask;
var signMultiplier = 1;
var signOffset = 0;

if ((bytes[0] & signBitMask) == signBitMask)
{
activeBitMask = fullBitMask;
signMultiplier = -1;
signOffset = 1;
}

for (dataIndex = 0; dataIndex < bytes.length; dataIndex++) {

//if the number is negative, perform two's complement, and then shift
//by MSB byte order
value +=
(
(bytes[dataIndex] ^ activeBitMask) <<
(8 * (bytes.length - (dataIndex + 1)))
);
}

return (value + signOffset) * signMultiplier;
}
};
return msg;

You can then call this function with a big endian byte array (that is to say, bytes[0] has the most significant byte, which by the way is how the dev board sends the data) of any length, and it will turn it into a signed integer equivalent.

You need to loop through the buffer consuming first the type identifier, and then the bytes representing the signed integer to follow. This implies your node-red code needs to have a definition of these different parts. For the LoRa demo report, this definition could look like this:


tags= [{tag:'lux', id:5, byteCount:2, valueCount:1},
{tag:'press', id:8, byteCount:3, valueCount:1},
{tag:'temp', id:11, byteCount:2, valueCount:1},
{tag:'3axis', id:14, byteCount:3, valueCount:3}];

At some point I might pull an example of this out of our node-red app and make a bare bones example on the devhq app store. Keep a look out for something like “zedi lora dev board bare bones” or something to that effect.

I hope this helps someone out!

Cheers,
Chris

[Chris Friedel]

Hi Jeff,

We’re actually doing both for right now, and deciding which we prefer long term.

In one method we completely decode the message from the mDot on the conduit, and transmit back JSON encoded data. Our typical M2M plans with our Telco vendors are 5MB, so this is a little less than ideal, but has been very nice for troubleshooting and such. In this case, the node-red application has a bunch of “protocol decoders” built into it to standardize each type of message (for example, the payload on the mdot dev board is different than the data being sent by our own product).

In the second method we are passing the binary message back directly to our IoT platform. While this is very efficient, the downside for us is now our IoT platform needs to be told what decoding mechanism should be used for each individual wireless card; it’s putting a lot more of the configuration burden onto our customer. Ultimately though, I’m sure this is the approach we will be taking simply for the reduction in cellular comms.

[Chris Friedel]

Thanks Jeff,

We did get a proof of concept working with, but found it a pretty PITA to troubleshoot sftp well stuck in AEP jail 🙂

Ultimately we just switched to mqtt instead (by the way, was about the easiest things in the world via node-red, so that was very nice).

Thanks again for the help.
Chris

[Author]

Posts