[Jim Maricondo]

Not to beat a dead horse, but is there anything else we can do to improve signal strength besides what has already been mentioned in this thread? Like buy a bigger external antenna for the Conduit?

Thanks,
-Jim

[Jim Maricondo]

Thanks. By the way, just for the record: with SF 10 and max power on both devices, the Conduit placed in a machine room approximately 50m deep inside the building on the second floor with stock antenna, end node with mDot EVB chip antenna, in a dense urban environment, I also have only been able to achieve about 700-800 ft max range. Also there are a lot of dead zones caused by buildings in the way.

I will do some additional tests, including the regular mDot with stock external antenna. However when I tested SNR chip antenna vs external antenna at my desk, SNS was only like 2-5 better with the external antenna.

-Jim

[Jim Maricondo]

Just to confirm what someone else said anecdotally, it’s preferable to put the Conduit as high up off the ground as possible, and point the antenna facing down, right?

And the receiving antenna should be pointed up?

Just trying to maximize my distance. Right now only getting 100-300m, but the Conduit is in a machine room on 2F maybe about 50m inside the building, and there are multiple other tall buildings surrounding it.

Thanks,
-Jim

[Jim Maricondo]

Debug nodes can output to the debug tab and/or the console. But where is the console? Can I tail a log file to see it?

Thanks,
-Jim

[Jim Maricondo]

Jeff,

You are right. Retried it with Firefox (41.0.2) and it is finally working. Maybe you can add to your support base the fact that it does not work with Safari (9.0.1).

I realize most hardware guys don’t use Macs. But 90% of Silicon Valley (at least software guys) do, and I guess we are spoiled to think that all web apps work across all browsers.

Thanks,
-Jim

[Jim Maricondo]

Understood, thanks. Someone should have said that sooner when Patrick posted! 😉

[Jim Maricondo]

OK understood. Since there is no other information available at this time, can you tell me how the chip antenna on the EVB compares to a AN868-915A-1HRA antenna connected to a MTDOT-915 on a MTUDK2?

Thanks,
-Jim

• This reply was modified 9 years ago by Jim Maricondo.
• This reply was modified 9 years ago by Jim Maricondo.

[Jim Maricondo]

Thanks.

Actually in the MTDOT_Senet_Demo project we got they setFrequencySubBand(0) so I assume that is what Senet requires.

In summary, theoretically this should work, right? Guess I need to try it in other locations to see if it is just a signal issue, right?

at&f
at+njm=1
at+fsb=0
at+pn=1
at+ni=0,[senet app EUI]
at+nk=0,[device app key from senet]
at+txdr=10
at+txp=20
AT&W
ATZ
AT+JOIN

• This reply was modified 9 years ago by Jim Maricondo.
• This reply was modified 9 years ago by Jim Maricondo.
• This reply was modified 9 years ago by Jim Maricondo.
• This reply was modified 9 years ago by Jim Maricondo.
• This reply was modified 9 years ago by Jim Maricondo.

[Jim Maricondo]

Worked great, thank you.

[Jim Maricondo]

I’m having trouble getting my mDot EVB to connect to the public Senet network. How can I troubleshoot this? It was working back in July when I went to the MultiTech/Senet/Semtech workshop but now it doesn’t. Not sure if it is an issue with Senet, or I changed something by accident that broke it, or if the network reception is just too poor in my office.

I am using the MTDOT_Senet_Demo_23-July project from class, and it just gets an error -4 when it tries to join the network. I have replicated this using AT commands as follows.

How can I troubleshoot this further?

at+njm=1
at+fsb=0
at+pn=1
at+ni=0,xxxxxxxxxxxxxxxx
at+nk=0,xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
at+txdr=10
at+rxdr=10
at+txp=20
at+join
Join Error - Failed to join network
ERROR

NI is Senet’s App EUI.
NK is the App Key given by Senet after registering my mDot’s EUI Device ID.

at&v
Device ID:..yyy
Frequency Band:..FB_915
Frequency Sub Band:.0
Public Network:..on
Start Up Mode:..COMMAND
Network Address:.00000000
Network ID:.. xxxxxxxxxxxxxxxx
Network ID Passphrase:.
Network Key:.. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Network Key Passphrase:.
Network Session Key:.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00
Data Session Key:.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00
Network Join Mode:.OTA
Network Join Retries:.2
Join Byte Order:.LSB
Link Check Threshold:.off
Link Check Count:.off
Error Correction:.1 bytes
ACK Retries:..off
Encryption:..on
CRC:...on
Adaptive Data Rate:.off
Command Echo:..on
Verbose Response:.off
Tx Frequency:..0
Tx Data Rate:..SF_10
Tx Power:..20
Tx Wait:..on
Tx Inverted Signal:.off
Rx Frequency:..903700000
Rx Data Rate:..SF_10
Rx Inverted Signal:.on
Rx Output Style:.HEXADECIMAL
Debug Baud Rate:.115200
Serial Baud Rate:.115200
Wake Mode:..INTERVAL
Wake Interval:..10 s
Wake Delay:..100 ms
Wake Timeout:..20 ms
Log Level:..0

OK

[Jim Maricondo]

Here is a a messages dump which shows logging into Node-RED by connecting to the admin GUI on port 1880.

admin@mtcdt:~# tail -f /var/log/messages
Nov 18 11:51:09 mtcdt user.info API: [SESSION] Authorized Agent [admin] Permission [admin] IP [127.0.0.1] Port [] Token []
Nov 18 11:51:09 mtcdt user.info API: [ROUTER][GET][heartbeat]
Nov 18 11:51:09 mtcdt user.info API: [SESSION] Ending FCGI Request [5228] as [RESPONDER]
Nov 18 11:51:09 mtcdt daemon.info lighttpd[662]: 127.0.0.1 127.0.0.1 - [18/Nov/2015:11:51:09 -0800] "GET /api/heartbeat HTTP/1.1" 404 85 "-" "curl/7.35.0"
Nov 18 11:51:15 mtcdt daemon.notice stunnel: LOG5[7256]: Service [node-red] accepted connection from 10.2.0.192:54711
Nov 18 11:51:15 mtcdt daemon.err stunnel: LOG3[7256]: SSL_accept: Peer suddenly disconnected
Nov 18 11:51:15 mtcdt daemon.notice stunnel: LOG5[7256]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket
Nov 18 11:51:17 mtcdt daemon.notice stunnel: LOG5[7257]: Service [node-red] accepted connection from 10.2.0.192:54712
Nov 18 11:51:17 mtcdt daemon.err stunnel: LOG3[7257]: SSL_accept: Peer suddenly disconnected
Nov 18 11:51:17 mtcdt daemon.notice stunnel: LOG5[7257]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket

Nov 18 11:51:26 mtcdt daemon.notice stunnel: LOG5[7258]: Service [node-red] accepted connection from 10.2.0.192:54713
Nov 18 11:51:26 mtcdt daemon.err stunnel: LOG3[7258]: SSL_accept: Peer suddenly disconnected
Nov 18 11:51:26 mtcdt daemon.notice stunnel: LOG5[7258]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket
Nov 18 11:51:28 mtcdt daemon.notice stunnel: LOG5[7259]: Service [node-red] accepted connection from 10.2.0.192:54714
Nov 18 11:51:28 mtcdt daemon.err stunnel: LOG3[7259]: SSL_accept: Peer suddenly disconnected
Nov 18 11:51:28 mtcdt daemon.notice stunnel: LOG5[7259]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket
Nov 18 11:51:29 mtcdt daemon.notice stunnel: LOG5[7260]: Service [node-red] accepted connection from 10.2.0.192:54715
Nov 18 11:51:29 mtcdt daemon.notice stunnel: LOG5[7261]: Service [node-red] accepted connection from 10.2.0.192:54716
Nov 18 11:51:29 mtcdt daemon.err stunnel: LOG3[7260]: SSL_accept: Peer suddenly disconnected
Nov 18 11:51:29 mtcdt daemon.notice stunnel: LOG5[7260]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket
Nov 18 11:51:29 mtcdt daemon.info stunnel: LOG6[7261]: SSL accepted: new session negotiated
Nov 18 11:51:29 mtcdt daemon.info stunnel: LOG6[7261]: No peer certificate received
Nov 18 11:51:29 mtcdt daemon.info stunnel: LOG6[7261]: Negotiated TLSv1.2 ciphersuite ECDHE-RSA-AES256-GCM-SHA384 (256-bit encryption)
Nov 18 11:51:29 mtcdt daemon.info stunnel: LOG6[7261]: s_connect: connecting 127.0.0.1:1881
Nov 18 11:51:29 mtcdt daemon.notice stunnel: LOG5[7261]: s_connect: connected 127.0.0.1:1881
Nov 18 11:51:29 mtcdt daemon.notice stunnel: LOG5[7261]: Service [node-red] connected remote server from 127.0.0.1:35952
Nov 18 11:51:29 mtcdt daemon.notice stunnel: LOG5[7262]: Service [node-red] accepted connection from 10.2.0.192:54717
Nov 18 11:51:29 mtcdt daemon.info stunnel: LOG6[7262]: SSL accepted: previous session reused
Nov 18 11:51:29 mtcdt daemon.info stunnel: LOG6[7262]: s_connect: connecting 127.0.0.1:1881
Nov 18 11:51:29 mtcdt daemon.notice stunnel: LOG5[7262]: s_connect: connected 127.0.0.1:1881
Nov 18 11:51:29 mtcdt daemon.notice stunnel: LOG5[7263]: Service [node-red] accepted connection from 10.2.0.192:54718
Nov 18 11:51:29 mtcdt daemon.notice stunnel: LOG5[7264]: Service [node-red] accepted connection from 10.2.0.192:54720
Nov 18 11:51:29 mtcdt daemon.notice stunnel: LOG5[7265]: Service [node-red] accepted connection from 10.2.0.192:54721
Nov 18 11:51:29 mtcdt daemon.notice stunnel: LOG5[7266]: Service [node-red] accepted connection from 10.2.0.192:54719
Nov 18 11:51:29 mtcdt daemon.notice stunnel: LOG5[7262]: Service [node-red] connected remote server from 127.0.0.1:35953
Nov 18 11:51:29 mtcdt daemon.info stunnel: LOG6[7266]: SSL accepted: previous session reused
Nov 18 11:51:29 mtcdt daemon.info stunnel: LOG6[7266]: s_connect: connecting 127.0.0.1:1881
Nov 18 11:51:29 mtcdt daemon.info stunnel: LOG6[7263]: SSL accepted: previous session reused
Nov 18 11:51:29 mtcdt daemon.info stunnel: LOG6[7263]: s_connect: connecting 127.0.0.1:1881
Nov 18 11:51:29 mtcdt daemon.notice stunnel: LOG5[7263]: s_connect: connected 127.0.0.1:1881
Nov 18 11:51:29 mtcdt daemon.notice stunnel: LOG5[7263]: Service [node-red] connected remote server from 127.0.0.1:35955
Nov 18 11:51:29 mtcdt daemon.info stunnel: LOG6[7264]: SSL accepted: previous session reused
Nov 18 11:51:29 mtcdt daemon.info stunnel: LOG6[7264]: s_connect: connecting 127.0.0.1:1881
Nov 18 11:51:29 mtcdt daemon.notice stunnel: LOG5[7264]: s_connect: connected 127.0.0.1:1881
Nov 18 11:51:29 mtcdt daemon.notice stunnel: LOG5[7264]: Service [node-red] connected remote server from 127.0.0.1:35956
Nov 18 11:51:29 mtcdt daemon.notice stunnel: LOG5[7266]: s_connect: connected 127.0.0.1:1881
Nov 18 11:51:29 mtcdt daemon.notice stunnel: LOG5[7266]: Service [node-red] connected remote server from 127.0.0.1:35954
Nov 18 11:51:29 mtcdt daemon.info stunnel: LOG6[7265]: SSL accepted: previous session reused
Nov 18 11:51:29 mtcdt daemon.info stunnel: LOG6[7265]: s_connect: connecting 127.0.0.1:1881
Nov 18 11:51:29 mtcdt daemon.notice stunnel: LOG5[7265]: s_connect: connected 127.0.0.1:1881
Nov 18 11:51:29 mtcdt daemon.notice stunnel: LOG5[7265]: Service [node-red] connected remote server from 127.0.0.1:35957
Nov 18 11:51:31 mtcdt daemon.notice stunnel: LOG5[7267]: Service [node-red] accepted connection from 10.2.0.192:54722
Nov 18 11:51:31 mtcdt daemon.err stunnel: LOG3[7267]: SSL_accept: Peer suddenly disconnected
Nov 18 11:51:31 mtcdt daemon.notice stunnel: LOG5[7267]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket
Nov 18 11:51:32 mtcdt daemon.notice stunnel: LOG5[7268]: Service [node-red] accepted connection from 10.2.0.192:54723
Nov 18 11:51:32 mtcdt daemon.err stunnel: LOG3[7268]: SSL_accept: Peer suddenly disconnected
Nov 18 11:51:32 mtcdt daemon.notice stunnel: LOG5[7268]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket
Nov 18 11:51:33 mtcdt daemon.notice stunnel: LOG5[7269]: Service [node-red] accepted connection from 10.2.0.192:54724
Nov 18 11:51:33 mtcdt daemon.err stunnel: LOG3[7269]: SSL_accept: Peer suddenly disconnected
Nov 18 11:51:33 mtcdt daemon.notice stunnel: LOG5[7269]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket
Nov 18 11:51:34 mtcdt daemon.notice stunnel: LOG5[7270]: Service [node-red] accepted connection from 10.2.0.192:54726
Nov 18 11:51:34 mtcdt daemon.err stunnel: LOG3[7270]: SSL_accept: Peer suddenly disconnected
Nov 18 11:51:34 mtcdt daemon.notice stunnel: LOG5[7270]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket
Nov 18 11:51:35 mtcdt daemon.notice stunnel: LOG5[7271]: Service [node-red] accepted connection from 10.2.0.192:54727
Nov 18 11:51:35 mtcdt daemon.err stunnel: LOG3[7271]: SSL_accept: Peer suddenly disconnected
Nov 18 11:51:35 mtcdt daemon.notice stunnel: LOG5[7271]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket
Nov 18 11:51:36 mtcdt daemon.notice stunnel: LOG5[7272]: Service [node-red] accepted connection from 10.2.0.192:54728
Nov 18 11:51:37 mtcdt daemon.err stunnel: LOG3[7272]: SSL_accept: Peer suddenly disconnected
Nov 18 11:51:37 mtcdt daemon.notice stunnel: LOG5[7272]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket
Nov 18 11:51:38 mtcdt daemon.notice stunnel: LOG5[7273]: Service [node-red] accepted connection from 10.2.0.192:54729
^C
admin@mtcdt:~# 

• This reply was modified 9 years ago by Jim Maricondo.

[Jim Maricondo]

Hi Jeff,

Thank you for the prompt response. Where is the option for developer tools/console output? I can’t find it in the admin GUI.

I logged in and checked the processes and actually the node-red process has been running continuously since the device was started. However, the Node RED GUI still always gives the lost connection error, and furthermore my Node RED flow to dump the payload does not get executed.

I thought maybe some of this info might be helpful? What do you think I should do next?

Thanks,
-Jim

admin@mtcdt:~# more /var/log/app/development.log

Welcome to Node-RED
===================
16 Nov 17:37:00 - [info] Node-RED version: v0.10.4
16 Nov 17:37:00 - [info] Node.js  version: v0.8.28
16 Nov 17:37:00 - [info] Loading palette nodes
16 Nov 17:38:00 - [info] User Directory : /var/config/app/install/development
16 Nov 17:38:00 - [info] Flows file     : /var/config/app/install/development/flows.json
16 Nov 17:38:01 - [info] Server now running at http://127.0.0.1:1881/
16 Nov 17:38:01 - [info] Starting flows
16 Nov 17:38:02 - [info] [lora in:10a69305.ef596d] lora in node created
16 Nov 17:38:02 - [info] Started flows
16 Nov 17:38:02 - [info] [lora in:10a69305.ef596d] mcard: true
16 Nov 17:38:02 - [info] [lora in:10a69305.ef596d] Connected to MQTT for LoRa in node.
Attempting to log in as: admin
Status code: 200
Attempting to log out using token: DABD9D8E93D23D07D395813FDEDDF25
admin@mtcdt:~# ls -l /var/log/app/development.log
-rw-r--r--    1 admin    root           845 Nov 17 13:52 /var/log/app/development.log
admin@mtcdt:~# date
Wed Nov 18 11:48:18 PST 2015

admin@mtcdt:~# tail /var/log/messages
Nov 18 11:49:39 mtcdt daemon.notice stunnel: LOG5[7211]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket
Nov 18 11:49:41 mtcdt daemon.notice stunnel: LOG5[7212]: Service [node-red] accepted connection from 10.2.0.192:54638
Nov 18 11:49:41 mtcdt daemon.err stunnel: LOG3[7212]: SSL_accept: Peer suddenly disconnected
Nov 18 11:49:41 mtcdt daemon.notice stunnel: LOG5[7212]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket
Nov 18 11:49:43 mtcdt daemon.notice stunnel: LOG5[7213]: Service [node-red] accepted connection from 10.2.0.192:54639
Nov 18 11:49:43 mtcdt daemon.err stunnel: LOG3[7213]: SSL_accept: Peer suddenly disconnected
Nov 18 11:49:43 mtcdt daemon.notice stunnel: LOG5[7213]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket
Nov 18 11:49:45 mtcdt daemon.notice stunnel: LOG5[7214]: Service [node-red] accepted connection from 10.2.0.192:54640
Nov 18 11:49:45 mtcdt daemon.err stunnel: LOG3[7214]: SSL_accept: Peer suddenly disconnected
Nov 18 11:49:45 mtcdt daemon.notice stunnel: LOG5[7214]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket

[Jim Maricondo]

Hi Andrew,

Just wondering, what GPS module did you use with the mDot? Did you use the stock mbed dev board? I am thinking about doing something similar. My hardware background is a little limited so I am looking for something easy.

Thanks,
-Jim

[Jim Maricondo]

Seriously, why is there no mDot EVB Developer’s Guide? Something that shows all the pinouts, buttons, etc. The EVB equivalent of the “MTDOT Developer Guide”. All I know is https://developer.mbed.org/platforms/mdotevb/ – I guess that is all the info that is available…

• This reply was modified 9 years ago by Jim Maricondo.

[Jim Maricondo]

I’ve got the same problem and can’t get the AT commands to work on my mDot EVB dev board. I assume that the AT command firmware for the mDot on http://www.multitech.net/developer/downloads/ is designed for the MTUDK2-ST-MDOT.

Can you please tell me exactly what you changed those two lines to in main.cpp in the mDot_AT_firmware project? I’d also like to recompile it for my EVB.

Serial debug(USBTX, USBRX);
mts::MTSSerial serial(XBEE_DOUT, XBEE_DIN, 512, 512);

I assume they are set as is for compatibility with the MTUDK2-ST-MDOT, which uses the DB9 serial port for AT commands.

Thanks,
-Jim

[Jim Maricondo]

I have a similar problem connecting to Node RED. In my case, I am able to access the Node RED app just fine. However, upon accessing it, I immediately get an error “Error: Lost connection to server”. Why?

I tried creating the demo case to dump the msg.payload of an incoming LoRa packet, but it does not work.

How can I troubleshoot this? Would like to get it working ASAP. Thank you.

You can see a screenshot at:
https://drive.google.com/file/d/0B3VFuV8cdsgUeXhZY1hQbGpkQUk/preview

• This reply was modified 9 years ago by Jim Maricondo.
• This reply was modified 9 years ago by Jim Maricondo.
• This reply was modified 9 years ago by Jim Maricondo.
• This reply was modified 9 years ago by Jim Maricondo.

[Author]

Posts