Thanks for all RF module speculations, please move them to the topic where they belong.
With regard to our choice of LoRa RF module: All HopeRF modules are tested before leaving the factory, Ideetron already made a lot of products containing it and never had problems with them. Ultra low power in standby, and sending messages at all spreading factors. Also certification has already been done with these modules, so nothing to worry about. For the purpose of sending LoRa messages, they work perfectly in the context of this PCB. And if you would like another module, it is easily swappable.
Please discuss the proposed features of this super nice PCB here
This is great to find. I hope your project is continuing well.
I got started with LoRa specifically to monitor bee-hives! I am using the Heltec Lora-32 modules with HX711 and a temperature / humidity sensor. Already deployed a few along with some Things Network gateways.
Your web-app is far beyond anything I have time or patience to make. Could you tell me if it would be acceptable and possible to send my sensor data in to the app - for example where can I look for the Lora payload protocol?
I expect I will change to your hardware as well once it’s available, but for now it would be really nice to have the data collection and visualisation working nicely for the local beekeepers.
@evs01 Thanks for your comment.
You can become a member of our Slack community, please send me a PM with you email. There you can find the API specs for using the BEEP API and BEEP app with your own data. You can check out our https://github.com/beepnl/BEEP for the TTN payload protocols that we currently use.
I now have a wAP LR8 kit running at house with the Mikrotik External antenna.
I have now in my suburban area with houses and woods a reach of about 700 meters to my BEEP hivescales that have an internal antenna (lose wire)
The antenna is now at 5-5.5 meters height (on the top of my bungalow)
What are my options to have a better reach? and how much of an improvement should i see?
Is there an option to change the SF to a higher value?
What would i typically gain in range by setting the antenna on a 8meter pylon (now it is at 5.5 meters)
and how much would i gain by going to 15 meters?
Or in a 20 meter tree?
Is there another (legal) antenna that would improve range? any examples?
If you have ADR enabled, LoRaWAN will optimize the link by changing SF to the best data rate.
Downside of Beep hive scales is that the antenna is low to the ground.
The best way is to increase the antenna height at the bee hives by putting the node on a pole of 2 meters and extend the wiring to the scale.
Indeed; I’ve also seen bad performance with someone else’s installation on a roof terrace, which had a hard time joining on SF12, 850 meters away from a gateway at a good location. (Line of sight obstructed halfway by a big church, but a test node would happily use SF9, inside.) And despite ADR it would not move away from SF12 after many uplinks.
This also makes changing the batteries much easier, without the need to first move away the hive to even get to the base’s enclosure.
Internally, on the bottom side of the PCB, the BEEP base V3 uses an uFL SMT connector, to which one could attach a pigtail for an external antenna connector. That needs one to remove the wiring and PCB though. And even an external antenna, horizontally below the hive, seems not quite optimal. So an external connector would probably need some extension cabling for the antenna anyway. I’ve not actually tried any of this.
Moving the base’s enclosure itself seems like a smart alternative!
Hi Arjan, I am not sure if this is the correct topic, While I greatly appreciate the feedback from pe1mew (Remko), I 'll try first to mitigate the issues at the gateway side. At least I now have a great understanding of the effect of heightening the antenna, going to 10 meters should double my reach, going to 15 meters should triple my current reach, I understand ofcourse that this is in an ideal situation, not counting the probably 200+ other parameters that might have an effect, both + and -
i will try this weekend somewhere to cut the wire from the beep box and put it on a 3 meter high pole, and see what the effect is.
Aside: by default the base has ADR enabled. This does not work well for non-stationary devices, so may not work well when using it with TTN Mapper for testing. I don’t know if you can disable that.
Also, transmitting its total packet size of 59 bytes every 1 minute won’t adhere to TTN’s Fair Access Policy. On SF12BW125 thee 59 bytes only allow for one transmission every 2 hours. But even on the best data rate, SF7BW125, you’d be limited to one message every 6 minutes. For testing, this is not a problem though.
you assumed wrong, I did not do that as I am a Noob, and did not find this info myself. I only read an article/blog on thethingsnetwork on how to connect to ttnmapper. How can I connect back to the global BEEP TTN application afterwards? I assume if I let it connect to my own application to use the ttnmapper, the connection to the BEEP’s global application will be lost.
ADR -> I didn’t see an option for this anywhere, but then again, I could be looking in the wrong places.
Sorry, I didn’t know about the fair Acces Policy. I can see that using ADR , it is mostly using SF7 ATM . after testing, and even in between testing rounds I will set it back to a 15 minute interval then. np.
Testing today.
Total Crap. Beep base seem not to be in even alpha stage regarding consistency and reliabilty. My wife took out the power supply for the gateway this morning. One BEEP refused to reconnect. The other one also lost connection and will not regain connection while testing, wasting again multiple precious hours. I am starting to understand while no real world data is being put out on the BEEP website. Prolly is none.
That’s not how LoRaWAN works: devices do not “connect” to a gateway. Instead, once they get some secrets by activating on the network through one or more gateways, they simply just transmit when they want, and hope that the same or other gateways will receive their transmissions and forward their data to TTN.
However, with ADR enabled and sending every minute, then if the only gateway around was offline for a longer time, chances are that the device detected that its transmissions may have gone missing quite soon. For ADR, it will then have lowered its data rate step by step, until hitting DR0 (SF12 BW125). If not getting ADR responses at SF12 either, then at that point a device could choose to start a new OTAA join. But many devices don’t as it it’s not likely to help at all. Maybe BEEP’s source code can reveal more.
Assuming the device would just be stuck at SF12, the gateway should receive its packets once powered on again (without the need for a new OTAA join), and ADR should help the device to get to a better data rate again.
Indeed, TTN only forwards the data to the application that owns the device. (So, the one for which the settings in TTN Console match those in the device.) I’d assume you should copy and safely store the existing AppEUI and AppKey if visible in the app, and could restore those any time you like. But I don’t know.
Then apparently the reception quality was okay at that time?
I am starting to understand while no real world data is being put out on the BEEP website. Prolly is none.