Sure, but that means the mappers are only visible to these specific gateways…
Got a RAK7258 installed. It brings great value, no doubt, but unfortunately no time, although is has an NTP client.
“gateways”: [
{
“gtw_id”: “eui-60c5a8fffeXXXXXX”,
“timestamp”: 3665728884,
“time”: “”,
“channel”: 7,
“rssi”: -53,
“snr”: 9.8,
“latitude”: 52.5XXXXX,
“longitude”: 13.4XXXXX,
“location_source”: “registry”
}
]
Anyone who knows a hack how to get the “time” field filled by the RAK7258?
First I guess you should see if decisively telling it that it doesn’t have a GPS accomplishes anything. Or look through the source code (at least the Semtech version) and see what logic is involved in adding or not adding the timestamp.
If that doesn’t work, build whatever packet forwarder you like from source?
RAK has a few customizations of the lora hal to deal with MT76x8 SPI oddities, but those are in their open repos.
Their closed builds do a fair number of other things but unless you are especially enamored of the web page configuration those do not have any clear benefit when you are working with an external server.
Another option could be to point the packet forwarder at an on-device intermediary. Surprisingly a not particularly efficient one written in python we were using on much larger compute platforms ported right over and seems to be running fine - the plan was to fold what it does into the packet forwarder but that hasn’t seemed necessary. I’m not sure if the factory openwrt build has python support, if it doesn’t it’s probably simpler to write an injecting intermediary in C.
1 Like
I checked the unit and found out that it has a GPS-PPS Input wired to an internal connector. I will connect a GPS module to USB port and wire PPS to the Input, configure the TTY in global_conf.json, and then i hope i will see the time. Let’s see…
Oh, interesting, where? I hadn’t taken time to trace that from the mPCIE to see if it goes anywhere yet.
The RAK2758 has a RAK2274 concentrator module inside, with mPCIE slot. GPS PPS is wired to pin19 of the slot connector, and that’s were i plan to grab it with a thin wire.
Do you have a suggestion which UART port of the RAK634 to use for connecting TX/RX (TTL) of the GPS module?
Oh okay, yes, that’s documented for the concentrator. I thought you were saying it was broken out to a connector footprint on the motherboard.
The console (I think ttyS0) is on the diagonal one at the corner of the concentrator module, and shifted to RS232 levels on the extra RJ45.
Another one, I think ttyS1, is on a similar connector at the front edge of the board, but does not seem to be actually enabled in the kernel, even though a device node exists for it.
To use it you have to rebuild the kernel with these changes:
That is for one of their open source builds using a through hole version of essentially the same processor module, but seems to work on the production gateway, too.
RS232 should work with TTL levels, right?
NO! Definitely not! Perfect way to destroy things!
Also keep in mind if you want to use the console port, you’ve first got to disable the getty that runs a shell there, otherwise you’ll have busybox sh complaining that your NMEA sentences aren’t valid commands.
Hmm, thanks for these hints, so it’s more complicated 
What if i use the USB port which is broken out to the case?
Or may it be busy by LTE modem?
USB port which is broken out to the case?
Or may it be busy by LTE modem?
Plausible. I’ve not been able to find out how the stock LTE modem is connected.
I forget if the stock build has lsusb if it does, that should be informative.
You can also see if there’s are /dev/ttyACM files (probably several for a USB LTE modem)
Or it’s possible they are running it off a UART or something else that wouldn’t be an obvious guess
Checked it: as expected the USB bus is used by Quectel EG95 LTE modem.
So we have no simple option to add a GPS with PPS 
RAK Wireless LoraWAN Gateway (1.1.0053_Release r188 20191018)
root@RAK7258:~# lsusb
Bus 001 Device 002: ID 2c7c:0195
Bus 001 Device 001: ID 1d6b:0002
Bus 002 Device 001: ID 1d6b:0001
TTYs listed:
crw-r--r-- 1 root root 5, 0 Jan 1 1970 tty
crw-r--r-- 1 root root 4, 64 Jan 1 1970 ttyS0
crw-r--r-- 1 root root 4, 65 Oct 25 16:53 ttyS1
crw-r--r-- 1 root root 4, 66 Jan 1 1970 ttyS2
crw-r--r-- 1 root root 188, 0 Oct 25 16:52 ttyUSB0
crw-r--r-- 1 root root 188, 1 Oct 25 16:52 ttyUSB1
crw-r--r-- 1 root root 188, 2 Oct 25 16:52 ttyUSB2
crw-r--r-- 1 root root 188, 3 Oct 25 16:52 ttyUSB3That’s key information that didn’t seem to be stated anywhere before. Thanks for verifying it!
So we have no simple option to add a GPS with PPS
Probably not with the stock RAK build, no.
Building from source it is probably quite possible to use ttyS1 which is at TTL levels.
Or in desperation you can disable the getty on the console and use ttyS0 either at TTL levels on the diagonal header near the corner of the processor, or RS232 levels on the RJ45.
But then you don’t have any easy way to get into the box for maintenance, if it doesn’t manage to come up on a network.
does this output from dmesg mean that ttyS1 may be usable without new build?
root@RAK7258:~# dmesg | grep "tty"
[ 0.000000] Kernel command line: console=ttyS0,57600 rootfstype=squashfs,jffs2
[ 0.360000] console [ttyS0] disabled
[ 0.360000] 10000c00.uartlite: ttyS0 at MMIO 0x10000c00 (irq = 28, base_baud = 2500000) is a 16550A
[ 0.380000] console [ttyS0] enabled
[ 0.410000] 10000d00.uart1: ttyS1 at MMIO 0x10000d00 (irq = 29, base_baud = 2500000) is a 16550A
[ 0.430000] 10000e00.uart2: ttyS2 at MMIO 0x10000e00 (irq = 30, base_baud = 2500000) is a 16550A
[ 39.460000] option1 ttyUSB0: no of_node; not parsing pinctrl DT
[ 39.470000] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB0
[ 39.510000] option1 ttyUSB1: no of_node; not parsing pinctrl DT
[ 39.520000] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB1
[ 39.560000] option1 ttyUSB2: no of_node; not parsing pinctrl DT
[ 39.570000] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB2
[ 39.610000] option1 ttyUSB3: no of_node; not parsing pinctrl DT
[ 39.620000] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB3No, unfortunately. If you try to use it, you’ll probably find you only get errors because it isn’t really enabled.
I had to make the kernel configuration changes linked above before it would work (in my case to talk to an MCU that will help manage the gateway system)
Hmm, i won’t be able to do that (recompile SDK etc.)
May i suggest something?
For using PPS you do not strictly need UART. The Gateway itself has already NTP. Therefore quite exact time. PPS only helps to determine exactly the start of the second.
I think you can add PPS output of quite any GPS to Pin 19 (take care of i/o voltage level) to achieve your goal. At least you can check if the module adds timestamps with active PPS.
Many professional radio equipment work this way. They have only the possibility to inject 1PPS. Mostly in combination with 10Mhz Reference.
((( Y )))
|
|
+- -|- - - - - - - - - - - - -+ xxxxxxxxxxxx +--------+
|+--+-----------+ +------+| xx x x xxx | |
|| | | || xx Internet xx | |
|| Concentrator |<----+ Host |<------xx or xx-------->| |
|| | SPI | || xx Intranet xx | Server |
|+--------------+ +------+| xxxx x xxxx | |
| ^ ^ | xxxxxxxx | |
| | PPS +-----+ NMEA | | | |
| +------| GPS |-------+ | +--------+
| +-----+ |
| |
| Gateway |
+- - - - - - - - - - - - - - -+
For me PPS is mandatory while NMEA is not and can be replaced with other methods(NTP).
pic source
and
LoRa concentrator : Timer synchronization Provides synchronization between unix, concentrator and gps clocks