Can't change baud rate on Ublox GPS

Hey everyone, I ordered the APM 2.5 with the Ublox (Lea-6H) GPS module, and I am writing my own custom code (C++ using AVR Studio) to integrate with the hardware on the APM.

 

So far, I have successfully integrated with the Barometer, IMU (gyro, accelero), Magnetometer, and to some extend the GPS, but I can’t get the GPS to change its baud rate.

 

I am able to send and receive data to and from the GPS using both NMEA, and UBX protocols including changing the output rate on a variety of messages (PUBX 40), polling for (reading) the configuration of the GPS’s ports (CFG-PRT), polling for the position in ECEF (NAV-POSECEF), and reading latitude/longitude (GPQ with RMC as the sentence identifier). The point is I’ve been successful at doing a lot of things with this GPS.

 

But for over a week I’ve been trying to change the baud rate to ANYTHING other than 9600, but it always seems to be stuck at 9600. Even if I execute CFG-PRT to set it to 38400, and then poll CFG-PRT (with the cpu’s baud rate still set to 9600 (because otherwise I wouldn’t be able to read the response)) it says that the baud rate is still set to 9600. And even though I get an Ack for a variety of other UBX commands that I send, I don’t get an Ack or a Nack for the CFG-PRG command. (Actually, if I try to set the baud rate on the GPS for serial port 2, I think at one time I got a Nack, but I didn’t investigate the cause, it could have just been an invalid command)).

 

Is the baud rate ‘read only’ on some Ublox GPS’s?

Should I be trying to set the baud rate on the GPS’s serial port 2 instead of serial port 1?

What am I doing wrong?

 

Here is an example of the command that I am sending to the GPS (I generally generate my commands from U-Center). 

 

byte portCfg[] = {0xB5, 0x62, 0x06, 0x00, 0x14, 0x00, 0x01, 0x00, 0x00, 0x00, 0xD0, 0x08, 0x00, 0x00, 0x00, 0x96, 0x00, 0x00, 0x01, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x8B, 0x54};

 

 

Thanks,

Rick

[Edit] Btw, my code that is running on the APM communicates with the GPS (on USART 1), and then forwards that data to an app running on my laptop over the provided APM 2.5 USB cable (just in case there is some kind of power issue with running the GPS off of the APM 2.5 when it's being powered by USB)

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

  • So after another two days of trying to change the baud rate, the baud rate still doesn't change. I have at least verified that I don't get an 'ack' back after trying to change the baud rate.

    Does anyone have any c code examples that I could run a test against real quick to change the baud rate on a ublox lea-6h that I can use to test against?

    Thanks

    • This is just crude snippet.

      You will have to adjust it to your needs but maybe its helpful ...

      I had most problems caused by doing things too fast, so a delay here and there  - suddenly makes your code work. And delay upon init doesn't hurt. Give the GPS at least a second after system powerup to settle/initialize before bombarding it with serial commands.

      This code will send the wanted baudrate setting string at different serial port speeds to the gps, because the serial speed of the gps on power up may be unknown. At the end of this loop ublox should be running at the desired baudrate - if it is not responding - bad luck. I tried that code on several ublox6 and it never let me down so far..

      ...

      const  uint32_t init_speed[5] = { 9600, 19200, 38400, 57600, 115200 };

      ...

      void UbloxForceBaud(uint32_t baud)
      {
          uint8_t i;
          for (i = 0; i < 5; i++)
          {
              delay(50);
              uart2ChangeBaud(init_speed[i]);
              delay(250);
              switch(baud)
              {
              case 19200:
                  gpsPrint("$PUBX,41,1,0003,0001,19200,0*23\r\n");
                  break;
              case 38400:
                  gpsPrint("$PUBX,41,1,0003,0001,38400,0*26\r\n");
                  break;
              case 57600:
                  gpsPrint("$PUBX,41,1,0003,0001,57600,0*2D\r\n");
                  break;
              case 115200:
                  gpsPrint("$PUBX,41,1,0003,0001,115200,0*1E\r\n");
                  break;
              }
          }
          uart2ChangeBaud(baud);
          delay(200);
      }

      static void gpsPrint(const char *str)
      {
          while (*str)
          {
              delay(7);
              uart2Write(*str);
              str++;
          }
          while (!uart2TransmitEmpty());                                                  // wait to send all
          delay(30);
      }

      • Excellent! Thanks for the reply. I'll give it a shot and see how it works.

        • I guess it's working on your side :) . BTW you can also use the Arducopter or Autoquad Ublox libs. I would look at both and also look at Autoquads ublox 7 part :). They are of course more flexible and calculate checksums, switch the speedcalculation model etc. As long as you are going for a specific ublox series you can do hector's sniffing method described in his post. You will end up with a config block that can be transferred like mwii does here: https://github.com/multiwii/baseflight/blob/master/src/gps.c#L29 .

          Note1: I find it useful to activate "Pedestrian". That will add the following lines to the beginning of the config block:

          #ifdef Pedestrian
              0xB5, 0x62, 0x06, 0x24, 0x24, 0x00, 0xFF, 0xFF, 0x03, 0x03, 0x00,
              0x00, 0x00, 0x00, 0x10, 0x27, 0x00, 0x00, 0x05, 0x00, 0xFA, 0x00,
              0xFA, 0x00, 0x64, 0x00, 0x2C, 0x01, 0x00, 0x3C, 0x00, 0x00, 0x00,
              0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x4F, 0x82,
          #endif

          Note2: SBAS support may be problematic in Australia (disturbed by Japanese SBAS system - as far as I know)

          Cheers

          Rob

          multiwii/baseflight
          32 bit fork of the MultiWii RC flight controller firmware - multiwii/baseflight
        • Have you tried just doing it in u-center ?, i had a go today and it seemed to work fine.

          i just went into messages view -> CFG - > PRT and changed it to 4800 from 9600 , unpluged and restarted u-center then checked it and dumped the logs without error.

          failing that try something man-in-the-middle ie use an arduino and hardwire uart1 of gps with softwareserial lib to see what ucenter is sending the gps then you can copy it,, or there are some serial programs that can intercept and display data but not all are equal nor free nor do they all work on 64bit ect ect. thats why i use hardware sniffers.

This reply was deleted.

Activity