[Mark Makarychev]

Hm, ok. Thanks for the answer Jason.

[Mark Makarychev]

One more quick question, if you don’t mind. Time to time I get the following error on saving configurations for the mDot:

[INFO] Saving configuration
[ERROR] SPIFFS_write failed -10015

This error also comes from the library – correct? What does it mean/what can be causing it? It doesn’t seem to affect how the mDot works (in any way I can see at least), but it doesn’t sound like something good (especially since SPIFFS probably stands for SPI Flash File System)…

[Mark Makarychev]

Oh, OK.
Thanks!

[Mark Makarychev]

Never mind – found what was wrong!

When I was updating the mDot library to V3.0.0 and all my code with it, I added the dot_util files as well (from the example), but only transferred the functions I thought I needed from them. But what I forgot is that my project doesn’t use the dot_util files anymore, as it uses its own “util” file. The “dot” in the dot_util file was not initialized (lacked the “mDot::getInstance(plan)” line), since it was being initialized and used in my other “util” file, and apparently a “dot” without an instance can successfully returns DI8 every time you call getWakePin!

I guess this is another example of when not deleting old code can lead to hours of troubleshooting, ha ha!

But as a side note – I’m still interested where the line ““[INFO] entering sleep (stop) mode 00000037” comes from in the message above…

[Mark Makarychev]

Whats even more interesting that it seems to sleep/wake just fine upon Join Error:

[INFO] Configure radio for TX
[WARNING] Radio Busy, cannot open Rx Window
[ERROR] Failed to join network
[ERROR] Failed to join network -4:Join Error
[INFO] entering sleep (stop) mode 00000037
▒(here it wakes successfully!)
[INFO] Send join request RxDelay: 0 Rx1Offset: 0 Rx2Freq: 869525000 Rx2Dr: 0
[INFO] Configure radio for TX

Although I can’t find “[INFO] entering sleep (stop) mode 00000037” anywhere, to see how it’s going into sleep – is this part of the mbed-os library?

dot_util contains something close, but it’s obviously not what’s being printed (confused why I don’t see anything along the lines of “…until next free channel”)

ret = dot->joinNetwork();
        if (ret != mDot::MDOT_OK) {
            logError("failed to join network %d:%s", ret, mDot::getReturnCodeString(ret).c_str());
            // in some frequency bands we need to wait until another channel is available before transmitting again
            uint32_t delay_s = (dot->getNextTxMs() / 1000) + 1;
            if (delay_s < 2) {
                logInfo("waiting %lu s until next free channel", delay_s);
                wait(delay_s);
            } else {
                logInfo("sleeping %lu s until next free channel", delay_s);
                dot->sleep(delay_s, mDot::RTC_ALARM, false);
            }
        }

• This reply was modified 6 years, 3 months ago by Mark Makarychev.
• This reply was modified 6 years, 3 months ago by Mark Makarychev.
• This reply was modified 6 years, 3 months ago by Mark Makarychev.

[Mark Makarychev]

Hello Leon,

The example code works fine on its own (both interrupt and RTC wake the mDot successfully), so the problem is not in the mDot itself. Calling the API directly from the main project acts the same as when calling it from mdotUtil (sleep not working, setWakePin not setting).

It seems to be some bug that occurs when my project interacts with the API, but I can’t seem to find why it’s acting the way it is… I guess I’ll just have to continue thoroughly inspecting my code until I find the problem. Is there any commands or settings I can use to get feedback from the library? For example – what error codes are risen before the controller hangs, or what happens when I call setWakePin? Is TRACE the lowest level of logging available?

Thanks,
Mark.

[Mark Makarychev]

Hello Martin,
I added the DigitalIn, InterruptIn, and .mode(PullDown) lines to my code, but the sleep/wake still doesn’t seem to work.

[Mark Makarychev]

Hello,
Has this been added yet?

There is currently not a message the device can send to signal that it is Class C.

If not, in what version is it expected/planned to be added?

[Mark Makarychev]

Doing a bit more research, found a few more things that might work, although I haven’t quite tried them yet:

1. Setting the lease time on the gateway to 5-10 minutes should (in theory) cause the devices to try to reconnect every 5-10 minutes. This way, if it goes out of reach of one gateway and enters the coverage area of another, after 5-10 minutes it should establish a new connection with the new gateway, correct?

2. Right now I’m using OTA join mode, but looking once more, I noticed that there is also a manual mode. If I configure identical network addresses, network session keys, and data session keys on each gateway for each device (will take quite some time though…), both of the gateways should hear all devices that are in their reach, correct?

[Mark Makarychev]

Momo, for class C to work, you need to also tell the gateway(*) that node ‘X’ is a class C device. In the class_c_example.cpp there is a send function to send data to the gateway, but this does not mean that the node receives data only after sending. If you initialized the mDot as class C, it will be continuously listening for packages from the gateway – not just after sending (as a class A device would).

(*) Now: how to set up a node as class C on the gateway:
1. Connect to the gateway whichever way is easier for you. I usually just connect through the microUSB port on the back and connect to the gateway through putty (COM device).
2. Type: lora-query -n to list all the connected nodes. Find your class C node in the list and remember what number it is (00000000X).
3. Then type lora-query –u 00000000X class C to set node X as a class C device. When both the node is initialized as Class C and the gateway knows that this node is Class C, you should be able to receive packets from the gateway right away.
4. Type /etc/init.d/lora-network-server restart to restart the gateway and save the new configuration.

• This reply was modified 6 years, 11 months ago by Mark Makarychev.

[Mark Makarychev]

Uh-huh, ok, now my calculations seem much more correct. Thank you! Turns out that constantly listening in class C is quite power consuming! Do you happen to know when MultiTech will be adding class B to their mDot library and gateway firmware? Switching to class B in theory should increase my battery life by about 50%. Would be a nice optimization to have!

[Mark Makarychev]

Hello Yogesh,

No, I just found some library using ARM mbed’s built in search functionality. I wasn’t aware os5 had an I2C API. Might even check it out myself now, haha!

[Mark Makarychev]

Sorry for the false alarm, it wasn’t a leak in your library after all! Hurray!!! Found a very helpful page: https://docs.mbed.com/docs/mbed-os-handbook/en/5.2/advanced/runtime_mem_trace/, turned on memory tracing for mbed OS (how very thoughtful of them!), and found that a poorly written I2C library was not freeing memory after allocating it =/. Thanks for your help anyways!

[Mark Makarychev]

Still getting the error after around one hour of sending with the duty-cycle enabled. I’m not dismissing the idea that it might be some other library’s fault, but it’s just strange, that the out of memory error always occurs on the “preparing frame” stage, and not when other libraries’ functions are being called. I’ll do some more testing and try to get an error from other parts of my code – if something is leaking every hour with sends, it should still leak without them, right? Just might take longer. I’ll write back if I find anything.

[Mark Makarychev]

Using mdot-library revision 2.0.16-7-ga61aab1 with mbed-os-5.3.4 I got to 1600+ frames (FCnt over 640) without any errors. Not bad so far! However, these 1600+ frames were sent with duty-cycle restrictions turned off to speed up the test. I’ll write back once more after doing a true test with the duty-cycle enabled.

[Mark Makarychev]

I was originally using libmdot-dev-mbed5 and moved to the “not-dev” version, thinking that this might be an instability in the “dev” version. Although, I’m not sure I was using the mbed-OS version the libmdot-dev-mbed5 was tested against. I’ll try one more “clean” test tomorrow. By the way, just to be clear: is it that you can’t recreate the error, or has the library just not been tested in such a manner before?

[Mark Makarychev]

Forgot this little bit:

void send_data(const std::vector<uint8_t>& data) {
    uint32_t ret = dot->send(data);
    if (ret != mDot::MDOT_OK) {
        logError("failed to send data to %s [%d][%s]", dot->getJoinMode() == mDot::PEER_TO_PEER ? "peer" : "gateway", ret, mDot::getReturnCodeString(ret).c_str());
    } else {
        logInfo("successfully sent data to %s", dot->getJoinMode() == mDot::PEER_TO_PEER ? "peer" : "gateway");
    }
}

[Mark Makarychev]

std::vector<uint8_t> payload;

int main() {
    /*--------LoRa Configuration-----------------*/
    // Custom event handler for automatically displaying RX data
    RadioEvent events;
    mts::MTSLog::setLogLevel(mts::MTSLog::TRACE_LEVEL);
    dot = mDot::getInstance();
    logInfo("mbed-os library version: %d", MBED_LIBRARY_VERSION);
    
    // start from a well-known state
    logInfo("defaulting Dot configuration");
    dot->resetConfig();
    dot->resetNetworkSession();

    // make sure library logging is turned on
    dot->setLogLevel(mts::MTSLog::INFO_LEVEL);

    // attach the custom events handler
    dot->setEvents(&events);

    // update configuration if necessary
    if (dot->getJoinMode() != mDot::OTA) {
        logInfo("changing network join mode to OTA");
        if (dot->setJoinMode(mDot::OTA) != mDot::MDOT_OK)
            logError("failed to set network join mode to OTA");
    }
    // in OTA and AUTO_OTA join modes, the credentials can be passed to the library as a name and passphrase or an ID and KEY
    update_ota_config_name_phrase(network_name, network_passphrase, 0, public_network, ack);
    
    // configure the Dot for class C operation
    // the Dot must also be configured on the gateway for class C
    // use the lora-query application to do this on a Conduit: http://www.multitech.net/developer/software/lora/lora-network-server/
    logInfo("changing network mode to class C");
    if (dot->setClass("C") != mDot::MDOT_OK)
        logError("failed to set network mode to class C");
    
    if (dot->setTxDataRate(DataRate) != mDot::MDOT_OK)
        logError("failed to set TX DR");
        
    if (dot->setTxPower(20) != mDot::MDOT_OK)
        logError("failed to set TX Power");
        
    // save changes to configuration
    logInfo("saving configuration");
    if (!dot->saveConfig())
        logError("failed to save configuration");

    // display configuration
    display_config();
    
    
    //Tell the gateway that this device is up and running
    if (!dot->getNetworkJoinStatus())
        join_network();
    payload.push_back((int8_t) var0);
    send_data(payload);

/*--------------LOOP------------------------------------*/
    while (true) {  
        if (refresh_Timer.read_ms() >= refresh_Time) {
                refresh_Timer.reset();
                // join network if not joined
                if (!dot->getNetworkJoinStatus())
                    join_network();
                //std::vector<uint8_t> payload; //tried changing the payload variable's 
	       //scope so that it would always be destroyed after sending, but that didn't help
                payload.clear();
                //std::vector<uint8_t>(payload).swap(payload); // also didn't help
                payload.push_back((int8_t) var1);
                payload.push_back((int8_t) var2);
                payload.push_back((int8_t) var3);
	        //var4 and var5 are uint32_t (conversion from float)
                for(int i=24; i>=0; i-=8)
                    payload.push_back((var4>>i)&0xFF);
                for(int i=24; i>=0; i-=8)
                    payload.push_back((var5>>i)&0xFF);
                payload.push_back((int8_t) var6);
                payload.push_back((int8_t) var7);
                logInfo("Time-on-air for %d byte: %ld",payload.size(), dot->getTimeOnAir(payload.size()));
                send_data(payload);
                next_tx = dot->getNextTxMs();
                logInfo("Time to next TX: %ld", next_tx);
        }
        
        //soft reset solution I was talking about
        if (reset_cpu_Timer.read_ms() >= reset_cpu_Time)
            dot->resetCpu();
    }
    return 0;
}

[Mark Makarychev]

I just stumbled upon the setting in the Conduit named “Disable duty cycle” in the testing section, and I did read the note that says “this is for testing purposes only – do not use for deployments”. However, if the ISM band here allows it, I guess I found the answer to my second question, regarding creating a 20% duty cycle.

And I found something in regards to my first question as well. If I understood correctly, the Conduit Gateway’s LoRa card has 2 radios, which are set to 867.5 and 868.5 MHz, and the “8 channels” are actually just the 8 LoRaWAN spreading factors. Is this correct? If so, is it possible to set the radios to frequencies of the local ISM band?

• This reply was modified 7 years, 2 months ago by Mark Makarychev.
• This reply was modified 7 years, 2 months ago by Mark Makarychev.

[Mark Makarychev]

Thanks for the answer!
I was mainly interested in getting my application to the mDot, not so much about programming a custom firmware version.

[Mark Makarychev]

Are you using the EU868 or US915 band? Sounds like this might be due to duty-cycle restrictions. US915 has a 400ms TX time restriction, whereas EU868 generally has a 1% TX duty-cycle (spread across about 8 channels, so almost 10%). If the mDot tries to send a message, but doesn’t find an available channel (where its duty-cycle timeout hasn’t ended yet), it will try to transmit this package together with the next one, when it gets an available channel. I’m not 100% sure, but I believe this is the procedure that goes on when there are no more available channels at a given time.

[Mark Makarychev]

Did you ever get an answer to this question? It’s just that I’ve also approached the stage in my product development where I’ll soon need to be get the mDot 50 pack with uFl connectors, but they don’t have programming headers (which is obviously done for being flat and compact). Due to this, I’m also now wondering what techniques are used to program them. All I can think of so far is using the “bus” like cable supplied in the starter kit (for programming mDot Box), sticking in male-male pins, and holding them in place by hand while the mDot programs itself.

[Mark Makarychev]

Pascal, I believe he is talking about the page that is located on the conduit web page (Status & Logs -> Statistics -> LoRa [tab]).

I found this topic while searching for an explanation as to why in Class C I’m only getting packages after TX, and I also found that on the LoRa server all the devices are marked as Class A. After reading this became a bit disappointed:

There is currently not a message the device can send to signal that it is Class C.

Is this going to be added sometime in the near future? Because changing 100+ mDots from Class A to Class C by hand on the LoRa server sounds like a dreadful task…

• This reply was modified 7 years, 3 months ago by Mark Makarychev.

[Mark Makarychev]

Oh wow, thanks! I had a feeling that DeviceHQ should have what I was looking for, and had even already made an account, but it seems I always skimmed over the “store” tab and never tried checking the “public apps” checkbox.

I’ve successfully found the LoRa demo, but I didn’t find anything for the “GPS sampling mode” that is found in the mDot Box. Does such a flow exist? Or has it just not been published yet?

Once again, thanks a lot for your answer Carol – won’t be too hard now to make my own “GPS sampling” flow using the starter-kit’s demo!

[Mark Makarychev]

Today I noticed that the mDot Box has a pretty cool feature (or mode I guess) in the latest version (1.3.3) called GPS scan, which would allow me to see where I start to loose signal for any given DR/PW combination. I thought that since there is a GPS scan mode in the official mDot Box firmware, there must be some official MultiTech code to receive the data on the other end (on the conduit and optimally send+display the GPS data on some service like Watson). Started searching, and once again didn’t find any sample Node-RED flows.

I really like that MultiTech does a good job of documenting their products, which really helps semi-beginners like myself, but I’m starting to see that the weakest link in the documentations seems to be the lack of Node-RED flow samples. Does anyone know whether they plan on creating such examples to help people get some test projects up and running, or has this been completely left up to the end developers?

[Mark Makarychev]

Hi Andrew,

Thank you for your answer! Does a 1% duty-cycle then mean that the maximum number of devices I can have is <100? I believe I remember reading something about the mDot being able to “jump” between frequencies – is this what allows for more than 100 devices to be in a LoRaWAN network?

As for the spreading factor – I guess I’ll need to use the lowest SF possible to achieve the ~0.03 on-air-time and ~3 second off-air-time. The lowest SF seems to be SF_7 125kHz, and it has a transfer rate of 5.47 kbps – so 13 byte should send in ~0.02 seconds, right? And what range am I looking at with SF7 in a rural environment? Is 2 kilometers possible, or even less than that?

And Leon,

Thanks for your answer as well! Looking at the EVB, I noticed that is has an “8-pin connector”. Are these like GPIO pins, or are they for debug purposes? And you said I’ll have to manage my added components with the on-board sensors – do you by chance know how many ports already have something hooked-up to them, and how many are still free?

• This reply was modified 7 years, 6 months ago by Mark Makarychev.

[Mark Makarychev]

0.03 time-on-air would lead to about 3 seconds off-air, correct? That would be pretty acceptable, however I still don’t quite understand – is the throughput (datarate) controllable via code? And approximately what range would I have using the max available datarate?

And I have the same question in regards to the “band at the top of 863-870 that can be used with 100% duty cycle” – will I be able to set such a “mode” via arm-mbed code? And about what range would I get with 7dBm (if there is some range equivalent for ERP)?

[Author]

Posts