The way RSSI is calculated has changed from when the SX127x devices were first introduced. The ‘new’ calculation can indeed vary by 20dB to the ‘old’ method.
Ask the library author, Leo Korbee, which method they are using.
For a TTN node, its not that important what the received RSSI is showing as anyway.
I’ve tried a bunch of things to get the RSSI values down but have had no luck. Maybe someone here can help me out. It’s making me a bit mental.
It might be helpful to the forum if you could tell us what ‘a bunch of things’ is, we dont know.
And the obvious question is why use an ATtiny84 ? I would imagine an ATTiny84 is going to be very memory constrained when running the software for a TTN node.
When you compile the code for a TTN node (using that library) how much free flash and memory do you end up with ?
Because it is smaller and cheaper. I have run one for over seven months on two silver oxide coincells about 180 maH. 30000 plus messages so far and voltage levels indicate it will go for over a year. Very little space left. Reading a bmp280 but had to send raw data back to server for processing.
Querying all the registers is a bit above my pay grade at present but I’ll look into that. It might be good skill to acquire in any event. I’m basically at the level of changing register values by poking them with a stick.
I wanted the ATtiny primarily for size and power consumption.[quote=“cslorabox, post:2, topic:30629, full:true”]
If all else fails, make each version log all registers writes to the radio chip, and diff them…
It’s not clear what you hope to gain by using an ATtiny, the LoRa chip costs enough to hide the cost of a halfway decent processor.
[/quote]
OK, I see how this forum works now. Protocol adjusted.
I don’t plan to have this connected to TTN, just my single channel gateway which means I can dispense with a bunch of the coding. I’ll remove whatever I don’t use from the libraries and hopefully it will stay under budget.
Right now a basic hello world sketch with all appropriate libraries runs around 1780 bytes (21%)
I could be wrong here but, it seems like RSSI is calculated at the gateway which would make it independent of the node
What I’ve tried to do is match up the chip configuration for the Korbee library with the Sandeep one for things like TX power, Low data rate optimization, and PA config. Hardware wise, they are essentially identical.
I’m not trying to be difficult. It just seemed like there is a lot of knowledgeable people here who might be able to help. I’ll try to find a more appropriate forum to post this problem. Thanks anyway.
We are running the RFM95 with an ATtiny85 and a limited LoRa stack. It’s limited in the way that not all MAC commands are implemented, but it does run the full functionality: up- and downlinks, all SF and channels, OTAA, ABP, etc.
What I don’t understand: how is your processor of any influence on the RSSI as this is measured by the RFM. Or do you mean the RSSI values reported on the TTN receiver side?
The RFM95 does put a value in one of its registers, which is indicative of the signal level.
However its up to the program running on the processor to turn that register value into an RSSI value we would recognise. The calculation for that is in the datasheet and has changed over the years. Thus it is entirely possible a library using the ‘old’ calculation will display a different RSSI than a library based on the ‘new’ calculation.
You can see another implementation of the ATTiny84 at https://attno.de. Unfortunately, the source code there does not support downlink/ ADR either.
Therefore, the attnode v3 was developed, which works with the ATTiny 3216 and supports both downlink and ADR.
In the meantime, Rainer has developed a firmware for the ATTiny84 with LMIC support, but I have not yet tested whether it meets all the requirements. Here is the sketch for a soil moisture sensor with the chip. https://gitlab.thethingsnetwork.de/RainerWieland/cnsms-01
Cool - with the right settings you can get MCC LMIC 3.3.0 on to that with room for a couple of sensors. Sadly I can’t find any 3216’s at present as I was going to make a design for that.
It looks like a mixture of things in this repro - the Heltech uses a fuller stack but the cnSMS-01 is using SlimLoRa which the author recently reported as having timing issues - I asked for info so it could be looked out (on here and on the GitHub repro) but he’s not responded. I’d anticipate that the SlimLoRa is going to have some challenges interacting with the v3 network server.