Which is why that is not how it is supposed to work.
The GPS’s PPS signal is supposed to be directly connected to the concentrator chip, and captured in hardware.
Slightly afterwards software then parses the NMEA sentences and retroactively decides which second the precise pulse timestamp captured in a concentrator hardware register belonged to.
Using a serial port alone, you could fix errors in the system clock to moderate accuracy, which might help with things like knowing what wall-clock-time to assign to a measurement report of sensor readings. But it doesn’t really help with the timing of a LoRaWAN network, not to mention any hope of time-of-flight location.
For that even a few milliseconds lag from a USB connection shouldn’t be an issue.
Some changes to the software/installation of the mentioned RAK7258 would be necessary however, which may require a degree of experience / persistence to work out.
I suspect the USB port would be lost in the LTE model, but they never answered my question on that. It’s possible they use a UART to interface the mobile modem instead. (I needed a different modem anyway, so put a USB hub between it and the processor)
Something pi-based is probably going to be more flexible in experimenting with custom configurations and features, and if it already has the GPS, great. If that already works in software, all the better - but a lot of these off-the-shelf things only “mostly” work and end up needing expertise and intervention in real world usage.
In contrast to a pi-based solution things like the RAK7258 that use a tiny static system image on an SPI flash have the potential to be far, far more robust in the field than things like a pi that depend on an SD card - currently testing prototypes of our own custom solution using the same processor family. It might be a case of what is best for the near term getting something to work being different than what is best for the long term having it keep working without attention.
I agree but Pi-based is indeed more flexible.
For reliability a small cheap SSD may be added via USB to SATA adapter and set fuse to boot from SSD. (On Pi 3 this will be limited to USB 2.0 speeds but Pi 4 supports USB 3.0.)
The drive is not yet nicely build into a gateway housing but does not have to be an issue.
Indeed, it would pretty much only be useful for pre-arranged experiments, perhaps functioning as a node that can range other nodes by pre-agreement of frequency and spreading factor coordinated through a “real” gateway.
It almost would have made sense to put a typical mPCIe concentrator socket on there and then perhaps develop on top of the pico gw reference design, that typically runs on an STM32F4.
Yes sure, for now it is nothing else that an experimenter’s gateway. Some guys in our community will install some of them for testing, runing them fixed on 868.1 MHz SF7 for mapper experiments. This is of course NOT a proper LoRaWAN Gateway. It’s just another experiementer’s board.
Extracting fine time stamps out of a SX125x/SX130x chip combination (or any contentrator board) has one big problem: One needs an IP license from Semtech to achieve that - which is not feasible for a maker/tindie project.
Please dont do that! Also I echo comment above wrt single channel GW.
If you MUST fix frq/SF please move to another part of the band where not used by LoRaWAN EU868 plans on LoRaWAN. For compliant systems payloads are spread (excuse the pun) across a number of channels pseudo randomly evening out spectrum use and being far more socially responsible. Having someone sit on one of the key Frq/SF combinations and effectively loading it is bad practice and causes problems for other spectrum users. At least agree a channel sequencer between the node and your experimental single channel bridging device and have transmissions move around a bit!
Yes Jeff, you’re right, I see that problem with working only on one channel. This brought me to the idea to take the current time retrieved from GPS (Nodes and Gateways have GPS in this case), calculate some modulo of it and use this result as a pointer to a pseudo random list of channels known on both sides. We also add some random time window to the transmittion start to be sure not to repeat the same list entries again and again which would cause collisions and uneven channel usage. This would balance the channel useage a bit…
