of course they can be removed.
Only by un-soldering, I think. There appear to be short coax cables with ufl plugs at both ends, which can be removed. But the sma sockets appear to be soldered to the board.
Yes, I agree, it’s a bit more involved than I thought. Update I have checked, you can’t use the integrated pigtails because they have the wrong gender for typical ISM antenna.
So you have to unsolder or better just cut one of the SMA sockets and replace it with a pigtail.
1 Like
Un-soldering would be less difficult and safer. Those connectors are solid brass. Or drill a third hole in the bracket for the n-fuse pigtail.
I also discovered that this card does not provide usb ports as @nestorayuso believed. It must be connected to a usb pin header on the motherboard. One port is connected to the mini-pcie socket and the other is connected to the usb socket on the adaptor. So this card would occupy a pcie slot in my server but not use it in any way, and it would also occupy a usb header from the motherboard.
I no longer think that this adaptor card would be a simple or neat solution. I will research other cards. But if none can be found (at reasonable price) then the external usb adaptor offered by n-fuse may be a more neat and simple solution.
As I told you before, you will need a Card with USB connector because there is no USB signal on the PCI bus. So there is no other easy way to use such a card and thus it IS the simplest solution I see for a normal desktop or server class host w/o mini PCIe port.
Internal mounting Plan B:
The inside of the server has space against the left wall to velcro-mount a mini pcie to usb adaptor. (Will need to be careful about shorting any part of the adaptor’s pcb against the metal.)
@Vanthome can you please comment about the compatibility of the above linked adaptor (picture below) with the n-fuse concentrator?
Above (in front of, in the picture below) the motherboard’s main connector panel there is a slot for mounting space for a full height bracket.
I could put a WLAN card backplate in there, like this one, for the n-fuse pigtail:
The motherboard has a spare USB header:
I emailed n-fuse and got the following response (the same day, and on a Sunday!):
Hello Paul.
as you can see in this hackster article:
Build a LoRa Gateway with n-fuse mPCIe card - Hackster.io
Such adapters are usable for our concentrator card LRWCCx-MPCIE.
If you scroll down on our product page we also offer a “Mini PCIe to USB adapter” with a metal enclosure that can but must not be used:
LoRaWAN® Concentrator Card SX1301/ SX1308 mini-PCIe - n-fuse
The advantage of this adapter is that you can connect it to the USB port via a cable.
Thanks
n-fuse Devices Sales
Mail: devices-sales@n-fuse.con-fuse GmbH
Ossietzkystrasse 4
70174 Stuttgart
GermanyGeschäftsführer: Thomas Hoppe
Handelsregister: Amtsgericht Stuttgart HRB 736379
(The “can but must not be used” part amused me. A little translation error, I guess.)
Anyway, all looks good. Time to dig into my bucket of parts…
Something to watch out for with randomly sourced mPCIe adapters intended for mobile data modems is that a lot of the cheap ones supply substantially more than 3.3 volts.
So make sure to measure the regulator output and decide it is appropraite before putting your LoRa card in there.
If the voltage is too high, it’s easy to rework them with a fixed 3-terminal regulator and grounding out the adjust pad, or by changing the resistors on an adjustable regulator to produce an allowed voltage.
Also consider cooling as the SX1301 chip will produce a fair amount of heat once the packet forwarder fully starts it up.
1 Like
Thanks for the warnings, @cslorabox.
Air flow should be ok. The cpu fan is close by and the case has at least three fans plus the PSU fan. Not sure how I can check the supply voltage, but I will aim to buy a mpcie-usb adaptor that looks identical to that shown in the hackster article. Suspect the probes of my DMM will be too large to measure the correct contacts, even if I knew which ones to measure…
Actually not hard at all as you don’t have to probe the mPCIe itself. There are plenty of grounds on such a board, and the tab on modern positive 3 terminal regulators is usually their output. If you’re worried about a probe slipping do the regulator voltage test with a USB power source you don’t particularly care about, and of course the LoRa card is not yet installed.
Incidentally the board in the hackster link is visually identical to those I found with the regulator set to output excessive voltage.
1 Like
@cslorabox You were right. The regulator output on my “randomly sourced” adaptor is 3.77V. But that is with no load. Could it be that it would be closer to the expected 3.3V with a load?
EDIT: No, loading it does not help. I shorted the regulator tab to ground with 330R. Around 11.3mA flowed, as you would expect @ 3.77V.
Not really - that would only happen on the edge of failure. Regulator failure would hopefully result in a shutdown, so really the only way you’d see droop would be loss on the input (USB/wiring) side. But setting the setpoint higher doesn’t help with that.
It looks like SX1301 operational max is 3.6 volts while the “absolute maximum” is 4.0, but you are not supposed to run parts beyond their operational ratings, and there are also other chips in a concentrator.
My feeling is that this higher voltage was chosen because someone thought it would work better with the mobile data modems for which these adapters are intended.
I personally just change out the regulator for a 3.3v fixed model and ground the adjust terminal (as it is a ground terminal on the fixed models). But you can also recalculate the resistors if you prefer.
Or you can make your own decision to chance running it as is. I decided the LoRa modems are expensive enough I’d prefer to be careful of them. For that matter, I’m also using mine with tiny wires pulling the non-standard SPI lines off the mPCIe connector, so it’s been on the to-do list to just make a more suitable board, make it out of thicker PCB stock, and perhaps leave the actual area where the modem sits open for better cooling.
I think these are EIA SMD resistor codes.
30A = 200R
01A = 100R
Which would make the output voltage
1.25 * (1 + 200/100) = 3.75V
(Ignoring Iadj which should be 50uA)
Which is close to what I measure.
If I put 1K in parallel with the 200R, that would bring the combination down to 167R. Then the output would be
1.25 * ( 1 + 167/100) = 3.33V
820R soldered in place. Regulator output is now 3.27V. Job done!
1 Like
Concentrator card has arrived. Now I need to find some time to install it!
I’m following the instructions here as suggested by N-fuse. Just plugged the concentrator + usb adaptor + antenna in for first time. lsusb shows:
Bus 004 Device 002: ID 0483:5740 STMicroelectronics STM32F407
In step 3, I needed to use sudo:
sudo ./util_chip_id/util_chip_id
A gateway ID appears. So far so good…
UPDATE: All steps completed. Gateway is up and running and receiving its first packets!
Thanks again @Vanthome and @cslorabox for the advice.
1 Like
Looks like I may have the same issue as described in the Hackster.io article. After a reboot, the packet forwarder service starts, but the gateway does not connect with TNN.
granary@granary:~$ systemctl status pkt_fwd.service
● pkt_fwd.service - Semtech packet-forwarder
Loaded: loaded (/lib/systemd/system/pkt_fwd.service; enabled; vendor preset:
Active: active (running) since Mon 2019-04-01 20:54:14 BST; 25s ago
Main PID: 856 (lora_pkt_fwd)
Tasks: 1 (limit: 4433)
CGroup: /system.slice/pkt_fwd.service
└─856 /home/granary/loragateway/picoGW_packet_forwarder/lora_pkt_fwd/
Apr 01 20:54:14 granary systemd[1]: Started Semtech packet-forwarder.
The journal shows nothing interesting either:
granary@granary:~$ journalctl -u pkt_fwd.service -b -f
-- Logs begin at Wed 2019-01-23 22:35:37 GMT. --
Apr 01 20:54:14 granary systemd[1]: Started Semtech packet-forwarder.
But if I stop and start the service, the gateway connects to TNN in ~ 1min:
granary@granary:~$ systemctl stop pkt_fwd.service
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Authentication is required to stop 'pkt_fwd.service'.
Authenticating as: granary,,, (granary)
Password:
==== AUTHENTICATION COMPLETE ===
granary@granary:~$ systemctl start pkt_fwd.service
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Authentication is required to start 'pkt_fwd.service'.
Authenticating as: granary,,, (granary)
Password:
==== AUTHENTICATION COMPLETE ===
granary@granary:~$ journalctl -u pkt_fwd.service -b -f
-- Logs begin at Wed 2019-01-23 22:35:37 GMT. --
Apr 01 21:04:23 granary lora_pkt_fwd[856]: *** Packet Forwarder for Lora PicoCell Gateway ***
Apr 01 21:04:23 granary lora_pkt_fwd[856]: Version: 0.1.0
Apr 01 21:04:23 granary lora_pkt_fwd[856]: *** Lora concentrator HAL library version info ***
Apr 01 21:04:23 granary lora_pkt_fwd[856]: Version: 0.2.2;
Apr 01 21:04:23 granary lora_pkt_fwd[856]: ERROR: FAIL TO CONNECT BOARD ON /dev/ttyACM0
Apr 01 21:04:23 granary lora_pkt_fwd[856]: INFO: Stopping concentrator
Apr 01 21:04:23 granary systemd[1]: pkt_fwd.service: Main process exited, code=exited, status=1/FAILURE
Apr 01 21:04:23 granary systemd[1]: pkt_fwd.service: Failed with result 'exit-code'.
Apr 01 21:04:23 granary systemd[1]: Stopped Semtech packet-forwarder.
Apr 01 21:04:37 granary systemd[1]: Started Semtech packet-forwarder.Maybe it doesn’t like being run before you have network connectivity? Often service startup scripts can be set to have an order.
That said, no matter what your network backhaul is, you should assume that it will go down (and hopefully come back up) in operation.
I ended up with a multi-level watchdog, on the network link itself, and ultimately on the packet forwarder stats packets being bounced back from a server setup to do that. Either failure will ultimately reboot the gateway if it persists long enough.
Applying the fix suggested in theHackster.io article, I get an error message when the service attempts to start:
● pkt_fwd.service - Semtech packet-forwarder
Loaded: loaded (/lib/systemd/system/pkt_fwd.service; enabled; vendor preset: enabled)
Active: activating (auto-restart) (Result: exit-code) since Mon 2019-04-01 21:14:05 BST; 22s ago
Process: 1541 ExecStart=/home/granary/loragateway/picoGW_packet_forwarder/lora_pkt_fwd/start.sh (code=exited, status=203/EXEC)
Main PID: 1541 (code=exited, status=203/EXEC)
Apr 01 21:14:05 granary systemd[1]: Started Semtech packet-forwarder.
Apr 01 21:14:05 granary systemd[1]: pkt_fwd.service: Main process exited, code=exited, status=203/EXEC
Apr 01 21:14:05 granary systemd[1]: pkt_fwd.service: Failed with result 'exit-code'.