Yes I have read the rules used by the open source ADR algorithm mentioned in the post you linked. During testing (with the ADR bit set to on, as is by default) I sent more than 20 uplink messages but the data rate never changed when checked with AT commands on the Lora-e5 board.
I tested this cycle multiple times with the ADR bit set to on and off, but neither triggered any action for a DR change. When the ADR bit was set to on, I could see the TTN log for the device acknowledging this in the logs, but the device never changed its rate.
In my understanding, time does not play into the algorithm after briefly looking over it. The only requirement is a minimum 20 uplinks (I think below this value as well, the ADR algorithm just adds a higher margin of error in dB, but still controls ADR).
If you could clarify how to track this with a demo or further information using your Lora-e5 board that would be great!
Getting this error sometimes when running lora setup code LoRa_Transmit_data.py
Traceback (most recent call last):
File "<stdin>", line 162, in <module>
File "<stdin>", line 71, in test_uart_connection
File "<stdin>", line 59, in receive_uart
UnicodeError:
Am I right in thinking this is a connection issue between the Pico and the LoRa-E5?
Also having an issue with getting failed join on TTN after the first time it worked. E5 i being picked up by TTN and sending confirmation signal, but the E5 seems to think the join has failed. Is there anyway to run the code without the full join sequence each time as it is already on TTN?
Regretfully we don’t have the weather station up and running at the moment so it is not sending through any data. Though we may have it back up soon so keep an eye out on that space!
@lab@Blayden I’ve fired up our test unit for a couple of samples and everything appears ok. New data published to the feed just fine.
We may have to figure out a long-term solution to keep this unit running continuously for posterity, lest we have a project page full of empty data
That’s usually due to the join request being accepted on TTN and broadcast at the gateway, but the remote unit not picking up the accepted-message. The gateway is probably more a more sensitive receiver than the remote LoRa unit - this may be a range issue.
I can see that the project code may not return sensible air quality data - the ENS160 requires some time to warm up - especially on the very first powerup → refer to the Initial Start-Up and Warm-Up section in the guide. It’s also worth noting that the ENS160 requires 24hrs of operation after its first powerup before it is considered to be out of the initial-start-up state.
I propose modifying the code with a loop (and maybe a timeout?) that guarantees the ENS160 is ready before proceeding to log or transmit data.
Presently the code does 5 throwaway readings before proceeding ie.
# Warm Up Read from Sensor 1 (ENS160)
aqi = sensor1.aqi
tvoc= sensor1.tvoc
eco2 = sensor1.eco2
sleep_ms(1000)
#True Read from Sensor 1 (ENS160)
for _ in range(5):
aqi = sensor1.aqi
tvoc = sensor1.tvoc
eco2 = sensor1.eco2
sleep_ms(1000)
I propose waiting for the .operation property to return 'operating ok' before proceeding. This could look like the following:
while sensor1.operation is not 'operating ok':
aqi = sensor1.aqi
tvoc = sensor1.tvoc
eco2 = sensor1.eco2
sleep_ms(1000)
# implement a timeout here too if you wish
Hi Tim@Core Electronics,
I’ve recently purchased the PicoW and E5 module and following the video and guide to set it up. I get as far as having created my TTN a/c, obtained the AppID and inserted into code of Lora_Transmit_data.py. What I get is…(ID’s masked)
I’m looking to bring this project to my students, but there are a few things I would like to sort out before I do so.
hPa, is incorrect, and from what I’ve read it needs to be adjusted, depending on the metres above sea level of the site of the unit.
As Michael mentioned on 12 July, there needs to be a warmup period for ENS160, before it will return correct readings.
I’m going to need some help with the coding please. I’ve completed the project and it works fantastic. I would just like to get these few issues sorted.
I wanted to share some findings that might assist fellow travellers on their journey. I’ve come across a few solutions to the issues mentioned earlier.
Regarding the advice from Michael dated July 12th, it’s crucial to keep your ENS160 powered up continuously for a full 24 hours for accurate results. But how do you determine when this 24-hour period is achieved?
Please take a moment to watch the video linked below. The information we’re seeking is available from the 4:15 mark in the tutorial:
Now that we have a clear understanding of the three states of the ENS160, I suggest the following code. I’ve incorporated Michael’s recommendation and added a timer. The timer is designed to prevent the ENS160 from completely draining your battery if it doesn’t return an ‘operating ok’ status. In my tests, running the unit continuously with three AAA batteries only provides about 12 hours of runtime.
# Initialise a Variable for time
timeout_seconds = 300 # Set your desired timeout in seconds for the ENS160, loop timer to prevent battery drain. Smith 25/10/2023
start_time = time.time()
#--------------------------------------------------------------------------------------
# Start Up Sensor 1 (ENS160)
aqi = sensor1.aqi
tvoc= sensor1.tvoc
eco2 = sensor1.eco2
sleep_ms(1000)
# Wait for sensor1.operation to return a 'operating ok' condition.
while sensor1.operation != 'operating ok':
aqi = sensor1.aqi
tvoc = sensor1.tvoc
eco2 = sensor1.eco2
sleep_ms(1000)
# Print air quality metrics from Sensor 1 (ENS160)
print('Air Quality Sensor')
print(' AQI: ' + str(aqi.value) + ' [' + str(aqi.rating) +']')
print(' TVOC: ' + str(tvoc) + ' ppb')
print(' eCO2: ' + str(eco2.value) + ' ppm [' + str(eco2.rating) +']')
print('Operational Mode Status: ' + str(sensor1.operation))
print('-------------------------------------')
print()
print('-------------------------------------')
# Check if the timeout has been reached
current_time = time.time()
if current_time - start_time >= timeout_seconds:
print("\033[31m" + str(timeout_seconds) + " Second have passed. Sensor operation not 'operating ok'." + "\033[0m")
print('-------------------------------------')
print()
print('-------------------------------------')
break
# Small timeout to avoid spamming shell
sleep_ms(1000)
# True Read from Sensor 1 (ENS160)
aqi = sensor1.aqi
tvoc = sensor1.tvoc
eco2 = sensor1.eco2
sleep_ms(1000)
# Print air quality metrics from Sensor 1 (ENS160)
print('Air Quality Sensor')
print(' AQI: ' + str(aqi.value) + ' [' + str(aqi.rating) +']')
print(' TVOC: ' + str(tvoc) + ' ppb')
print(' eCO2: ' + str(eco2.value) + ' ppm [' + str(eco2.rating) +']')
print('Operational Mode Status: ' + str(sensor1.operation))
print('--------------------------------')
# Small timeout to avoid spamming shell
sleep_ms(1000)
hPa, is incorrect. I’ll keep looking for a more eloquent solution but for the meantime I will use this solution I will calculate the offset between what the ENS160 output, an add the difference from a weather app, this should get us close. Example if the ENS 160 produces 923.33 hPa, and my weather app shows 1024.8. 1024.8 – 923.33 = 101.47 I’ll be using the below code.
# Convert air pressure Pascals -> hPa (or mbar, if you prefer)
pres_hPa = presPa / 100 + 101.47 # 101.47 barometric pressure offset for my location
I liked this project, well done and thanks for all the hard work in creating it. I have been a fan of LoRa for several years and have played around with it using several different boards. From what I remember a LoRa device should not repeatedly JOIN the network ever time it wants to send data. There is a limit to how many JOINs an end device can do, not to mention it takes much longer to JOIN and send data than it needs to just send new data thereby using more power to do so. There needs to be a way to save the session keys so it does not have to do another JOIN.
Thanks for the feedback! LoRa is a super cool protocol and has so many application to play around with. I think you are correct about the JOIN process. normally a JOIN is only required again if the device resets or in conditions where the network requires the device to re-join for security purposes which wouldn’t happen very often.
If you run into a way to save session keys let us know, that would be a great thing to add to the LoRa toolbelt!
