tnx… still a bit expensive, this afternoon I’ve tested a BME280 … positive
fresh start this morning with new code and a new sensor… the BME280
and a new public dashboard address
that silicone kit is for protecting the cheap chinese sma connectors from rusting
Payloads is the same as frame counter?
* changed it
it survived the first night so I leave it now and just let it do its job… for how long it will run on a normal AA battery ?
What are you using as the air purge valve? I’ve found a few but they either come in at about £15 each or I have to buy 1000 from Aliexpress…
here are 4 frames received by TTN gateways from the above BME280 testnode
at what RSSI level its no longer added to the application metadata ?
this is part of the CayenneLPP buffer code from this sensor.
why is the sequence different in the metadata ? 3 4 2 1
RSSI does not determine whether data is included. Packet being from gateway received within deduplication timeout is what matters. Packets received after the timeout are discarded as duplicates.
and what determines this ’ deduplication timeout '
… a lot of packets from that specific GW, is that possible, a ‘slow’ responding GW with a good rf signal ?
now I understand the following (a little bit) better :
during testing of this node firmware, I had one day my own gateway on, OTAA joining worked fine and when I switched my gateway off the packets were seen by 3 other gateways (sometimes only one)
next day, I had my gateway still off, I started the node again… no OTAA possible but join request visible in application ??
switched my gateway on, re started the node, no problem joining, switched off my gateway…
e voila… packets are seen by 3 gateways.
my conclusion sofar… always start your node close to a gateway
The back-end. After the first gateway forwards the packet to the back-end it waits for a certain amount of time to allow gateways with slow(er) connections to deliver the same packet. After that time it forwards the packet to the application.
The only thing I can think of is the gateway that received the OTAA request could not respond due to airtime restrictions or may-be it had to drop the response packet because it arrived too late at the gateway (after the transmission slot).
I will try duplicate this again and take some snapshots … this happend several times, so when the receiving gateway/connection is slow… it can drop the back-end join packet and/or the node doesn’t receive the join packets in time… creating the same status… then after several tries you then get the famous 'no_free_channel
’ to allow gateways with slow(er) connections to deliver the same packet. ’
why … isn’t the first packet received the fastest (for joining) and can the backend respond directly to that GW so a bigger chance for a successfull join ?
The first gateway may have the fastest internet connection but not the best RF path to the node.
I wonder, a metallic temp/humidity sensor enclosure 'will that hold the temperature inside longer then a plastic enclosure ?
Looking at your workbench I expect an answer by tomorrow
Were did you buy this antenna?
Rocket Scream from Malaysia, asked me to test their new 1.5 v low power node in Dutch climate.
I am curious so I agreed, also to write a review about it for TTN (new idea… reviewing LoRaWAN hardware).
The modules arrived with that 5 dbi antenna… I will ask him if they are for sale separate.
They did some research on small antennas
- got an answer back
these 5 dbi antennas are all over the internet and even if they look the same… they are not.
so Rocket Scream found a quality supplier and test each antenna individually before shipping
finishing the coffee spy node
- special timesaver tip : check the thermal fuse before glueing it to the ac-dc converter
I realise now that I break it during soldering… it was a 65°C fuse
ok took the broken fuse out and just for this proof of concept I don’t put another one back… we have dc now