Given:
and
I’d suspect that there must be some reasonable separation of device & gateway unless the OP is climbing antenna poles …
But still, none of this is relevant until we get the settings right to remove the MIC mismatch.
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….
Yep, typical LoRaWAN sensor device.
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.
1 Like
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. 
Good luck….
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.
Easy to add RTC, not at all easy to get session details from LMIC to save in RTC ram & then restore them after sleep.
With the deadline you face and the consequent pressures, you would be better served to move to a well supported device as has been suggested above.
1 Like
Let’s hope none of your tutors read along or else you will have a hard time while defending your choices.
Overloading receiver circuits results in malformed signals which means data corruption resulting in retransmissions because CRC or MIC fails.
1 Like
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).
There is a good Python script for decoding things: GitHub - tanupoo/lorawan-parser: a parser of LoRaWAN PHY payload for Python3 – if you use that to try to decode the uplink traffic, you may be able to play around with byte orders etc., and figure out what’s going on.
Good luck!
–Terry
1 Like
OP is using someone else’s gateway so unlikely to know.
Any ideas who’s software or what gateways are affected?
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.
THe gatway used is a RAK7258: Indoor LoRaWAN Gateway - Compact, Quick, Easy Installation - IoT Made Easy, and its managed from my university. other devices do work.
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) ?
You can try, but when you start searching the forum, you’ll find out what reality means.
You can try, but when you start reading the instructions, you’ll see that it’s not endian sensitive.
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 )
Edit just notived the line:
os_setTimedCallback(&sendjob, os_getTime()+sec2osticks(TX_INTERVAL), do_send);
so the 5 seconds would have only been used for the messages after the device joined, thats why it never used that number befor.
It has been a while since I worked on that issue, however what I recall is that the data I was getting was mostly random with just a few bytes consistently providing the same values indicating it wasn’t a valid uplink. I need to check again with MultiTech hardware to find the other ‘stable’ bytes to see if I can refine the valid uplink check.
This will take some time as I’m rebuilding my Linux development system after the previous system died and I don’t have the toolchains available yet.
The fix for other platforms will be available soon. (Basically just removing the check as it isn’t needed)