For SW reset, just add this on the line where you want to reset NVIC_SystemReset();
When the device shutdown or reset, it has no idea on the join attempts it previously did.
If you are failing on joining, we need to figure out where is the issue. Is it on the device (HW or SW)? Are the EUIs and KEY confirmed? Can you generate a new KEY and try to join again? Is it a gateway issue? Is the gateway really online? If it is Helium, do you have a device that connects to the helium network via that hotspot to confirm that the hotspot really transmits LoRa packets? Do you have control over the gateway or hotspot? Does your device reach the hotspot? Is it too far? Or too near? Are the antenna both on the device and gateway/hotspot secured?
Just from my experience when I setup my Helium Hotspot.
If the Hotspot is in sync mode, it does not transmit any packets including Join requests.
Even if the Helium explorer or the Helium app says it is synced, it might not be fully synced. I had to use this link https://explorer.helium.com/blocks/latest to see the number of blocks and then the diagnostics of the Helium app to see that there are still blocks to be synced.
I would strongly suggest to test the Join request first on a “normal” gateway and a “normal” LoRaWAN server before trying to connect it to Helium.
Another thing to check is the region that the Helium Hotspot is using. My Hotspot is a US915 hotspot, but because I am in the Philippines, the hotspot decided to use AS923-3 instead.
Turns out it was actually an issue on the blockchain side, and appears it has been resolved. I was able to connect today! Also I am using US915, it is the correct region. Another question I have is related to the gas readings. So the sensor reads gas in hms, but I can barely find anything about the unit hms on the internet. It does stand for Hydrogen Monitoring System correct? Is there any way to convert this to AQI or something so that we can accurately show the air quality percentage?
I still do get this issue where I have to keep power cycling it though to send a packet. As you can see, the first two dots that are close together were my first attempt, and the second one spaced out was the second. I have to unplug it and plug it back in to do anything. Usually after a couple tries it will work, but as of lately it hasn’t stayed connected long. I do think this is an issue the blockchain has been having though
Welcome to RAK4630 LoRaWan!!!
Type: OTAA
Region: US915
I am using DR 3 and ADR set to off already. Should I bump up to DR 4? Another question I have is related to the gas readings. So the sensor reads gas in hms, but I can barely find anything about the unit hms on the internet. It does stand for Hydrogen Monitoring System correct? Is there any way to convert this to AQI or something so that we can accurately show the air quality percentage?
What is your payload size? I can tell you the data rate (or you check by yourself in the link I gave you). But without knowing the payload size I cannot say if DR 3 or DR5 or ??? is required.
For the BME680, the algorithm to calculate AQI is Bosch proprietary calculations. You have to use the Bosch BSEC library (linkable library, not open source).
We have right now no example how to use the Bosch library, but there are some information on the internet about it.
In this case DR1 or DR2 should be enough if using US915 region.
I have a Helium Hotspot Miner V2 and a RAK7258 Edge gateway. My environment node (WisBlock + BME680) was running for weeks without packet loss when connected to the RAK7258 and my private Chirpstack server. Using the exact same code, but connecting to Helium, I see severe packet loss. Both gateways are in same distance to the node, both are using same region, both show similar RSSI of the packets (quite good, ~50 dBi).
I don’t want to push the problem to Helium, but I have no explanation for your problem. Do you have the possibility to test with a normal gateway that is connected to TTN or another LoRaWAN server?
Continued some testing and changed the packet to confirmed message (node waits for ACK from server and repeats to send the packet if no ACK from server arrives).
On Helium Console I see many repeated packets, which means the WisBlock didn’t receive the ACK:
Same node, now connected to RAK7258 and Chirpstack server. There is not a single failure to send on the first try (check the time-stamps, all 10 minutes from each other)
Ok, I saw something related to that. Good to know Carl! Beegee I will try switching to dr 2 and see if I get any better results. Ok so would the best thing to do is buy a top extension piece for my raspberry pi to create a lora gateway?
Also side issue… so the wind speed monitoring example you guys gave had this link to buy the wind monitor device, and it’s all in Japanese. Even if we could translate it, I’m not sure if they will even take US dollar or ship to the US. Is there any US vendor for one of these, or a similar product that you can recommend that will work just as well as an alternative?
As you can see, this is all Japanese here http://jxiotcity.com/zdcs/zdcs204.html
Having a standard LoRaWAN gateway will be good because you can isolate if the issue is in the device or in the Helium network. As the Helium network grows, it will experience unstable operation unless the blockchain are now in the validators and not in the hotspot miners.
Ok, you nearly lost me here with too many different things in one message.
About the Wind monitoring device, I do not know that device and how to connect it.
About merging the two applications, you need
read the values from the wind speed device
read the values from the BME680
create a payload that includes all sensor values
For the payload:
count the bytes, check your region and maximum payload size, check if there is a data rate that allows to send your payload in one packet
If the payload is too large, you have to create two data packets and send them one after the other. Keep in mind, that lmh_send is giving the packet to the LoRaWAN library, but it does not wait for the packet to be sent. You can send the second packet only after the first packet TX has finished. You can use the TX finished callbacks as explained in the SX126x-Arduino documentation.
For the RPi Hat, I have no idea what you want to do with it. The link goes to a LoRa transceiver, I do not understand how this helps with your questions.
I’m sorry beegee, I can be bad about that sometimes. Ok I guess what I’m missing here, is what hardware do I need to setup a gateway to test something on ttn or something like that? I thought you could set one up with a rpi so I bought that hat, but if this is the wrong piece of hardware can you point me in the right direction and I’ll cancel the order. I just want to run tests the way you are showing me
Ok, I am curious if I could use this hat on ubuntu mate 21.04 that I have installed on my rpi4, or do I have to install a separate os to use it? Also the US ones are sold out. Is there anywhere else I can get it, or get one like it to run tests? Looking into it, the original one beegee showed me seems to have a similar hat. Could I put this hat on my rpi 4 too if I bought this? Gateway
If you will use the WisGate Developer D0/D0+, it has an RPI Zero W so you wont need an extra RPI.
Since the RAK2245 has no stock for US915, you can also use this concentrator and match it with appropriate hat. This one also uses the latest LoRaWAN Baseband Chip processor.
As for the software, the RAK FW is based on Raspbian OS. We have provided an image for that than can be found on the quick start guide.
