Disable Frame Counter Checks in V3

[descartes (Nick McCloud)]

@scott-williams-xentr

I am using MCCI LMIC because that is what most support, examples, and use cases are based on for beginners getting started with LoRaWAN, and because it has full support for the STM32 B-L072Z-LRWAN1 Discovery Kit (which is what the Murata Module is used on…)

I’d consider my self pretty clued up on MCCI LMIC and this would be the first time someone has used it on the LRWAN1 which has a nice certified module with the ‘official’ LoRa-node code base. Both code bases have their foibles so YMMV and given the relatively clear separation between sensor/device/app code and the LoRaWAN code in both, porting back should be feasible.

@scott-williams-xentr

I have tested OTAA several times with MCCI LMIC and cannot get it to work in AU915.

This would appear to be the crux of the matter. MCCI are moving towards certification so it not working for a region seems unlikely. Have you set it for sub-band 1? Any commentary on the MCCI LMIC GitHub regarding AU915 that may give you any clues?

I’m more firmware & use the expertise on here for RF, but I’m not sure how you’d get two blips on a scope like that as one device is transmitting and then another one is transmitting and it’s not clear from the divisions what the time gap is. Normally people post pictures of an SDI which shows us the actual chirp. If anyone else is going to comment, perhaps some more info would be useful.

@scott-williams-xentr

We are looking into the CLI to manage this, sure, but still seems like a poor and impractical solution.

I heartily agree - but it is a quick win as an alternative to delete & add. But as I say, I can add a device and not have the counter get in the way. Here’s the CLI that I use for LMIC:

ttn-lw-cli dev create **Your-App-ID** **Desired-Device-ID**
  --dev-eui **An-EUI**
  --frequency-plan-id EU_863_870_TTN
  --lorawan-version 1.0.3
  --lorawan-phy-version 1.0.3-a
  --abp  --session.dev-addr **260B-Not-Sure-Find-One**
  --session.keys.app-s-key.key **Random-Key**
  --session.keys.f_nwk_s_int_key.key **Another-Random-Key**
  --mac-settings.factory-preset-frequencies 867100000,867300000,867500000,867700000,867900000,868100000,868300000,868500000
  --mac-settings.rx1-delay RX_DELAY_5 
  --mac-settings.supports-32-bit-f-cnt 
  --mac-settings.resets-f-cnt

Obviously you’ll need to alter this for the AU915 band. You can grab a random EUI and some keys from here: Random EUI or Key generator. I’m still trying to elicit a response from TTI about the generation of valid DevAddr on the CLI.

@scott-williams-xentr

No, I have done many sanity checks

I mean’t here - a totally different set of eye balls.

@scott-williams-xentr

I know the CLI may work, but again this will take some time for us to investigate and explore

Compared to delete & re-add??? Not really that much investigating or exploring to do:

https://www.thethingsindustries.com/docs/getting-started/cli/

ttn-lw-cli end-devices reset [application-id] [device-id] --session.last-f-cnt-up

And by searching the forum: Uplink messages not arriving anymore - #12 by descartes

But for the very quickest win, there is this:

LMIC-node | One example to rule them all

LMIC-node LMIC-node is an example LoRaWAN application for a node for The Things Network. It uses the Arduino framework, the LMIC LoRaWAN library and PlatformIO. With LMIC-node it is easy to get a working node quickly up and running. Basic steps to get a node up and running with LMIC-node Select a supported board Select your LoRaWAN region Provide the LoRaWAN keys for your node Compile and upload the firmware and you’re ready to go! Implemented features Send uplink messages. Receive down…

which is created by a forum member so you can use LMIC and ask questions, the second bit being the most important as you appear to have dug yourself a deep deep hole before asking for help.