If you are using an M8N module, you may find the NAV_PVT example does not successfully parse any packets. Seems most M8N modules are using a newer version of the firmware in which the NAV_PVT message has an extra 8 bytes of data. Try adding this at the end of the packet definition struct: unsigned char dummy[8];
I don't know about this dummy bytes but i know there are dummy bytes issued to act as a buffer, because the MCU needs to determine the point of storage in the register. I am no programmer, but this is also to do with the mcu architecture and bus speed.
Nothing to do with 'bus' speed (UART is not a bus). The problem is that if you are expecting the wrong message length, you'll calculate the wrong CRC and never validate a packet.
plus i noticed one more thing, you coded to save code size but technically it would be best to create a separate code instructions to make the MCU to do more clock cycles per sec. I love the detail you give in the vids. Keep it up and all the best.
can you not amend this issue in your header file? Create a Base address and offset the difference? i am coding with a arm mcu, the dummy byte are included within my UART header.
Thank you for making this video. It saved me a lot of time. I specifically needed to know how to initialize the u-blox rover to send the message I needed.
SWEET!!! follow-up to the last video. Another great example of using the "struct" data type along with adding the "union". The ubx->cfg-msg is very helpful indeed! Thank as always.
Thank you so much for this explanation, the programming of the module is EXACTLY what I've been looking for for the project I'm going. Modified your 66 lines code from your previous video for an earlier version, now I can make it better. Thank you thank you thank you :D :D :D
I am setting up a uBlox module for a completely different purpose and was about to try and find out how to set the configuration from an Arduino - you have just saved me a ton of work. Thanks. BTW when this video started I immediately put it in full screen - I then kept clicking on the message bell because I thought I had 1 message waiting... doh.
Thanks so much for both of these videos. I was looking at using a GPS as the basis of a clock, and the ublox GPS has a very compact UTC message. I was able to do the NMEA-off, UBX-UTC-on directives, and following the ublox documentation and your video and code for reading the data blocks, was able to extract the NAV-UTC data the first time I tried it. My sketch starts with a default config ublox and prints the UTC time out to the serial port - 12% of program space and 17% of memory. Cool! One note - I was seeing warning messages about "warning: narrowing conversion of '181' from 'int' to 'const char' inside { }" for the UBLOX_INIT block. I wasn't 100% sure if it was chopping off the top bit, so I changed it to "const unsigned char UBLOX_INIT[] PROGMEM = " and the warnings went away. Thanks again!
Yes, 'char' is a signed type so it represents values from -128 to +127. I think assigning 181 to such a value will be ok if all you're doing is passing it around as data, but if you tried to use it for math it would of course not be 181 anymore. In any case, it's best to observe the 11th commandment God gave to Moses which says "Thou shalt not ignore compiler warnings".
Thank you; very useful info! Especially appreciate the configuration set-up as I develop on a Mac and really don't want to install Windows in e.g. a virtual machine just to run the u-Center tool.
you are my hero ! :D More stuff on this please, I would be interested in a complete implementation process you go through, aswell as how it would look on a Pi with i2c, UART and or SPI. I will try to adapt it myself, your Video is a gem. ;)
Yea…. I just commented on your original video years ago but now see that you found the programming from the Arduino already. Haha! Thanks for the video!
Finally got my Neo-6M working. Ended up having to use a SMA antenna which made a huge difference. The little built in one was not even picking up much when outside. (Now get 12+ satellites with a strong fix quite fast) For my clock, only need the UBX_NAV_TIMEUTC message so took out all except that one. When the need arises I will grab the long and lat etc. The RTC on my MCU drifts slowly so ~ every few days I will try and sync with GPS. It will also try and sync after being turned on. Have ordered 2 cheap Neo-7M modules so I can get the UBX_NAV_PVT message. Other thing that makes a difference is bumping the baud rate from 9600 to 115200. I left the rate at 1Hz as the code that gets the date and time waits for a new value in non-blocking code anyway.
Thanks for tons of information, these are definitely videos to come back and rewatch :) I might have missed it in the video, but did you do tests about whether the accuracy of the lat/lon values decreases when using higher update rates? If it doesn't, averaging over 10 samples could actually improve accuracy a little bit, I guess, right? So it might be worth trying even if you don't really need a higher update rate.
I think the accuracy would be the same, and yes, a little smoothing might help. But as for testing the absolute accuracy, there's really no 'correct' answer to test against. The best you can do is look at the aerial imagery on google maps and see if it looks about right - but those photos are not always so accurate anyway.
Hi, First I will thank for sharing this information! I followed your advice and ordered then M8N version of the GPS receiver and intend to use it’s ODO-function on an Arduino board. None of the Arduino libraries I have seen (including TinyGPS++) support this M8N ODO function. So it is great to see how you use the receiver without a library and there are no (library) limitations to use all functions. I wonder if you are experienced using the ODO information and how you did that. Can you advice me or do you have a link to read more about this? Best regards, Hans.
Thanks @iforce2d for the nice and clear description. Running through your code, there is one thing that I couldn't understand is the reason you use "continue" command in row 117 from your example UBX_GPS_MultipleMessages.ino. The way I see it is there is no needs for that command (already test without it), but maybe I'm overlooking about it. Can you perhaps tell me the reason on it?
True, it's probably not necessary, especially if the code never encounters an unknown message type. It just makes things a little clearer to the reader, that the following section of the loop should not be executed unless the message type is known, and avoids some unnecessary comparisons.
In case anyone was wondering like I was, if you want to send a string thats longer that gets split into multiple lines in u-center, you just combine them (kind of makes sense but I wasnt sure.) So ignore the ascii on the right and the first 4 digits with no spaces on the left, you only care about the stuff with the spaces in between it in the middle.
Got a new module as my M7 was no longer getting any real GPS data.... found and confirmed the antennae connecting it is dead as I'd always had problems with the connector. The new one is only a 6M but was able to verify TX and RX are working and the antennae has no crappy connector. Problem is inside it never picks up anything and after making a 3 metre extension to put outside it's still marginal. I can now use u-Centre to turn messages on and off and change the baud rate and frequency of updates etc. The new one I bought has a SMA connector so going to try that 1st. Also found the 6M does not have NAV_PVT available.
I know this is ancient history, but it's worth noting that the device will send back an ACK message (0x05) upon receipt of a configuration message. If you waited until that came in before sending the next one, you'd not have to put in delays.
Did you bump with such a problem? Somtimes, or after several hours of debuging, when you try to set settings(UBX) to GPS resiver. It don't get these settings and return NAV(default) messages or return NAV message and part UBX messages. Settings don't set clear. I use your src files. Use with neo-6m and 7m. It looks like there is some sort of buffer, settings that are full. Did you bump with such a problem?
Hello! Your videos are really very helpful. It all worked fine. Thank you! In my current project i need the '30.19.4.2 Multi-GNSS Raw Measurement Data' and its message stucture reads as follows: Header: 0xB5 0x62 Class: 0x02 ID: 0x15 Length (Bytes): 16 + 32*numMeas Payload: see below Checksum: CK_A CK_B I'm probably going to stumble over the length. Since I'm away over Easter, I start coding next week. Maybe someone here faced the same "problem" already. Have a nice day!
First of all thankyou so much for this video it helped a lot . I just wanted to discuss a problem that i encountered. i am usgin a stm32f1 bluepill with arduino.I enabled two messages NAV_PVT and NAV_DOP with the arduino code that you explained . set the rate to 1 Hz . I i tried to read the msg . I was able to read the NAV_PVT msg succesfully but the NAV_DOP message didnt seem to work . So i crosschecked all the struct data members and their repectives types but there wasnt a probelm with them . So i added a few instructions and found out that the checksum values for not correctly generated. So after doing more debugging i figured that the payloadSize for the struct was not correct. It is due to something called padding. you can read more about it ..... So long story short if you want to enable a msg check its payload first and then check if your your microcontrollers proccesing word size . For my case it is 4 bytes so if the payloadSize is not a perfect multiple of four it will not work. You can directly enter the payloadSize i.e payloadSize= 22(for DOP message) if you know the no of bytes used by your message instead of using " payloadSize=sizeof(NAV_DOP)
The message size is nothing to do with the architecture of the receiving microcontroller. More likely the UBX protocol version of the GPS just doesn't match the document you used for reference. The message contents don't change often, but they do change sometimes. For example, in v7 the size of NAV_PVT is 84 bytes: bit.ly/3cRSEdh But in v8 it's 92 bytes: bit.ly/3c6jgs4 Adding dummy space to the end of the struct is a clearer way to handle it, eg. see my pinned comment. Another issue you might come across when dealing with this stuff is that some compilers on 32-bit architectures do actually force 4-byte boundaries for struct size, which is not what we want here. To avoid that you can force structs to be packed, the method depends on the compiler. bit.ly/393qdIj Arduino is an 8-bit architecture so no packing was necessary for my original code. btw 22 is not a multiple of four....... :p
@@iforce2d I didnt say message size i said payloadSize . I am using M8n gps srry i didnt mention it earlier with a stm32f1 bluepill so the size of NAV_PVT i.e 92 and NAV_DOP i.e 18 is correct. I tried to say the same thing but i think you misunderstood . But rather than forcing the structs to be packed in a 2 byte boundaries I just hardcoded the payloadSize for Individual messages like NAV_PVT (payloadSize=96 ; // i.e. 92bytes +1 byte class id +1 byte message id + 2bytes length) and NAV_DOP (payloadSize=22; //i.e 18bytes +1 byte class id +1 byte message id + 2bytes length).lol...Ik 22 is not a multiple of 4 thats why i said NAV_DOP message was not working because the compiler was adding a 'padding' of 2 which makes the payloadSize 24 which is a multiple of 4. But the problem was that the checksum input from the gps was for 22bytes and the checksum calculated by the microcontrollre was for 24 bytes . Thats why i was getting checksum error.
iforce2d, Great tutorial!! I'm thinking of getting this GPS module, could you tell me what the average acuracy is in meters? I need acuracia of up to 1 meter. Thanks!
I would suggest to check the datasheet of any module you're thinking to get. They are usually stated to have around 2-3m accuracy, but in practice it's often a little better than that.
@@iforce2d With neo-6m and ground plane made with a can of cat food I have achieved precision of less than 48 cm to 5 cm using the u-center with laptop and the precision is much lower if I had used the ubx protocol and arduino due. The ubx protocol requires less processing time than nmea if you add the arduino due which is 32 bit and a speed of 84 MHz compared to the 16 MHz of the arduino uno. Greetings from Chile
Great, thanks for the extra tips. Very interesting that you can push info back to the u blox and limit the info. Now onto watching the next installment on the u blox 8. I'm hoping to measure distance using the GPS, but how do you eliminate the spurious GPS velocity/movement when you are stationary and not ignore real movement. I don't really want to use an IMU to negate this effect. There must be a way of making reasonable assumptions, maybe over 10 GPS readings/sec, the mean velocity every second is practically zero.
@@iforce2d Thanks for the tip, I've got a u blox 8 & comparing it to the u blox 6 using the u-center. You reminded me of the central limit theorem..The sampling distribution of the mean will have the same mean as the population mean. So I'll do some maths and more testing. Thanks
Thanks for your contribution. I am using a EVK-6T receiver to get POSLLH. However, it seems weird when I run your code. Some epochs it can decode UBX correctly, while other epochs output nothing. Can you help me out? Thank you!
Make sure that POSLLH is the only message being output from your receiver. This code cannot handle multiple message types. You might be interested in this follow-up: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-ylxwOg2pXrc.html
Thanks for you reply. Yes, I am using your multiple message version, and I have closed all other messages except POSLLH (I use a serial reader to check). I find the decoding process stops at the checksum every time. Just don't know where is my problem...
I find the problem. Your code can run on my Arduino Mega 2560 board, but it can't run on my Arduino Due board, may be due to the variable memory size of these two boards is different?
I did it now and earlier today. It seem that is generic for any of the protocols that has "NAV" is the description. I have the M8 and M6 GPS module. My MCU is very unforgiving on the registers. I would suggest using the HNR if you want to use the PVT, the payload is 72bytes with a very similar detail pack. I am writing a new header file for the HNR.
Hi, were you able to get rxm-raw messages out of neo6m? i tried to send enable rxm-raw by a line that i found online at forums but no luck. also some code differ between people seem to have been using and ucenter, is it a version thing. Thought all the messages should be backwards compatible.
I don't recall mentioning that in this video and have never heard of those messages sorry. I know that each new module generation adds new capabilities and messages, eg. the 6 series doesn't have NAV-PVT messages. I suggest to have a good look at the documentation instead of assuming some old code from forums should work :)
Is there something that should prevent the initialization routine from working within the NAV_PVT sketch? My GPS unit can be set from the UCenter program, but it resets to factory defaults after several hours. I would like my GPS reader to initialize to the NAV_PVT at 10Hz, during the setup. I've been trying to merge the two sketches, but haven't been successful. Is there a reason you have split this into two sketches?
That's odd... It is a 6, but I can see NAV_PVT message values in uCenter and I was getting a 3 for the fix type and the proper lat, lon and height values in the sketch. I'll have to dig a bit deeper into that (maybe there has been a firmware update to this unit?) At any rate, it seems I've got the sketches merged and initializing the GPS at every start. Now, I have to figure out why the I2C communication from the magnetic compass fails to reliably return 6 bytes (delivers between 10-100 reads and then hangs at while(Wire.available() < 6);.
Disable ALL messages? The u-center program lets you select a message category (e.g. NMEA or UBX) and Disable (all) Child Messages of the category with a single click of the mouse. But the code you provide seems to only disable individual messages, one at a time. Is there a way, via Arduino code, to disable ALL child messages of a category with just a single message out to the GPS device? Alternatively, when you turn a device off and back on and it resets to its default set of messages that it will send, is there a defined (limited) set of such messages that automatically get enabled, so that our Arduino can know which ones it has to turn off in order to assure that when it subsequently ENables the desired messages it can be assured of getting only those desired messages?
Regarding disabling all with just one command, I don't know if that's possible. The default is usually a handful of NMEA messages, but it might differ for various modules. After setting your desired messages you can tell the module to save the current config, so that it doesn't reset to the default: // UBX-CFG-CFG (save current config as permanent config) 0xB5, 0x62, 0x06, 0x09, 0x0D, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x1D, 0xAB
@@iforce2d Thank you. And thank you for taking the time to reply to comments, like mine, made years after the video is initially posted! :) That "Save current config as permanent" looks like it could be pretty useful, so thank you for posting that. I had looked for something like that on the u-center program but didn't see it. CAN that be done directly from the u-center? It seems like it could be handy. I'm surprised that it doesn't seem to be possible, from an Arduino or other user-developed program, to Disable All Children of a given message type or to simply disable everything. Either of those would be really helpful in setting up for receiving just particular messages.
Hi, I know it's an old video, thanks for all the helpful instructions! I am working with M8N module, which seems to send some messages, but it doesn't allow me to configure it. It just simply disregards whatever configurations I am sending to it. That's why basically your script is not working for me. Do you know what could cause this? Why doesn't it want to save any configurations? Thanks.
As the code comments suggest, the configuration code at the beginning of the sketch assumes the GPS will listen to a 38400 baud communication, and maybe yours doesn't. Try the previous video to see how you can use u-center to figure out what's going on with your module. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-TwhCX0c8Xe0.html
@@iforce2d After a bit of research I found out that my module was some chinese ripoff. so I bought myself a proper M8N module and it works flawlessly. Of course I did have to add a dummy placeholder in the structure. after that no problem at all. Thank you very much for your reply! And I appreciate your work a lot!
Aloha again, My project requires that I get highly accurate TIME information from the GPS unit, down to the millisecond. My overall setup will use a large number of GPS devices positioned around an area and they all need to be time-synchronized with one another. Many of the messages that come through from the GPS device contain an iTOW (Time of Week) value that by its definition provides values at that millisecond accuracy, but my experience with it makes me think that maybe it's not, maybe it's somehow defaulting to the "nearest second" based on the GPS device's own internal clock, because in general the milliseconds portion of the value is always 000 (when grabbing data at 1Hz) or 100, 200, 300, etc. (when grabbing at 10 Hz). I'm reading through the ublox documentation and it seems to me that it's saying that I can only acquire such high accuracy when the GPS device is stationary and I need to do some kind of Time Mode Configuration and do some kind of Survey-In operation. But it's all way too confusing for me. Have you done any videos on this, explaining how to achieve millisecond time accuracy from a GPS device? Or can you direct me to something that might help me do what I need to achieve? Mahalo (that's thank you in Hawaiian, I live in Hawaii! :)
forum.sparkfun.com/viewtopic.php?t=25061 electronics.stackexchange.com/questions/30750/why-do-gps-receivers-have-a-1-pps-output ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-cCPz8v85y88.html If you need faster pulses or at arbitrary timing, how about a local 'master' transmitter that sends a simple pulse, maybe like these: bit.ly/3rTvLvQ
I wasn't able to make it work with my NEO-M8N using a Arduino Mega with Serial2 for the GPS and Serial for displaying data. Changing the settings via the Bytes at the top of the programm worked for me. (I needed to edit a few, maybe this is some M8N change?) My goal of getting the speed in 10Hz is reached, but it kinda sucks to use NMEA with TinyGPS++ again :c Anyway, you helped me a lot with my current project, thank you! :) PS: the programm outputs absolutely nothing (the process-function is returning false), although the GPS is only sending the NAV-PVT packages..
im using the same setup and mine is doing the same thing. It looks like its failing the checksum. Did you ever figure this out. I found some data types that were different but even after chaning those it' still failing the checksum. I havnt found a way to compare the data coming out to my structured variables. I'm new at this.
Felix EFX I'm not using the tinygps++ library. I did it the way the video shows. I used the data variables and types out of the data sheet but I think I'm missing something. That's why the checksum keeps failing. I have a m8n with protocol version 17 and firmware 2.01
OHh and yes this affects every model of ublox receivers 5 and up, use the data sheet, yes it is slower and you have to manually calculate the checksum but its not so hard, but whats an hour if your 500$ drone does not do a "left go left for 9 miles miscalc", Ohh and the the binary output lag, I am sure some of you have seen the 5 second delay between movment and actual output.... swap to NMEA output to stop that, some of the USA / RUSSAN sat collaborative systems cause a hugely unacceptable lag in binary mode. fly well my fellow droners
Am trying to work this out using using ublox neo m8n. The NAV_POSLLH works fine, but the NAV_PVT doesn't work. setting up the module using the arduino also doesn't work. would you kindly tell me know what to do? Am on the way to building a gps tracker.
How do i workout the checksum. seems like that's the issue. i have noticed the NAV_POSLLH worked because it has exactly the same id and payload contents as that of neo 6m
I got it. The problem was with the payload contents. you have to replicate the number of reserves six times. i had to count the number of bytes to notice that. thanks though. hope i will get there
hi David, (neo-m8n), I check and check again the payload (92) bytes and still don't see nothing, I see data came from the serial, with Ublox PAM 7Q the Gps work fin, can you send to my email the program. my mail is: gaishaul@walla.co.il, thanks
Hello, I have some questions maybe you can answer me. When I connect the GPS to my arduino using the software serial example I get the NMEA data. When I add your config settings and send them to my GPS module I found out that when I disable all the binary protocols and only add the RMC I get only the RMC. Now I want to use your binary protocol for NAV_PVT but when I do that I only get data once. Using the other binary protocols I get data continuously. I was wondering if you could explain to me why my NAV_PVT doesnt work, maybe you had the same struggle. And yes I repower my gps every time I apply changes so the old changes are not there anymore. Thanks in advance.
+Peoplefighter189 I think I mentioned this in the video. If you enabled RMC then you enabled RMC, so you will get RMC until you disable RMC. If your sketch is expecting only NAV_PVT then it will fail when it gets a RMC. You need to explicitly disable things you don't want.
+iforce2d I tried first with RMC to check if its working but then I uncommented the RMC so its disabled and uncommented the ON for PVT and re uploaded to my arduino. Then I re applied power to everything and I was getting 1 line of data and then everything stopped. I tried the same with POSLLH and I got continuously data from that, but I want to use the PVT because it has all the information that I need.
@@iforce2d What I've done in my project is to set everything to default, as it is also possible in the UBX-CFG-CFG window. So, everytime I power on my arduino and gps receiver, it will first put the receiver to the default status, which is sending only NMEA messages. It should be this: 0xB5, 0x62, 0x06, 0x09, 0x0D, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x03, 0x1B, 0x9A, Hope this could help!
Aha, but if you have to access U-Centre to get the data (hex codes) you need, why wouldn't you use it to set the data packets you want sent in the first place? Just started to write my own code to display speed over the ground. Had to use a different msg packet of course (Nav-VELNED, 36 Bytes) and have written the structure for it. Given I'm not interested in processing the incoming data I just "imported" it all as chars to display later. (not yet tested this to see if it works) One question though, in the union statement will it only work if there are the same number of fields in each structure??? Cheers
+James Lamb Because that only works for one GPS module, and the change is permanent. Making a non-permanent change via the program at run-time means the end-user never needs to fiddle with any message settings, you can use a brand-new module right out of the box and it will work, and you can switch your GPS modules to any other usage and back without caring about how they are set up. There is no need to use the u-center app at all if you are game to read the datasheet and work out what the message should be, but it's a hell of a lot easier and less error-prone to just copy and paste it in (and much easier when making a video like this to demonstrate what the hell is going on :). The union just causes each member of the union to start at the same memory address, does not make any difference what the size of each member is.
+James Lamb If your GPS module is capable of NAV_PVT message you might like to use that, it has pretty much every value you'd typically need, including ground speed, heading, lat/lon, horizontal accuracy and fixType. I used it for my car tracker, works nicely.
+James Lamb There's also a different scenario where on-the-fly configuration can be useful. I accidentally removed the battery from my u-blox board (tried to replace it with a new one) and destroyed the solder pads. Without a battery (or with a discharged one), it doesn't save any configuration permanently.
I am getting an output from the multiple messages sketch but zero fixes. I tried the PVT sketch an didn't have any feedback on the serial monitor. Does this mean that I am at least communicating with the GPS board. My antenna might not be as good as it should be. Do you have any advice as to what to check?
Use the u-center app, it will let you check that the GPS is actually working, and whether it has a fix in the first place. After that you can expect to see useful messages. If in doubt about what the code is doing you can put debug logging in, that's what I often end up doing.
I have tried the sensor board with u-center and do not get any fixes. I am thinking that it is a problem with the simple antenna supplied with the board. Have you experienced poor antennas?
What can I say... just that I admire your c++ programming style. Everything seems easy looking your video. Full of interesting starting point... I must ask you one thing that is out of my understanding now. How can you read binary data where there is written "Lenght Bytes: 16 + 32*numMeas" Is your 66 line code already able to read also these kind of messages? It would be very useful for me to understand how I can read this messages. When the lenght is variable. I think that out there only you have the answer. Anyway thank you for opening this new door on UBLOX GPS. Bye xlettera
If the length is variable then the length must be given in the packet at the beginning so you know how many bytes to read before expecting the CRC check. These UBX packets have a 'packet length' member near the beginning: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-TwhCX0c8Xe0.htmlm38s
Thanks to your reply I have managed to read this kind of messages. Today's Xmas and you have made me a big gift. I wish you a merry Christmas and a happy new year. I am very interested in your project, I am doing the same thing in a different way and in the other side of the world. Thanks.
@@byxlettera1452 Hello XLETTERA, I'm currently trying to read the UBX-RXM-RAWX message from my NEO-M8P-2-11, which also happens to have this 16+32*numMeas length in the payload. Now, how do you read in the length before reading the packet? I understood that the length can vary, but I'm not quite sure how to implement this. Thanks for your help!
Arduino: 1.8.0 (Windows 10), Board: "Arduino/Genuino Uno" C:\Users\SUPER-PC\AppData\Local\Temp\Rar$DIa0.033\GPS_Speedometer\GPS_Speedometer.ino:9:20: fatal error: U8glib.h: No such file or directory #include "U8glib.h" ^ compilation terminated. exit status 1 Error compiling for board Arduino/Genuino Uno. This report would have more information with "Show verbose output during compilation" option enabled in File -> Preferences. Can somebody help me?
@@iforce2d thanks mate. I finally made it work following the instructions on the video. However, my goal id to get rid of ucenter. Il take a look at those lines. Cheers
Great video topic! I actually did the same thing for my boat project, if you remember me talking about that. I removed the battery from my u-blox board and destroyed the solder pads, because of that it won't permanently save the configuration anymore. I rematched your old video and ended up using a serial sniffer program to record the serial traffic from the u-center app and imported that into my arduino code. Only to figure out I could've gone a much simpler route... oh well. It's also useful for dynamic configuration, being able to adjust the GPS update rate in the micro controller code is nice: github.com/Bensge/ArduinoBoatTelemetry/blob/master/BTSender/BTSender.ino#L225 I made a tiny program to calculate the checksums on my computer too, if it helps anyone (practically mac only, sorry): github.com/Bensge/ArduinoBoatTelemetry/blob/master/Helpers/Checksum.swift And something else, why on earth did you use int as the return type of your processGPS() function and not the message enum directly? :P Cheers!
Apparently he does not work for me(UNO & MEGA2560),I do not get anything. in u-center Ublox n8m work very good void setup() {Serial.begin(9600); Serial1.begin(9600); }void loop() {if (Serial1.available()) { int inByte = Serial1.read(); Serial.write(inByte); } } I would appreciate any help eli
Nice Work man. But I had a lot of trubbel with it at first i thought I messset something up but now im pretty sure that my NEW ubloy neo 6m is a fake and that it dosaent work for me because of that. :( Now I wait for my next ublox module....
Hi thanks a lot for this tutorial. I think you are the only one who did an ublox raw data to ardoino tutorial. I am working with an ublox M8U (Untethered Dead Reckoning) and I want to use the NAV_PVT aswell as some M8U specific messages (internal gyroscope and accelerometer). Single POSLLH as well as multiple messages POSLLH and STATUS are working for me. I tried your NAV_PVT sketch, but sadly it does not work. I also tried to replace some "reserved" bitfields, like they are described in the M8U protocoll pdf, but still no output. I tired to add some serial debug messages, the code reconizes the header but still I am not sure about where the code stopped working. I am currently using an Arduino Pro Mini and different pins for the softSerial, I could try out HardwareSerial on an Arduino Due, but I think thats not the problem....
Firstly make sure that other messages are disabled, as I think I mentioned at some point in this video it's not enough to enable the messages you want at startup, you should also disable the defaults and any others you have been using recently. Most likely the struct you're using has the wrong size. You could make a simplified sketch that merely looks for the headers and counts the bytes between them, and check that it matches with sizeof the struct you're using. A common mistake is to misread the datasheet number format U1[6] which means an array of 6 bytes, not 1 byte. You could also try to figure out what firmware version your module is running, because the size of message packets sometimes changes with new firmwares, eg. NAV-PVT payload goes from 84 bytes in v14 to 92 bytes in v15-19: goo.gl/MH28Jr goo.gl/jnCa61 fwiw this question has come up about six times already in these comments and it has always been struct size.
Thank you for your fast answers. I am sorry, I couldn't test it until now. I once again picked your original NAV-PVT sketch, changed the bottom part to the newer bytes from the manual and this time using 6 bytes (unsinged short followed by unsigned long) for the U1[6] reserved block. Now everything works perfect for me. I misinterpreted the U1[6] as you said....Sorry I read through a lot of comments but I must have missed this. Thanks again for your patience.
I have a good gps lock but the lat and long paquets are limited to 4 byte according to the datasheet, and after verification the long variable pvt.lat ant pvt.lon are 4 byte long. By the way your program and videos are very good :)
Unless I'm mistaken the lat/lon values are always four bytes, in other messages too. They are in units of degrees * 10,000,000. This is at worst (at the equator) a resolution of around 1cm, which is finer than you could expect the module to function at. I don't see the problem.
Looking at the "Serial.print(ubxMessage.navPosllh.lon/10000000.0f);" line I only get 2 decimals. I tried "Serial.print(ubxMessage.navPosllh.lon/10000000.0f,7);" and get seven decimals but the last 2 decimals comes out wrong. Anyone with a solution?
Emil first you need to explain the problem... what is 'wrong' with the last two digits? Do the integer numbers look correct before you do this division?
HELLO, I cannot solve the problem so I need your help please, I use the program(NAV_PVT) with Adafruit 32u4 Lora the program run perfect, but the memory of 32u4 is very low so I use the Adafruit MO. the SoftwareSerial is not in use with Adafruit MO instead we use sercom learn.adafruit.com/using-atsamd21-sercom-to-add-more-spi-i2c-serial-ports/creating-a-new-serial. I use the example of adafruit works fine. I made the necessary changes but still i don’t get nothing from GPS. Maybe you can help please, thanks eli
I don't know what Adafruit MO is sorry. The method used in this video (explained more in the previous video ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-TwhCX0c8Xe0.html) uses about as little memory as possible. I don't think the memory footprint could be any smaller...
ah, I see, the M0 is a type of board, but has no software serial. You can use a normal serial and it will work the same. Basically you just need to be able to check if there is any incoming data (eg. available() function) and then read one byte (eg. read() function). I can see those functions in the link you gave so I don't think there should be any problem. The reason I use software serial in my videos is so that I can use the normal serial (ie. usb connection) to output to the serial monitor.
Thanks for your response, about the memory I want to combine your code into a larger program so the Adafruit 32u4 Lora does not fit. I am quite new in arduino and C++ language, so for the experts to solve problems it's easy for me it's harder.
HI, just be REALLY REALLY careful of using ublox message centre for creating your hex strings, we just spent 20 hours working out that some of the commands the message center shows are utter bullshit compaired to the datasheet, in my case is was setting a uart to 19200 buad it gives an output that would wonderfully with a PC linked but many less "powerful"UARTS on MCU's loose frame lock and you end up with garbage for half your message, I actually pointed this out to ublox and they said, and I quote " well nothing is perfect is it sir." end of phone call..... UBLOX sort your control center out, people's expensive drones crash cause you cannot be arsed to do QC!
So your problem was that the MCU you were using was not fast enough to receive 19200 baud data from the GPS module? That's not what I would call a fault of the GPS module. Were you using a software serial? I have found that an arduino has a hard time using software serial even with 9600 baud, let alone 19200, especially if it's doing other tasks at the same time (which it usually is, otherwise you would probably not be using software serial).
No, not at all worked all the way up to 900k just fine, just some of the config bits(and thus hex values) produced by ublox center are not the same that woul get manually from the data sheet
You seem to be contradicting yourself. Did it work on 'less powerful' MCUs or didn't it? Maybe you have a faulty module. I doubt what you are seeing is the norm - people trust their lives to these modules. I'm sure if you can come up with a reproducible test case they will have a look.
The problem seems to come from some "HARDWARE" uarts on certain MCU's that have.. well lets say less than perfect timing hardware, you would not use such a unit in a commercial airliner for sure, but for mass market stuff, yes they get used, the error did not show itself on a PC with a sparkfun USB/rs232 converter, or a dedicated serial monitor by Fluke, but it did manifest as a classic frame error on the MCU in question when a single config bit was different from the data sheet compared to the ublox center output, we probably only use 250k ublox chips a year so I doubt we are classed as high up the chain when reporting an error they cannon reproduce without a specialist MCU (floating point heavy). As I mentioned 2 professors of computing and a GPS specialist were on this for a day and only found the one bit mistake at 8pm on friday. It would probably not effect an microchip or atmel mcu, but on this one it did, just so strange that 1 bit on one unrelated byte cause it.
