From the data sheet:
Looks like R12 & R13 on the adaptor are R1 & R2 in the above schematic.
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'.That’s not the meaningful error message, it is only the error that there was an error.
You need to look in /var/log/syslog or wherever the packet forwarder output is going to see the actual error.
Also make sure your systemd service is set to auto-restart on failure…
/var/log/syslog shows:
Apr 1 21:25:10 granary systemd[1]: pkt_fwd.service: Service hold-off time over, scheduling restart.
Apr 1 21:25:10 granary systemd[1]: pkt_fwd.service: Scheduled restart job, restart counter is at 23.
Apr 1 21:25:10 granary systemd[1]: Stopped Semtech packet-forwarder.
Apr 1 21:25:10 granary systemd[1]: Started Semtech packet-forwarder.
Apr 1 21:25:10 granary systemd[1832]: pkt_fwd.service: Failed to execute command: Exec format error
Apr 1 21:25:10 granary systemd[1832]: pkt_fwd.service: Failed at step EXEC spawning /home/granary/loragateway/picoGW_packet_forwarder/lora_pkt_fwd/start.sh: Exec format error
Apr 1 21:25:10 granary systemd[1]: pkt_fwd.service: Main process exited, code=exited, status=203/EXEC
Apr 1 21:25:10 granary systemd[1]: pkt_fwd.service: Failed with result 'exit-code'.If I stop the service and run start.sh manually, I get:
granary@granary:~/loragateway/picoGW_packet_forwarder/lora_pkt_fwd$ sudo ./start.sh
[sudo] password for granary:
*** Packet Forwarder for Lora PicoCell Gateway ***
Version: 0.1.0
*** Lora concentrator HAL library version info ***
Version: 0.2.2;
ERROR: FAIL TO CONNECT BOARD ON /dev/ttyACM0
INFO: Stopping concentrator
*** Packet Forwarder for Lora PicoCell Gateway ***
Version: 0.1.0
*** Lora concentrator HAL library version info ***
Version: 0.2.2;
*** MCU FW version for LoRa PicoCell Gateway ***
Version: 0x010A0006
***
INFO: Little endian host
INFO: found global configuration file global_conf.json, parsing it
INFO: global_conf.json does contain a JSON object named SX1301_conf, parsing SX1301 parameters
INFO: lorawan_public 1, clksrc 1
INFO: antenna_gain 0 dBi
INFO: Configuring TX LUT with 16 indexes
INFO: radio 0 enabled (type SX1257), center frequency 867500000, RSSI offset -164.000000, tx enabled 1
INFO: radio 1 enabled (type SX1257), center frequency 868500000, RSSI offset -164.000000, tx enabled 0
INFO: Lora multi-SF channel 0> radio 1, IF -400000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 1> radio 1, IF -200000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 2> radio 1, IF 0 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 3> radio 0, IF -400000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 4> radio 0, IF -200000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 5> radio 0, IF 0 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 6> radio 0, IF 200000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 7> radio 0, IF 400000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora std channel> radio 1, IF -200000 Hz, 250000 Hz bw, SF 7
INFO: FSK channel> radio 1, IF 300000 Hz, 125000 Hz bw, 50000 bps datarate
INFO: global_conf.json does contain a JSON object named gateway_conf, parsing gateway parameters
INFO: gateway MAC address is configured to 3338333045003200
INFO: server hostname or IP address is configured to "router.eu.thethings.network"
INFO: upstream port is configured to "1700"
INFO: downstream port is configured to "1700"
INFO: downstream keep-alive interval is configured to 10 seconds
INFO: statistics display interval is configured to 30 seconds
INFO: upstream PUSH_DATA time-out is configured to 100 ms
INFO: packets received with a valid CRC will be forwarded
INFO: packets received with a CRC error will NOT be forwarded
INFO: packets received with no CRC will NOT be forwarded
INFO: [main] concentrator started, packet can now be received
INFO: host/sx1301 time offset=(1554150705s:740683µs) - drift=1554150705740683µs
INFO: [down] PULL_ACK received in 23 ms
INFO: [down] PULL_ACK received in 24 ms
INFO: [down] PULL_ACK received in 22 ms
and the gateway connects to TNN again…
It’s refusing to run the startup script.
You should probably post the full systemd service file, and the permissions and first few lines of start.sh
start.sh is just these 3 lines, as suggested in the Hackster article:
timeout 10 ./lora_pkt_fwd
sleep 5
./lora_pkt_fwd
It runs OK if I invoke it manually using sudo.
Permissions on start.sh:
granary@granary:~/loragateway/picoGW_packet_forwarder/lora_pkt_fwd$ ls -l start.sh
-rwxrwxr-x 1 granary granary 49 Apr 1 21:09 start.sh
Where do I find the systemd service file?
Well, there’re your problem exactly as the error complained.
It must begin with something like
#! /bin/bash
To tell the system that it needs to be interpreted by a shell, as a text file isn’t an executable format. Why it works when invoked from an interactive shell is probably an interesting topic to research, but not really relevant to your need.
1 Like
Thanks, I wondered why the shell script did not begin with the usual #! line, but because it ran when I invoked it manually, I began to think it didn’t matter.
I updated start.sh:
#! /bin/bash
timeout 10 ./lora_pkt_fwd
sleep 5
./lora_pkt_fwd
Then I restarted the service and got:
granary@granary:~/loragateway/picoGW_packet_forwarder/lora_pkt_fwd$ journalctl -u pkt_fwd.service -b -f
-- Logs begin at Wed 2019-01-23 22:35:37 GMT. --
Apr 01 21:50:32 granary start.sh[2192]: INFO: Stopping concentrator
Apr 01 21:50:37 granary start.sh[2192]: *** Packet Forwarder for Lora PicoCell Gateway ***
Apr 01 21:50:37 granary start.sh[2192]: Version: 0.1.0
Apr 01 21:50:37 granary start.sh[2192]: *** Lora concentrator HAL library version info ***
Apr 01 21:50:37 granary start.sh[2192]: Version: 0.2.2;
Apr 01 21:50:37 granary start.sh[2192]: ERROR: failed to open COM port /dev/ttyACM0 - No such file or directory
Apr 01 21:50:37 granary start.sh[2192]: ERROR: FAIL TO CONNECT BOARD ON /dev/ttyACM0
Apr 01 21:50:37 granary start.sh[2192]: INFO: Stopping concentrator
Apr 01 21:50:37 granary systemd[1]: pkt_fwd.service: Main process exited, code=exited, status=1/FAILURE
Apr 01 21:50:37 granary systemd[1]: pkt_fwd.service: Failed with result 'exit-code'.
Apr 01 21:51:08 granary systemd[1]: pkt_fwd.service: Service hold-off time over, scheduling restart.
Apr 01 21:51:08 granary systemd[1]: pkt_fwd.service: Scheduled restart job, restart counter is at 35.
Apr 01 21:51:08 granary systemd[1]: Stopped Semtech packet-forwarder.
Apr 01 21:51:08 granary systemd[1]: Started Semtech packet-forwarder.
Apr 01 21:51:08 granary start.sh[2229]: *** Packet Forwarder for Lora PicoCell Gateway ***
Apr 01 21:51:08 granary start.sh[2229]: Version: 0.1.0
Apr 01 21:51:08 granary start.sh[2229]: *** Lora concentrator HAL library version info ***
Apr 01 21:51:08 granary start.sh[2229]: Version: 0.2.2;
Apr 01 21:51:08 granary start.sh[2229]: ERROR: failed to open COM port /dev/ttyACM0 - No such file or directory
Apr 01 21:51:08 granary start.sh[2229]: ERROR: FAIL TO CONNECT BOARD ON /dev/ttyACM0
Apr 01 21:51:08 granary start.sh[2229]: INFO: Stopping concentrator
Apr 01 21:51:13 granary start.sh[2229]: *** Packet Forwarder for Lora PicoCell Gateway ***
Apr 01 21:51:13 granary start.sh[2229]: Version: 0.1.0
Apr 01 21:51:13 granary start.sh[2229]: *** Lora concentrator HAL library version info ***
Apr 01 21:51:13 granary start.sh[2229]: Version: 0.2.2;
Apr 01 21:51:13 granary start.sh[2229]: ERROR: failed to open COM port /dev/ttyACM0 - No such file or directory
Apr 01 21:51:13 granary start.sh[2229]: ERROR: FAIL TO CONNECT BOARD ON /dev/ttyACM0
Apr 01 21:51:13 granary start.sh[2229]: INFO: Stopping concentrator
Apr 01 21:51:13 granary systemd[1]: pkt_fwd.service: Main process exited, code=exited, status=1/FAILURE
Apr 01 21:51:13 granary systemd[1]: pkt_fwd.service: Failed with result 'exit-code'.
Apr 01 21:51:43 granary systemd[1]: pkt_fwd.service: Service hold-off time over, scheduling restart.
Apr 01 21:51:43 granary systemd[1]: pkt_fwd.service: Scheduled restart job, restart counter is at 36.
Apr 01 21:51:43 granary systemd[1]: Stopped Semtech packet-forwarder.
Apr 01 21:51:43 granary systemd[1]: Started Semtech packet-forwarder.
Apr 01 21:51:43 granary start.sh[2250]: *** Packet Forwarder for Lora PicoCell Gateway ***
Apr 01 21:51:43 granary start.sh[2250]: Version: 0.1.0
Apr 01 21:51:43 granary start.sh[2250]: *** Lora concentrator HAL library version info ***
Apr 01 21:51:43 granary start.sh[2250]: Version: 0.2.2;
Apr 01 21:51:43 granary start.sh[2250]: ERROR: failed to open COM port /dev/ttyACM0 - No such file or directory
Apr 01 21:51:43 granary start.sh[2250]: ERROR: FAIL TO CONNECT BOARD ON /dev/ttyACM0
Apr 01 21:51:43 granary start.sh[2250]: INFO: Stopping concentrator
It repeats the same stuff every 5s.
Just as with the previous failure, the key is in the error messages.
This one is telling you that the port doesn’t exist.
Maybe it isn’t ready yet. I’m not sure I think that little trick of double starting is a wise one.
Another thing is that unfortunately Linux by default re-numbers ports if something is still holding the old one when the hardware re-enumerates. So your board can end up as /dev/ttyACM1, something you can check.
Also make sure you don’t have the dreaded modem-manager or brltty or similar wrecking havoc with anything that looks like a USB modem for a while before giving up and surrendering the port to other usage.
1 Like
I rebooted. This time the gateway connected to TNN without intervention…
Well, I know from first-hand experience of using Arduino Zero compatibles that, initially, those devices go into a “bootloader” mode for a few seconds, in case a new firmware version is to be uploaded. If nothing happens after a few seconds, they open the /dev/ttyACM0 port. Maybe the concentrator is doing something similar?
I’ll remember to check that next time it refuses to start. Again, that’s something I’m used to from using Arduino Zero compatibles. Right now, all I see is:
granary@granary:~$ ls /dev/ttyACM*
/dev/ttyACM0
I remember that too. In the past, I have had to add the USB vendor/device codes into some “blacklist” or “whitelist” file to get modem manager to ignore them. Not had to do that recently, though. Will have to investigate that further later in the week.
Anyway @cslorabox, your help is much appreciated! Is there any way to thank forum users apart from “liking” their posts?
The gateway has now been running for several days without any problems. The “double starting” fix suggested on the Hackster article seems to be holding up.
Have replaced the 3dB antenna supplied by N-fuse with a no-name 5dB antenna purchased a while ago on eBay. Made a noticeable difference to the rssi, at least a couple of dB.
What’s more, and I didn’t expect this, is that the concentrator seems significantly more sensitive than my single-channel gateway. That consists of a Wemos Mini connected to an rfm95 module, and the exact same antenna (I purchased 2 on eBay). See below. The same packet being received from the same node by the concentrator (eui-3338333045003200) and the single-channel gateway (eui-5ccf7fffff0b6219). The two gateways are less than a metre apart, with only an internal wall between them, and the node being received is in another part of the house. The signal from the node has to pass through an extra wall, that internal wall, to be received by the concentrator, so you would expect the single-channel gateway to get slightly the stronger signal.
{
"time": "2019-04-04T10:11:20.377239354Z",
"frequency": 868.1,
"modulation": "LORA",
"data_rate": "SF7BW125",
"coding_rate": "4/5",
"gateways": [
{
"gtw_id": "eui-3338333045003200",
"timestamp": 1319443651,
"time": "",
"channel": 0,
"rssi": -43,
"snr": 8,
"rf_chain": 1,
"latitude": 53.55391,
"longitude": -1.6946094,
"altitude": 283,
"location_source": "registry"
},
{
"gtw_id": "eui-5ccf7fffff0b6219",
"timestamp": 3299079467,
"time": "",
"channel": 0,
"rssi": -57,
"snr": 9
}
]
}This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.