Reply To: Messages store

January 2, 2019, 9:35 am

≫ Next: GPS data not found using AEP API

≪ Previous: Reply To: Downlink Data being received on Port 0, resulting in invalid MAC Command errors.

Hello Julien

AEP versions of the ConduitAP have a configurable option to store up to a
maximum of 1000 sent and received SMS text messages. If you reach the limit the
oldest messages are overwritten.

-Best Regards

↧

GPS data not found using AEP API

January 3, 2019, 1:32 pm

≫ Next: How to set code rate (codr) for UL transmission in loramdot?

≪ Previous: Reply To: Messages store

Good Day -

We have two nearly identical conduits. One reports GPS data but the other does not. The one that does not report GPS data is a Multitech Conduit: MTCDT-LVW2-246A running firmware 1.6.2.

When we execute “http://<ip_addr>/api/stats/gps”, we get:

{
“code”: 200,
“result”: {
“error”: “GPS data not found”
},
“status”: “success”
}

On the other conduits, we get back something like:

{
“code”: 200,
“result”: {
“alt”: “41.3 M”,
“data”: [
"$GNGGA,213011.00,2622.38528,N,08005.87728,W,1,07,1.33,41.3,M,-27.2,M,,*45\r",
"$GNGSA,A,3,76,67,,,,,,,,,,,2.49,1.33,2.10*11\r",
"$GPGSV,3,1,11,03,41,269,08,08,05,188,09,14,38,119,17,16,79,237,*73\r"

],
“fix”: “1″,
“lat”: “2622.38528 N”,
“lng”: “08005.87728 W”,
“sats”: “07″,
“time”: “213011.00″
},
“status”: “success”
}

Any help will be appreciated!

William Laing

↧

How to set code rate (codr) for UL transmission in loramdot?

January 3, 2019, 6:28 pm

≫ Next: Downlink que not sent to device

≪ Previous: GPS data not found using AEP API

Hello,
I am testing mdot devices connectivity with the multiconnect conduit (lora gateway). The default value of code rate used by the mdot is 4/5.

I want to know how can I change this code rate value? After I do reflash, I get the new loramdot.bin file after compilation (using mdot compile). But the problem is that there is no module in mdot class that allows me to set the code rate for UL transmission from the device. I will be greatly thankful if someone please advise me.
Cheers

↧

Downlink que not sent to device

January 4, 2019, 4:11 am

≫ Next: Reply To: Downlink que not sent to device

≪ Previous: How to set code rate (codr) for UL transmission in loramdot?

Hello,

I have a problem with my gateway. It uses to send downlinks with no problem. Now it just add the paquets to the queu but never send to device.
I have an mlinux. Here is the log of the log:

root@mtcdt:~# cat /var/log/lora-network-server.log | grep "33:34:37:39:66:37:7f:08\|33-34-37-39-66-37-7f-08"
11:11:0:691|INFO| ED:33-34-37-39-66-37-7f-08|CHECK-PKT|FCNT: 00002482 LAST-FCNT: 00002481 Duplicate: no
11:11:0:691|INFO| ED:33-34-37-39-66-37-7f-08|CHECK-MIC|ADDR: 66:37:7f:08 passed
11:11:0:691|INFO| ED:33-34-37-39-66-37-7f-08|PER|1.369863%
11:11:0:692|DEBUG| ED:33-34-37-39-66-37-7f-08|PACKET-RX|GW:00:80:00:00:a0:00:17:a0 Time_us:1561186291
11:11:0:692|DEBUG| ED:33-34-37-39-66-37-7f-08|PACKET-RX|Downlink Packets Queued: 1
11:11:0:693|INFO| ED:33-34-37-39-66-37-7f-08|FCTRL|ADR:0 ADRACK:0 ACK:0 CLASS:A OPTS:0 
11:16:51:167|INFO| ED:33-34-37-39-66-37-7f-08|QUEUE-TX|DATA SIZE: 2
11:21:0:621|INFO| ED:33-34-37-39-66-37-7f-08|CHECK-PKT|FCNT: 00002483 LAST-FCNT: 00002482 Duplicate: no
11:21:0:621|INFO| ED:33-34-37-39-66-37-7f-08|CHECK-MIC|ADDR: 66:37:7f:08 passed
11:21:0:622|INFO| ED:33-34-37-39-66-37-7f-08|PER|1.360544%
11:21:0:622|DEBUG| ED:33-34-37-39-66-37-7f-08|PACKET-RX|GW:00:80:00:00:a0:00:17:a0 Time_us:2161124683
11:21:0:622|DEBUG| ED:33-34-37-39-66-37-7f-08|PACKET-RX|Downlink Packets Queued: 2
11:21:0:623|INFO| ED:33-34-37-39-66-37-7f-08|FCTRL|ADR:0 ADRACK:0 ACK:0 CLASS:A OPTS:0 
11:30:46:790|INFO| ED:33-34-37-39-66-37-7f-08|QUEUE-TX|DATA SIZE: 2
11:31:0:550|INFO| ED:33-34-37-39-66-37-7f-08|CHECK-PKT|FCNT: 00002484 LAST-FCNT: 00002483 Duplicate: no
11:31:0:550|INFO| ED:33-34-37-39-66-37-7f-08|CHECK-MIC|ADDR: 66:37:7f:08 passed
11:31:0:550|INFO| ED:33-34-37-39-66-37-7f-08|PER|1.351351%
11:31:0:551|DEBUG| ED:33-34-37-39-66-37-7f-08|PACKET-RX|GW:00:80:00:00:a0:00:17:a0 Time_us:2761063163
11:31:0:551|DEBUG| ED:33-34-37-39-66-37-7f-08|PACKET-RX|Downlink Packets Queued: 3
11:31:0:551|INFO| ED:33-34-37-39-66-37-7f-08|FCTRL|ADR:0 ADRACK:0 ACK:0 CLASS:A OPTS:0 
11:41:0:483|INFO| ED:33-34-37-39-66-37-7f-08|CHECK-PKT|FCNT: 00002485 LAST-FCNT: 00002484 Duplicate: no
11:41:0:484|INFO| ED:33-34-37-39-66-37-7f-08|CHECK-MIC|ADDR: 66:37:7f:08 passed
11:41:0:484|INFO| ED:33-34-37-39-66-37-7f-08|PER|1.342282%
11:41:0:484|DEBUG| ED:33-34-37-39-66-37-7f-08|PACKET-RX|GW:00:80:00:00:a0:00:17:a0 Time_us:3361000707
11:41:0:485|DEBUG| ED:33-34-37-39-66-37-7f-08|PACKET-RX|Downlink Packets Queued: 3
11:41:0:485|INFO| ED:33-34-37-39-66-37-7f-08|FCTRL|ADR:0 ADRACK:0 ACK:0 CLASS:A OPTS:0 
11:48:34:698|INFO| ED:33-34-37-39-66-37-7f-08|QUEUE-TX|DATA SIZE: 2

Any help on this?
thanks

↧

Reply To: Downlink que not sent to device

January 4, 2019, 4:36 am

≫ Next: Reply To: Downlink que not sent to device

≪ Previous: Downlink que not sent to device

Please create support ticket and provide sw and hw version info. Also provide full logs of state transition from working to non-working if possible.

support.multitech.com

↧

Reply To: Downlink que not sent to device

January 4, 2019, 4:48 am

≫ Next: Reply To: How to set code rate (codr) for UL transmission in loramdot?

≪ Previous: Reply To: Downlink que not sent to device

Could be scheduling conflict or duty-cycle limits. What channel plan is used?

↧

Reply To: How to set code rate (codr) for UL transmission in loramdot?

January 4, 2019, 5:49 am

≫ Next: Reply To: Downlink Data being received on Port 0, resulting in invalid MAC Command errors.

≪ Previous: Reply To: Downlink que not sent to device

Lorawan uses 4/5 coderate only.
Using next datarate will allow more range than increased coderate.

Using an open stack source would allow changing. The sxradio driver will allow all options.

https://github.com/ARMmbed/mbed-os-example-lorawan

↧

Reply To: Downlink Data being received on Port 0, resulting in invalid MAC Command errors.

January 5, 2019, 8:58 am

≫ Next: Reply To: Downlink Data being received on Port 0, resulting in invalid MAC Command errors.

≪ Previous: Reply To: How to set code rate (codr) for UL transmission in loramdot?

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.

↧

Reply To: Downlink Data being received on Port 0, resulting in invalid MAC Command errors.

January 5, 2019, 11:40 am

≫ Next: Reply To: Downlink que not sent to device

≪ Previous: Reply To: Downlink Data being received on Port 0, resulting in invalid MAC Command errors.

Expected type for port is an int.

↧

Reply To: Downlink que not sent to device

January 5, 2019, 11:48 pm

≫ Next: Reply To: Downlink Data being received on Port 0, resulting in invalid MAC Command errors.

≪ Previous: Reply To: Downlink Data being received on Port 0, resulting in invalid MAC Command errors.

Hello Jason,

How can I know the hw and sw version with SSH? My gtw is 12.000 km away at the client’s site.

How can I see if it is a scheduling conflict or duty-cycle limits?

Thanks
Nicoalas

↧

Reply To: Downlink Data being received on Port 0, resulting in invalid MAC Command errors.

January 6, 2019, 2:48 pm

≫ Next: Cannot connect to cellular – Connect script failed

≪ Previous: Reply To: Downlink que not sent to device

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:}

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

Thanks,
Ajay

↧

Cannot connect to cellular – Connect script failed

January 7, 2019, 2:29 am

≫ Next: Reply To: GPS data not found using AEP API

≪ Previous: Reply To: Downlink Data being received on Port 0, resulting in invalid MAC Command errors.

Hello,

I am trying to configure cellular connection on a Multitech Conduit IP67 Base Station – mLinux version. I have tried two sim cards. I inserted the sim card with sim contacts facing down and its cut corner to be up-left (while facing the sim port) – this is the only way that it clicks anyway.

I set correctly the APN. When I call pppd call gsm or pppd call leu1 with their default configurations I don’t have a successful connection. Instead I get the following in the log messages (/var/log/messages):

Jan 7 11:33:21 mtcdt daemon.notice pppd[558]: pppd 2.4.7 started by mtadm, uid 50
Jan 7 11:33:22 mtcdt local2.info chat[559]: abort on (NO DIAL TONE)
Jan 7 11:33:22 mtcdt local2.info chat[559]: abort on (NO DIALTONE)
Jan 7 11:33:22 mtcdt local2.info chat[559]: abort on (NO ANSWER)
Jan 7 11:33:22 mtcdt local2.info chat[559]: abort on (NO CARRIER)
Jan 7 11:33:22 mtcdt local2.info chat[559]: abort on (DELAYED)
Jan 7 11:33:22 mtcdt local2.info chat[559]: abort on (VOICE)
Jan 7 11:33:22 mtcdt local2.info chat[559]: abort on (BUSY)
Jan 7 11:33:22 mtcdt local2.info chat[559]: send (AT^M)
Jan 7 11:33:22 mtcdt local2.info chat[559]: expect (OK)
Jan 7 11:33:22 mtcdt local2.info chat[559]: AT^M^M
Jan 7 11:33:22 mtcdt local2.info chat[559]: OK
Jan 7 11:33:22 mtcdt local2.info chat[559]: — got it
Jan 7 11:33:22 mtcdt local2.info chat[559]: send (ATZ^M)
Jan 7 11:33:22 mtcdt local2.info chat[559]: expect (OK)
Jan 7 11:33:22 mtcdt local2.info chat[559]: ^M
Jan 7 11:33:22 mtcdt local2.info chat[559]: ATZ^M^M
Jan 7 11:33:22 mtcdt local2.info chat[559]: OK
Jan 7 11:33:22 mtcdt local2.info chat[559]: — got it
Jan 7 11:33:22 mtcdt local2.info chat[559]: send (AT+CSQ^M)
Jan 7 11:33:22 mtcdt local2.info chat[559]: expect (OK)
Jan 7 11:33:22 mtcdt local2.info chat[559]: ^M
Jan 7 11:33:22 mtcdt local2.info chat[559]: AT+CSQ^M^M
Jan 7 11:33:22 mtcdt local2.info chat[559]: +CSQ: 23,99^M
Jan 7 11:33:22 mtcdt local2.info chat[559]: ^M
Jan 7 11:33:22 mtcdt local2.info chat[559]: OK
Jan 7 11:33:22 mtcdt local2.info chat[559]: — got it
Jan 7 11:33:22 mtcdt local2.info chat[559]: send (AT+CGDCONT=1,”IP”,”cytamobile”^M)
Jan 7 11:33:22 mtcdt local2.info chat[559]: expect (OK)
Jan 7 11:33:22 mtcdt local2.info chat[559]: ^M
Jan 7 11:33:22 mtcdt local2.info chat[559]: AT+CGDCONT=1,”IP”,”cytamobile”^M^M
Jan 7 11:33:22 mtcdt local2.info chat[559]: ERROR^M
Jan 7 11:34:52 mtcdt local2.info chat[559]: alarm
Jan 7 11:34:52 mtcdt local2.info chat[559]: Failed
Jan 7 11:34:52 mtcdt daemon.err pppd[558]: Connect script failed
Jan 7 11:34:53 mtcdt daemon.info pppd[558]: Exit.

Am I missing something? The sim card for the aforementioned example does not require authentication.

Also, I would like some instructions on how to configure PAP Authentication for another sim card that I have because I can’t find any information in the datasheet or the website.

Thank you very much!

↧

Reply To: GPS data not found using AEP API

January 7, 2019, 5:43 am

≫ Next: Reply To: Cannot connect to cellular – Connect script failed

≪ Previous: Cannot connect to cellular – Connect script failed

Hello William,

Is there anything related to the GPS fix/lock in the /var/log/messages on the device that has the failure?

Jeff

↧

Reply To: Cannot connect to cellular – Connect script failed

January 7, 2019, 5:46 am

≫ Next: Reply To: Cannot connect to cellular – Connect script failed

≪ Previous: Reply To: GPS data not found using AEP API

Hello Christos,

For help with this you could open a support portal case at https://support.multitech.com. They can provide better support than the forums.

Jeff

↧

Reply To: Cannot connect to cellular – Connect script failed

January 7, 2019, 7:12 am

≫ Next: Lora packets sent to gateway have empty payload

≪ Previous: Reply To: Cannot connect to cellular – Connect script failed

Hello Jeff,

Thanks for the reply. I opened a case on the multitech support as you suggested. I managed to have some progress on my issue. Maybe someone could help with the following:

I changed the location of the gateway and I managed to get connected to the APN but I have a modem hangup (SIGHUP).

I need the instructions for authenticating my sim card (Simfony) because it requires a username and a password.

In the log file I get:

Jan 7 17:04:10 mtcdt daemon.notice pppd[693]: pppd 2.4.7 started by mtadm, uid 50
Jan 7 17:04:11 mtcdt local2.info chat[694]: abort on (NO DIAL TONE)
Jan 7 17:04:11 mtcdt local2.info chat[694]: abort on (NO DIALTONE)
Jan 7 17:04:11 mtcdt local2.info chat[694]: abort on (NO ANSWER)
Jan 7 17:04:11 mtcdt local2.info chat[694]: abort on (NO CARRIER)
Jan 7 17:04:11 mtcdt local2.info chat[694]: abort on (DELAYED)
Jan 7 17:04:11 mtcdt local2.info chat[694]: abort on (VOICE)
Jan 7 17:04:11 mtcdt local2.info chat[694]: abort on (BUSY)
Jan 7 17:04:11 mtcdt local2.info chat[694]: send (AT^M)
Jan 7 17:04:11 mtcdt local2.info chat[694]: expect (OK)
Jan 7 17:04:11 mtcdt local2.info chat[694]: AT^M^M
Jan 7 17:04:11 mtcdt local2.info chat[694]: OK
Jan 7 17:04:11 mtcdt local2.info chat[694]: — got it
Jan 7 17:04:11 mtcdt local2.info chat[694]: send (ATZ^M)
Jan 7 17:04:11 mtcdt local2.info chat[694]: expect (OK)
Jan 7 17:04:11 mtcdt local2.info chat[694]: ^M
Jan 7 17:04:11 mtcdt local2.info chat[694]: ATZ^M^M
Jan 7 17:04:11 mtcdt local2.info chat[694]: OK
Jan 7 17:04:11 mtcdt local2.info chat[694]: — got it
Jan 7 17:04:11 mtcdt local2.info chat[694]: send (AT+CSQ^M)
Jan 7 17:04:11 mtcdt local2.info chat[694]: expect (OK)
Jan 7 17:04:11 mtcdt local2.info chat[694]: ^M
Jan 7 17:04:11 mtcdt local2.info chat[694]: AT+CSQ^M^M
Jan 7 17:04:11 mtcdt local2.info chat[694]: +CSQ: 21,99^M
Jan 7 17:04:11 mtcdt local2.info chat[694]: ^M
Jan 7 17:04:11 mtcdt local2.info chat[694]: OK
Jan 7 17:04:11 mtcdt local2.info chat[694]: — got it
Jan 7 17:04:11 mtcdt local2.info chat[694]: send (AT+CGDCONT=1,”IP”,”direct.simfony.net”^M)
Jan 7 17:04:12 mtcdt local2.info chat[694]: expect (OK)
Jan 7 17:04:12 mtcdt local2.info chat[694]: ^M
Jan 7 17:04:12 mtcdt local2.info chat[694]: AT+CGDCONT=1,”IP”,”direct.simfony.net”^M^M
Jan 7 17:04:12 mtcdt local2.info chat[694]: OK
Jan 7 17:04:12 mtcdt local2.info chat[694]: — got it
Jan 7 17:04:12 mtcdt local2.info chat[694]: send (ATD*99***1#^M)
Jan 7 17:04:12 mtcdt local2.info chat[694]: timeout set to 120 seconds
Jan 7 17:04:12 mtcdt local2.info chat[694]: expect (CONNECT)
Jan 7 17:04:12 mtcdt local2.info chat[694]: ^M
Jan 7 17:04:12 mtcdt local2.info chat[694]: ATD*99***1#^M^M
Jan 7 17:04:12 mtcdt local2.info chat[694]: CONNECT
Jan 7 17:04:12 mtcdt local2.info chat[694]: — got it
Jan 7 17:04:12 mtcdt local2.info chat[694]: send (^M)
Jan 7 17:04:12 mtcdt daemon.debug pppd[693]: Script /usr/sbin/chat -v -t 90 -f /etc/ppp/peers/gsm_chat finished (pid 694), status = 0×0
Jan 7 17:04:12 mtcdt daemon.info pppd[693]: Serial connection established.
Jan 7 17:04:12 mtcdt daemon.debug pppd[693]: using channel 14
Jan 7 17:04:12 mtcdt daemon.info pppd[693]: Using interface ppp0
Jan 7 17:04:12 mtcdt daemon.notice pppd[693]: Connect: ppp0 <–> /dev/modem_at0
Jan 7 17:04:13 mtcdt daemon.warn pppd[693]: Warning – secret file /etc/ppp/pap-secrets has world and/or group access
Jan 7 17:04:13 mtcdt daemon.debug pppd[693]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x4d9009a5> <pcomp> <accomp>]
Jan 7 17:04:13 mtcdt daemon.debug pppd[693]: rcvd [LCP ConfReq id=0xed <asyncmap 0x0> <auth chap MD5> <magic 0x455a8b88> <pcomp> <accomp>]
Jan 7 17:04:13 mtcdt daemon.debug pppd[693]: sent [LCP ConfNak id=0xed <auth pap>]
Jan 7 17:04:13 mtcdt daemon.debug pppd[693]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x4d9009a5> <pcomp> <accomp>]
Jan 7 17:04:13 mtcdt daemon.debug pppd[693]: rcvd [LCP ConfReq id=0xee <asyncmap 0x0> <auth pap> <magic 0x455a8b88> <pcomp> <accomp>]
Jan 7 17:04:13 mtcdt daemon.debug pppd[693]: sent [LCP ConfAck id=0xee <asyncmap 0x0> <auth pap> <magic 0x455a8b88> <pcomp> <accomp>]
Jan 7 17:04:13 mtcdt daemon.warn pppd[693]: Warning – secret file /etc/ppp/pap-secrets has world and/or group access
Jan 7 17:04:13 mtcdt daemon.debug pppd[693]: sent [PAP AuthReq id=0x1 user="mtcdt" password=<hidden>]
Jan 7 17:04:13 mtcdt daemon.debug pppd[693]: rcvd [LCP DiscReq id=0xef magic=0x455a8b88]
Jan 7 17:04:13 mtcdt daemon.debug pppd[693]: rcvd [PAP AuthAck id=0x1 ""]
Jan 7 17:04:13 mtcdt daemon.notice pppd[693]: PAP authentication succeeded
Jan 7 17:04:13 mtcdt daemon.debug pppd[693]: sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
Jan 7 17:04:13 mtcdt daemon.debug pppd[693]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Jan 7 17:04:13 mtcdt daemon.debug pppd[693]: rcvd [LCP ProtRej id=0xf0 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
Jan 7 17:04:13 mtcdt daemon.debug pppd[693]: Protocol-Reject for ‘Compression Control Protocol’ (0x80fd) received
Jan 7 17:04:15 mtcdt daemon.debug pppd[693]: rcvd [IPCP ConfNak id=0x1 <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Jan 7 17:04:15 mtcdt daemon.debug pppd[693]: sent [IPCP ConfReq id=0x2 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Jan 7 17:04:16 mtcdt daemon.debug pppd[693]: rcvd [IPCP ConfNak id=0x2 <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Jan 7 17:04:16 mtcdt daemon.debug pppd[693]: sent [IPCP ConfReq id=0x3 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Jan 7 17:04:17 mtcdt daemon.debug pppd[693]: rcvd [IPCP ConfNak id=0x3 <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Jan 7 17:04:17 mtcdt daemon.debug pppd[693]: sent [IPCP ConfReq id=0x4 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Jan 7 17:04:18 mtcdt daemon.debug pppd[693]: rcvd [IPCP ConfNak id=0x4 <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Jan 7 17:04:18 mtcdt daemon.debug pppd[693]: sent [IPCP ConfReq id=0x5 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Jan 7 17:04:20 mtcdt daemon.debug pppd[693]: rcvd [IPCP ConfNak id=0x5 <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Jan 7 17:04:20 mtcdt daemon.debug pppd[693]: sent [IPCP ConfReq id=0x6 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Jan 7 17:04:21 mtcdt daemon.debug pppd[693]: rcvd [IPCP ConfNak id=0x6 <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Jan 7 17:04:21 mtcdt daemon.debug pppd[693]: sent [IPCP ConfReq id=0x7 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Jan 7 17:04:22 mtcdt daemon.debug pppd[693]: rcvd [IPCP ConfNak id=0x7 <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Jan 7 17:04:22 mtcdt daemon.debug pppd[693]: sent [IPCP ConfReq id=0x8 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Jan 7 17:04:24 mtcdt daemon.debug pppd[693]: rcvd [IPCP ConfNak id=0x8 <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Jan 7 17:04:24 mtcdt daemon.debug pppd[693]: sent [IPCP ConfReq id=0x9 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Jan 7 17:04:25 mtcdt daemon.debug pppd[693]: rcvd [IPCP ConfNak id=0x9 <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Jan 7 17:04:25 mtcdt daemon.debug pppd[693]: sent [IPCP ConfReq id=0xa <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Jan 7 17:04:25 mtcdt daemon.info pppd[693]: Hangup (SIGHUP)
Jan 7 17:04:25 mtcdt daemon.notice pppd[693]: Modem hangup
Jan 7 17:04:25 mtcdt daemon.notice pppd[693]: Connection terminated.
Jan 7 17:04:26 mtcdt daemon.info pppd[693]: Exit.

Even if edit /etc/ppp/pap-secrets or /etc/ppp/chap-secrets file with the correct username and password I can’t manage to get a successful connection.

Can someone please provide me the instructions for having a ppp connection with authentication?

Thank you very much!

↧

Lora packets sent to gateway have empty payload

January 7, 2019, 8:25 am

≫ Next: Reply To: Downlink Data being received on Port 0, resulting in invalid MAC Command errors.

≪ Previous: Reply To: Cannot connect to cellular – Connect script failed

Hello,

Whenever one of our xDot devices sends Lora packets to our AEP Gateway the first several packets have correct payloads, but then the packets stop having a payload entirely.

It appears that if I reset the Lora connection, then the first several packets have correct payloads again, but then the packet payloads become undefined again.

Has anyone else had this problem?

Thanks

↧

Reply To: Downlink Data being received on Port 0, resulting in invalid MAC Command errors.

January 7, 2019, 10:28 am

≫ Next: Reply To: GPS data not found using AEP API

≪ Previous: Lora packets sent to gateway have empty payload

Did you find that one of your proposed solutions works?

↧

Reply To: GPS data not found using AEP API

January 7, 2019, 10:44 am

≫ Next: LORA CERTIFICATION with xDOT module

≪ Previous: Reply To: Downlink Data being received on Port 0, resulting in invalid MAC Command errors.

Hi Jeff -

Five of our Conduits are reporting GPS; one is not. They are all configured the same way as best we can tell.

These same messages are found in /var/log/messages for both Conduits:

2019-01-07T18:28:50.699113+00:00 mtcdt admin: Is GPSD running?
2019-01-07T18:28:50.729038+00:00 mtcdt admin: FIX OK field should be single hex digit: gpsmon data: gpsmon:ERROR: TCP device open error can’t connect to host/port pair.
2019-01-07T18:28:50.758635+00:00 mtcdt admin: GPS does not have a fix yet. Try again later.

Yet one is reporting GPS, and the other is not.

↧

LORA CERTIFICATION with xDOT module

January 8, 2019, 8:04 am

≫ Next: Reply To: GPS data not found using AEP API

≪ Previous: Reply To: GPS data not found using AEP API

Hello,
We are planning on using the xDOT module in our application,
and I am wondering what are tests involved for LORA certification.
I am assuming all the tests would comply automatically as we are using xDOT module. Please let me know if there are any challenges that we can expect and
any workarounds etc.

Also please pass on if there is any document that talks about the certification process.

Thanks,
Naga.

↧

Reply To: GPS data not found using AEP API

January 8, 2019, 1:00 pm

≫ Next: Updated host CPU for Conduit?

≪ Previous: LORA CERTIFICATION with xDOT module

William,

Could you file a support portal case at https://support.multitech.com on this? There’s been some issues with the connectors to the board for the gps antennas among other things. Also, they may be able to give some additional advice on what environmental factors to rule out.

Thanks,

Jeff

↧