Closed MedadRufus closed 3 years ago
Pretty printing Json
{
"app_id": "icss_lora_tracker",
"dev_id": "icspace22",
"hardware_serial": "00B76CF36C7CFA8A",
"port": 0,
"counter": 2220,
"payload_raw": null,
"metadata": {
"time": "2020-10-28T13:44:37.129959782Z",
"frequency": 904.6,
"modulation": "LORA",
"data_rate": "SF8BW500",
"airtime": 20608000,
"coding_rate": "4/5",
"gateways": [
{
"gtw_id": "eui-647fdafffe009962",
"timestamp": 2283517889,
"time": "",
"channel": 18,
"rssi": -107,
"snr": -10.5,
"rf_chain": 0,
"latitude": 48.12364,
"longitude": -78.09939,
"altitude": 397
}
]
}
}
{
"app_id": "icss_lora_tracker",
"dev_id": "icspace22",
"hardware_serial": "00B76CF36C7CFA8A",
"port": 99,
"counter": 2245,
"payload_raw": "AHMJoAFn/7wCiAfXY/QIXA8NIAMCJiYEAQs=",
"payload_fields": {
"analog_in_3": 97.66,
"barometric_pressure_0": 246.4,
"digital_out_4": 11,
"gps_2": {
"altitude": 9864,
"latitude": 51.3891,
"longitude": -78.4292
},
"temperature_1": -6.8
},
"metadata": {
"time": "2020-10-28T14:38:24.185519511Z",
"frequency": 904.6,
"modulation": "LORA",
"data_rate": "SF8BW500",
"airtime": 38528000,
"coding_rate": "4/5",
"gateways": [
{
"gtw_id": "eui-647fdafffe009962",
"timestamp": 1215593121,
"time": "",
"channel": 18,
"rssi": -109,
"snr": -8,
"rf_chain": 0,
"latitude": 48.12367,
"longitude": -78.09937,
"altitude": 399
}
]
}
}
{
"app_id": "icss_lora_tracker",
"dev_id": "icspace22",
"hardware_serial": "00B76CF36C7CFA8A",
"port": 0,
"counter": 2251,
"payload_raw": null,
"metadata": {
"time": "2020-10-28T14:49:31.104492242Z",
"frequency": 904.6,
"modulation": "LORA",
"data_rate": "SF8BW500",
"airtime": 20608000,
"coding_rate": "4/5",
"gateways": [
{
"gtw_id": "eui-647fdafffe009962",
"timestamp": 1882515809,
"time": "",
"channel": 18,
"rssi": -106,
"snr": -9,
"rf_chain": 0,
"latitude": 48.12365,
"longitude": -78.09937,
"altitude": 389
}
]
}
}
{
"app_id": "icss_lora_tracker",
"dev_id": "icspace22",
"hardware_serial": "00B76CF36C7CFA8A",
"port": 0,
"counter": 2260,
"payload_raw": null,
"metadata": {
"time": "2020-10-28T15:07:51.137357052Z",
"frequency": 904.6,
"modulation": "LORA",
"data_rate": "SF8BW500",
"airtime": 20608000,
"coding_rate": "4/5",
"gateways": [
{
"gtw_id": "eui-647fdafffe009962",
"timestamp": 2982558473,
"time": "",
"channel": 18,
"rssi": -107,
"snr": -3.8,
"rf_chain": 0,
"latitude": 48.12365,
"longitude": -78.09939,
"altitude": 395
}
]
}
}
{
"app_id": "icss_lora_tracker",
"dev_id": "icspace22",
"hardware_serial": "00B76CF36C7CFA8A",
"port": 99,
"counter": 2276,
"payload_raw": "AHMF5wFn/80CiAfXwPRecQ8aBAMCJCUEAQg=",
"payload_fields": {
"analog_in_3": 92.53,
"barometric_pressure_0": 151.1,
"digital_out_4": 8,
"gps_2": {
"altitude": 9897,
"latitude": 51.3984,
"longitude": -76.2255
},
"temperature_1": -5.1
},
"metadata": {
"time": "2020-10-28T15:39:55.104081611Z",
"frequency": 904.6,
"modulation": "LORA",
"data_rate": "SF8BW500",
"airtime": 38528000,
"coding_rate": "4/5",
"gateways": [
{
"gtw_id": "eui-647fdafffe009962",
"timestamp": 611557965,
"time": "",
"channel": 18,
"rssi": -107,
"snr": -6.5,
"rf_chain": 0,
"latitude": 48.12366,
"longitude": -78.09938,
"altitude": 391
}
]
}
}
{
"app_id": "icss_lora_tracker",
"dev_id": "icspace22",
"hardware_serial": "00B76CF36C7CFA8A",
"port": 0,
"counter": 2277,
"payload_raw": null,
"metadata": {
"time": "2020-10-28T15:42:24.125170512Z",
"frequency": 904.6,
"modulation": "LORA",
"data_rate": "SF8BW500",
"airtime": 20608000,
"coding_rate": "4/5",
"gateways": [
{
"gtw_id": "eui-647fdafffe009962",
"timestamp": 760577143,
"time": "",
"channel": 18,
"rssi": -101,
"snr": -6,
"rf_chain": 0,
"latitude": 48.12366,
"longitude": -78.0994,
"altitude": 390
}
]
}
}
All transmissions were on 904.6Mhz which corresponds to Channel 65. I expected it to tx on 9 different channels but by setting it to use DR4, it only transmits on SF8 - BW500. Channel 8-15 use BW125 which is not used at all when using DR4. So it is stuck in one single channel.
The single channel txing does not explain why the transmissions were limited. According to Disk91, the only limitation is it can tx for at most 400ms in 20 seconds:
The no data packet can be replicated in EU868 by setting the packet size to be very big i.e 60 bytes. Data rate was set to DR_0
lorawan_regional_parameters_v1.0.3reva_0 says that max bytes is 59.
However, Every single tx in EU868 simulation has the no data packet. However, we have seen over US915 that it is intermittent; 4 out of 6 packets had no data.
I believe that the first tx from each us915 transmission is an empty frame. This is based on using the debugger to trace. Not sure why. However, this happens only on the first tx(after power up). Subsequent transmissions will all have frames with data. However, from flight data, we find that this empty frame transmission happens often and intermittently. Empty frame happened 4 times out of 6 received transmissions. The code seems to show no indication of this intermittent empty frame transmission.
Solar Voltage is 3.6V and 3.8V on the two transmissions. I would expect it to be higher, though I did not verify the height of the sun.
I suspect that the device is resetting often, due to brownouts.
My first suspicion is because of the wider bandwidth used on US915 than in EU868 and AS923. In EU868 and AS923, bandwidth is 125khz while in US915, bandwidth is 500khz. This larger bandwidth may becausing higher current consumption. Also, it appears that the 500khz transmissions have a very short air time compared to 125khz. Around 38 milliseconds for 500khz vs 154milliseconds for 125khz. I think there may be a transient current spike during the US915 transmission that the solar cells cannot sustain.
One solution is to switch to using DR3 instead of DR4 as default data rate. This will make the tracker tx on 125khz bandwidth in the US. This will improve SNR performance as well.
The bandwidth info is taken from Region.h
:
/*!
* Region | SF
* ------------ | :-----:
* AS923 | SF9 - BW125
* AU915 | SF7 - BW125
* CN470 | SF9 - BW125
* CN779 | SF9 - BW125
* EU433 | SF9 - BW125
* EU868 | SF9 - BW125
* IN865 | SF9 - BW125
* KR920 | SF9 - BW125
* US915 | SF7 - BW125
* RU864 | SF9 - BW125
*/
#define DR_3 3
/*!
* Region | SF
* ------------ | :-----:
* AS923 | SF8 - BW125
* AU915 | SF8 - BW500
* CN470 | SF8 - BW125
* CN779 | SF8 - BW125
* EU433 | SF8 - BW125
* EU868 | SF8 - BW125
* IN865 | SF8 - BW125
* KR920 | SF8 - BW125
* US915 | SF8 - BW500
* RU864 | SF8 - BW125
*/
#define DR_4 4
lorawan_regional_parameters_v1.0.3revA indicates that max payload size for DR3 and 4 is 250 bytes. Plenty of space.
Richard will be doing some tests with the B-L072-LRWAN1 dev board on US915 frequencies.
When using US915, the first frame after reset ALWAYS goes through this point: code link. The comment there says
// Send empty frame in order to flush MAC commands
This happens everying single time when transmitting on US915 but never when using EU868. Note that the second and beyond frame in US915 does not hit this breakpoint. Also, changing from DR4 to DR3 does not change this phenomenon.
What I think is happening is the tracker is resetting often, possibly during the tx phase. This may be due to the higher power transmissions over US915.
looking at the region.h
file for EU868 and US915, we see that max EIRP for EU868 is 16.0f
vs max ERP 30.0f
for US915. Note that the definition for EIRP and ERP is a little different.
/*!
* Default Max EIRP
*/
#define EU868_DEFAULT_MAX_EIRP 16.0f
/*!
* Default Max ERP
*/
#define US915_DEFAULT_MAX_ERP 30.0f
90% sure of reset happening. The US915 TX power is much higher
This is the smoking gun.
When we plot elapsed time from previous tranmission, we find that all transmission with empty frames(in red dots) have had an elapsed time from previous transmission of more than 107 seconds. The values range from 149 -181 seconds. There is some variation in this time period. This can be explained by the time taken for the GPS to get its first fix after a full power cycle after a reset of the MCU. Only after the GPS fix does it do its first transmission after reset.
On the other hand, tranmissions with data(in blue) all have an elapsed time of either 107 seconds or a multiple of this time period, taking into accound lost packets due to poor reception.
It is however a mystery why it has a standard period between tranmissions of 107 seconds while it is programmed to be 120 seconds. It may be due to extreme drift of the internal 32Khz RC oscillator that provides this timing.
The data in the graph is taken from the flight of ICSPACE22 over California, USA on 8 November 2020 tranmitting on US915 frequencies.
The data from the next day looks more interesting. We have a lot more empty packets. We have a lot more variation in elapsed time between transmissions. Indeed due to poorer reception in North Dakota, we may be missing quite a few packets.
However, this could ALSO be due to less sunlight at this latitude compared to the previous day's latitude. Less sunlight may be causing it to have less current, and hence more likely to reset.
Its definately browning out due to high power transmissions over US915. Simple solution is to reduce tx power over US915.
The raw logs are here