[Ajay K]

Thanks Jason, we have been working up until now on 1.7.4 firmware version and on a older gateway, so on that it had always worked without any issues.

However since we got the new gateway and here is what I have from the home page on the gateway for the model and version of firmware. I am guessing the sftp is not enabled by default?

mPower™ Edge Intelligence Conduit – Application Enablement Platform
MTCDT-L4N1-246A Firmware 5.1.2

Also I got the same o/p as you have mentioned above:

admin@mtcdt:/var/volatile/orsat$ opkg list | grep ftp
inetutils-ftp – 1.9.4-r0.0
kernel-module-nf-conntrack-ftp – 4.9.87-r11.1
kernel-module-nf-nat-ftp – 4.9.87-r11.1
openssh-sftp-server – 7.5p1-r0.mts5.0

admin@mtcdt:/var/volatile/orsat$ ps aux | grep ftp
admin 29895 0.0 0.4 3092 1124 pts/0 S+ 23:23 0:00 grep ftp

How do I get the SSH server enabled?

Thanks,
Ajay

[Ajay K]

Thanks Jason I did read that and I was confused because of the examples still calling out regarding deep sleep. We are planning to start using the latest libmdot5 version and I was looking at the examples to see if anything has changed in the way we connect to the gateway.

Also in the deep sleep the following was called out based on your link above:

Under the hood, sleep and deep sleep now function the same with the exception of how the external IO are handled.
Deep sleep mode: When entering deep sleep, external pin configurations are saved and all external IO are configured as analog input with no pull resistors. This achieves lowest power consumption while mimicking how IO are configured in standby mode. Upon wake, pin configurations are restored. If having all external IO pins floating works in your installation, this mode is recommended.

Currently in our code base we have implemented the following when the MDot boots up, do we need to do this anymore in the deep sleep mode?

//first thing you do is initialize the unused GPIO pins as analog in, with no pull.
    GPIO_InitTypeDef GPIO_InitStruct;
 
    //PA_0, PA_5, PA_6, PA_13, PA_14  to analog nopull
    GPIO_InitStruct.Pin = GPIO_PIN_0 | GPIO_PIN_5 | GPIO_PIN_6 |GPIO_PIN_13 | GPIO_PIN_14 ;
    GPIO_InitStruct.Mode = GPIO_MODE_ANALOG;
    GPIO_InitStruct.Pull = GPIO_NOPULL;
    HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);    
 
    // PB_3 & PB_4 to analog nopull
    GPIO_InitStruct.Pin = GPIO_PIN_3 | GPIO_PIN_4;
    GPIO_InitStruct.Mode = GPIO_MODE_ANALOG;
    GPIO_InitStruct.Pull = GPIO_NOPULL;
    HAL_GPIO_Init(GPIOB, &GPIO_InitStruct); 
 
    // PC_1 to analog nopull
    GPIO_InitStruct.Pin = GPIO_PIN_1;
    GPIO_InitStruct.Mode = GPIO_MODE_ANALOG;
    GPIO_InitStruct.Pull = GPIO_NOPULL;
    HAL_GPIO_Init(GPIOC, &GPIO_InitStruct);

Thanks,
Ajay

[Ajay K]

Hi Jason,

Thanks for taking the time to respond, isn’t size_t below an unsigned integer type? Can I pass a negative number?

bool seekUserFile(mDot::mdot_file& file, size_t offset, int whence);

Thanks,
Ajay

[Ajay K]

Thanks Jeff, after the power cycle it works, but a reset doesn’t seem to help. Not sure why a reset doesn’t fix it?

Thanks,
Ajay.

[Ajay K]

Just adding the packet, since it seems to be clipped in the previous post.

11/21/2019 0:2:25: [DEBUG] Received Uplink Packet with EUI: 00:80:00:00:00:01:57:47, sequence#: 123
Uplink Packet: {“tmst”:3637994484,”chan”:6,”rfch”:1,
“freq”:906.7,”stat”:1,”modu”:”LORA”,
“datr”:”SF7BW125″,”codr”:”4/5″,”lsnr”:5.8,
“rssi”:-92,”opts”:””,”size”:0,”fcnt”:123,”cls”:0,”port”:1,
“mhdr”:”801f8ae001807b00″,
“data”:””,
“appeui”:”55-ab-d3-90-e4-c5-a9-0a”,
“deveui”:”00-80-00-00-00-01-57-47″,
“ack”:false,
“adr”:true,
“gweui”:”00-80-00-00-a0-00-41-ca”,
“seqn”:123,”time”:”2019-11-21T00:02:24.977047Z”}

[Ajay K]

Thanks Jason, the sample helps. I am guessing when switching between channel plans, if we had set the join delay to be 1 second in the previous channel plan and later when we apply say a new channel plan it defaults the previous settings and reverts back the join delay to 5 seconds?

Thanks,
Ajay.

[Ajay K]

Hi Jason,

So when install the Custom App, we SSH into the conduit using a given user name and password which I assume is the admin user and password. So are you saying with 5.0 version the SSH session even though we login using the admin user name and password the SSH session doesn’t have root permissions?

So before we install the custom app, we launch Putty in our case as a command line prompt to execute the above command in which case we prepend sudo before the app-manager command? Continue again to login as the admin?

“sudo app-manager –command local –appfile testapp.tar.gz –appname “TestApp” –apptype CUSTOM”

Thanks,
Ajay

[Ajay K]

Hi Jeff,

I haven’t used logrotate before, is this some kind of configuration I need to implement on the conduit. Is this something I can setup so that it can be handled during the install of the custom app? I was hoping I could get an example scripts you could share, if I can set this up during the install of the custom app.

Thanks,
Ajay

[Ajay K]

Hi Jason,

So would it be okay if pass as json object such as this one below or should we not set the JSON property “port” in the json object? Which method below would default the port to 1?

var msg = {data: new Buffer(payload).toString("base64"), ack:1, port:}

or

var msg = {data: new Buffer(payload).toString("base64"), ack:1}

Thanks,
Ajay

[Ajay K]

Hi Jason,

Thanks for the information. It is not defaulting to “1”, at least not with the latest conduit firmware version we are using.

Here is the code that we use to send the downlink packet. The appSettings.downlinkAppPort configuration setting we use is currently a blank string and this has worked previously on the earlier versions of the conduit firmware.

var eui = arrLoraDownlinkPackets[0].eui;
var payload = arrLoraDownlinkPackets[0].dataPacket;

var msg = { data: new Buffer(payload).toString("base64"), ack: 
      appSettings.downlinkAckRequired, port: appSettings.downlinkAppPort };

mqttClient.publish('lora/' + eui + '/down', JSON.stringify(msg));

Let me know if you have any questions or concerns regarding the way the port value is being set in the code above?

Thanks,
Ajay.

[Ajay K]

Thanks Ryan, I figured out how to do it using node.js in the custom app.

However my original question still remains, is this a new requirement to specify a port#, since if we don’t set it in the custom app, the new conduit firmware could pick port 0. Is this a bug, that needs to be fixed? Since the radio node mDot API would end up throwing an error while attempting to parse the downlink payload as a MAC command and this would result in unnecessary errors. So it would be ideal if we don’t have to pick a port and the conduit assigns a port since the conduit firmware understands which ports are reserved and which are not.

So in the future if for some reason port# 1 is reserved for example then all the customers using this port# to transmit data have to change their custom code to not use port# 1, as I have done to fix this issue.

Thanks,
Ajay

[Ajay K]

Thanks Ryan for taking the time to respond and providing an example. I am guessing what you have written is using c++ version of the mqtt api. The custom app we have written is built on node.js and we use the mqtt node js library which is also used by the node-red application. Does this node.js version of the mqtt library also have the same api that you have described above?

Also what has changed in the conduit, that all of a sudden it’s also transmitting downlink data over port 0? Is this a bug since I didn’t have to ever control the port# in the previous versions of the conduit firmware?

Thanks,
Ajay

[Ajay K]

We have written a custom app that subscribes to the MQTT broker to receive and send messages from and to the radio nodes. This hasn’t changed since we have been using the conduit for a while now. Only after we upgraded the Conduit firmware to 1.6.2 did we start seeing the downlink packets being sent over Port 0.

Thanks,
Ajay.

[Ajay K]

Any thoughts on why the linker errors occur. Most of the other platforms I don’t have to do anything extra to get it to build in mbed-cli. I imported the application after I published it in private mode and running the compile command results in linker error.

Thanks,
Ajay

[Ajay K]

A follow up question regarding the setChannelPlan(lora::ChannelPlan*) method. Calling this method, is that an equivalent of passing the channel plan to the mdot getInstance method? I assuming the mDot instance now refer to the new channel plan set?

Thanks,
Ajay.

[Ajay K]

Thanks for pointing me to the lorawan spec.

[Ajay K]

Thanks a lot Jason for the detailed explanation. I will try changing or limiting the number of available DRs on the conduit and see if that helps.

When is the next version of the mdot sdk planned to be released?

Thanks,
Ajay.

[Ajay K]

Hi Jason,

An update to the Australian channel plan issue and also the US Plan. When we reverted back to the Conduit firmware to 1.4.3 and our application firmware for US Channel connected immediately with the 2.0.16 and 3.0.0 Prod MDOT SDK. However for the Australian Channel Plan version of our Application firmware, I could only get it join with 3.0.0 SDK version of the mDot and work consistently.

Does this anyway shed a light as to why our application firmware doesn’t work with Conduit firmware version 1.4.16?

Thanks,
Ajay

[Ajay K]

Thanks Jason, can you let me know what Spread factor does DR0 correspond to and the DR4 correspond to in the current supported spec?

Thanks,
Ajay

[Ajay K]

Also I forgot to mention previously we have ADR enabled as well.

[Ajay K]

Do you have to set the join delay explicitly in the mdot code or is there a default. Currently the join delay for private mts mode is set to 1 second on the conduit, should I be setting this join delay explcitly in the mdot? I am not sure what is going on here shouldn’t an upgrade to the conduit firmware not disrupt what has been working for so long and since we haven’t changed the mdot custom firmware over a while now?

After upgrading our US version of the conduit to the latest firmware, even the join failures have started to replicate. Is there a way to revert the conduit version to the previous version of the gateway?

Thanks,
Ajay.

[Ajay K]

Hi Jason,

Thanks for your response. We have installed the latest gateway software. It was on private mts mode earlier and then I switched it to private mode, because the mdot wasn’t able to join in that private mts mode, although in both modes the conduit kept indicating that the mdot successfully joined, but as mentioned earlier the mdot has receive timeouts and indicates a join failure all the time.

We have two versions of the custom firmware, one which is built using mdot sdk 2.0.16-1 and the other built with 3.0.0 production version. So are you saying for both these firmware versions i need to set it in “private” mode and not “private mts” mode? If so I have already done that.

Also in the 3.0.0 build do i need to set the channel plan explicitly. I have done that too, just because the mdot getInstance method required that and I have set it to AU915 channel plan. On the version prior to 3.0.0 mdot sdk, I am guessing I don’t have to select a channel plan?

Thanks,
Ajay.

[Ajay K]

Hi Jason,

Thanks for your response. We have installed the latest gateway software. It was on private mts mode earlier and then I switched it to private mode, because the mdot wasn’t able to join in that private mts mode, although in both modes the conduit kept indicating that the mdot successfully joined, but as mentioned earlier the mdot has receive timeouts and indicates a join failure all the time.

We have two versions of the custom firmware, one which is built using mdot sdk 2.0.16-1 and the other built with 3.0.0 production version. So are you saying for both these firmware versions i need to set it in “private” mode and not “private mts” mode? If so I have already done that.

Also in the 3.0.0 build do i need to set the channel plan explicitly. I have done that too, just because the mdot getInstance method required that and I have set it to AU915 channel plan.

Thanks,
Ajay.

[Ajay K]

Thanks so much Jason. The second link worked, the first one fails with an invalid URL.

Thanks,
Ajay.

[Ajay K]

Thanks Jason for the clarification. I couldn’t find this info in the data sheet of conduits that have wifi capability.

1) What is the transmit power of the on-board WIFI for a wifi enabled conduit?
2) What is the antenna gain for the same?
3) Receiver sensitivity for the wifi on board?

Thanks,
Ajay.

[Ajay K]

So I guess I don’t understand the concept of packet forwarding completely based on your comments. I was under the impression that the one conduit was able to forward packets to the other conduit? For the conduits to be networked they will have to be in close range to one another right either ethernet or wifi?

We have a scenario where the conduits are almost a mile apart and since the farm/ranch where they are being deployed is fairly large and only one of them conduits have wifi access and I am wondering in such scenario I am guessing the packet forwarder mode would not be viable and if so what is the best way for us to get the packets from one conduit to the conduit with either cellular/wifi connection?

Thanks,
Ajay.

[Ajay K]

Thanks Steve for taking the time to respond and with all the details mentioned in your response. I was just wondering are there any samples on the multitech/mbed site which uses the link checks as an alternative to acks for all packet transmissions.

Thanks,
Ajay.

[Ajay K]

Thanks Steve for your valuable inputs. We do have ADR enabled as well. Is there a reasonable ACK count that can be set which could reduce power consumption.

Thanks,
Ajay

[Ajay K]

Hi Jeff,

Is there a plan anytime in the near future to upgrade the hardware on the conduit to support later versions of nodejs?

Thanks,
Ajay.

[Ajay K]

Hi Jeff,

When is the AEP 1.5 version release slated? Also what would be the version of nodejs that would be on this platform. The reason I ask is because we have custom app’s written on top of the nodejs version that is currently on the conduit.

Thanks,
Ajay.

[Author]

Posts