@Revital Maroko @Revital Maroko good questions, and the timing stuff especially is worth getting right before you're deep in the filter tuning.
On the fix interval — yeah, it does wander in practice, somewhere in that 53–60ms range depending on constellation load and geometry, so don't hardcode 55ms in your predict step. Just timestamp on arrival with the MCU clock and pass the actual elapsed dt into the filter. It's a small extra step but it'll save you weird drift artifacts that are a pain to diagnose later.
On the NMEA timing — the standard sentences include a UTC timestamp field but it's only second-level resolution, so for tight fusion at IMU rates you really want to capture the host-side arrival timestamp as the authoritative timing reference. If you need tighter sync you can look at the PPS pin output if the module exposes one, which gives you a clean 1Hz edge to calibrate your MCU clock against the GNSS timebase — that's usually how people tighten up the IMU/GNSS alignment properly.
The 1.5m spec is CEP, which is the 50th percentile circular error — so your measurement noise matrix should account for the fact that you'll see errors beyond that pretty regularly. A common approach is to set R conservatively at something like 2–3x CEP² to cover the tail, then tune from there with logged data.
As for piping the position output directly into the filter — position noise is clean enough to go straight in without pre-filtering, as long as your R matrix is reasonably tuned. The IMU data from the sensors module pairs well for the high-rate prediction step, and the GNSS just does the correction updates asynchronously whenever a fix arrives. If you've got a fusion pipeline already running I'd actually be curious what MCU you're on and whether you're doing this onboard or offloading the filter.
