[Szymon Zieba]

Following on from above, I have implemented a Node-RED script which gives a heartbeat to whether any script is running. Basically I have the program turning on/off one of the signal lights on the front of the Conduit due to the lack of usage of these lights at this time. I then measured how long it took to have the Node-RED script begin running, finding that it took approximately 4 minutes to start running Node-RED script. Is there a way to improve this time, or should I just start writing shell script in order to reduce load times?

[Szymon Zieba]

Hi Steve,

The problem with Node-RED is that I need to have assurance that it turns on consistently as it severly hampers testing if it doesn’t automatically activate the script when turned on. Is there an easy way to turn the Node-RED script into a shell script, or a way to generate a shell script that can listen to the LoRa ports for incoming information and log it that way?

With range, the advertised ranges I am talking about are the ones listed in the mDot data sheet, where it states a 1-3mile (or 2km) in Building Penetration and 16km maximum range. We weren’t expecting to get the perfect results due to signal attenuation, however we were attempting to get at least 5km (ideally 10km) in our rural test from one of the highest points easily available to us, which is about 85m above sea level going off Google Maps. As previously stated, the best result that was obtained was ~3.56km during our testing. This was on a signal that was alternating through DR1 to DR4 and sending GPS Data to the Conduit. Thank you for the information of previous tests, however, it at least gives us an idea of the limits.

As for the mDot Box, I have found that it appears to have a shorter range than the standard mDots and I am not convinced that the survey mode works correctly on the Box that we currently own. As such we created a simple mDot GPS device to send the distance data to the Conduit as this appears to be more effective than the Box.

Regards,

[Szymon Zieba]

Hi Mike,

I have changed the libraries so that I am now using mbed-os and now the Serial function is working. I am not sure what happened as I haven’t changed anything code wise.

Regarding the usage of the bootloader, I am a little confused as to how I would transfer a file onto the mDot via LoRa for example? Should I be setting up an SPISlave on the LoRa for reading any incoming files?

Thank you for your help

[Szymon Zieba]

Thank you for your answer regarding OTA updates. I will take a read through. For the Serial Code, here is the full thing, minus code for connecting to the LoRa server:

#include “mbed.h”
#include “mDot.h”
#include “MTSLog.h”
#include “MTSText.h”
#include <string>
#include <vector>
#include <algorithm>
#include <bitset>
#include <stdlib.h>

Serial connect(SERIAL_TX, SERIAL_RX, 115200);

int main() {
int32_t ret;
mDot* dot;
std::vector<uint8_t> data;

while (true) {
char mystring;
if (connect.readable() == 1 && connect.writeable() == 1) {
connect.puts(“Please enter a character: \n”);
mystring = (char) connect.getc();
} else {
mystring = 0x00;
}

if (mystring != 0x00) {
logInfo(“mystring = %c”, mystring);
std::string msg(1,mystring);

// format data for sending to the gateway
for (std::string::iterator it = msg.begin(); it != msg.end(); it++)
data.push_back((uint8_t) *it);
}

// in the 868 (EU) frequency band, we need to wait until another channel is available before transmitting again
osDelay(std::max((uint32_t)5000, (uint32_t)dot->getNextTxMs()));
}

return 0;
}

I can get the Serial connection to work if I change to RawSerial, but it would be good to know whats wrong with the normal Serial Connection.

Library wise I am using libmDot-dev-mbed5 rev:75:60e21ba8350a, mbed-rtos rev:123:58563e6cba1e, and mbed.bld rev:130:d75b3fe1f5cb.

[Szymon Zieba]

As an additional, separate question, is it possible to update the mDot remotely, Such as updating the firmware or changing the programming via OTA connection?

[Szymon Zieba]

This is correct, the problem has been resolved.

Thank you for your suggestion.

Kind regards

[Szymon Zieba]

Hi Mike,

The confusion may be a result of the time difference. By the time you were asking for the libraries, I had made several attempts to remedy the issue, one of which was successful.

The dot library being used for my programs is libmDot-dev-mbed5, as found at https://developer.mbed.org/teams/MultiTech/code/libmDot-dev-mbed5/.

Currently I have programs using both mbed.bld (top search result under import programs search) and mbed-dev.

The version of mbed-rtos I am using, according to the mbed compiler, is https://developer.mbed.org/users/mbed_official/code/mbed-rtos/

Thank you for the note about mbed-os, I had not previously seen it used by other programs and so wasn’t aware of it.

Kind regards

[Szymon Zieba]

Hi Mike

I am not currently using mbed-dev, however there were no compiling issues when I was running the code with it.

The mbed-rtos revision I am using is 123:58563e6. I thought mbed-rtos was always required as mdot.h calls rtos.h?

Cheers

[Szymon Zieba]

Correct

[Szymon Zieba]

Hi Mike,

You don’t need to worry anymore, it seems that something was wrong with the mbed-rtos library I was using, so I replaced it and now it all works again.

regards

[Szymon Zieba]

Hi Mike,

I am using the newest available version of mbed-dev and the libmDot-dev-mbed5 available from the mDot page on the mbed website.

regards

[Szymon Zieba]

Nevermind, using the bleeding edge library seems to make it work again.

[Szymon Zieba]

Hi Jason, thank you for your suggestion. I have implemented the 2.0.16 firmware with the correct frequency, however I now have a new problem possibly related to the change in firmware. When the code tries to call the mDot::getInstance() function, the mDot seems to just stop now, proceeding no further into the code. Do you have any ideas why this may be happening?

[Szymon Zieba]

Thank you for your help.

[Szymon Zieba]

Hi Jason,

The problem with the regular downlink messages from the Conduit is that I am unable to have the Conduit send a message from one mDot to another, e.g. have one mDot send a message saying “reduce” the Conduit accept the message and then relay that message to the other mDot. When testing, the Conduit just sends back the message the second mDot sent as a reply. I am unsure if this error is happening on the Conduit or on the mDot.

The desired operation is for an mDot to be able to either poll for messages or just receive them as necessary. I am using the 1.0.8 Australian Debug code as attempting to use the newer firmware locks my mDots to US frequency bands with no way to change this. As such, my understanding is that Class C operation is not possible with the firmware I am currently using.

What would you suggest as a solution?

[Szymon Zieba]

Thank you for your help.

[Author]

Posts