It would - that gives me enough to start with really, as soon as I finish the next release of a VERY important project (Keg Cop .)
That HTCC-AB01 seems to be out of stock wherever I check. Any thoughts on the Heltec Automation CubeCell GPS-6502 ASR6502 LoRa GPS?
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:
purposerole name, either node or gateway
transportname of the physical transport mechanism, e.g. rfm69, gprs or wifi.
protocolname 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
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 . 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
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.
With kind regards,
As you can see on the repository at GitHub - hiveeyes/beradio: The BERadio specification and implementation for Arduino and Python. Transmit data in Bencode format over radio links, decode and publish to MQTT., it has not been updated since ages. We should actually reflect that statement on the repository or somewhere else as well. Also, we should bring the repository up to speed (Python 3.7+?) in case this is still useful to others. ↩︎
The way I see it, and given the ubiquity of PlatformIO, board variants should be handled in the
platformio.ini file as new definitions. Within reason of course. If we assume all of them will have an rfm69 radio, then the pin definitions for other items is trivial. Maybe. I say that without starting so you know how that goes.
I’m back! It took me forever to get my latest release done for another project, plus I was actually keeping bees in my spare time. I hope to get back to this to contribute some firmware in the near-term.