Feather M0 - sample Code Not working - no join accept

I don’t know if I’m in range of a gateway (how to tell)

Getting:
12:26:29.042 -> 25964897: EV_TXSTART
12:26:35.127 -> 26345236: EV_JOIN_TXCOMPLETE: no JoinAccept

with nothing seen on the gateway side (nearest is about 2.5KM, another 2.9KM) - I suspect I might not be heard in the urban environment.

// This EUI must be in little-endian format, so least-significant-byte
// first. When copying an EUI from ttnctl output, this means to reverse
// the bytes. For TTN issued EUIs the last bytes should be 0xD5, 0xB3,
// 0x70.
static const u1_t PROGMEM APPEUI[8] = { 0x82, 0x69, 0x03, 0xD0, 0x7E, 0xD5, 0xB3, 0x70 };
void os_getArtEui (u1_t* buf) { memcpy_P(buf, APPEUI, 8);}

// This should also be in little endian format, see above.
static const u1_t PROGMEM DEVEUI[8] = { 0xDD, 0x16, 0x11, 0xB8, 0x71, 0xA4, 0x2D, 0x00 };
void os_getDevEui (u1_t* buf) { memcpy_P(buf, DEVEUI, 8);}

// This key should be in big endian format (or, since it is not really a
// number but a block of memory, endianness does not really apply). In
// practice, a key taken from the TTN console can be copied as-is.
static const u1_t PROGMEM APPKEY[16] = { Deleted };
void os_getDevKey (u1_t* buf) { memcpy_P(buf, APPKEY, 16);}

from the gateway
Device EUI
The serial number of your radio module, similar to a MAC address

00 2D A4 71 B8 11 16 DD
8 bytes
Application EUI

70B3D57ED0036982

Please be specific about exactly which code you are using, eg, which repository for both LMiC and which example, and how long ago you downloaded those.

Note that for downlinks to work on the feather lora platform, you also need to add an additional connection from a radio DIO to the processor, as should be documented wherever you got the code - it’s not a bad board, but the person who designed it didn’t really understand LoRaWAN’s need for precise timing, and so left that out.

More generally though, not really knowing how far you are from a functioning gateway will be a challenge. Most serious about LoRaWAN experiments ultimately end up getting their own gateway - in an ideal world you wouldn’t need to, but both the certainty of knowing its status, and the ability to see raw message traffic that might not be quite valid enough for TTN to recognize are hugely helpful when debugging node issues.

OK, I’m following everything here:

I downloaded the libraries Thursday or Friday (aka less than a week ago) and I’m using the sample called
ttn-otaa-feather-us915-dht22.ino

Given this seems to be using the MCCI LMiC stuff it would be better to use the MCCI LMiC guidance.

The Adafruit folks kind of try, but are more on the periphery of TTN and LoRaWAN and not deeply involved in it the way the MCCI people who actually maintain that code are.

Also it’s unclear if you are using the appropriate frequencies for your region, which is primarily an issue of software settings, though for good performance you also need a board manufactured with components tuned to the frequency band you are going to use (eg, 868 and 915 may weakly cross-operate, but 433 is entirely distinct with different wiring)

The usage of a kilometers as a distance unit suggests you are not in the US. Unlike US-centric Adafruit the MCCI folks have both a closed-loop test setup for regional settings that aren’t legal where they sit, and also actual physical presence of test systems in a variety of countries using different bandplans.

I’m in NYC - I converted to KM, mostly because as a company, we tend to work in metric, and I know that a ton of the people here are un Europe, so I was trying to be considerate

Where is there MCCI LMiC guidance found?

BTW, we ordered a gateway today from the folks named for a river, so in the next 2 days or so, THAT should be handled

When you see an uplink in your console. Get in the car!

If you try an ABP uplink rather than going for the fancy OTAA, no join is required so has a better chance of getting through.

We actually work in km, mainly because that’s what radio waves use. For an urban environment those distances are pretty marginal. The LMIC guidance is on a European server on Github so there will be a transit delay …

Then you should join the things nyc TTN group and slack channel, someone can probably tell you if they’re seeing your attempted packets. And the lead MCCI maintainer of the code you’re using hangs out there…

Yes, I know RF is Metric - note my user name

73 de KG2V

General info for TTN in NYC

https://thethings.nyc/

Remote/Online live hacking/help day:

1 Like

Going to TRY and get there, but that is usually mid commute, then in dinner cooking time

The scheduled event may not be that unique, you might just get on their slack channel and see if anyone has a gateway near you they could briefly monitor for your packets at some other agreed upon time.

Their slack is not public (you have to be NYC.gov or MCCI)

That’s a misunderstanding, you have to join the group and be manually added, but membership is not really restricted, eg it’s open to those who demonstrate that they’re real well-intentioned humans interested in TTN. The group is a distinct legal entity, which has in the past cooperated with city government and obviously has some MCCI people involved, but it is organized as its own entity.

I signed up for Thursday’s meeting - Hope I can get on!

Just to let everyone know - Yep, it was no gateway in range. We setup our own gateway today
(eui-b827ebfffeedd188)
and now it works.

Now to get the Gateway mapper app at:

working - it isn’t talking to the gateway - I ASSUME I have a bug, as the libraries have changed so much, I’ll bet that I’m not in the right band

Congrats on some progress!

As for your newer question, the project you link uses the older and deprecated LMiC repo.

You should adapt things to work on the MCCI LMiC with which you already have basic success.

And of course be specific about looking at each step in the path, eg, raw uplink received by gateway, uplink decoded to application traffic by TTN, etc.

I was using the newer library - turns out I needed 2 things
1)A reboot
2)To go where the GPS could get signal

Now the fun - I see the traffic
I see the traffic decoded
(Lat long etc)
I see the traffic on my gateway
I see the gateway and application in my console
But despite being running for more than 24 hours, I don’t see anything on TTNMapper