Announching LoRa Gateway OS

Thanks for your feedback and great that this solved the issue :+1: will update the wording!

HI brocaar!
Can CN470 be used?

1 Like

Yes, but I haven’t added the CN470 channel config yet. If you (or somebody else) would like to test this and create a pull-request, the Raspberry Pi configuration files can be found in this folder: https://github.com/brocaar/lora-gateway-os/tree/master/layers/targets/meta-raspberrypi/recipes-lora/lora-packet-forwarder/lora-packet-forwarder.

Hi @brocaar, just came across the Gateway OS, looks great. I see it doesn’t include AU915 which I am happy to contribute to add. Also see the existing US915 only allows one of the 8 potential block of channels. Can I suggest a concept, after selecting GPS or No GPS and then US915 or AU915, an extra menu selection is added to select channel blocks 1 to 8. Happy to create all the SX1301 config files, but before I do, thought I would check what you thought of the concept.

@brocaar, not sure if your realise, there are still references to RAK381 in the file “gateway-config.sh”

Yes, that would be great :+1:

Just have to work out how to use GitHub (I’m more of a RF and Hardware person) I’ll create files for both AU and US as I understand how they work. Think I understand AS923, so could have a go at this as well. BTW, running LoraServer for a network of research nodes in Australia, works just great.

I have fixed this :slight_smile:

1 Like

On another topic. Out of interest, why are you running the OS on Ubuntu? I can see in the Docker files, that Debian is commented out. Did you try that and switch to Ubuntu? Also, any reason for not basing this on Raspbian Lite, that way all the Pi’s, from PiZero to a Pi3B+ would work on the same code.

Ubuntu is used for the Yocto build environment, not as a final target. Note that the image that Yocto outputs has nothing to do with Ubuntu, Debian, Raspbian or any other distribution. Yocto is building these images from scratch (https://www.yoctoproject.org/).

The reason to not use Raspbian (Lite) is that I want to make these images also compatible with other gateways, which is easy-(ish) the way Yocto works as usually the BSP layer implements all the hardware specifics. It should be fairly easy to compile for other Raspberry Pi models too, only I haven’t tested that yet. E.g. setting the the MACHINE variable to raspberrypi2 should result in a RPi2 image or raspberrypi0 for the RPi Zero. Please see also the meta-raspberrypi BSP layer that is used: http://layers.openembedded.org/layerindex/branch/master/layer/meta-raspberrypi/

Also stay tuned for the second test release! I don’t have an ETA yet, but it is going to support remote atomic OTA updates of your gateways :slight_smile:

Nice, look forward to seeing that. In the mean time, need to understand about Yocto.

For me, this was a really good read: https://www.amazon.com/Embedded-Systems-Project-Software-Development-dp-0133443248/dp/0133443248/ref=mt_hardcover?_encoding=UTF8&me=&qid=.

A sneak-preview of what will be included in the next test-release: Mender based atomic updates (note that a Mender account is not required, running an update using the CLI will also be possible). This will be available for Raspberry Pi 3 based gateways and the LORIX One. See also: https://mender.io/.

Hi @brocaar, I’m working on creating the global_conf files for the 8 potential blocks of channels in both AU915 and US915. To select the required block of 8 channels will require another variable in “gateway-config.sh”. I notice $3 is not currently used when calling the function “do_copy_global_conf()”, could I use this to pass the “Block Number”?

do_copy_global_conf() {
cp /etc/lora-packet-forwarder/$1/global_conf.$2.json$3 /etc/lora-packet-forwarder/global_conf.json

I think a simpler option would be to use $2 of do_copy_global_conf :slight_smile: E.g:

do_setup_channel_plan() {
    # $1: concentrator type
    # $2: config suffix, eg ".gps"
    FUN=$(dialog --title "Channel-plan configuration" --menu "Select the channel-plan:" 15 60 2 \
        1 "EU868" \
        2 "US915 (channels 0-7 + 64)" \
        3 "US915 (channels 8-15 + 65)" \
        3>&1 1>&2 2>&3)
    RET=$?
    if [ $RET -eq 1 ]; then
        do_main_menu
    elif [ $RET -eq 0 ]; then
        case "$FUN" in
            1) do_copy_global_conf $1 "eu868" $2;;
            2) do_copy_global_conf $1 "us915_0" $2;;
            3) do_copy_global_conf $1 "us915_1" $2;;
        esac
    fi
}

As the filename template is /etc/lora-packet-forwarder/$1/global_conf.$2.json$3, you would then get /etc/lora-packet-forwarder/rak831/global_conf.us915_0.json.gps (when $3 is set to .gps).

Then to support all the US915 bands, you get us915_0 up to us915_7. You could also make an other menu after selecting the US915 band which would then display the blocks of 8 channels (like you suggested). When adding more and more channel-plans this would become easier to navigate as it would avoid having 8 US915 options, but it would mean that for each band a specific menu is needed as the number of channels are not equal. Still with this function you would be able to use the same arguments for the do_copy_global_conf function.

What do you think?

if we create one menu then we will likely end up with 20-25 options on that one menu (8 x US, 8 x Au, 1 for Eu and first inspection of some other frequency plans could end up with 2 version). For this reason I was thinking about two menus, the first for the plan and then for some, it breaks out into a second menu. At this point in time, I am working through each of the frequency plans published in the LoraAlliance Regional plans to determine the required global_conf files.

Yes, I agree :slight_smile: I think a separate menu to select the channel block to be used is better. Looking forward to add this :+1: Also feel free to split this up into multiple pull-requests, e.g. one for US915, …

hii i have problem with packet forwarder . when i boot sd card and turn raspberry pi on . go tho the configuration and config gateway but my packet forwarder send me Execution failed | Does not exist in the monit status . some times packet forwarder work perfect but most of times dont work :frowning: . please help me :pray: tnx

On the Raspberry Pi 3, it takes a couple of attempts to start the packet-forwarder because the way the SPI interface is provided. Usually within a couple of minutes after boot, Monit should display that the packet-forwarder is running correctly. In the next release I’ll change the Monit monitoring interval so that it takes less time.

2 Likes

Do you add “core_freq=250” to the file /boot/config.txt? This locks the VGU clock frequency and prevents it going into Turbo Mode. This is required as the SPI clock is derived from the VGU clock frequency. This is specific to the Pi3