A huge difference! (look up dB scaling!) - -100dbm fine for LoRa dev work, -17dbm and the devices ARE EFFECTIVELY SHOUTING AT EACH OTHER drowning out correct signal, saturating/distorting front ends and causing channel bleed over etc⌠all conditions which get in the way of effective developemnt and debug and which destroy ability to deploy reliablyâŚ
You need to look at these carefully and specifically and use/follow the advise oft repeated on this very Forum.
I am using what i have at hand. the goal is a custom PCB which acts as a sensor station adn will send sensor data. all powered via a solar cell. so that whoel thing will sleep msopt of the time wake up, checks if things chnages and send stuff or go back to sleep if nothign happened.
The PCB will use a esp32, unfortunetly the esp32 dev board doesnt fit on my breadboard, so I used the adafruit feater esp8266 instead. dio0&1 where printed becuase for some reason the lib not always printed join Fail, even when sednign correct and TTN displayed MIC mismatch. becuase of the debugging i noticed dio0 was wired to dio1 and dio1 was flaoting, becuase i put the wire in the wrong colum.
Not all parts have arrived yet so I cant solder and test with the PCB. and as my deadly is next month I need to use all time I have (or chnaces are high I will fail my degree as this is my diploma thesis)
if they are shouting at each other, whixch they are given the small distance is that bad ? puting my phone next to the wlan router also increses the wlan speed.
LoRaWAN isnât WiFi and the signal/channel optimisation algorithms are very different. âSpeedâ in the LoRa context comes from stepping up and down the SF ladderâŚ. A strong signal allows use of better (shorter & hence higher effective throughput) SFâs for most common systems the best being SF7, the trade off is low SFâs afford lower SNR headroom so in RF noisy environments the mitigation is to go to higher SFâs taking longer on air for any given message length - hence a lower throughput. If at SF7 and if device has ADR enabled the LoRaWAN also with then also start to command lower Tx power from the node to diminish range (reducing SNR for everyone else in hearing range and improving node battery life) but those changes take time whilst LNS determine average signal quality level vs locally defined RF signal headroom, and if ADR not enabled (often the case in development stages) there is no dial down mechanism s o they just shout at each other!
That statement in and of itself suggests you really have not got to grips with and understood the 101 of LoRa & LoRaWAN so strongly recommend go read more of the docs and watch the videos to help your studiesâŚ.
About the most difficult choice of controller for Low Power LoRaWAN operations available because it does not retain ram contents in low power mode and required additional code to save critical stack values in RTC ram. Just about any STM32, PIC or AVR with sufficient memory would be a better choice.
WiFi is a short range solution with provisions to optimize power quickly. LoRaWAN is designed for Long Range and is takes a lot of time to optimize transmission power. Keep LoRaWAN devices at least 4.5 meter/15 feet and a wall away from gateways.
Is this these specifically wrt LoRaWAN or what your doing with it (in terms of the sensing)? Asking as if you need to do a defence of your thesis you will really need to be able to answer questions that demonstrate knowledge of the underlying technology and use cases and so some of that time improving learning should benefit & help you.
if the devices shout at each other noise should not be an issue so that is good. I tried to use STM32 once and it was a night mare. no documentation and the docs I found did nto even work. so alot of time was just spend trying to figure out what works and what doenst. the HAL system sued made everythign wworse and I was fighting against that aswell. esp32 was choosen becuase so far I had great experience with it and as arduino supports it coding at it is easy< enoguh and you actually find workign docs.
RTC is nto that hard, as I can edit the code I can jsut add RTC_DATA_ATTR to the varibales of the libraries.
yeah lora uses shirps and i defined to use sf9 so 512 shirps per symbol. more air time but longer trans mission range. that was still from the time when I expected the gateway would ahve a longer range and not just 100m around the building its atâŚ
I tried wifi in the past wwhich did nor work. alternative is zigbee whixch is better suited for this but sadly its industrial standart and closed source or everythign is behind a paywal, so Lora it is. My mistake was to assume LoRa and LoRaWAN are the same and people jsut dont like to sue the full name, but apparently LoraWAN is somethign ontop of Lora. simiular to how TCP is basicly ontop the IP protokoll.
You donât mention what gateway is used. I have seen problems with the packet forwarder on the gateway discarding packets where the first 4 bytes (after the header byte) are all zero. Normally not a problem, but a join request with an AppEUI of all zero will have the first 4 bytes all zero. There is nothing special about the AppEUI; you can set it to any value you like. If you chose 01-01-01-01-01-01-01-01, you will guarantee that the AppEUI wonât trigger the discard.
The mentioned delays are because of duty-cycle limitations. The LMIC is not fully compliant in the backoff calculations from the LoRaWAN spec, but it does comply with regulatory limitations (less strict than join backoff instructions in 1.0.3).
It is one of the forwarders for the MultiTech. We observed the problem and narrowed it down to the packet forwarder, and then went looking. Jeff Honig of TTN Ithaca has the code on his machine; I looked at it with him a week or two ago; today Iâm traveling and canât check as there are several repos that are pulled together.
If memory serves, we found code that looks for packets with 4 bytes of zero; comments say itâs to reject spurious packets from USB-based LoRa cards. We concluded the code meant to check for a devaddr of zero, but it doesnât use the packet type from the MHDR; IMO it should not do this unless the packet type is unconfirmed uplink or confirmed uplink. (If you want to find the code yourself, look for four byte-by-byte compares of packet[] to zero, for each of the bytes after the MHDR.) Iâve sent a query to Jeff, will repost after I get word back.
Yes, cause has been found but I need some more testing before I release the fixed sources.
If you take a moment of two to check GitHub you will find Iâve found the same some
September 14th, the code was added to drop rogue packets created by USB connected concentrators on (yes you guessed it) MultiTech hardware. It didnât cause issues on V2 because back then everyone was using a real AppEUI. These days it seems there is no need for them so all zeros is recommended triggering the issue in joins.
If you wait a couple of days I intend to push a fix.
So a round of field upgrades in order?! Perhaps rather than all zeroes as recomendation we change to 010101⌠as above if not using a ârealâ ID (or the other trick of duplicate Dev EUI?)
I guess crossing messages. We have about 100 MultiTechs deployed, and first noticed this issue as soon as we upgraded to V3, but we didnât get a chance to check the code until more recently. In any case, we have remote management software so we can push updates.
I have no objection to checking mote address for zero; but those four bytes are only the mote address if MHDR says that the packet is an unconfirmed or confirmed uplink.
For those who canât push updates, an AppEUI of 0x1 is sufficient as long as the user doesnât hit endian issues (and thatâs what we normally use at TTN NY). Using 0x01010101010101 avoids endian issues.
those effects honestly sound super interesting, I wish I had courses about these topics and more advanced electronics
even if I edit the library itself?
chances are low it will arrive on time alias if I order now it will take 3 weeks at best until it arrives.
that is a good idea I will try that. if it still triggers a MIC Mismatch, even when I am far away so I dont overload the circuit, what else can I try ? (besides from trying to switch btween big and little endien for the AppKey) ?
Thanks everone! I changed JoinEUI to 2222⌠DevEUI to 44444⌠AppKey to 666⌠and it worked. Which means software and hardware can work! (this was ma greatest fear) now I need to find actual save value which are somehwat secure and find out what was the issue. ( I als changed the transmission window back to 60 seconds )