to get a certified device you need to have the full stack implemented.
it should be the goal of each developer to build a device that comes near these specs.
you can build a small device which is only 23x19mm in size with a cubecell module and an bme680 and a full stack.
and that is even smaller than the ATTiny84 version
The price of a cubecell module is: 12,09€
The price of a ATTiny84 is: 0,84€
Any questions?
Which part of the device manages the MAC commands, you mentioned?
The RFM95W… without any notices
or
the microprocessor chosen?
Sum up all your parts cause the cubecell is the cpu and lora transmitter.
It is by far more powerfull and nearer to lorawan specs
ok. this sounds promising. will do further investigation
An RFM95W is not doing anything related to LoRaWAN. So, the LoRaWAN stack in one’s own code would handle the MAC commands after the RFM95W has received the LoRa downlink.
(This is different in, e.g., a Microchip RN2xx3 module, which takes care of everything LoRaWAN, and only needs one’s own code to set some initial configuration, and to trigger persisting the state if one wants that state to survive a full power down. And do whatever is needed to provide the application payload, of course.)
By even asking this question, you’ve indicated that you really don’t have sufficient awareness of the task to be suggesting an ATtiny as a solution.
The price of a cubecell module is: 12,09€
The price of a ATTiny84 is: 0,84€
Comparing a bare chip to a module is not legitimate. Compare a bare chip to a bare chip, and you’ll find a suitable ARM Cortex M0 costs a couple of € - which is to say less than a suitable large-memory ATmega1284 or 2560.
If you want to look at modules, the Mura LoRa/MCU module is maybe 50% more than the price of a radio-only module without an MCU.
I think you are not in the position to judge about me in this manner!
It is simply not possible to argue for a proposed solution until one understands the task. When proposing a processor it is necessary to understand how the overall task divides between the radio and processor(s). LoRaWAN is a fairly complex protocol which is implemented in software of substantial complexity, requiring quite a bit of program storage. A LoRa radio only handles the LoRa level, leaving all of the protocol to be accomplish by software.
I do not take part in discussions like this.
i think we all have to calm down a little.
i dont like nodes that cant handle the complete protocol or at least most of it
and i think a ATTiny84 cant handle that. but it is only my honest opinion
if the ATTiny84 can do it great but if not be open for other platforms.
I love it!
I can appreciate the do-it-yourself route that is taken during this project, you probably learned a lot along the way.
I also have some sensors running based on the attiny84a + RFM95W combination. Maybe I will change the setup in the future, but for now I prefer it because:
Of course there are more powerful uC available, I will probably thinker with them in the future (I already have a project planned), but the restricted space on the attiny family also forces you to program more efficient which triggers my interest.
I’m eager to learn more, especially about the fact that my sensors are maybe not well-behaving according to the specifications (I simply don’t know?). Looking at the responses above it is clear that people have something to say about this kind of combination, but I’m missing clear violations and I’m also missing help and information about how to overcome this (I’m under the impression that this should be the goal of a forum, but maybe I’m wrong).
So for the experts above, can you shine some light on:
Bear in mind: I’m not a professional, I’m just tinkering with it in my spare time.
First of all, as an intellectual exercise and an example of low resource programming this is a very nice project. However for a fully compliant LoRaWAN node it is not efficient.
Regarding your points:
Keep tinkering by all means. Invest your time in whatever you want as it is yours to invest. But please keep an open mind about the limitations. (And I know some of those limitations make the challenge interesting)
A question because I am curious about your choice: have you ever checked the available cheap Arm based controllers or is the ATTiny just a default you know well?
Thank you for your reply.
If I understand correctly, for my use case (hobby projects) it is not obligated to receive (and process) the MAC commands. I should of course be careful about the messages I send (spreading factor, transmission power, duty cycle) and should respect the 868 MHz band rules and the TTN Fair Access Policy. In my use case (SF7, low transmission power and duty cycle below 0.001 %) I think I’m in the clear. Or should I still be worried?
A good remark is that the device will not have LoRaWAN certification, but if I understand correctly, certification is not mandatory for TTN? If so, this should not be stated as a problem but can certainly be noted as a remark when it is reasonable that the project will be used commercially.
Regarding the receiving part, reading posts from this forum I conclude it is possible to receive and process the MAC commands with an attiny8x + rfm95w combination (link). You said before that this combination of hardware will never be compliant. I assume that you probably meant never be certified instead of compliant (because you say compliant specification does not explicitly state receiving/processing MAC commands to be mandatory). But when receiving and processing of MAC commands are implemented, why should it still fail certification? Can you shine some light on that?
It is confusing to read such a resistance against a project like this. I can understand that it is maybe not the approach other people would prefer, but that doesn’t mean it is wrong and cannot be tweaked to something that is right without using other hardware. I think it is good the keep an open mind about different use cases and levels of skills. Not everyone is building a commercially device in high volumes, a lot of people are trying to learn something here.
I actually started tinkering with Raspberry Pi’s (not with LoRa at the time), but after some time I thought, that’s quite some overhead, running a full OS, to control some simple electronics. That was the start to first learn about some Arduino stuff and later a dive into bare attiny chips. Which are, funny enough, for a lot of small projects still overkill. And now I am used to the Atmel chips and those are lying around here and I also use them for other projects.
You say this node is not efficient, “efficient” can be interpreted in several ways. I think the combination is quite efficient regarding power, size and costs, but maybe not the most efficient looking at the full development process. But yeah, buying an off-the-shelf node would then be the most efficient, but where is the fun in that? 
But still, if you know a module with better specs (size, power consumption) without being more expensive, I would love to know.
Receiving LoRaWAN messages was already something on my learning list, not necessarily for processing MAC commands but primarily for other things. I will certainly dive into the specifics of that in the future. Looking at this conversation and multiple other posts at this forum, I think an open conversation about the development of this kind of nodes is a positive thing.
@koenn As far as I am aware, you should take care that your device does at least the following:
Regarding the receiving part, reading posts from this forum I conclude it is possible to receive and process the MAC commnds with an attiny8x + rfm95w combination
No, it’s not really possible to implement proper bidirectional LoRaWAN - especially not when leaving program space for the node to do anything meaningful with sensors. People who’ve not been up to their elbows in the details simply do not understand the complexity, period.
You said before that this combination of hardware will never be compliant.
Indeed, it will not be
It is confusing to read such a resistance against a project like this.
The only thing that is confusing is why people like you are so ignorantly determined to continue wasting time and money on something that can never work right, when there are so many alternatives MCUs that are easier to work with, physically as small and low power, inexpensive, and have memory room to grow to full compliance.
Receiving LoRaWAN messages was already something on my learning list, not necessarily for processing MAC commands but primarily for other things. I will certainly dive into the specifics of that in the future. Looking at this conversation and multiple other posts at this forum, I think an open conversation about the development of this kind of nodes is a positive thing.
Such learning goals are precisely why you need to cease wasting time with an ATtiny and switch to a chip with enough memory to support these goals.
You don’t buy a growing child shoes that are already too small.
@cslorabox @koenn We have a LoRa implementation consisting of ATtiny85 + RFM95 with 8 channels, all datarates, full bidirectional communication, ABP or OTAA and support for a pretty decent subset of MAC commands.
The only thing which is really limiting is the IO on the ATtiny. If you implement a full SPI interface with the RFM, there’s not much IO left for a sensor. But as a small size and really cheap geotracker or for detecting some on/off signal it works great.
@koenn, the LoRaWAN standard prescribes that all devices (and also all gateways) should at least support those 3 basic channels: 868.10 / 868.30 / 868.50
As to your last paragraph, I don’t follow the reasoning that a fixed channel device uses lower bandwidth. In my opinion it makes no difference. However, a fixed channel device puts an unbalanced load on the frequency spectrum as a whole (i.e. only one channel) therefore I would say such devices are unwanted.
Posts shall not contain only links, which holds even stronger for topic start posts.
Your start post contains only a link but no description. As a result it is not clear what the link is about (without first clicking it) and worse it is unclear why you are posting it, which invites to any random responses - including critical ones - wasting other people’s time and efforts and leading to nothing.
RFM95 is a LoRa radio that itself does not support the LoRaWAN protocol. The LoRaWAN protocol stack software therefore needs to run on the microcontroller. Only few public LoRaWAN compliant libraries are available and they are too large to fit on an ATTiny84 (were not designed for that).
That software is closed source and was developed commercially, investing much time. The source code is not publicly available. The IoT space and LoRaWAN have matured since then and more capable hardware and software solutions are currently publicly available. It is therefore not wise to use ATTiny for development of new LoRaWAN devices.
The TinyLoRa device appears to be able to transmit / send LoRaWAN uplink messages only - which is only a part of the LoRaWAN protocol - and without capabilities to handle downlink (control) messages.
Devices that are able to transmit only are NOT LoRaWAN compliant and are therefore NOT supported on the forum (similar to ‘single-channel’ devices and LoRa-only devices).
My 2¢: The RFM95 module alone is much more expensive than ATTiny84 and many microcontroller(board)s that are more capable than the ATTiny84. Add to that the price of the sensors. So from price perspective I personally do not really understand why to save (less than) €0.75 on a microcontroller(board) and then spend a lot of time and hassle to get LoRaWAN (somewhat) working on ATTiny.
The contents in this thread has moved way off-topic and appears to lead to nothing but discussions, even behavior not tolerated on the forum.
To quote @TwentySixer’s undiplomatic statement
I will now end above discussions.