LMIC-library and Moteino Mega

[ursm]

Hi
in TheThingsNetwork https://thethingsnetwork.org/ we often use the LMIC-Library https://github.com/tftelkamp/arduino-lmic-v1.5
Unfortunately the MoteinoMega misses 3 wires to make it directly usable.
Question: do you plan to build a LoRaWAN compatible board with the needed wires?

[Felix]

UPDATE: the LMIC variant of MoteinoMEGA can now be ordered from here (choose LMIC variant option): https://lowpowerlab.com/shop/product/119

I think someone else asked a similar question but I'm sure the wiring was different, in their app they needed one extra wire. So i'm puzzled, should I start planning to make a different board every time a new library uses different wiring?
Is it not reasonable to wire the extra pins like we see in the photo above?
I already have a dozen variants of Moteinos, one yet to be released and it feels like I spread my wings very far already. The problem is the more variants I try to stock the larger stocks of chips and parts I have to have on hand, and the days of hand assembly are gone when I could make 5 units at a time if that's all I wanted. Sorry if that sounds like complaining 

[ursm]

hi Felix
thanks for answering so fast. Yes, I could anticipate what your answer would be;
but like a lot of your customers using RadioHead for their 'private' network, there will be a huge community use (the sole) LMIC library for their sensors on LoRaWan (TTN).
And it's fun, we get some of your LoRa-boards, because they fulfilled (except the needed wires) most of our requirements for a solid basic infrastructure building our sensors on top of it.
The connections of the additional (3 or 4) wires are, as from my opinion, not crucial. I made it so because it was convenient.
The definition in the program is as:
// Pin mapping
const lmic_pinmap lmic_pins = {
  .nss = 4,
  .rxtx = LMIC_UNUSED_PIN,      // (5) should be foreseen for later release (ok for A, needed for C)
  .rst = 3,
  .dio = {2, 1, 0},
};

I would not enforce you to build a new version, but probably you should listen to the LoRa community before making you decision.
Thanks in advance, urs

[Felix]

Thanks for the suggestion.
I'd like to see more requests at the very least. And consistency.

[gonzalocasas]

Hi Felix,

I'm also on the things network community and I agree with @ursm in that it would be great to have the moteino work without having to make changes to it. Maybe something along the lines of what Dragino v1.3 LoRa shield does with jumpers could work for moteino as well?

Cheers
Gonzalo

[Felix]

Maybe solder jumpers?

[dbrgn]

I'm also interested in building nodes for the things network, and the Moteino Mega looks great to get started.

I'd like to order a few of them, but would also be happy if the soldering jumper wires wouldn't be required.

[lukas]

I've sodered up 15 so far, and would certainly order a couple more of a "LMIC" version :-)

lukas

[Felix]

How imperative are the wirings to D0 and D1?
For instance I am wondering if routing DIO1 and DIO2 to D21 and D22 which are much closer by.

This is what it looks like for D0 and D1, these are solder jumpers, you'd have to still solder them but it allows the use of the board without hardwired LMIC:

[ursm]

Hi Felix
That sample looks great.   
1.) I put your question to Thomas, the creator of the LMIC library. He should know it best.
     Hopefully I get an answer quickly.
2.) I'm a little confused, looking at the  \MoteinoMEGA\pins_arduino.h. There a DIL40 package is shown and that package does not correspond to the QFN package you're using.
so to what signals/pins do D20/D21 be assigned?
3.) It would be nice having closed solder bridges, but that's a minor issue.
4.)  .nss = 4 & .rst = 3  are connected too? (It's not clear on the sample)

regards, Urs

[Felix]

@ursm:

2) Don't worry about the pins declaration, that is based on an older pins file, nothing has changed. The package used on the MEGA is TQFP44, not QFN.
3) I followed your first post/photo wiring where you soldered DIO1=>D0, DIO2=>D1, RST => D3.
My proposal is to change these to: DIO1=>D22, DIO2=>D21, RST => D3. The reason is much shorter routing which helps with signal integrity.
4) Yes, NSS => D23 (as before) and RST => D3 as you proposed.

Also, someone else suggested I add a SOT23 footprint for this I2C device which allows EUI64 unique global addressing: http://ww1.microchip.com/downloads/en/DeviceDoc/20002124F.pdf
This one would require more work so are you familiar with this type of chip and whether the LMIC lib supports something like that or how it would be used?

[ursm]

@Felix
I got an answer from Thomas, so you can do it as you suggested.
about the topic of EUI64: I don't think, that it's no need having a hardware based EUID. It's possible to get some of them as "soft bulk"
It's not supported by the library and must be programmed in user space and then given to the LMIC to work with it.

[Felix]

@Felix
I got an answer from Thomas, so you can do it as you suggested.
about the topic of EUI64: I don't think, that it's no need having a hardware based EUID. It's possible to get some of them as "soft bulk"
It's not supported by the library and must be programmed in user space and then given to the LMIC to work with it.

Great, so I rewired them this way, more obvious labels also:


How is this library different than things-network: http://www.research.ibm.com/labs/zurich/ics/lrsc/lmic.html
That supposedly supports EUI64, hence the other request to add a pad for that device. Trying to figure that one out then this LMIC variant would be ready for fabbing.

[ursm]

That supposedly supports EUI64, hence the other request to add a pad for that device.

Please use this https://github.com/matthijskooijman/arduino-lmic updated library.
The DEVEUI must be changed in the user program (example/ttn.ino)
   static const u4_t DEVADDR = 0x03FF0001 ; // <-- Change this address for every node!
and the SX variant in /src/lmic/config.h, which is newerdays set to SX1276 = RFM95W    #define CFG_sx1276_radio 1

Good luck!

[Felix]

Ok here are the latest changes.

Pin mappings (through non-bridged solder jumpers):
DIO1=>D22, DIO2=>D21, RST => D3

This also includes the EUI-64 chip footprint for those interested.