[Ajay K]

Now I get the same error when I use pin PC_13. Is there libmdot version that wouldn’t throw an error using this pinname? If I go to the pinnames.h file under the mdot target folder in the mbed-os github repository, I do see the pinname defined, however I don’t get a compilation error, but does error out when the application runs.

Can you let me know the right revision to use?

Thanks,
Ajay

[Ajay K]

Hi Mike,

The AT commands don’t work and I have configured the baud rate to 115200. I got the firmware from the multitech site downloads. As mentioned previously the o/p stops at “[INFO] Flashing new firmware successful”. However in the UDK board if I flash it via the ymodem option, not only does it flash it successfully with the same text “[INFO] Flashing new firmware successful” in the tera term screen, but is followed by “mDot ready” debug o/p. This I am assuming shows up because not only was the firmware updated successfully, but also was started successfully to run.

However on our custom board, this doesn’t happen, so my guess is even though the firmware is loaded successfully as stated above in the tera term window, it is not able to run the updated firmware. Any thoughts on why this could be happening or how I can debug this further?

Thanks,
Ajay

[Ajay K]

Here is the bootloader prompt o/p and after the flash was successful, it just sits there and it looks like its not able to start the application? How can I debug this further?

bootloader :> transfer ymodem
[INFO] Starting YMODEM file transfer
[INFO] YMODEM file transfer succeeded
bootloader :> flash
[INFO] Starting flash
[INFO] appended crc: 2244052040
[INFO] calculated crc: 2244052040
[INFO] erasing sector 4 addr 0X8010000
[INFO] erasing sector 5 addr 0X8020000
[INFO] erasing sector 6 addr 0X8040000
[INFO] erasing sector 7 addr 0X8060000
[INFO] 0X2C124 bytes remaining
[INFO] 0X2A124 bytes remaining
[INFO] 0X28124 bytes remaining
[INFO] 0X26124 bytes remaining
[INFO] 0X24124 bytes remaining
[INFO] 0X22124 bytes remaining
[INFO] 0X20124 bytes remaining
[INFO] 0X1E124 bytes remaining
[INFO] 0X1C124 bytes remaining
[INFO] 0X1A124 bytes remaining
[INFO] 0X18124 bytes remaining
[INFO] 0X16124 bytes remaining
[INFO] 0X14124 bytes remaining
[INFO] 0X12124 bytes remaining
[INFO] 0X10124 bytes remaining
[INFO] 0XE124 bytes remaining
[INFO] 0XC124 bytes remaining
[INFO] 0XA124 bytes remaining
[INFO] 0X8124 bytes remaining
[INFO] 0X6124 bytes remaining
[INFO] 0X4124 bytes remaining
[INFO] 0X2124 bytes remaining
[INFO] 0X124 bytes remaining
[INFO] 0 bytes remaining
[INFO] Flashing new firmware successful

[Ajay K]

Thanks Mike for your timely response and update. Would you be able to provide a timeline as to when the PVD support for the production version of the libmdot library be out with the pinmap fix that seems to be resolved in the latest dev library?

One of the reasons I was using the dev library was because the version I was using was one version after the stable production library with PVD feature support and I was told upgrading to that version was safe enough to test with. However as per your response I would be on a version that possibly is several versions ahead of the current production build of the libmdot?

Thanks,
Ajay

[Ajay K]

Hey Mike,

I just mis-spelled that when I wrote it in the forum thread. However it is correctly used in the program. The XBEE related serial pins are only used in my actual application. The test application I wrote just to test a basic serial ports isn’t even working. In my test application as I mentioned I just use the debug USB ports to communicate with the mdot. This should have worked as is without any issues. As this works perfectly well in the older version and not sure why porting my application to mbed os 5 and libmdot os5 version should throw this error.

Is there a list of pin names that are no longer valid in the new version of libmdot built for mbed os5?

Thanks,
Ajay

[Ajay K]

Hi Mike,

I am just using the serial objects. Since I just created a basic MBED serial object in my test application and all I do is access the debug serial port using USBTX and USBRX and set the baud. I call the MDot Logging API. But my original application uses XBEE_IN and XBEE_DOUT to access the db9 serial connector, in addition to the debug ports on the UDK board.

Both the application give out the same error. I don’t get any error in the earlier version of mdot lib and mbed os.

Thanks,
Ajay

[Ajay K]

I was wondering if I could get some clarifications regarding running i the deep sleep mode.

I run additional threads in my application and during the deep sleep mode, are these threads suspended and re-started on wake up or do I need to re-start it again?

Since the memory is kept intact in the new deep sleep mode, I am assuming the additional thread stack stays intact as well?

Thanks,
Ajay

[Ajay K]

Hi Jeff,

Sorry another follow up question, has the multitech team tested the conduit with a mongo db install? If so what version of mongo db should I be using as I see on the mongo db site there are various flavors depending on the OS, not sure which one to specifically pick?

Thanks,
Ajay.

[Ajay K]

Hi Jeff,

Thank you so much for your quick response.

What is the best way to install Mongodb on the conduit? I don’t think the data could exceed 1mb, but I could just to be sure ensure the actual data is on the SD card instead.

One other question I had as of today, my conduit is connected to the internet via the cellular connection i.e. via the sim card. I can’t get the conduit to use my in house internet connection. I didn’t see any steps on the multi-tech site how to configure internet connection when connected to my laptop.

Thanks,
Ajay.

[Ajay K]

Thanks a lot Andrew for running those tests. We are going to begin those test shortly as well on libmdot 17 revision. By the Dot examples you meant using libmdot-mbedos5 or the latest libmdot revision 17 on the older mbed os?

Thanks,
Ajay.

[Ajay K]

Thanks Mike and Andrew for your inputs. so based on Andrews comments the latest libmdot removes the deep sleep feature, while the version I am on currently supports it. Although we wanted to originally use the non deep sleep mode because of the RAM being intact, but we chose the deep sleep mode because of the lower current consumption.

So Mike are there tests from the Multitech side confirming that the current consumption in the non deep sleep mode is in the ~50UA range? Is there any links on the site that you can point me to wrt to the new current consumption under non-deep sleep mode, before we switch over? Although its a technical decision, once the mdots are in the field the firmware updates would be harder to implement.

Thanks,
Ajay

[Ajay K]

Hey Jeff,

You mentioned the following in your last post:
“Once AEP 1.3.x is released there is a sample Node application that we have been using in-house to test with that we call “express-hello-world” that is a simple web server app that you could probably use as a reference.”

Can you point me to his express-hello-world sample?

Thanks,
Ajay.

[Ajay K]

Thanks Jeff for the information.

[Ajay K]

Thanks so much Jeff for taking the time to respond in detail. When is the AEP 1.3 release due to be out? Also I may have asked this question before what is the supported version of nodejs on this platform? With the custom applications would they have to be deployed via Device HQ?

Thanks,
Ajay.

[Ajay K]

Thanks Jason for your quick response. Some follow up questions.

1) How many times will it retry sending the same packet if the Ack is not received.
2) You talked about a sequence number, is it possible to read this value in the node-red flow?

3) Also since there is a fixed limit to the queue per mdot/end device connected to the conduit, how does the lora output node handle the queue max size being hit?

4) One last question, the mqtt request_sent topic what kind of information does it provide, other than the packet being sent via the radio? Does it provide any additional information.

[Ajay K]

Thanks Jason and Lawrence for taking the time to respond.

Packet sent – a packet has been sent to the radio to be transmitted
lora/<DEV-EUI>/packet_sent

would the above MQTT output topic indicate that the message was sent successfully or is it more a pre-send notification.

Also as Lawrence called out, if I am right the LORA output node, has a checkbox to receive acks on transmission, does this require the MDot to turn on acks on its end as well? Is this checkbox for the LORA output node to internally figure out if the message was transmitted successfully and would it throw an exception which can be handled by the catch node?

Thanks,
Ajay.

[Ajay K]

Thanks Brandon. How about the startup scenario, is there a way to read the data stored in a file before the flows begin processing any data?

Thanks,
Ajay.

[Ajay K]

Any thoughts related to the sends while the downlink packet is being processed by the Lora MAC events? Does the MDot API handle this scenario without any custom code being written?

[Ajay K]

Thats the plan to sleep between sensor reads and its good to know we are able to get the current time. Thanks Mike for your prompt response.

[Ajay K]

Thanks Mike for your response!

Is there a way to set the system date/time or figure out the system date/time in the mdot, so I can figure out how much time elapsed so I can address the other scenario described above where I am trying to read a sensor every several minutes?

Thanks,
Ajay

[Ajay K]

Hi Jason,

I have a follow up question. mDot API has an getIsTransmitting function to check if there is current uplink in progress. However after a send is executed in a non-blocking mode and as I would have subscribed to the LORA MAC Events, I would receive the various events as described by you in the earlier.

My Question is since I would be executing a Send in a non-blocking mode and lets say there was a down link packet expected. Would I be able to transmit immediately or the receive needs to complete before any transmit can occur? If so would I need to use some kind of thread synchronization such as MBED’s thread Signaling, since I am assuming the LORA MAC events are running on a different thread.

Thanks,
Ajay

[Ajay K]

Thanks Jason, that worked. By the way mDot::FM_CREAT does it create files always or if it exists, the file is overwritten?

[Ajay K]

Hi Jason,

I set the log level to trace_level and there were no trace debug outputs generated for the writeUserFile call. However I tried using another API call appendUserFile which is mentioned below and it worked fine. However I am assuming in this API call the file will be opened and closed every time I call this API correct? If so I am not sure if its efficient to open and close the file repeatedly and so I was using the writeUserFile API Call described earlier in this forum thread.

bool appendUserFile(const char* file, void* data, uint32_t size);

In reality I would be writing out a vector containing structs with fixed size containing data that needs to be stored and reloaded after a deep sleep.

Thanks,
Ajay.

[Ajay K]

Any Ideas as to why the writeUserFile API call is failing? I have set the log level to tracel_level for the mdot. However I don’t see any trace logs to see what the underlying issue may be for the write failures.

I was hoping to resolve this issue quickly, as I need to test the mdot under deep sleep mode and when it wakes up to be able to read this file that I saved before the mdot going into deep sleep mode.

Thanks,
Ajay.

[Ajay K]

Thanks Jason for the quick response. I am guessing the MQTT input and output nodes in node-red will help me with the same thing that was achieved in the link related to the mLinux version, where the sample code subscribes to the MQTT broker and sends and receives messages from the LORA network server?

Thanks,
Ajay.

[Ajay K]

Hi Jason,

Can you point me to any documentation as to how I would achieve sending an MQTT message to the network server from Node-Red flow? I see the details based of the link you sent, however I am not familiar with the MQTT node or how the protocol works.

Thanks,
Ajay.

[Ajay K]

Thanks Brandon. Is that the standard node_modules path that the node-red would recognize? Also the feature requests in the earlier threads which Lawrence seems to have requested a while back was the once I was talking about…
“custom NR node preservation on Firmware update
LoRaOUT node I want to track & guarantee the sending of downlink commands to mDots.”

Thanks,
Ajay.

[Ajay K]

Just wanted to check the status of some of the feature requests in the earlier forum threads, are they implemented in the latest 1.2.2 build?

I was looking to build a custom node module so I can npm install it into the node-red. These are custom utility functions to manage the data that I would re-use from my Node-Red function nodes. With the current version of AEP would these node-modules need to be re-installed on a firmware upgrade or would get blown away on an NR Reboot/full system reboot?

Thanks,
Ajay.

[Ajay K]

Thanks Jason for your response. Makes things a lot easier to manage in an asynchronous fashion and the events make it lot easier to manage the next uplink as well.

Thanks,
Ajay.

[Ajay K]

Jason,

Just wanted to clarify regarding the asynchronous functionality. Do I have to explicitly call a recv method on the mDot object or is it good enough to call the Send and the corresponding LoraMacEvents will fire as shown in the source code that you shared and eventually the recv event would fire?

Thanks,
Ajay.

[Author]

Posts