DWQA User Profile cono44Questions(7)Answers(0)Posts(0)CommentsThanks clive, this was basically my plan just I don't have easy access to the base station at the moment due to distance. I guess my question is more related to base station site selection and what I should be doing and what metrics are important. There doesn't seem to be any good guides out there. For example, if I want to compare two potential sites what metrics should I be evaluating, are solution convergence (rms) and ambiguity resolution (%) sufficient?On Base station quality & monitoringIs there any documentation for this?! Would this allow monitoring as well as changing configruation remotely (via u-center)?On 4g ntrip client casterGreat! Will it ever be possible to remotely log into the device via the 4g client (similar to the ntrip wifi master?)On 4g ntrip client casterThanks, it wasn't out of choice, I was trying to connect to a ntrip service and that was the only protocol available.On Unable to specify Protocol in as RTCM2Thanks!On Answer for Unable to specify Protocol in as RTCM2...so it seems dropping the baud rate on UART1 down from the default 38400 to 9600 (with navigation rate kept at 1Hz) fixes the issue. So it certainly some kind of timing problem. On Debug session with simpleRTK2B and STM32 Nucleo tutorialThanks for your reply.- Yes only UBX messages are enabled on UART1. If you look at my code, I have made a simple array (called testbuf) that dumps each byte from the rxBufferGNSS variable as it is received so I can see that there is no other data being received.- I actually decreased the navigation rate from 1s to 10s to slow things down.If I understand the code correctly each byte received is processed on the fly (i.e.there is no buffer):- after each byte is received, handleGNSS() is called- as soon as a header byte (0xB5) is received it starts to fill a buffer array and does so until the last checksum byte arrives- the state is set up SM_UBX_END and this triggers the parsing section of the codeSince the first message is read and parsed without issue it seems that there is a delay in the parsing section of code but I'm struggling to see what the issue might be. On Debug session with simpleRTK2B and STM32 Nucleo tutorialTo follow up on my last comments above. As can be seen in the screenshots here (https://imgur.com/a/mGuUBxg) it looks like the handleGNSS() function is causing me to lose the first 5 bytes of the second message (NAV-RELPOSNED) which results in this message not getting parsed (although occasionally it will)To test this I just slowed down the output rate from the F9P and added a buffer in HAL_UART_RxCpltCallback so that I could dump all the values send from a single transmission into an array. I then commented out the call to handleGNSS(). When handleGNSS() is called I consistently miss the first 5 bytes of the NAV-RELPOSNED message. When handleGNSS() is not called the problem goes away so this looks like a processing/timing issue. It only occurs at the end of a message so the time it takes to process a fully received message is causing the program to miss the first few bytes of the second message. I quickly tested this by commenting out the parsing for NAV_PVT messages which resulted in only 4 bytes being missed.I haven't had time to try rectify this but any suggestions welcome! I'll try to get back to this later and will post any updates.On Debug session with simpleRTK2B and STM32 Nucleo tutorialSmall issue. The RELPOSNED values do not update very frequently whereas the PVT values instantly update every time I run the code up to the breakpoint. Removing the breakpoint at line 162 as shown in the video and placing a new break point at line 180 it can take several minutes before the code breaks. If I disable the PVT messages then the breakpoint at 180 is triggered every time I run the code however so this behaviour only occurs when both messages are being sent over UART1.Any ideas why this might be happening? It seems that the RELPOSNED messages are being missed so possibly related to timing/update rates? It's odd however as if this is a timing issue I expect it to "catch" the messages at random, not for one message type (PVT) to be parsed significantly more often than the other as is happening here.On Debug session with simpleRTK2B and STM32 Nucleo tutorialOnly getting back to this now. Worked like a charm, thanks!On Debug session with simpleRTK2B and STM32 Nucleo tutorialI suspected this could be the case but since this is my first time using a Nucleo board so I wasn't too sure. The solder bridges table in the nucleo-64 manual seems to say that SB62 and SB63 should be ON."PA2 and PA3 on STM32 are connected to D1 and D0 (pin 2 and pin 1) on Arduino connector CN9 and ST morpho connector CN10 as USART signals. Thus SB13 and SB14 should be OFF"Hopefully someone at ardusimple staff can confirm the configuration used in their video.On Debug session with simpleRTK2B and STM32 Nucleo tutorialThanks Clive , that's what I figured. Ended up using the UBX-CFG-TMODE3 as you suggested anyway since CFT-TMODE-ECED-Y wouldn't update correctly for some reason. On Base station fixed position – how to set high precision coordinatesNot familiar with the openlog but first thing I'd suggest is trying to log NMEA data if possible to confirm if it logs that correctly/as expected.On Ntrip for base initial position with data loggingAs regards your issue with converting from .ubx to RINEX using rtkconv. Does you .ubx file not contain any data or what is happening?It seems that the current stable release isn't equipped to handle this data properly. My own experience so far and comments I've seen on other forums seem to suggest that rtkconv 2.4.2 will only convert the L1 signals. Tim Everett's version of RKTLib looks like it will work however. It can be downloaded from here: http://rtkexplorer.com/downloads/rtklib-code/Here is a screenshot of my .ubx data converted using the main branch stable release v2.4.2 of RTKLib RTKConv vs the same data file converted using the RTKLib Test5 version above. Note how I have both L1 and L2 data when processed using the Test5 program. Also, my E31 and E36 sats are now showing whereas in the main release has a bug (No.141 Unable to handle data of Galileo E31 - E36 satellites) related to these sats so I guess the Test5 version solves this too.https://imgur.com/a/8pUaTd2On Ntrip for base initial position with data loggingI'm in the process of setting up a permanent base station so I can't give definite answers right now until I finish it myself but to answer your first question Section 3.5.7 of the ZED-F9P Integration Manual specifies what CFG items need to be set to set a base station into fixed mode. On Ntrip for base initial position with data loggingGreat! Thanks!On Supplying NTRIP corrections to simplertk+heading kitThanks, didn't realize I could connect via the POWER+XBEE USB connector (seems obvious now!). I'll try this tomorrow. Thanks again.On Supplying NTRIP corrections to simplertk+heading kitThanks! Good call with the adapter, hadn't considered going that route.On Answer for Supplying NTRIP corrections to simplertk+heading kitCrop
and 
