Brandon Bayer
Forum Replies Created
-
AuthorPosts
-
Brandon Bayer
BlockedLawrence,
So I found some older measurements on data usage and check-ins are actually more on the order of 4KB. We are going to add the data usage to the DeviceHQ user guide.
-Brandon
BlockedPatrick,
Ok, sorry about the delay. I’ll try to get that moving.
-Brandon
BlockedPatrick,
The lights as you see them are correct. From everything you’ve described, your setup should be working.
Please create a support case for this.
The EVB is basically an mDot with sensors attached, so it should be very similar.
-Brandon
-
This reply was modified 9 years, 5 months ago by
Brandon Bayer.
BlockedPatrick,
Ah, ok I understand your cable setup now. That should work.
Yes, that sounds correct for firmware flashing.
Which firmware are you loading on the mDot? You should be using the AT Command Firmware available from the Downloads page.
-Brandon
BlockedLawrence,
1) Yes, change Timeout Minutes on Access Configuration under the Administration menu.
2) We haven’t done any analysis on this, so we can’t give you good answers. However, check-in will be the largest size but shouldn’t be over 500K. App download overhead and re-boot should be quite small.
If you want exact data, ssh into the Conduit and capture DeviceHQ comms with tcpdump. Then you can copy the file to your computer and view it with wireshark.
-Brandon
BlockedVikram,
All you should have to do on 1.0.33 after changing eth0 to WAN is to go to Firewall > Settings and create an Inbound Filter Rule with the Destination Port set to 1880. This will allow incoming connections to port 1880 over WAN.
-Brandon
BlockedPatrick,
The mDot has two serial ports:
1) Serial over USB (which you are using). By default this is for output logging only.
2) Serial through the UDK’s DB9 connector. By default this is used for AT Commands,So you’ll need to use the DB9 connector to issue AT commands.
Make sense?
-Brandon
BlockedJon,
Ping’s payload size is 0.
-Brandon
BlockedWith that setup, the mDot effective transmit power is 23 dBm and the Conduit’s is 26 dBm. So the RSSI should be slightly higher than PING (which it is).
-Brandon
BlockedJon,
Yes, you can!
-Brandon
BlockedJon,
By default, the AT Command firmware uses the serial port through the DB9 connector on the UDK, not the virtual USB COM port.
See if that works for you.
-Brandon
BlockedAdhavan,
Ok, understood. Which mDot serial port is the arduino connected to? It should be the same one on which you issue AT Commands. Are you sure the serial connection is correct? I.e. Rx connected to Tx and vice versa?
-Brandon
BlockedAdhavan,
Have you seen this forum thread?: http://www.multitech.net/developer/forums/topic/mdot-serial-data-mode/
Also the two FAQ’s on serial mode at the bottom of this page: https://developer.mbed.org/platforms/MTS-mdot-f411/
-Brandon
BlockedJohn,
Ok, it’s a really good chance your MTAC-LORA is defective and causing at least some of your issues. Also, there is a small bug in Conduit firmware 1.0.33 that can create problems for receiving data over 868 (this will be fixed in the next release).
To get it replaced for free, open a support case and include the following:
1) Your name
2) Your company
3) Return address
4) Contact phone number
5) MTAC-LORA serial number-Brandon
BlockedJohn,
I’m wondering if you have a defective MTAC-LORA card. Early production ones had a solder issue that’s since been fixed.
When did you get your MTAC-LORA? What is it’s serial number (visible on the Conduit’s homepage dashboard)?
-Brandon
BlockedJohn,
Please issue AT+PING before AT+RSSI. The order is important.
-Brandon
BlockedJohn,
Please load the AT Command Firmware on the mDot for the test (available from the downloads page).
The delay in the while loop should not negatively affect the join.
-Brandon
BlockedJohn,
Thanks for the helpful information. Please do the following test:
1) Place Conduit & mDot right beside each other
2) Take antennas off mDot & Conduit
3) Set Conduit tx power to 26
4) Set mDot tx power to 20
5) Have mDot join network
6) On mDot issue, AT+PING then AT+RSSI and post the output of these two commands.-Brandon
BlockedJohn,
Can you describe exactly the behavior you are seeing and what you expect?
-Brandon
BlockedJames,
I suggest looking at the documentation for whatever cloud server you want to use. They probably have examples for posting data from the command line using
curland for different programming languages. Get it working usingcurland then use the same keys, settings, etc. in your preferred language. If you need further help getting data to the cloud server, I suggest contacting them for help. We can help with Conduit specific things (like running the nodejs sample app), but we can’t support other cloud servers.-Brandon
BlockedHenry,
We don’t currently support that. Your best bet would be to use Node-RED (or a simple nodejs app) as a proxy to receive MQTT from the lora server and then post them to another, secured MQTT server.
-Brandon
BlockedAndrew,
TTN doesn’t currently support ACKs (according to Johan), so you’ll want to disable that for now.
Also, TTN has a back-end issue where all received packets don’t show up through the API. Quoting Johan from the TTN forum thread:
Now, we have a storage issue on our back-end. Turns out that not all data is being routed correctly and stored as it should.
So you’ll only want to rely on the packet forwarder logs for verifying packets are being forwarded to TTN. Here’s an example where the forwarder receives 1 valid packet and 1 ghost packet from noise. You can see in the UPSTREAM log that 1 packet was CRC_OK and was forwarded to TTN:
lgw_receive:1428: FIFO content: Pkts: 1 6c 0 Stat: 5 Size: 12 lgw_receive:1443: [6 17] //<--- VALID PACKET Note: LoRa packet lgw_receive:1428: FIFO content: Pkts: 1 8e 0 Stat: 7 Size: 7f lgw_receive:1443: [5 17] //<--- GHOST PACKET FROM NOISE Note: LoRa packet WARNING: [down] ignoring invalid packet ##### 2015-10-26 13:36:57 GMT ##### ### [UPSTREAM] ### # RF packets received by concentrator: 1 # CRC_OK: 50.00%, CRC_FAIL: 50.00%, NO_CRC: 0.00% # RF packets forwarded: 1 (18 bytes) # PUSH_DATA datagrams sent: 1 (234 bytes) # PUSH_DATA acknowledged: 0.00% ### [DOWNSTREAM] ### # PULL_DATA sent: 2 (0.00% acknowledged) # PULL_RESP(onse) datagrams received: 0 (0 bytes) # RF packets sent to concentrator: 0 (0 bytes) # TX errors: 0 ##### END #####-Brandon
BlockedMichal,
No, those were pre-release beta versions and are not available any more.
1.0.33 still has the same lora logging, but it’s now in
/var/log/messages-Brandon
BlockedIf they are undefined, it means you haven’t defined them. As you can see in the example sensor program,
dotis defined like this:mDot* dot; Ticker ledTick;-Brandon
BlockedJames,
Here is an example that transmits temperature data:
-Brandon
October 21, 2015 at 11:33 am in reply to: Intermittent reception of LoRa packets with MT gateway #9677BlockedAntony,
Great!
The gateway will always use the first window only except when there is a tx scheduling conflict. In that case, it’ll use only the second window. It should never transmit during both windows. And there is no way to reconfigure this behavior.
-Brandon
BlockedOctober 15, 2015 at 11:47 am in reply to: Intermittent reception of LoRa packets with MT gateway #9643BlockedAlright, sounds good! Keep us updated.
-Brandon
October 15, 2015 at 9:07 am in reply to: Intermittent reception of LoRa packets with MT gateway #9627BlockedAntony,
Good to hear!
Unless you got your MTAC-LORA card recently, it could have a problem transmitting (super low range).
You can run this test with an mDot to evaluate it:
1) Place Conduit & mDot right beside each other
2) Take antennas off mDot & Conduit
3) Set Conduit tx power to 26
4) Set mDot tx power to 20
5) Have mDot join network
6) On mDot issue, AT+PING then AT+RSSI and send us the output of these two commands.The RSSI response should be higher than PING because the Conduit is transmitting at a higher power.
-Brandon
BlockedPatrick,
It’s a significant problem because no one has done it before (that we know of), and there isn’t an obvious straightforward way to do it. I suggest emailing marketing at
mtsmktg@multitech.comand fully describe what you’d like it to do (they & product management decide what features go into the Conduit).Unfortunately, you can’t currently configure AEP to match the TTN network.
With any network server settings, you can use Node-RED to publish received LoRa packets to any MQTT server, but I don’t know if TTN supports receiving data via MQTT.
-Brandon
-
This reply was modified 9 years, 5 months ago by
-
AuthorPosts