A week ago, I got a chance to borrow a RAKWireless' RAK7243C LPWAN Developer Gateway and a few RAK5205 WisTrio modules for a test, and this is my first impression of the products with my understanding on how it works.
As a person by training in radio communication, I'm generally interested on all things in wireless. Lora is one technology that I want to understand more and possibly put it in use in actual application. A company that I know bought a RAK7242C LPWAN Developer Gateway and three RAK5205 WisTrio modules for a proof-of-concept(POC) project a year ago. I ask for borrowing the equipment to see if I could test it out a week ago.
In case you are wonder, this article is not sponsored by RAKWirless, or its sales agent, or the company that I borrow the equipment from. The information and opinions are based on my week-long research and first-hand experience from tinkering with the Lora gateway.
Hardware
RAKWireless offers dizzying range of hardware that it is sometime could be quite confusing to figure out the differences and how the modules could be put together to create your own Lora solution.
The gateway that I got is a RAK7243C which has a EG95-E cellular module as the backhaul network. The two antennas at the bottom are the LTE antennas, the top left connector is for Lora Antenna and the top right is for GPS antenna.
RAKWireless Gateways
Each RAK7243 has a built-in Raspberry Pi(RPI) 3B+. There is also another gateway RAK7244 that comes with a built-in Raspberry Pi 4. Both RAK77243 and RAK7244 uses the same aluminium casing and same RAK2245 Lora Concentrator module (more on this later).
In the case where you need Power-over-Ethernet(PoE), for example, where your antenna is on the rooftop and away from the router for quite some distance. This is not available in RAK7243, but RAK7244P comes with a built-in RPI 4, the same Lora Concentrator RAK2245 as RAK7243, plus a RAK9003 PoE HAT.
The RAK7246 gateway is another gateway based on Raspberry Pi Zero W with a different RAK2246 Lora Concentrator module using a different Semtech chip and one radio front-end and no GPS. The RAK7246 comes with a transparent Acrylic casing and power adaptor is not included. There is also a RAK7246G that come with a built-in GPS module.
The RAK7243/7244/7246 are all designed for indoor deployment, mainly because of the enclosure casings are not designed for outdoor environment. There are also a range of gateways for outdoor purpose with IP67-compliant enclosure.
The different of indoor and outdoor actually go beyond just the enclosure it used, the chip/module used from Semtech also have different parts for indoor and outdoor purpose (mainly in temperature range), but RAK7243 or more specifically RAK2245 Lora Concentrator uses Semtech SX1301 chip which itself is categorised as capable for outdoor purpose. If you plan to deploy your Lora system in a hash outdoor environment (extreme hot or cold atmosphere), you will need to pay attention to those details.
There are several more gateway products, concentrators (multi/single channel, with/without GPS), HAT boards for interface with various host computers (Raspberry Pi, 96Boards, etc.). But those I mentioned above are the main gateways based on Raspberry Pi that RAKWireless currently offers, see the comparison table for the differences of the 3 products that I mentioned.
RAK7243 LPWAN Developer Gateway
Going back to RAK7243, there are actually 2 RAK7243 SKUs that you can choose from:
- RAK7243 - RPI 3B+ with RAK2245 Lora Concentrator.
- RAK7243C - RPI 3B+ with RAK2245 Lora Concentrator, plus RAK2013 Cellular Board (with the choice of EG95-E/EG95-U).
Specifically for RAK7243C that I have with me now, the diagram below illustrated the internal connectivity and the functional block diagram of all the key hardware components as well as software stacks.
On the very top of the diagram is RAK2245 Lora Concentrator pi-HAT, which consists of a Semtech SX1301 concentrator chip, plus two SX1357 RF front-end chip, together capable of receiving up to 8 LoRa packets simultaneously sent with different spreading factors on different channels. RAK2245 also has a built-in Ublox Max-7Q module.
The RAK2013 is a cellular communications module pi-HAT that supports Low-Power Wide-Area (LPWA) cellular connectivity. The cellular pi-HAT provides much more functionalities such as Voice-over-LTE (VoLTE) than a Lora gateway would needed. As far RAk7243 gateway application, it is mainly functions as a cellular backhaul to the gateway, as an option for ensuring service reliability.
The Raspberry Pi 3B+ as a host computer provides the Hardware Abstration Layer, the system services and the necessary IP stack, but more importantly is the software called Packet-Forwarder which forward the data packets to the application servers or infrastructure such as The Things Network with LoraWAN protocol. The Packet Forwarder also provides configuration parameters for programming each radio front-end and all the spread factors for each Lora channel in according to each region's Lora channels allocation and specification.
Raspberry Pi communication with RAK2013 and RAK2245 via SPI interface, and I2C is used for the communication between Ublox Max-7Q and Raspberry Pi.
Getting Started with RAK7243
First of all, this is not going to be a walk-through of Getting Started with Lora Gateway tutorial, RAKWireless provides sufficient step-to-step walk through for RAK7243.
I will explain what the setup do behind the scene and with that I hope it will provide better understanding on how the gateway is configured and how it actually works.
Before you power on the RAK7243 Lora Gateway, make sure that you connected all the antennas first!
Access RAK7243 Gateway
When you power up the RAK7243 Gateway (wait for a minute or so), you should see an Access Point(AP) name Rakwireless_xxxx, the value of the xxxx varies from each gateway(in my case xxxx is AB32), the xxxx is derived from the hex-decimal value of last two bytes of either the Ethernet (eth0) or WiFi(wlan0) MAC address of the Raspberry Pi in the gateway. The default password for the AP is wireless.
You can access the RAK7243 gateway (i.e. the Raspberry Pi) using ssh command:
ssh pi@rak-gateway.local
Default password for the ssh access is raspberry.
In case your computer can't resolve rak-gateway.local for some reason (for example, your computer does not have the mDNS service installed), you can access the Raspberry Pi either via a pre-defined IP address if you are connect the gateway through ethernet cable:
ssh pi@192.168.10.10
or if you are connect the gateway through WiFi:
ssh pi@192.168.230.1
Configure the Raspberry Pi and RAK7243 gateway
RAK7243 gateway offers a utility program gateway-config, for those who are familiar with Raspberry Pi, it is quite similar to raspbi-config, so I won't explain every setup step here.
First thing upon accessing the Raspberry Pi, you should run the utility program to config the RAK7243 gateway.
sudo gateway-config
gateway-config to configure RAK7243Configure WiFi
By default, RAK7243 gateway is configured as a WiFi Access Point, so that we could login with ssh for the first time. This however does not connect to the Internet through your router. It will be better to configure the RAK7243 gateway as a WiFi Client as part of your router network so that you can access it within the internal network.
In order for the RAK7243 gateway to connect to your router's Access Point, you need to create SSID and password for accessing the WiFi. This can be done through Add New SSID for Client under the Configure Wifi menu.
If wifi country is not explicitly configured on the /etc/wpa_supplicant/wpa_supplicant.conf on the Raspberry Pi, the operation system will not enable the WiFi interface, and therefore the Raspberry Pi will not connect to your WiFi network. Add New SSID for Client under the Configure Wifi will ensure that the correct country code to be written into the configuration file.
All you've done so far for configuring WiFi is to add the proper configuration into /etc/wpa_supplicant/wpa_supplicant.conf. You can check the file to see if all your input are setup correctly with this command:
sudo cat /etc/wpa_supplicant/wpa_supplicant.conf
The file should looks something like this:
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=SG
network={
ssid="your-wifi-ssid"
psk="your-wifi-password"
key_mgmt=WPA-PSK
}
Noticed that the SG is for Singapore, yours should match your country's short code.
Confgiure LAN
If you are connecting the RAK7243 gateway using ethernet, by default the RAK7243 gateway has a configuration with a static IP address of 192.168.10.10, and the AP routing IP address as 192.168.10.1. This very likely will not match your router's IP address, and therefore you will need to change it to match your internal network configuration. What Configure LAN does is making the change of /etc/dhcpcd.conf:
# WARNING:Do not delete or modify the following 5 lines!!! # RAK_eth0_IP interface eth0 static ip_address=192.168.0.200 static routers=192.168.0.1
This shows the changes that I've made on both the ip_address and routers.
Setup RAK7243 Gateway Lora concentrator
For this, there are two choices, you can either use TTN (The Things Network) as your Lora server or to uses your Raspberry Pi as your LoraServer. In either case, you will be asked for the frequency band that your Lora Network is going to operate at. Behind the scene, it will change some of the settings specified on Lora Packet Forwarder's configuration file which is a json file that you can find at /opt/ttn-gateway/packet_forwarder/lora_pkt_fwd/global_conf.json. The script alo restart the daemon service running in the background upon the changes have been made.
You can view the content of the global_conf.json file with:
cat /opt/ttn-gateway/packet_forwarder/lora_pkt_fwd/global_conf.json
There are two configuration files for Lora Packet Forwarder, global_conf.json that you just see, and local_conf.json. The Lora Packet Forwarder works in such a way that the parameters in the local_conf.json will override the same parameter in global_conf.json. For example, the gateway_ID in global_conf.json is "0000000000000000", and it has been override by the same parameter from global_conf.json. To see this, run the following command:
cat /opt/ttn-gateway/packet_forwarder/lora_pkt_fwd/local_conf.json
You should see something like this:
{
"gateway_conf": {
"gateway_ID": "B827EBFFFExxxxxx"
}
}
The "B827EBFFFExxxxxx" is actually created by split the MAC address of either your Raspberry Pi's ethernet (eth0) or wifi (wlan0) into two part and added "FFFE" in the middle, to see the MAC address for eth0 and wlan0, type:
ifconfig
RAK7243 gateway use systemd for running services in the background, you can view the status or restart the service.
sudo systemctl status ttn-network.service
or to restart the service manually every time you made the changes to global_conf.json or local_conf.json.
sudo systemctl restart ttn-network.service
Configure Timezone
There is one thing that gateway-config didn't configure, that is the timezone of the Raspberry Pi. This can be done by running:
sudo raspi-config
Select Localisation Options, and Change Timezone to make the change. It would be much better to have this integrated into the gateway-config utility software than the need to run raspbi-config separately.
Now re-boot the RAK7243 gateway with:
sudo reboot now
Login into the system again with your new password and IP address:
ssh pi@rak-gateway.local
And you should be able to access Internet now. To test it, uses ping to see if you can access an public IP address.
ping -c 3 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=2.99 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=118 time=3.65 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=118 time=3.07 ms --- 8.8.8.8 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 5ms rtt min/avg/max/mdev = 2.990/3.238/3.650/0.293 ms
As we now can access the internet from the gateway, it is better to update and upgrade the Raspberry Pi software to the latest version. When upgrade is completed, reboot the RAK7243 gateway again.
sudo apt-get update sudo apt-get upgrade
I didn't set anything for the LTE cellular as it is not my focus and if I ever purchase a gateway or create my own gateway, I will probably don't need the 4G cellular as the backhaul in most of the usage cases.
I also didn't setup the LoraServer at this moment and opts to use the The Things Network server.
Setting up The Things Network account and register the gateway is quite straightforward and is covered in both RAKWireless documentation and The Things Network website, so I don't repeat it here.
So far so good
So far the RAK7243 is up and running. I placed the gateway on my balcony so that it can get GPS signal and eventually I can mount it there for a rough range test later. I did a quick check of Raspberry Pi CPU temperature on the date where the atmosphere temperature is around 29 degree Celsius, the CPU temperature give a reading of 56.9 degree Celsius. The heatsink on the top of the case is measured (I use a DS18B20 temperature sensor and Arduino to get the reading) at 36 degree Celsius.
/opt/vc/bin/vcgencmd measure_temp temp=56.9'C
This is quite normal and nothing to be concerned as the server for this very website e-tinkers.com is also running on a Raspberry 3B+ for the past 4 years! It is constantly showing that the CPU is operated at temperature of 58 degree Celsius in my living room without air-conditioning.
Issues that I'm facing
There are however a couple of issues that I'm encountered with the RAK7243 gateway.
GPS coordinates
By default, the GPS is enabled in /opt/ttn-gateway/packet_forwarder/lora_pkt_fwd/global_conf.json file.
.....
"gateway_conf": {
.....
"gps_tty_path": "/dev/i2c-1",
"fake_gps": false,
"ref_latitude": 10,
"ref_longitude": 20,
"ref_altitude": -1,
"autoquit_threshold": 20
}
When the GPS is able to detect the signals from GPS satellites, the correct latitude, longitude and altitude can be observed by check the /var/log/syslog, however when the GPS is out of sync and the signals can't be received reliably, the default reference coordinates in the global_conf.json will be used as the fallback GPS coordinates (that is the lat=10, long=20, alt=-1 that you see in the global_conf.json file.
During my testing, the GPS sometime works properly and get the correct coordinates but often out of sync and the system fall back to use the default coordinates. To prevent this happen, I decided to temporarily disable the GPS and also manually configure the GPS coordinates data so that it matches the coordinates that I used in The Things Network. The local_conf.json file looks like this:
{
"gateway_conf": {
"gateway_ID": "B827EBFFFExxxxxx",
"fake_gps": true,
"ref_latitude": 1.35547,
"ref_longitude": 103.84468,
"ref_altitude": 37
}
}
With this configuration, it also means that I no longer need the GPS antenna to be connected with the gateway anymore.
GPS Beacon Configuration
I'm not an expert in GPS, but I suspect that the GPS is not correctly provisioned. A look into Semtech Lora Packet Forwarder indicates that there are GPS configuration files for configuring GPS beaconing parameters. The same files can also be found at /opt/ttn-gateway/packet_forwarder/lora_pkt_fwd/cfg directory in RAK7243 gateway. In both cases, only EU and US configure files are available, there is no configure files for AS bands.
The specific parameters that I was looking are the GPS beaconing parameters, for example, here are the parameters from one of the EU868 file:
"gateway_conf": {
...
"beacon_period": 128,
"beacon_freq_hz": 869525000,
"beacon_datarate": 9,
"beacon_bw_hz": 125000,
"beacon_power": 14,
"beacon_infodesc": 0
}
These values are different from each region, could the lack of such configuration parameter causing the gateway not be able to recover from 'out-of-sync'?
AS920-923 versus AS923-925
ISM stands for Industrial, Scientific and Medical, and was originally envisioned for non-telecommunication applications. There are ISM bands and applications that still allocated for such purposes, however over the past two decades, with the evolving of technologies and the deregulation of telecommunication services, ISM bands are almost synonymous with non-license frequency bands nowadays.
Singapore, along with Malaysia and Japan has a frequency allocation on ISM band between 920-923MHz for Lora application, this spectrum is commonly named as AS1 or AS920. Korea is also operated on the same frequency band, its frequency hopping and spread scheme however is different from AS920 and therefore marked as KR920. The majority of the Asia (Thailand, Indonesia, Hong Kong, Taiwan, etc., except Philippines) are operated between 923-925MHz, commonly known as AS2 or AS923.
For those who are interested to find out the frequency allocation for your country, you can check out The Things Network website on Frequency Plans for more details.
The limited countries and market that using AS920 band is almost a curse to country like Singapore when come to ordering Lora products with the correct frequency band, many Lora equipment vendors simply does not provide a product SKU for AS920. There is no exception for RAK Wireless, on its online stores, you can only order product for AS923, as the result, a quick look at The Things Network Registered Gateway for Singapore indicates that majority of the gateways are operated at the wrong frequency bands, including several of RAK7243 gateways.
The Semtech radio chips are designed in such a way that the frequency band and spread factors are software-configurable. Semtech provides the master configuration templates for each band as part of its Packet Forwarder library, The Things Network further enhanced the list covering all bands used globally, and this can be find at Gateway Config Master files.
RAK7243's global_conf.json is created based on the master template files which are included in /opt/ttn-gateway/packet_forwarder/lora_pkt_fwd/global_conf. The template file for AS920 however is missing in RAK7243, despite that I can find the file at RAKWireless github where a master template for AS920 is available.
I was puzzled why AS920 file is missing in RAK7243 implementation while the file actually exist in RAKWireless master template?!
It seems that I can modified the frequency based on the configuration template that I found on both RAKWireless or The Things Network githubs, this bring up another question, if I modified the frequency, will be any Tx power and Rx sensitivity reduction due to the change of the frequency band with the assumption that the RAK2245 used in RAK7243 gateway was originally optimised for operating at AS923 band? I also want to make sure what I found on the githubs are correct (RAKWireless not included it in its distribution package means that they probably never tested it before).
Feedback from RAKWireless
I had a conference call with RAKWireless sales agent in Singapore to discuss these issues/questions, and I got some of the answers back within 24 hours after the agent had conference call with RAKWireless.
On the reduction on receiver sensitivity and transmission power, I was told that all the 900 range bands (i.e. US915, AS923, etc.) uses the same chip from Semtech and only optimised based on US915. As for how much reduction in tx power and rx sensitivity when changing the module is re-configured to AS920? I was told that it is negligible and therefore can be "ignored" without any tangible data to back it up. I read this as the reduction is "expected" but I don't have an RF spectrum to verify that for now.
Configure RAK7243 to operate at AS920
RAKWireless confirmed that AS920 can be configured based on the information that I found in github. RAKWireless's confirmation on configuring AS920 bring up another question, at this moment, I have not touch the RAK5205 module yet, but how to configure RAK5205 (which is based on RAK811 module with a Semtech SX1276 chip and STM32L1 MCU)?
I got the global_conf.json for AS920 two days later from RAKWireless, together with the firmware for flashing the RAK5205 firmware to operate at AS920 band (which I will discuss in the part 2 of this series of articles). The GPS beaconing settings are also included in the file that I received.
global_conf.json for AS920 provided by RAKWireless
{
"gateway_conf":{
"gateway_ID":"0000000000000000",
"server_address":"127.0.0.1",
"serv_port_up":1700,
"serv_port_down":1700,
"forward_crc_disabled":false,
"forward_crc_error":false,
"forward_crc_valid":true,
"keepalive_interval":10,
"stat_interval":30,
"push_timeout_ms":100,
"fake_gps":false,
"autoquit_threshold":30,
"gps_tty_path":"/dev/i2c-1",
"beacon_freq_hz":923400000,
"beacon_freq_nb":1,
"beacon_freq_step":600000,
"beacon_datarate":9,
"beacon_bw_hz":125000,
"beacon_power":20,
"beacon_period":0
},
"SX1301_conf":
{
"lorawan_public":true,
"clksrc":1,
"antenna_gain":0,
"radio_0":{
"enable":true,
"type":"SX1257",
"freq":923000000,
"rssi_offset":-166,
"tx_enable":true,
"tx_freq_min":921800000,
"tx_freq_max":923600000
},
"radio_1":{
"enable":true,
"type":"SX1257",
"freq":922000000,
"rssi_offset":-166,
"tx_enable":false
},
"chan_multiSF_0":{
"enable":true,
"radio":0,
"if":200000
},
"chan_multiSF_1":{
"enable":true,
"radio":0,
"if":400000
},
"chan_multiSF_2":{
"enable":true,
"radio":1,
"if":200000
},
"chan_multiSF_3":{
"enable":true,
"radio":1,
"if":400000
},
"chan_multiSF_4":{
"enable":true,
"radio":0,
"if":-400000
},
"chan_multiSF_5":{
"enable":true,
"radio":0,
"if":-200000
},
"chan_multiSF_6":{
"enable":true,
"radio":1,
"if":0
},
"chan_multiSF_7":{
"enable":true,
"radio":0,
"if":0
},
"chan_Lora_std":{
"enable":true,
"radio":1,
"if":100000,
"bandwidth":250000,
"spread_factor":7
},
"chan_FSK":{
"enable":true,
"radio":1,
"if":-200000,
"bandwidth":125000,
"datarate":50000
},
"tx_lut_0":{
"pa_gain":0,
"mix_gain":9,
"rf_power":-6,
"dig_gain":0
},
"tx_lut_1":{
"pa_gain":0,
"mix_gain":11,
"rf_power":-3,
"dig_gain":0
},
"tx_lut_2":{
"pa_gain":0,
"mix_gain":15,
"rf_power":0,
"dig_gain":0
},
"tx_lut_3":{
"pa_gain":1,
"mix_gain":8,
"rf_power":3,
"dig_gain":0
},
"tx_lut_4":{
"pa_gain":1,
"mix_gain":10,
"rf_power":6,
"dig_gain":0
},
"tx_lut_5":{
"pa_gain":1,
"mix_gain":13,
"rf_power":10,
"dig_gain":0
},
"tx_lut_6":{
"pa_gain":1,
"mix_gain":14,
"rf_power":11,
"dig_gain":0
},
"tx_lut_7":{
"pa_gain":2,
"mix_gain":10,
"rf_power":12,
"dig_gain":0
},
"tx_lut_8":{
"pa_gain":2,
"mix_gain":10,
"rf_power":13,
"dig_gain":0
},
"tx_lut_9":{
"pa_gain":2,
"mix_gain":11,
"rf_power":14,
"dig_gain":0
},
"tx_lut_10":{
"pa_gain":2,
"mix_gain":11,
"rf_power":16,
"dig_gain":0
},
"tx_lut_11":{
"pa_gain":3,
"mix_gain":9,
"rf_power":20,
"dig_gain":0
},
"tx_lut_12":{
"pa_gain":3,
"mix_gain":11,
"rf_power":23,
"dig_gain":0
},
"tx_lut_13":{
"pa_gain":3,
"mix_gain":12,
"rf_power":25,
"dig_gain":0
},
"tx_lut_14":{
"pa_gain":3,
"mix_gain":13,
"rf_power":26,
"dig_gain":0
},
"tx_lut_15":{
"pa_gain":3,
"mix_gain":13,
"rf_power":27,
"dig_gain":0
}
}
}
I replaced the original global_conf.json with this one, and make some minor modification by adding
"server_address":"router.as1.thethings.network"
into the local_conf.json to get the correct server address for accessing the The Things Network server.
The reference GPS coordinates are missing from this newly-provided file but that's okay as I already have it in my local_conf.json as I show before. I re-enable the GPS that I previously disabled from the local_conf.json.
"fake-gps": false
I also change the settings on The Things Network to reflect the fact that my gateway is now operated at AS920.
My RAK5205 is still on AS923, so I can't test the gateway with my RAK5205 yet. But I do see the gateway received data from three motes consistently, what this means is that the gateway now is operating at the correct frequency band of AS920.
Aug 24 23:56:16 rak-gateway ttn-gateway[552]: INFO: Received pkt from mote: 923A0008 (fcnt=14135)
Aug 24 23:56:16 rak-gateway ttn-gateway[552]: JSON up: {"rxpk":[{"tmst":3472182636,"chan":5,"rfch":0,"freq":922.800000,"stat":1,"modu":"LORA","datr":"SF12BW125","codr":"4/5","lsnr":-10.5,"rssi":-105,"size":23,"data":"QAgAOpKANzcRoQD91RJRgQ4fFVGixkg="}]}
Aug 24 23:56:16 rak-gateway ttn-gateway[552]: INFO: [up] PUSH_ACK received in 6 ms
Aug 24 23:56:16 rak-gateway ttn-gateway[552]: INFO: [down] PULL_ACK received in 4 ms
Aug 24 23:56:16 rak-gateway ttn-gateway[552]: INFO: Received pkt from mote: 923A0266 (fcnt=9899)
Aug 24 23:56:16 rak-gateway ttn-gateway[552]: JSON up: {"rxpk":[{"tmst":3475307604,"chan":0,"rfch":0,"freq":923.200000,"stat":1,"modu":"LORA","datr":"SF12BW125","codr":"4/5","lsnr":-15.5,"rssi":-109,"size":23,"data":"QGYCOpKAqyYR49QtyG+2Vqu6ZFiCP90="}]}
Aug 24 23:56:16 rak-gateway ttn-gateway[552]: INFO: [up] PUSH_ACK received in 4 ms
Aug 24 23:56:16 rak-gateway ttn-gateway[552]: INFO: Received pkt from mote: 260421F9 (fcnt=396)
Aug 24 23:56:16 rak-gateway ttn-gateway[552]: JSON up: {"rxpk":[{"tmst":3480606491,"chan":0,"rfch":0,"freq":923.200000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.5,"rssi":-36,"size":38,"data":"gPkhBCaCjAEDBwO6thh+nh9rLchiCecKhdgsbHtGjjCRo7WRN4s="}]}
Aug 24 23:56:16 rak-gateway ttn-gateway[552]: INFO: [up] PUSH_ACK received in 4 ms
Aug 24 23:56:16 rak-gateway ttn-gateway[552]: INFO: [down] PULL_RESP received - token[2:135] :)
Aug 24 23:56:16 rak-gateway ttn-gateway[552]: JSON down: {"txpk":{"imme":false,"tmst":3481606491,"freq":923.2,"rfch":0,"powe":14,"modu":"LORA","datr":"SF7BW125","codr":"4/5","ipol":true,"size":12,"ncrc":true,"data":"YPkhBCYgYgGdLxPI"}}
Aug 24 23:56:16 rak-gateway ttn-gateway[552]: INFO: == used txlut index:9
Aug 24 23:56:16 rak-gateway ttn-gateway[552]: INFO: tx_start_delay=1495 (1495.500000) - (1497, bw_delay=1.500000, notch_delay=0.000000)
Aug 24 23:56:16 rak-gateway ttn-gateway[552]: INFO: [down] PULL_ACK received in 8 ms
GPS Beacon for AS920
The configure file provided by RAKWireless comes with the GPS beaconing provision. As my knowledge on Lora deepen, I realised that those GPS beacon configuration is more for supporting Lora Class B(https://www.thethingsnetwork.org/docs/lorawan/classes.html and https://www.rfwireless-world.com/Tutorials/LoRaWAN-classes.html) operation, and not necessary to do with the GPS out of Sync issue that I’m facing. Nevertheless, if RAK7243 is capable of supporting, or requires to support Class B operation, then the Beaconing configure parameters need to be included in the system configuration.
GPS Synchronisation
With the new global_conf.json file from RAKWireless, the GPS is able to re-gain the sysnchronizaton at each cycle, but “out-of-sync” only stopped after roughly 5 hours later.
Aug 24 20:47:45 rak-gateway ttn-gateway[552]: ### [GPS] ### Aug 24 20:47:45 rak-gateway ttn-gateway[552]: # GPS coordinates: latitude 1.35515, longitude 103.84454, altitude -38 m Aug 24 20:47:45 rak-gateway ttn-gateway[552]: WARNING: [gps] GPS out of sync, keeping previous time reference Aug 24 20:47:45 rak-gateway ttn-gateway[552]: WARNING: [gps] GPS out of sync, keeping previous time reference Aug 24 20:47:45 rak-gateway ttn-gateway[552]: WARNING: [gps] GPS out of sync, keeping previous time reference Aug 24 20:47:45 rak-gateway ttn-gateway[552]: WARNING: [gps] GPS out of sync, keeping previous time reference Aug 24 20:47:45 rak-gateway ttn-gateway[552]: WARNING: [gps] GPS out of sync, keeping previous time reference Aug 24 20:47:45 rak-gateway ttn-gateway[552]: WARNING: [gps] GPS out of sync, keeping previous time reference Aug 24 20:47:45 rak-gateway ttn-gateway[552]: INFO: Disabling GPS mode for concentrator's counter... Aug 24 20:47:45 rak-gateway ttn-gateway[552]: INFO: Enabling GPS mode for concentrator's counter. Aug 24 20:47:45 rak-gateway ttn-gateway[552]: ### [GPS] ### Aug 24 20:47:45 rak-gateway ttn-gateway[552]: # GPS coordinates: latitude 1.35519, longitude 103.84454, altitude -54 m Aug 24 20:48:45 rak-gateway ttn-gateway[552]: WARNING: [gps] GPS out of sync, keeping previous time reference Aug 24 20:48:45 rak-gateway ttn-gateway[552]: WARNING: [gps] GPS out of sync, keeping previous time reference Aug 24 20:48:45 rak-gateway ttn-gateway[552]: WARNING: [gps] GPS out of sync, keeping previous time reference Aug 24 20:48:45 rak-gateway ttn-gateway[552]: WARNING: [gps] GPS out of sync, keeping previous time reference Aug 24 20:48:45 rak-gateway ttn-gateway[552]: WARNING: [gps] GPS out of sync, keeping previous time reference Aug 24 20:48:45 rak-gateway ttn-gateway[552]: ### [GPS] ### Aug 24 20:48:45 rak-gateway ttn-gateway[552]: # GPS coordinates: latitude 1.35521, longitude 103.84451, altitude -52 m Aug 24 20:48:45 rak-gateway ttn-gateway[552]: WARNING: [gps] GPS out of sync, keeping previous time reference Aug 24 20:48:45 rak-gateway ttn-gateway[552]: WARNING: [gps] GPS out of sync, keeping previous time reference Aug 24 20:48:45 rak-gateway ttn-gateway[552]: INFO: Disabling GPS mode for concentrator's counter... Aug 24 20:48:45 rak-gateway ttn-gateway[552]: INFO: Enabling GPS mode for concentrator's counter. Aug 24 20:48:45 rak-gateway ttn-gateway[552]: ### [GPS] ### Aug 24 20:49:45 rak-gateway ttn-gateway[552]: # GPS coordinates: latitude 1.35520, longitude 103.84449, altitude -46 m Aug 24 20:49:45 rak-gateway ttn-gateway[552]: ### [GPS] ### Aug 24 20:49:45 rak-gateway ttn-gateway[552]: # GPS coordinates: latitude 1.35520, longitude 103.84449, altitude -46 m Aug 24 20:49:45 rak-gateway ttn-gateway[552]: INFO: Disabling GPS mode for concentrator's counter... Aug 24 20:49:45 rak-gateway ttn-gateway[552]: INFO: Enabling GPS mode for concentrator's counter.
When GPS is finally “stabilised” from “out-of-sync”, the altitude is way off. I understand that to obtain altitude data, more than 5 satellites would need to be in view to get a reliable data.
To proof this is not RAK7243 or my location (my balcony) problem, I setup my own GPS with a uBlox neo-7M module, the altitude data is also way off. I further tested my uBlox neo-7M on a widely carpark rooftop in front of my apartment, the acquisition time improved (take about 30-45 seconds to acquire lat/long) but still take 6-7 minutes to acquire altitude data and altitude data is still way off, So I concluded that my location is probably less ideal for GPS operation, and what I observed on the RAK7243 GPS is not much different from what I see on my neo-7M purchased from China e-commerce shop.
Other than the incorrect GPS altitude data, I observed an “Invalid time reference (age: xxxx sec)” message from syslog, and the number of “age” second keep going up, even after rebooting the gateway. This syslog shows the information before and after the reboot.
Aug 26 08:59:17 rak-gateway ttn-gateway[552]: # Invalid time reference (age: 130164 sec) Aug 26 08:59:17 rak-gateway ttn-gateway[552]: # Invalid time reference (age: 130194 sec) Aug 26 08:59:17 rak-gateway ttn-gateway[552]: # Invalid time reference (age: 130224 sec) Aug 26 09:00:07 rak-gateway ttn-gateway[552]: # Invalid time reference (age: 130254 sec) Aug 26 09:00:07 rak-gateway ttn-gateway[552]: # Invalid time reference (age: 130284 sec) Aug 26 09:00:47 rak-gateway ttn-gateway[552]: # Invalid time reference (age: 130314 sec) Aug 26 09:03:11 rak-gateway ttn-gateway[521]: # Invalid time reference (age: 1598403731 sec) Aug 26 09:03:11 rak-gateway ttn-gateway[521]: # Invalid time reference (age: 1598403761 sec) Aug 26 09:04:11 rak-gateway ttn-gateway[521]: # Invalid time reference (age: 1598403791 sec) Aug 26 09:04:11 rak-gateway ttn-gateway[521]: # Invalid time reference (age: 1598403821 sec) Aug 26 09:05:02 rak-gateway ttn-gateway[521]: # Invalid time reference (age: 1598403851 sec)
As of this writing, I still don’t know how to make sense out of this observation yet.
My overall conclusion is that the GPS and GPS Beacon configuration will probably only needed for supporting Class B operation. If one intend to utilise altitude data in its application, particularly for getting altitude reading, it will probably require either a better GPS module (than the built-in Ublox Max-7Q in the RAK2245) and/or a better GPS antenna even at a widely-open area with no blocking.
Summary
Overall, RAKWirless made solid piece of hardware, its hardware are well made and professionally executed, both in mechanical and electronics designs. Its software packaging, documentation is still evolving and often kind of sloppy and needs improvement. RAK7243's documentation is well done but very limited, one of the problems that I see is that RAK2245 was based on and earlier concentrator RAK831, and many of the information and knowledge base that are relevant to RAK7243 can only be found under RAK831 documentation, this is almost require you to know RAKWireless product history and take hours of digging through its website/github page by page, and put the puzzle together.
I provided my suggestion through email and sincerely hope one day that RAKWireless will provide a SKU for AS920 on each product it sell. No matter how small the market it is for AS920 for now, it is after all one of the global allocation for the Lora deployment.
I personally leant a lot from this week's tinkering and gain a lot knowledge and understanding on how the a Lora Gateway works fundamentally. It provides me the hand-on experience on how to pick a gateway that I'm going to use for deployment and how to configure it.
I'm very surprise that there are very few Lora gateways on The Things Network in Singapore, maybe Singaporeans are more self-centre and do not like to share their gateways on The Things Network, nevertheless the number of gateways on The Things Network is a good indicator on actual deployment of the technology.
I'm also surprise to see how many people operating on the wrong frequency band, to me it is pointless to run a network on a wrong frequency band, for 1) you don't know what kind of interference you are facing when the network is operated at a frequency band that is not supposed to be; 2) whatever performance and range result are probably meaningless; 3) you can't commercially deploy a network that is operated on a wrong spectrum.
I will take a look at RAK5205 on my next article. Stay tuned....