Add support for sub band 2 network in Australia about arduino-lmic HOT 17 CLOSED

Ah got it working on Australian frequencies

I updated the lorabase.h file as follows
// Default frequency plan for AU 915MHz

enum { US915_125kHz_UPFBASE = 915200000,
       US915_125kHz_UPFSTEP =    200000,
       US915_500kHz_UPFBASE = 915900000,
       US915_500kHz_UPFSTEP =   1600000,
       US915_500kHz_DNFBASE = 923300000,
       US915_500kHz_DNFSTEP =    600000
};
enum { US915_FREQ_MIN = 915000000,
       US915_FREQ_MAX = 928000000 };

from arduino-lmic.

Excellent, thank you!

I'm thrilled to hear that the 32u4 is working. I guess I'll have to get a few so we can regression test.

The subband 2 thing (1 origin versus 0 origin thing) is right; the API was added with zero origin code before anyone realized that the subbands were origin 1 (unlike everything in the spec). At that point, the damage was done... so we decided to live with it. I am about to do a refactor to support AS923 and India, so we should probably make an explicit AU plan. Maybe we can start with AU since you can test.

Thanks again.....

from arduino-lmic.

Re public network.... that's not actually a term that's defined by the LoRaWAN spec. I am not sure what it means to a device. I remember that MultiTech has a setup for that in one of their AT commands, but I don't know what it does -- maybe it enables encryption. Anyway, there is no such setting in the LMIC stack so I think public network is what you get.

If you have two 32u4s, I'd be really interested to know whether the raw-feather example works node-to-node. It worked really well with M0s as a test case. (You might have to do another fetch as it looks as if I didn't remember to push it until yesterday.)

from arduino-lmic.

@gloveboxes @terrillmoore this is great, I'll buy some 32u4 feathers then to give them a try.

from arduino-lmic.

@terrillmoore this is to confirm that I have also put the MCCI-arduino-lmic code onto my 915 32u4 adafruit feather successfully. Sounds Like Ken did as well.

Not to put you on the spot...but...are there any large differences between The Things NYC Aduino-lmic and this MCCI fork? Is it worth making a pull request over to Things NYC to get the two merged? Maybe I should try to put the Things NYC Arduino-lmic on my feather with the same keys and then see how it works.

I'll need to get anther 32u4 and try the other sketches you have here. Thanks!

from arduino-lmic.

from arduino-lmic.

I've changed the issue title so that I will have a reference when I close it.

from arduino-lmic.

I'm working on adding this today.

from arduino-lmic.

Refactoring is complete, code is three-quarters done, everything compiles cleanly, but I lost access to the tester before I could test. See https://github.com/mcci-catena/arduino-lmic/tree/TMM-bandplans-1 for work in progress.

from arduino-lmic.

@gloveboxes: I have now pushed a version of Arduino LMIC with integrates au921 support. It's extensively refactored, and I've also added in866 support, and all the underpinning for as923 support (but as923 is not yet done).

It's all still on a branch: see https://github.com/mcci-catena/arduino-lmic/tree/TMM-bandplans-1. Check out that branch if you want to try it out. I don't have a gateway set up with au921 support here, nor do I have the tester on hand. But I reckon it will at least lurch.

If you have a chance to test before I do, please let me know what you find.

from arduino-lmic.

Hi @terrillmoore

I have been testing this branch out with an Arduino Nano and an inAir9 with some mixed luck.

It seems that not all packets are making their way to my gateway and same with responses, seems to be a large gap in time before a payload makes it down to the arduino, seeing lots of

Packet queued 90827980: EV_TXCOMPLETE (includes waiting for RX windows) 94578423: Unknown event Packet queued 94861795: EV_TXCOMPLETE (includes waiting for RX windows) 98612248: Unknown event Packet queued 98928805: EV_TXCOMPLETE (includes waiting for RX windows) 102679239: Unknown event Packet queued

I'll keep working with it, but thought I'd let you know that the library changes to support AU are at least 'working'.

Cheers,
Shaun

from arduino-lmic.

Hey, that's great, thanks for the comment. To my surprise, IN866 is also working. But US915 seems not to be. (As it happens, I'm in Japan on business, so ... can't debug the US915 stuff very easily.)

The "Unknown event" is a new event that was added by IBM LMIC 1.6: EV_TXTART. I forgot to update the sketch. An issue needs to get filed or I'll never remember to fix that.

To debug the packet loss, my recommendation is that you add a print on EV_TXSTART to print out LMIC.txChnl and LMIC.freq -- that way you can see what the LMIC thinks it's doing. Then look at the TTN console, and check the metadata for each successful receive. Usually there's a pattern, and you'll be able to see whether I've screwed up the channel, screwed up the frequency or perhaps there's an issue with the regional settings for your gateway -- we found an error in the TTN settings for India, so it's not impossible. What gateway are you using?

Best regards,
--Terry

from arduino-lmic.

Thanks Terry,

From what I can see the node is trying to TX higher than 918 every few packets, I assume that could be the issue?

from arduino-lmic.

Higher than 918: aha, you must make sure your sketch has LMIC_selectSubBand(1) in the "join-accept' processing handler. Please check.

Background for future readers.

The text from the LoRaWAN region spec:

• Upstream – 64 channels numbered 0 to 63 utilizing LoRa 125 kHz BW varying from DR0 to DR5, using coding rate 4/5, starting at 915.2 MHz and incrementing linearly by 200 kHz to 927.8 MHz
• Upstream – 8 channels numbered 64 to 71 utilizing LoRa 500 kHz BW at DR6 starting at 915.9 MHz and incrementing linearly by 1.6 MHz to 927.1 MHz
• Downstream – 8 channels numbered 0 to 7 utilizing LoRa 500 kHz BW at DR8 to DR13) starting at 923.3 MHz and incrementing linearly by 600 kHz to 927.5 MHz

But since the gateways available today only receive on 8 125kHz channels, and 1 500 kHz channel, for sanity TTN chooses a subset of 8 channels, called a subband. Subbands are numbered 1..8 by TTN, but 0..7 by the LMIC code. TTN uses subband , which is channels 8-15 (at 125 kHz) and channel 65 (500 kHz); these correspond to center frequencies 916.8 MHz to 918.2 MHz for 125 kHz channels, and 917.5 MHz for the single 500 kHz channel.

from arduino-lmic.

aha, you must make sure your sketch has LMIC_selectSubBand(1) in the "join-accept' processing handler. Please check.

Now i feel like a goose! That fixed that issue! Now to work out why im not getting any downlink data to my node.

I'm running a custom gateway from a company called Definium in Tas, Aus. I havent moved to the new packet forwarder yet, but i do recall seeing some data come through earlier. so not sure where the issue is.

Thanks again!

from arduino-lmic.

If your device is joining, you're getting downlink data (the join-accept is coming through). (If you're using ABP, of course, no need for any downlink.)

I had problems with the TTN setup months ago when they updated from staging to production. Had to reinstall the gateway software. Uplink was working, downlink not.

From that experience, I learned to at the gateway logs on the console. There you'll see whether it's scheduling downlink data, and then you can compare that to the logs on your gateway and on your device.

Worst case, if you have two devices, use the raw example app. If the devices can talk to each other, you know that you have to look upstream. If not, you might conclude that I broke downlink when I updated the LMIC....

--Terry

from arduino-lmic.

Thanks Terry,

From what I can see, its a bit of hit and miss. The gateway is showing me that its receiving downlink packets, but not all are either going to the node/or being displayed by the node.

I'll keep investigating and let you know what I find.

from arduino-lmic.