It’s going to be very hard to make a well-behaved LoRaWAN device with such a low resources chip, and there’s little cost, power or physical size reason to even try, especially when there are off-the-shelf hybrid modules combining the radio and a far more suitable MCU.
Not only do you have all the challenges of fit, once you drop receive capability you also add the severe compromises and obligation for location specific tuned configuration inherent in not using ADR, ie, you’re not allowed to use the slowest SF all the time, unless you find that the installed location actually requires that.
so, what should i learn from your statement? World is complicated? I dont really get your message.
regards
g
That this project isn’t a sound investment in parts or effort since it offers no advantage over hardware that could fully implement LoRaWAN and so be free of the extreme limitations of a transmit-only node
If it is used in a fixed position for my usecases and SF7 is sufficient, will be no need for ADR.
ATTiny84 MCU does all that is essential to drive RFM95W.
No compromises are needed.
i wonder whom you represent allhere
regards
g
Yes there is! ADR will also instruct the node to reduce transmission power when applicable, thar results in (potentially) less interference.
Trying to to shoehorn a LoRaWAN stack into a too small processor is a nice intellectual exercise but hardly useful as it will never be compliant and the result will occasionally cause issues for LoRaWAN compliant networks.
@cslorabox represents users that take the technology seriously and do not want to cut corners just because they can get away with it. The current generation of microchip arm controllers (not those of 15 years ago) are far more capable and a better choice.
https://www.thethingsnetwork.org/docs/lorawan/adaptive-data-rate.html should not must.
End of discussion!
Euh?
Anyway, if we are quoting documentation, let’s go to the LoRaWAN specification v 1.0.3 which states:
3.3 Receive Windows
Following each uplink transmission the end-device opens two short receive windows.
It does not state an end-device may open a receive window. It states an end-device does open receive windows.
So a transmit only device is not LoRaWAN compliant.
Okay, we open two receive windows and do nothing
What sense does that make? None!
Sometimes there is no reason for downlink messages 
Don’t network-initiated MAC commands such as DutyCycleReq, RXParamSetupReq, DevStatusReq, NewChannelReq (EU and China), RXTimingSetupReq and DlChannelReq (EU and China), and maybe even LinkAdrReq, also apply to nodes that do not enable ADR?
(Peeking into the TTN V2 code, it seems only RXParamSetupReq is used, and then only for ADR. For the TTN V3 code all the abovementioned MAC commands are found multiple times, but I’ve not investigated if usage is limited to specific LoRaWAN versions.)
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.