Multitech Conduit AEP and time

[Fernando Molina]

Hello.

We have 3 Multitech Conduits AEP for exterior (newest version SPI) and one AP (SPI too) and they seem to have a little problem.

We are using the 4 of them like packet_forwarder but they seem to not be adding the time to the packages.

So in our platform we get packages wit time 0 (Year 2000).

Is this intended? I have tried a lot of things to make them work (fake GPS, real GPS) and nothing seems to be working.

We have 3 older models (USB models I think) and they seem to be retransmiting packages with time, this models do not have GPS.

Here are 2 samples

Older model package:
{“rxInfo”:{“mac”:”000800fffe4a082c”,”time”:”2017-12-27T07:51:48.46198Z”,”timestamp”:1105722868,”frequency”:868100000,”channel”:0,”rfChain”:1,”crcStatus”:1,”codeRate”:”4/5″,”rssi”:-114,”loRaSNR”:-0.8,”size”:23,”dataRate”:{“modulation”:”LORA”,”spreadFactor”:12,”bandwidth”:125},”board”:0,”antenna”:0},”phyPayload”:”APQJAAAAAHq+NWwcAAujBADybaluiyE=”}

Newer model package:
{“rxInfo”:{“mac”:”00800000a0001b79″,”timestamp”:305972196,”frequency”:868100000,”channel”:0,”rfChain”:1,”crcStatus”:1,”codeRate”:”4/5″,”rssi”:-67,”loRaSNR”:10,”size”:23,”dataRate”:{“modulation”:”LORA”,”spreadFactor”:12,”bandwidth”:125},”board”:0,”antenna”:0},”phyPayload”:”APQJAAAAAHq+NWwcAAujBADybaluiyE=”}

[Jason Reiss]

When the packet forwarder source was updated to include basic, gps and beacon functionalities into one binary, time was changed to only be included when a gps signal is available.
This new packet forwarder code is used for the SPI cards.
The USB cards use the older version.

https://github.com/Lora-net/packet_forwarder

[Fernando Molina]

So if I’m understanding this well. The basic does not exist anymore? If there is no GPS the time isn’t added?

Thanks for the answer

[Jason Reiss]

That is correct, with the packet forwarder used for SPI cards, time is only included when a gps signal is available.

[Fernando Molina]

But the Multitech conduit AP does not have GPS, how do I get time from them?

[Jason Reiss]

The packet forwarder could be patched to add the time field.
Or a process could be in-lined to modify the UDP packets to add a time stamp.
Or the network server could fill in the missing time field.

What network server are you using for the backend?

[Fernando Molina]

We are using open source LoRa-Server by Brocaar – https://www.loraserver.io/

I have to speak with him and see if he can add that in his server.

Could a gpsfake do the trick?
I have to try the (real)gps on the new outdoor conduits and check if the time appears there.

Still don’t understand the decision by LoRa-Net to get rid of the time in the package

[Jason Reiss]

Does not look like fakegps would work.
The packet forwarder looks for an updated time from the gps device.

ref_ok can only be true if gps_enabled is true

line 1518

        /* get a copy of GPS time reference (avoid 1 mutex per packet) */
        if ((nb_pkt > 0) && (gps_enabled == true)) {
            pthread_mutex_lock(&mx_timeref);
            ref_ok = gps_ref_valid;
            local_ref = time_reference_gps;
            pthread_mutex_unlock(&mx_timeref);
        } else {
            ref_ok = false;
}

line 1609

            /* Packet RX time (GPS based), 37 useful chars */
            if (ref_ok == true) {
                /* convert packet timestamp to UTC absolute time */
                j = lgw_cnt2utc(local_ref, p->count_us, &pkt_utc_time);
                if (j == LGW_GPS_SUCCESS) {
                    /* split the UNIX timestamp to its calendar components */
                    x = gmtime(&(pkt_utc_time.tv_sec));
                    j = snprintf((char *)(buff_up + buff_index), TX_BUFF_SIZE-buff_index, ",\"time\":\"%04i-%02i-%02iT%02i:%02i:%02i.%06liZ\"", (x->tm_year)+1900, (x->tm_mon)+1, x->tm_mday, x->tm_hour, x->tm_min, x->tm_sec, (pkt_utc_time.tv_nsec)/1000); /* ISO 8601 format */
                    if (j > 0) {
buff_index += j;

[Fernando Molina]

I have been checking the code and that line seems to be there for a long time It has been always there, only with gps the variable “time” appears.

But then how are my older conduits doing it? Or even my RisingHF gateway doing it? I truly dont understand anything right now.

The only thing that make sense to me is that somebody has patched the forwarder to add the time even without GPS. As I see it is the only way to “fix” this.

Thanks for the help

[Jason Reiss]

If the “older” conduits have USB lora cards then basic_pkt_fwd is used.
Release v1.4.1 of packet_forwarder on lora-net

[Fernando Molina]

And that packet forwarder is based on this?
https://github.com/Lora-net/packet_forwarder

[Jason Reiss]

Here is a link to the v1.4.1 release source
https://github.com/Lora-net/packet_forwarder/tree/0011a60759a7d81656a5393e97089daab1ff1a81

[Fernando Molina]

Ok.

Many thanks for everything. Will try to convince Brocaar to add time in his server.

[Fernando Molina]

So we made the modification in the pkt_fwd.

We have it running in an Outdoor conduit (SPI version) and seems to be running correctly and doing what is expected.

Now the problem, with the indoor conduit (SPI version too) there seems to be some kind of error with the SPI, when you try to execute pk_fwd it always says that the concentrator cannot be started (error -1). We suspect that the chip is not resetting.

Do you have any info about this? If I run the packet_forwarder by multitech it works like a charm, mine fails to start concentratos.

We based our forwarder in the latest version:
Forwarder 4.0.1
HAL 5.0.1

Thanks

[Jason Reiss]

Here is a link to our recipes and patches for the packet forwarder and gateway.
http://git.multitech.net/cgi-bin/cgit.cgi/meta-mlinux.git/tree/recipes-connectivity/lora

[Fernando Molina]

Just tried, does not work.

I found a way to reset the LoRa SX1301 and did nothing.

It seems to be somewhere else the problem. The connection to the SPI are equal in both conduits? (outdoors and indoors). The only thing I’m left to try is use the same version of packet forwarder and HAL. But that does not explain why it works in the outdoor version. I have to say that the test inside HAL do not work either in the indoor version, is like it does not find the SPI.

There is one little difference between the two versions I have, there seems to be a /dev/spidev0.0 and /dev/spidev0.1, the ones in the outdoors are different from this. There is only a /dev/spidev0.0 and is a link to another spi dev (2 of them) wich are probably the 2 cards available.

Thanks.

[Jason Reiss]

Did you try the card in each slot?

[Fernando Molina]

The one with the card works fine with my modified forwarder, detects SPI and pass the tests.

The problem is with the one that has no card:
https://www.multitech.com/brands/multiconnect-conduit-ap

This one, in case I’m explaining poorly.

[Jason Reiss]

Actually here are the latest.
http://git.multitech.net/cgi-bin/cgit.cgi/meta-mlinux.git/tree/recipes-connectivity/lora?h=3

There is patch to add FPGA version 28, 31, and 33 that is different.

# mts-fpga-loader -c
Checking hardware compatibility
Found Valid Hardware: MTCAP-LORA-1.5
Valid FPGA version: 31

On Conduit AP

spidev0.0 is the lora card
spidev0.1 is a spi flash

mts-io-sysfs show lora/*

This should return 1
mts-io-sysfs show lora/cdone

To reset the card
mts-io-sysfs store lora/creset 0
mts-io-sysfs store lora/creset 1
mts-io-sysfs show lora/cdone

[Fernando Molina]

This is my return :

#mts-fpga-loader -c
Checking hardware compatibility
This software is licensed only for supported MultiTech products.
Version Check failed. Error Code: 3

The other commands return 1 and everything seems right. The pkt_fwd inside the conduit seems to work fine even with that error.

[Fernando Molina]

Made it run!

Seems that you have to add version 28 to HAL.

Many many thanks!

[Fernando Molina]

Last question.

Is there any way to know which version of the FPGA the devices has? Because the command “mts-fpga-loader -c” gives error in the AP conduit and does not exist in the outdoor device.

As far as I have been looking the only thing I have seen different is the SPI mode. I don’t know if adding this “unsuported” version to HAL will broke something.

It working pretty well now and everything seems fine.

• This reply was modified 7 years, 3 months ago by Fernando Molina.

[Jason Reiss]

Looks like there was a recent change to add MTCAP-0.1 hw support to the utility. It will not work for MTCAP-0.0, perhaps you have a early rev?

$ mts-io-sysfs show hw-version
MTCAP-0.1

28 was an intermediate release for the v1.5 cards and AP units.
The spectral scan utility may be different from 31.
Other LoRa rx/tx operations are same.

We use 31 and 33 in our cards and AP units.
31 – spectral scan
33 – listen-before-talk

[Fernando Molina]

Yes, seems an early version. Will talk to my boss to see if they know something more about this MTCAP.

# mts-io-sysfs show hw-version
MTCAP-0.0

Anyway it seems to be working now and it will be useful for testing indoor LoRa ranges.

Thanks for everything.

[Author]

Posts