and 
GSV slows RTK2B messages view to a crawl
pigosso asked 5 months ago
But disable NMEA GxGSV over USB inside of UBX-CFG-MSG, and everything becomes instant flawlessly smooth.
I think you should really check into this, because you are shipping the thing in your default configuration (idk if this couldn’t be different on older firmwares, but it’s definitively a problem on 1.32)
Ardusimple Staff answered 5 months ago
What you are describing is not normal, maybe you can share more details with us?
1. Which product do you have?
2. Which software and configuration are you trying to upload?
pigossoEven just your normal rover 10Hz 1.32 cfg.
Both on my older simpleRTK2B-F9P V3 and simpleRTK2B.
After painstakingly comparing that with another cfg I had lying around that didn’t exhibit the issue, I found that was the killer feature.
Ardusimple1.32cfg doesn’t have 10Hz configuration file, because 1.32 doesn’t support 10Hz with full constellation.
https://www.ardusimple.com/wp-content/uploads/2022/09/simpleRTK2B_FW132_Rover_10Hz-00.txt
I meant this file, which you are officially providing in your support page.
clive1Yeah, I think fire hosing GSV at 10 Hz is inadvisable, and of little use/merit.
Does it work if you decimate the GSV output rates?
GSV is disabled on UART, but not on USB: You can reduce GSV output with UBX-CFG-MSG.
UBX-CFG-MSG only has you enable/disable GSV (which is what I already toggled in the OP). Where can I lower just its rate?
And.. besides that, if nothing is seemingly eluding me then, how could this fly undetected for so long?
Setting it to 10 literally decimates the output
0=DISABLE
1=EVERY EPOCH
2=EVERY OTHER EPOCH (1/2 Hz for 1 Hz solution rate)
..
I see, thanks. 10 seems more or less the neighbourhood everything isn’t just super sluggish (though it’s so awful in u-center flashing rapidly, that I’m not even sure how useful it could be at this point).
Is anybody going to correct the configuration files?
Hi, we are following this thread and currently is in the to-do list for testing. What we see is that USB interface has enough bandwidth for all this data and some users want this data, and is u-center which is not able to process all this data when run on not super fast PCs. For your case I think you found already a workaround.
To be honest, GSV (and to a lesser extent GSA and GLL) are also causing extreme stuttering even in another program I have here.
And yes, the tablet I was trying this is far to be high-end but the crazy thing is that cpu usage was *not* maximized (not even on a single core!).
Maybe you should get in touch with u-blox, I don’t know?
Ok, so what’s being reported is that uCenter Classic is not able to sink data and the host side system gets hot due to high CPU load or disk/swap activity?
If you connect with a simple serial terminal application does the serial data flow continuously?
uCenter Classic does have issues with high data volume and long-term running. It’s considered obsolete and I’ve not got them to fix it in years of trying.
Is there some other application you can use form data collection or viewing?
Well, you actually seem right.
I just checked cpu usage in u-center, and that does skyrocket once I enable GSV (it goes from around 15% to 25%, which is kinda the maximum you can get on my quad core Atom while only using a single thread).
If I try with QtSerialMonitor instead, there’s barely a difference and values seem to be coming pretty smooth (even though I couldn’t precisely confirm if the output rate was 100% obeyed or if something couldn’t have been dropped here and there).
Anyway, what I would really care for eventually was AOG, where I have this crazy bug. https://github.com/farmerbriantee/AgOpenGPS/pull/303
When GSV (or GSA/GLL) are enabled, if you then drop their message you have extreme stutter. If you do *not* drop them, everything is good.
All of this while the CPU is almost completely idle (and I could reproduce this even on a beefy desktop).
Couple of things going on here.
Any computer from the last 30-years should be able to sink serial data at 115200 baud. And most any 32-bit MCU for that matter, should be fine.
If the application can’t sink the data there’s either an issue with the app or the OS ignores the serial ports. uCenter is doing some logging/database work, and that’s historically been an issue, with it flooding SQLite or whatever it does in the background allowing you to plot paths and signal strengths, deviation plots, etc. This is aggravated by high update rates and long term running. It’s primarily with how it archives this data, sorts it, etc and not the flow from the receiver specifically. It wants to retain all the data in a session, and doesn't have a strategy to shed data as that accumulates uncontrollably.
The receiver has a finite pool of buffers, they retire as the messages leave all the interfaces they’ve been enabled on. Slow baud rates, if left on UART1 or UART2 with NMEA can cause a log-jam.If this is occurring you’ll get a “$GxTXT txbuf,alloc” warning and it will dump packets. You really need to cull all messages, and interfaces you are not using. This will solve the majority of issues. Application software should recognize the “txbuf,alloc” messages, ideally counting and alerting the users. As more satellites are tracked the more data volume NMEA will generate, issues may appear to come and go.
Getting satellite lists for user interface really doesn’t need to be faster than 1 Hz.
On vehicles, 5 – 8 Hz data rates should be sufficient for the kind of dynamics we’re dealing with mowers, tractors, and cars.
People like DJI use 5 Hz and 921600 baud, with lots of messages. Not NMEA, but UBX.
In apps check for data flow and things that might wait or block. Watch for dependency on message ordering.
I see thank you. So it was technically two separate bugs that I was experiencing (even though there’s not much of a reason for GSV to be high frequency).
Btw I found that if you set the dwords in HKCU\SOFTWARE\u-blox\u-center3\Database\Completer to 0, then the disk activity stops.
clive1Please login or Register to submit your answer
