Like the headline says: u-center has flickering windows for satellite level and history after changing UART1 from 115200 to 19200 baud.
Both docked windows are mostly black with sporadically showing a huge font in the satellite level history, and two out of far more satellites. In addition the Satellite row in the Data window flickers in the same frequency.
The config change for the UART1 was in both baud rate and output protocol; protocol was changed to NMEA. When I change the baud rate back to 115200 (despite leacing the output to NMEA); the blinking on u-center is gone. (All back to normal).
The machine has enough grunt (Windows 10, i7 CPU; 8GB memory)… no idea why this is the case.
I can replicate the problem in a Win7 VM on Linux Mint 20.1; hence, this must be related to the F9P or the arduSimple2B board?!
I am happy to post this in the ublox forum if more appropriate.
Hi 19’200bps might be too low baudrate for the default configuration which includes satellite information of all constellations on L1 and L2. You might be experiencing a buffer overflow.
USB is 9,600 baud and easily feeds u-center with all the data imaginable.
There are some 10-ish NMEA sentences per second on UART1… but, further thinking about it, I left incoming on the full gamut of messages… well, I may not understand enough about it. I changed the hardware from an UNO and software serial with 19,200 bound to a MEGA with its hardware serial 1 set to 115,200… it works… but I still think there is a problem.
Hi MaxG, USB works at 1Mbps regardless of what you choose on u-center.
A good starting point to know if there is a problem with u-center or your settings is to go back to the 1Hz configuration files: http://www.ardusimple.com/configuration-files
Data is going to choke at 19200 baud on UART1. Watch for $GxTXT txbuf alloc warnings, it indicates data lose is/has occurred.
USB is virtual, is has no baud rate,the interface just shovels blocks of data, as available
I changed the baud rate on USB, which did not change a thing; got it.
I also noticed that the clock ‘processed’ all the time stamps (by the looks of it) and the hour hand started moving like a second hand to catch up 🙂 –> certainly indicating a bottleneck somewhere.
I thought USB and UART, I2C, etc are individual ports… why would the UART1 choke on outputting NMEA sentences at 19,200 baud? … given the low data volume. The question here is, should I have changed the input protocol as well? Which also makes no sense as nothing was ‘inputting’ to UART1. I assume, if I say NMEA only that everything else is dropped and not chocking buffers. It almost looks like ‘all’ data types are generated, but only NMEA (in my case) is ‘filtered’ through.
Anyway, I have no idea how this is actually implemented, and the reasons why it works like it does.
Mind you, I had the 19,200 NMEA data consumed for a few days w/o data loss or problems. IT was only when I connected u-center that it flickered (when UART1 was set to 19,200).
I think we can put this to rest, now that I can consume 115,200 with the Arduino MEGA (thus no longer impacting USB output).
Thank you clive1 for your contribution to the community. You seem to be active on ublox too. Thank you for helping others.
And I forgot to say: I did not change the base/rover config or ‘Hz’, just the baud rate for UART1.
The other change I will need to make is RTCM (Time3); anything else I will stay away from until I am more familiar with it all.
19200 baud is just shy of 2000 bytes/second.
Check the text window for $GxTXT warnings.
You could also look at metrics reported via UBX-MON-IO, COMMS, TXBUF, etc
The ‘input’ relates to configuration and queries, really shouldn’t impact the output