[Fernando Molina]

Can official FW FPGA versions be burned in Multitech cards with fpga? Just want to check if the v33 posted in git and yours is the same.
EDIT: Git seems to have 2 versions of v33, 915 and 863

• This reply was modified 6 years ago by Fernando Molina.

[Fernando Molina]

I know it is not required, but as far as I know EU let’s you decide between using LBT or DutyCycle.

Anyway seems that is not a problem of the gateway.

EDIT:
Seems limited by program. FPGA should support it

SX1301_FPGA_200K_NOTCH_LBT_SPECTRAL_SCAN_863_v33.hex:

    200KHz Notch filter for TX (not programmable)
    Listen-Before-Talk for 863+MHz frequency range
    Background Spectral Scan (limited) Note: This image is the same as the 915+MHz version. It is just meant for testing "Japan-like" LBT feature on a EU868 board. It does not provide certified LBT for European band.

Thanks for the answers.

• This reply was modified 6 years ago by Fernando Molina.

[Fernando Molina]

It appears I do something wrong:

        "lbt_cfg": {
            "enable": true,
            "rssi_target": -80,
            "chan_cfg": [
                {"freq_hz":867100000, "scan_time_us":5000},
                {"freq_hz":867300000, "scan_time_us":5000},
                {"freq_hz":867500000, "scan_time_us":5000},
                {"freq_hz":867700000, "scan_time_us":5000},
                {"freq_hz":867900000, "scan_time_us":5000},
                {"freq_hz":868100000, "scan_time_us":5000},
                {"freq_hz":868300000, "scan_time_us":5000},
                {"freq_hz":868500000, "scan_time_us":5000}
            ],
            "sx127x_rssi_offset":-165
         },

When LBT is activated packet_forwarder shows an error “Failed to start the concentrator”. If I turn off LBT packet forwarder works fine.

INFO: Auto-quit after 300 non-acknowledged PULL_DATA
INFO: FPGA supported features: [TX filter]  [Spectral Scan]  [LBT]
ERROR: [main] failed to start the concentrator

Test works fine

Followed this page: http://www.multitech.net/developer/software/lora/listen-before-talk/

• This reply was modified 6 years ago by Fernando Molina.
• This reply was modified 6 years ago by Fernando Molina.
• This reply was modified 6 years ago by Fernando Molina.
• This reply was modified 6 years ago by Fernando Molina.
• This reply was modified 6 years ago by Fernando Molina.
• This reply was modified 6 years ago by Fernando Molina.
• This reply was modified 6 years ago by Fernando Molina.

[Fernando Molina]

MTCDT-0.0 seems to be upgradable.
Is this right?

Thanks for clarification.

[Fernando Molina]

I could upgrade my MTCDT with that commands.

I don’t know why I cannot upgrade the MTCAP. Faulty device?

[Fernando Molina]

There seems to be a problem with my device then:

root@mtcap:~# mts-io-sysfs show hw-version
MTCAP-0.0
root@mtcap:~# mts-fpga-loader -c
Checking hardware compatibility
This software is licensed only for supported MultiTech products.
Version Check failed. Error Code: 3
root@mtcap:~# mts-fpga-loader -i /usr/lib/mts-
mts-flash-binaries/ mts-io-sysfs/
root@mtcap:~# mts-fpga-loader -i /usr/lib/mts-flash-binaries/mtcap-fpga-v3
mtcap-fpga-v31.hex  mtcap-fpga-v33.hex
root@mtcap:~# mts-fpga-loader -i /usr/lib/mts-flash-binaries/mtcap-fpga-v33.hex
Checking hardware compatibility
This software is licensed only for supported MultiTech products.
Upgrade Failed, Error Code: 3

[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.

[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 6 years, 4 months ago by Fernando Molina.

[Fernando Molina]

Made it run!

Seems that you have to add version 28 to HAL.

Many many thanks!

[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]

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.

[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.

[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

[Fernando Molina]

Ok.

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

[Fernando Molina]

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

[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

[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

[Fernando Molina]

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

[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

[Author]

Posts