I want to verify the hardware connection and data publication feasibility of using the Sparkfun RTK Express as a 1PPS trigger source for separate external IMU and LIDAR units (each accept 1PPS sync input). I am new to GPS projects and hardware/software. See below my plan and questions after review of the Sparkfun hook-up guide.
Plan was to use a RTK Express GPS in Rover mode (maybe implementing RTK in the future) and use a RPi to collect/merge sensor data streams. I think there are 2 sensor hookup options in my setup. (1) Collect data from each of the GPS, LIDAR, and IMU with common GPS 1PPS-sync’ed time-stamps. (2) Collect data from only the LIDAR and IMU with those again using GPS 1PPS sync. The LIDAR is able to receive GPS fix input data during its 1PPS triggered snapshots (i.e. UTC date/time + location & fix quality data via NMEA string GPRMC or GPGGA formats) and embed that into its point-cloud output data.
Below is a screenshot of the Sparkfun RTK Express hook-up guide summary describing the “DATA” port usage and physical DATA port pin-out/labels.
Regarding Option #1 – the hook-up guide states the DATA port TX pin can supply a 1PPS trigger. Can I connect the TX pin to both an external LIDAR and IMU PPS-inputs at same time? Must the GND pin be connected to the LIDAR/IMU to have common ground across the 3 devices to not have 1PPS triggering issues? The RTK Express is powered by its internal LiPo, where the IMU/LIDAR would be powered by another battery source. I don’t see a hardware option to have common power source for the RTK Express, IMU, LIDAR.
Regarding Option #2 – I think this may not be possible with the RTK Express DATA port. The hook-up guide describes the DATA port TX pin can be used for GPS NMEA out, but the description implies that TX pin can be either NMEA or 1PPS output. Is this correct? My LIDAR on the other hand has 2 input pins for GPS input – one for GPS NMEA data and another for GPS 1PPS. If I were to use TX for NMEA output only, can the uBlox ZED-F9P output the needed GPRMC or GPGGA format data strings?
I’d appreciate feedback for my Option #1 and #2 scenarios. Can I use the RTK Express GPS unit in some fashion (#1 would be fine, #2 seems more ideal). Or, would utilizing the SparkFun GPS-RTK-SMA Breakout - ZED-F9P (Qwiic) (SKU: GPS-16481) be a better GPS match? It seems to have more output ports and could have a common power source across all 3 sensors.
Thanks for any feedback.
SparkFun RTK Express Hookup Guideexcerpt – DATA port highlighted.
4 pins (L-to-R): 3V3, TX, RX, GND
GND must be connected across all devices. For a 1PPS trigger to work reliably, all devices must share a common ground. Without a common GND, the pulse may be misread or ignored due to floating voltage references.
A development board will be easier to work with verses the Express.
Question: Will you be generating a combined 3D point cloud from all the LiDAR Sources ?
If so, take a look at the LG580P breakout, which could make your registration easier/quicker. The Dual Antenna LG580P (assuming RTK) will provide more accurate orientation vs an IMU to give each individual point cloud a head start during automatic registration, as a course/rough alignment. Please disregard if you aren’t generating a 3D model
Thanks for this feedback - I think you’re right that a dev board format may be better to use. It would be good to get confirmation that I am correct about Option #2 – you cannot use Express RTK’s DATA TX for PPS and NMEA simultaneously. I didn’t dive into its driver info to confirm restrictions.
As to your question – I plan to combine 3D LIDAR point clouds. I checked out the Dual Antenna LG580P dev board you mentioned and now understand your comment that it may provide a better-formed set of initial point clouds to stitch.
I am looking through Sparkfun’s GPS offerings to compare boards – there’s a lot to choose from in the inventory. The MicroMod system with processor & various GPS function boards looks cool, and there is a LG580P RPi Phat. I may splurge $200-250 on a board. Want to make sure I get the most features to allow re-purposing what I purchase for other future projects (i.e. RTK, extra IO ports, ROS, etc.).
you cannot use Express RTK’s DATA TX for PPS and NMEA simultaneously
That’s correct. The signals are routed through a multiplexer. You can have access to: either ZED TX and RX; or PPS and EXT_INT. If you need access to both, you’ll need to pick up one of the signals elsewhere on the circuit board. J15 could be a good choice for ZED-TX.
I suspect a GNSS Breakout is going to be a better solution for you.
GND must be connected across all devices
all devices must share a common ground
This is usually true, but it depends on your application and, in your case, how the IMU and LIDAR are powered. Large / multiple ground loops can cause different problems. You may have to opto-isolate the signals for best results. Can you share links to the IMU and LIDAR units you’re using? We can take a quick look and let you know if they’re likely to be compatible with the 3.3V PPS and TX signals from the GNSS.
Also, the best path heavily depends on your intended use case.
Is your robot autonomous, or an AGV ?
Will you have multiple vehicles operating at the same time ?
Will the robots perform stationary scans, or SLAM ?
Do you prefer production rate or final point cloud accuracy ?
What software will you use for scan registration ?
It’s probably best to work this problem backwards…start with whatever your final deliverable is and decide the best way to achieve it. I’m guessing the registration software (and method) will likely have the most impact on your design.
Examples for range of complexity :
For general mapping: gnss assisted SLAM is extremely quick and easy. But if I need to measure the flange thickness for a steel beam in the roof framing to +/- 1mm, then I scan with tripods and fixed targets that are conventionally surveyed. The difference in complexity (and time) could easily be a factor of 20x between those 2 examples.
Share any details that you’re comfortable with, and good luck
@rftop My use case is at a DIY edutainment project level (not commercial 1mm accuracy inspection scans). Goal is a LIDAR SLAM hand-held/transported system and maybe a rover at some point. I’d like to achieve a ~1-2cm point cloud accuracy with option for indoor/outdoors. Select hardware that can give good chance of success and can be re-purposed as solid foundation for future engineering projects. Currently plan to collect all sensors’ raw data on a RPi 5 with NVMe SSD, then off-line view and process with opensource tools.
@PaulZC – thanks for confirming the multiplexing behavior on the Express RTK DATA pin and potential use of J15. I inquired so that this could be documented if anyone else may need the info similar to my Option #2 scenario.
Bulleted below are links to user manual PDFs for the LIDAR unit (Pandar40P) and IMU (VN-100) that I plan to use. I have purchased a Pandar40P – it supports 1PPS input and NMEA input data from a GPS and has 40 line scan pattern suitable for robotics or SLAM. The VN-100 IMU supports “SyncIn” which appears to be 1PPS compatible; I found this IMU referenced in various robotics example. I considered an ACEInna IMU (300ZI) that is highly configurable, but VN-100 specs appear stronger, has rugged packaging, and can disable its magnetometer if needed (and I don’t have expertise or need to play with Kalman filtering on an ACEInna). I would greatly appreciate your feedback if these would work well together with a Sparkfun GNSS breakout solution.
Moving to GNSS breakout choices, I initially looked at ZED-F9P breakout, but at suggestion of @rftop now considering LG580P module as top-contender. I’ve put links to a few Sparkfun GNSS products of interest thus far, along with some comments/questions after reviewing several Sparkfun demo videos and hookup guides. Note that the LG580P/LG290P GNSS versions have not added to the Sparkfun GPS Guide page.
See all info below. Thanks for your feedback on LIDAR/IMU device compatibility with some GNSS board options. Sorry if this has morphed into what should be a seperate forum dedicated topic.
IMU: VN-100 – is there any Sparkfun or other suggested alternative?
LG580P basedoptions— dual-antenna, most-robust GNSS lock potential, heading fix; Factor in cost for 2 quad-band antennas (but see pHAT question below). But how soon will “SPI*, I2C*, and CAN*” be implemented so all potential board I/O options fully available?
GPS-29890: SparkFun GNSS Flex pHAT - LG580P – was planning to use RPi for data collection from GPS/LIDAR/IMU; need to audit what RPi pins untouched by pHAT leftover available. RPi bluetooth/WiFi can get RTK. But – a) uFL usage potential damage risk, b) where’s the dual-antenna mount?? CORRECTION – I now observe in a close-up of the LG580P Express carrier board there are 2 UF.L. connectors for primary & secondary antenna. One goes by UFL-to-UFL jumper to the pHAT board then to SMA antenna, and there’s a UFL-to-SMA patch cord for connection of the 2nd antenna.
ZED-F9P option: dual-band, RTK with BlueSMIRF add-on; established firmware with all I/Os available
GPS-26916: SparkFun RTK Postcard – demo video looked great – super small/portable, quad-band, RTK with on-board ESP32 bluetooth. Has PPS. But when “SPI*, and I2C*” available? Best low-cost option of all for RTK. Haven’t yet compared to LG290P SMA breakout board I/Os.
PPS is “TTL level 3.3/5V”, so you’re OK there.
Pin 2 provides 5V power output, so you could power a GNSS Breakout board directly from that.
GNSS TX will need to be level-shifted to RS232. We have a MAX3232 Breakout for that.
Looking at the IMU - assuming you are considering the VN-100 Rugged:
It needs 5V power.
It has both RS232 and TTL (3V) UART ports.
You could connect the TTL port direct to a RPi for control / configuration and logging.
You could also power the IMU from the RPi 5V power source.
Going back to the LIDAR:
The connection box has a 5.5/2.1mm jack for power input.
It needs DC 9V to 48V.
So, I suspect you’ll want something like this:
LIDAR with connection box, powered from a small 12V rechargeable “leisure battery” power source.
LIDAR providing power to the GNSS.
GNSS TX level-shifted to RS232.
GNSS PPS connected direct.
LIDAR Ethernet connected to RPi. This may need a Hub / Switch (which would also need power).
RPi powered by a 5V USB rechargeable battery pack.
IMU powered by the RPi.
IMU interfaced to RPi using the TTL UART interface.
Software to configure and log data from: LIDAR over Ethernet; IMU over UART.
I’m assuming the GNSS data is available from the LIDAR over Ethernet. I suspect you don’t need to connect the GNSS to the RPi for direct GNSS logging.
It’s not clear if the LIDAR would be able to benefit from the proprietary PQTM heading information from the LG580P. You would need to dig into the docs to find that out. But the LG580P is still a good choice; it will output standard NMEA sentences - which is probably what the LIDAR is expecting.
You shouldn’t need to worry about common ground and ground loops. The LIDAR plus GNSS is one circuit. RPi plus IMU is a separate circuit. Only Ethernet connects the two and that has magnetic (transformer) isolation.
If you do decide that you need to log the GNSS data directly on the RPi, maybe including the LG580P PQTM heading information, I would recommend opto-isolating that interface.
The LG580P has multiple UARTS. You can configure and dedicate one for the LIDAR. Another could be connected to the RPi. RPi also supports multiple UARTs.
That interface would bridge the LIDAR/GNSS and RPi/IMU power circuits. My advice would be to design in opto-isolation from the start. You may get away with a common ground between the 12V LIDAR and the 5V RPi circuits, but it is easier to design that out from the start.
A pair of simple opto-isolators, one for the GNSS TX path and another for the GNSS RX path is all you need. Two of theseshould do the job, but you would need to test it to be sure. It is dual-channel but you still need two of them, one for TX, a second for RX.
One little detail with a dual antenna LG590P, is the requirement to separate them.
There is no standardized distance, but 1m is a good starting point. That, along with your proposed indoor option makes me think you might need a handheld system that works without GNSS, and definitely not a dual antenna.
If you want indoor functionality, you should probably go with a Hybrid (SLAM + GNSS) verses GNSS-LiDAR. Basically, the LiDAR/IMU is the primary driver, and something like the PostCard (or LG290P breakout, etc) is the “assistant”, when available.
For some reason, I was envisioning a Swam of Autonomous vehicles that “attacked” an outdoor site, from your original post. Sorry, that was just my brain getting too excited
@rftop No – won’t have a rover swarm although wouldn’t that be epic. This is homebrew with a single hand-held rover LIDAR/IMU/GNSS sensors & RPi in an enclosure I’ll design once I select final GNSS board (breakout vs. Flex pHAT). I know that for indoors is SLAM (LIDAR + IMU) and then add-in the GNSS for outdoors. I think I’ll proceed with the LG580P dual-antenna, even if maybe not required, as it will be good infrastructure to re-use for a future project.
@PaulZC – thank you so very much for the technical review of the LIDAR/IMU sensor manuals and providing feasibility assessment and suggested approaches to connect the sensors. I believe I follow your comments in the 2 detailed responses you provided. I need to decide breakout vs. pHAT path. I am studying the Sparkfun hook-up guides & PCB layouts of the Flex pHAT vs. Breakout GNSS LG580P boards to consider which may be better choice for my project. I did purchase both the LIDAR optional Control box (supports GPS input) and the VN-100 “rugged” 10-pin connector IMU. Thanks for your recommendation to use the opto-isolator and level-shifter boards, both which I have on my Sparkfun Wishlist now. I will sketch out a sensor connection plan and might inquire for advice again if needed. The Sparkfun hookup guides are outstanding reference.
One thing for the LG580P – is there an ETA for the I2C/Qwiic, SPI, and CAN firmware support for either the breakout or Flex-based boards? I certainly don’t expect any “vaporware” situation for a Sparkfun product, but I also don’t want proceed and then not have a path to add QWiic devices.
Quectel have said that “the [I2C] function, feature, interface, pin, or argument is under development and currently not supported”. We have no information about if / when I2C support will be added… From your description, it’s not clear - to me - how I2C / Qwiic would help with your application…?
@PaulZC Just asking as I am purchasing this board for this project, and spending more for this nicer board that I can re-purpose for other future projects. It was not clear by the disclaimer if it was a manufacturer deliverable gating future functionality, or Sparkfun just needed time to write a follow-up update to your software driver. I’d consider a manufacturer promise riskier for eventual timing.
Since the GNSS breakout/pHAT has Qwiic connectors on it, it would be nice to use them if I wanted to add other Sparkfun Qwiic sensor boards in the future.
Is the ublox smaller antenna that I linked above compatible for the LG580P? I think would be better mobile solution for my case, and saves some money since 2 antennas required.
Yes, it is compatible. But whether it is the right choice for your project, I can’t say. That antenna may need a separate ground plane for best results; the performance in the datasheet is “Measured on a ø12 cm ground plane.”
