Some progress with ATTiny84 made by Stefan

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:

  • Both chips can run from 1.8+ V, interesting for battery operations
  • Low deep sleep power consumption (4 uA with timing, and 300 nA with external trigger)
  • Low processor-running power consumption for the attiny (below 400 uA)
  • Cheap (the combination costs me less than ā‚¬ 5)
  • Small and thin but still easy to solder by hand

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:

  1. What are the most minimal requirements for a sensor like this?
  2. It is possible to receive messages with this combination, but letā€™s say I send messages at SF7 and low transmission power, it is hard to see the benefits of opening a receiving window against the costs of extra power consumption. Am I missing something?
  3. Is it, in every thinkable way possible, mandatory to open a receiving window? And do other ultra low sensors just accept the extra power consumption or are there other ways?

Bear in mind: Iā€™m not a professional, Iā€™m just tinkering with it in my spare time.

2 Likes

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:

  1. A node should be LoRaWAN standard compliant. That way you know you will not cause issues for other users of the same radio frequencies and youā€™re able to interoperate with networks without issues. Keep in mind TTN might accept transmissions without issue, however the same frequencies are used by other LoRaWAN providers (and other users) as well and you probably do not want to accidentally create some denial of service attack for them. Most commercial LoRaWAN operators required nodes to have a LoRaWAN certification to be allowed for use.
  2. The benefits are that you receive the MAC commands issues by the network. The network can use those MAC commands to change the list of available channels, change duty cycles etc. Of course just receiving them is not the point, you will need to process the commands as well.
  3. The specification does not explicitly state it to be mandatory, however if you go for compliance testing your device will fail if it doesnā€™t implement receive capabilities. So implicitly receive is required for a LoRaWAN compliant node. Yes, all LoRaWAN compliant nodes I know of accept the additional power consumption because that is the only way to become compliant.

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?

1 Like

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? :stuck_out_tongue_winking_eye: 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:

  • Use multiple frequency channels for transmissions in a semi random order. You should have at least implemented the basic 3 channels
  • Use a mechanism that selects the optimum combination of SF and TX power (i.e. do not ā€˜overuseā€™ spectrum)
  • Do not violate the 1% duty cycle limit and TX-power limit related to this frequency band
  • Do not violate the TTN fair use policy
    I think it is not mandatory to open an RX channel for each transmission, even if that means you cannot receive MAC commands from the network
1 Like

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.

1 Like

@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.

1 Like

@bluesensing1

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.

1 Like