Apologies. Some of the resources already linked into this compilation are still being edited by their original authors, i.e. they are currently still in draft mode yet [1].
What I can say about this appliance is that the board will also include a GSM modem, most probably the SIM800 again. So, depending on which type of telemetry you are looking at, it might not be the right choice anyway [2].
I felt like the articles are close to completion, so I decided to include them already in order to humbly build up a very slight pressure towards publishing them, mainly to remind us that those resources will not be forgotten about. On the other hand, they might in fact not be ready for public consumption yet. If this is the case, we will have to respect that and I would like to recommend to check back at a later point in time. Ping @clemens and @wtf. ↩︎
Correct. I am housing my hives on my land and I can rely upon a rural setting, and < 1/2 mile (0.8 Km) in all of the cases I have considered. That seems to scream LoRa to me.
All right. I think the designated board within our community on this matter is the HTCC-AB01: Heltec CubeCell Dev-Board, being a development board which can be used reasonably well in production. On the projects I am aware of,
Feel free to use the search function to find out more about certain details after getting accustomed to acronyms and jargon. I think the search functionality of Discourse is pretty decent and I personally use it more often than not.
Is the “The Things Indoor LoRaWAN WiFi Gateway - 8 Channel LoRa 900 MHz” (Product ID: 4345 on Adafruit’s website) a reasonable starter gateway for some initial work? A lot of the shields and hats with multi-channels seem to have supply chain issues right now, and for ~$100 that seems like it might be a good choice until things are not so weird.
I have 3 of them here in the US and like them. I emailed TTI and asked if they were still being produced and they said yes, they are still popular. They do not come with instructions, so you’ll need to google that. Setup process is a little funky but it works. Great for the price!
One of those TTIGs [1][2] was donated to me for developing Terkin and Kotori, but, as far as I know, I forwarded it to @einsiedlerkrebs the other day. I think he even managed to attach an external antenna to the device after tearing it slightly apart, in order to increase coverage.
You will find diverse reports on the TTN forum about this device, also some troublesomes, with eventual lockups. Maybe this is just what users observed that @NewHopApiary refers to as »funky setup process« ;] [3].
Personally, while never having worked with it, I also think it is a very reasonable starter gateway, suitable for development and home automation. For production usage in a rural area (outdoor conditions!?) you will probably also have a look at the Mikrotik or a similar device again in the future.
Also, I think the migration to TTNv3 caused some troubles for many users. This should now be a thing of the past, and current shipments will probably include modern firmware releases to resolve this matter. ↩︎
@Andreas I haven’t experienced any lockups yet. My comment about the setup being odd is that you have to hold a reset button for 5 secs and then a setup button for 10 secs. Just seemed convoluted to me.
@lbussy I have the unit plugged into an outlet inside a house. I then have several Dragino LSN50 units outside about 225 meters away. I’m seeing about -90db RSSI and about 9 SNR.
Something that’s just struck me is that the Arduino repository doesn’t have a LoRa node exemplar. All I see is RFM69 which I understand is not LoRa. Am I right?
Is there a reason LoRa doesn’t seem to be represented there? As a newbie, I may not understand the nuances, but it seems like LoRa would be a primary solution.
thank you for your excellent question. You are absolutely right. RFM69 is not LoRa. LoRa is RFM95/96. And even LoRa is not LoRaWAN. Roughly ;].
I had to catch up on this topic a bit, mainly because the work in this area spun off into two different dedicated projects by @wtf and @MKO, both based on the HTCC-AB01: Heltec CubeCell Dev-Board.
Arduino firmwares with LoRaWAN telemetry now has a short summary in order to give an overview about both projects to the community in this context, and to compare some of their properties.
Would this feature set be a common ground what you also roughly be aiming at?
It adds GPS which may or may not be desired and has solar cell management. It does have an OLED which we don’t need, but I am assuming it can be disabled via software and/or removed.
Whelp, I’ll try it out. I have one now and I am finally at Beta 2.1 of my other project so that’s good. I’m doing a little studying on Vue but I can take on a couple more things.
@Andreas I see the naming convention for the firmware is in the format of:
purpose role name, either node or gateway
transport name of the physical transport mechanism, e.g. rfm69, gprs or wifi.
protocol name of the transmission protocol, e.g. beradio, mqtt, http or any.
So a “scale” node I write using LoRa and beradio for the SparkFun QWIIC AD board would be named node-rfm69-beradio-nau7802?
Is beradio the currently recommended protocol for new development? And if I use that, does that imply I would need to implement a gateway (gateway-rfm69-beradio) to send to Hiveyes? And keeping in mind I snagged a Things Indoor Gateway; using the TTN gateway that I would use some other format compatible with TTN, correct?
I realize some of these questions are remedial, but until I actually get a “Hello World” running, I need to ask them.
don’t get confused about BERadio. It is a Bencode-based, yet custom-baked, ASCII-compatible payload format we used in the early days when running RFM69-based radio communication [1]. Today, I would focus on CayenneLPP instead as we did elsewhere already and only resort to a different serialization scheme when absolutely needed.
I think today, given that we would like to start with a LoRaWAN-based datalogger doing payload serialization using CayenneLPP, I would just call the variant/folder name "node-lorawan", straight ahead.
If we would gain different subvariants while we go, we can still rename to take in different other labels discriminating the firmware from similar ones, like heltec, ttn, etc.
This matter around the whole topic of telemetry resonates very much with your other question, which is yet unanswered:
Your inquiry here absolutely makes sense. I just haven’t been able to catch the time to write a concise compendium about that topic.
.)