Hello,
i am looking for LoRaWAN Modules which are mini PCIe cards.
I have found two options so far:
Advantech
which only seem to support the WISE network and
Globalsat
where i find only little Documentation and almost no rellsers.
Does know of any other options supporting mini PCIe?
The following addresses mPCIe gateways based on a mis-reading, because gateways radios are commonly implemented in this form factor. None of this is particularly relevant if what you are actually looking for is a node.
There are plenty of existing threads on the options.
Something you should be aware of is that as a standard, the only relevant interface supported by mPCIe is USB, and the traditional FT2232H based USB interface for a concentrator card is officially deprecated, as it performs poorly on busy networks.
The modern replacement for host systems which only support USB is the “pico GW” reference design, which uses an MCU to create a USB bridge that keeps all of the operations which need to be done with speed on the embedded side of the USB bus and thus does not incur the latency of doing the details transactions across USB. Several manufacturers sell boards based on the pico GW design. It also needs its own slightly distinct version of the host software.
There are mPCIe form factor cards on the market which actually use the preferred low-latency solution of SPI, but on a non-standard assortment of reserved mPCIe pins (SPI is not a part of the mPCIe spec). But these only work in host systems which provide SPI on the same pins, ie, those made specifically to work with those cards. RAK is a well known manufacturer of these, unfortunately they introduced a slow, unecessary level translator on their recent designs which requires modifying code to reduce the SPI clock to 1 MHz (2 MHz might work, but one is safer).
So, make sure you have clarity if you are using SPI, and if so on which pins. If you are using USB, consider the concerns with older FT2232H designs and if you want to consider a pico GW solution instead.
With internal mPCIe you also need to be aware of possible issues with power and potentially non-standard polarity of the concentrator reset signals. I’ve seen situations where putting an mPCIe concentrator in a host system prevents it from booting, though it worked on an external USB-mPCIe, or hot plugging (which is not something one should really do!)
I think the OP is asking about devices / nodes / motes, given the topic and the links he’s provided …
You are indeed correct, I misread.
An mPCIe node would be… odd. I think we need more details of the host system and the use case.
For a multitasking host system, the conceptually cleanest solution is probably going to be a LoRaWAN stack in an MCU, sitting behind a standard or custom serial-over-USB scheme connected to the mPCIe USB pins. That could be a very thin modification of one of the AT command set firmware, eg, a Murata module on a card.
Something that’s been somewhat overlooked in the community is that while multi-tasking operating systems make the timing of precisely hitting a receive window challenging, they are also heavily correlated with mains power. And once you have mains power, turning on the receiver quite a bit early to allow for scheduler latency is certainly an option, it just may start to point to configuring the radio chip in a different way than it would be in a battery powered node.
So for example, a node radio sitting on the SPI bus of a raspberry pi could basically afford to receive continuously but a simple port of an MCU-style LoRaWAN stack like LMiC is going to try to turn it on at precisely the right time, and probably fail to do so when running under Linux…
Yes i am indeed looking for a mPCIe node.
I have a system consisting of an Industrial PC that i would like to connect to a LoRaWAN network.
That system already exists an i just want to add LoRaWAN connectivity to it. The Industrial PC is equipped with some spare mPCIe slots and to keep the system as robust as possible i would like to use them.
That is exactly what im looking for. The reason behind the use of mPCIe is to prevent the usage of any “loose” parts like USB connections. Also i would like not to solder very much or design some kind of custom PCB. I was hoping that someone knwos of an mPCIe solution that i have not found yet.
I also found a M.2 Solution that at least has better documentation for my use case, but still if anyone has some other ideas i would be very interestet.
Aside, but just to be sure you got your expectations right: Fair Use Policy explained
And another aside, not my cup of tea, but in case you know more:
(If indeed a problem, then receiving continuously like you wrote would probably avoid that.)
Sure when using The Things Network the Fair Access Policy will be respected, when using a private Network at least the duty cycle limitations have to be repected. I am not sure which solutin will be used yet.
For the receiving window, for now all the solutions i found use their own MCU with which i hope not to have any such problems. But opening up the receiver window even up to being a Class-C device, when supported by the network, is a good option.
The goal of finding a mPCIe node is more to have an easy yet rugged implementation process.
Just remember we work with a shared spectrum and just because the duty cycle reg may permit use ‘up to’ a limit that doesnt mean you can/should run up to that limit (other than say in emergency operating conditions!). Continuous operation at, or even close to a large fraction of, the limit is bad social behaviour and can still disrupt other nearby users - including those on say a local TTN community. Best practice is to design down to the minimum needed to sustain your application vs design up to the limit allowed by law… just saying 
Sure i’m trying to design just like that. Just that i am not completely satisfied with the hardware i found and i am unable to design something myself.
That seems conceptually the right idea. It looks like you can probably get the source code though one of the specific links seems to be broken.
Conceptually the M2 vs mPCIe vs USB is just form factor - if you look at that board, there’s not much there but the MCU and an RFM95 or similar radio sub-module. So a DIY mPCIe version would be quite simple. If you have a good SMD assembler you could pretty much drop the Murata module on a board with some bypass caps, but it’s a very tricky footprint that likes to solder bridge; some of the other integrated ones have better land patterns and since you have plenty of space there’s not much reason not to simply use a distinct radio module and MCU the way Dragino did.
One negative of that board is that its not immediately clear they’ve done anything to make the MCU SWD signals readily available; they appear to be on the M2 connector but one might need a special jig. And yes, there is a bootloader, but SWD works so well its really preferable for hands-on-hardware development, vs pushing updates to something deployed.
I suspect that ultimately most of the time spent on such a project will be software time, albeit often requiring a hardware-aware skillset.
And keep in mind that in software terms there’s essentially no distinction between an external USB implementation and a USB-on-mPCIe one, so you could prove out a path and then respin the hardware. (There is the possibility of a system reset pin, I’d route that through a resistor footprint to retain options…)
There may even be node boards small enough to glue and white-wire to some sort of blank mPCIe carrier, though most will be too long.
Yeah and I think the mPCIe or M.2 form factor is my best option.
The idea of the DIY option sounds simple, but i don’t think that i will be able to do that.
Maybe i can check that out in the future and report on that.
I was hoping to keep the programming on the LoRaWAN module to a minimum and would prefere to use the firmware installed.
In terms of reliability I suspect this might not be the best solution.
But so far thank you for your ideas. I check out the dragino module in a first POC Prototype, maybe this will already work out.
I’ll try to come back later with my results.
Consider me a cynic, but I have my doubts that there’s a LoRaWAN product in existence that doesn’t cry out for fixes in its stock firmware.
Hopefully the pre-flashed version will be enough to let you evaluate the principle of the idea though.
I don’t have much experience with LoRaWAN products yet, i hope to fix that soon, so far it was a lot of reading 
I will see i guess. Otherwise I will have to get into that too.
I want to write a short follow up on this, just in case anybody finds this in the future:
I did not try out the Advantech device, becaus i did not find sufficient information about supporting LoRaWAN and higher level AT-Commands.
Similarly I did not try out the Globalsat module because of missing information.
I did try out this module using an mPCIe Adapter, but had to find out that integration into an PC is no intended. I contacted Draginos support and they confirmed that this module was not developed/tested in combination with a PC but only with Draginos embedded devices.
In the end i used this Microchip Mote. With this device I can at least build a prototype even though the integration I wanted is not possible. Maybe in the future a custom board with the RN2483 modem is possible, but not yet planned.