Problems getting 10hz

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
  • #16105

    Hi, I’ve spent ages going round in circles on this one.  Any advice appreciated!

    Goal: To power the pi on, and gpsd to be automatically configured for 10hz rate.

    What does seem to work:  Following the page to configure ser2net, and setting baud+rate via U-Center.  Then disconnecting, starting gpsd.  However this seems to only last until I disconnect power from the Pi?

    What doesn’t work: Everything else!  I’ve tried the echo commands on the FAQ to set baud, rate.  Tried gpsctl -c 0.1 -b 115200.  Tried stopping/starting gpsd.  It seems to stay at 1 update per second.


    Any advice most welcome – I appreciate it’s a little bit of an open ended question but my attempted analysis is reaching a dead end.


    Right all this seems to be down to trying to use gpsd as well…

    As I as only doing “gpspipe -r” to file I’ve dumped it in favour of cat /dev/serial0 to file, and it seems to be hanging together with the FAQ commands running on start-up.



    I have the same issue!

    I have a BerryGPS-IMU connected to a Raspberry Pi4; everything works very well. I am using Pyhton code, using your examples. I would like to to increase the NMEA sentence update rate to 10Hz. Nevertheless, I am a little bit confused/lost on how to do it.

    Using the FAQ ( I understand that, when increasing the update rate, I will also need to increase the baud rate

    With the basic program provided with the BerryGPS-IMU and using the baudrate of 9600, everything works well and I am able to recored the NMEA frame.

    So, to change the baud rate to 115200, I typed the following in a terminal:
    echo -e -n “\xB5\x62\x06\x00\x14\x00\x01\x00\x00\x00\xD0\x08\x00\x00\x00\xC2\x01\x00\x07\x00\x03\x00\x00\x00\x00\x00\xC0\x7E” > /dev/serial0
    stty -F /dev/serial0 115200

    then, from the same terminal, I launched my python program, on which I have changed the line of code, from:
    ser = serial.Serial(port, baudrate = 9600, timeout = 0.5)
    ser = serial.Serial(port, baudrate = 115200, timeout = 0.5)

    It didn’t work; the GPS is working, but the $GNRMC sentence, the time stamp is always every seconds.

    So, I tried the following, with minicom. In detail, what I did:
    sudo killall gpsd
    echo -e -n “\xB5\x62\x06\x00\x14\x00\x01\x00\x00\x00\xD0\x08\x00\x00\x00\xC2\x01\x00\x07\x00\x03\x00\x00\x00\x00\x00\xC0\x7E” > /dev/serial0
    echo -e “\xB5\x62\x06\x08\x06\x00\x64\x00\x01\x00\x01\x00\x7A\x12” > /dev/serial0
    stty -F /dev/serial0 115200
    minicom -b 115200 -o -D /dev/serial0

    And minicom is showing me NMEA sentences (below). However, when looking at the $GNRMC sentence, the time stamp is always every seconds; I was expecting a time stamp something like 144941.00; 144941.10; 144941.20; 144941.30, but not 144941.00; 144942.00; 144943.00, etc…

    Any idea where I am doing wrong?

    Any one expert could confirm me that my step by step actions to increasing the GPS update rate is correct? or point me in the right direction?

    Thank you so much!




    Mark Williams

    What you are doing above is correct.

    I just tested, using your commands;

    echo -e -n "\xB5\x62\x06\x00\x14\x00\x01\x00\x00\x00\xD0\x08\x00\x00\x00\xC2\x01\x00\x07\x00\x03\x00\x00\x00\x00\x00\xC0\x7E" > /dev/serial0
    echo -e "\xB5\x62\x06\x08\x06\x00\x64\x00\x01\x00\x01\x00\x7A\x12" > /dev/serial0
    stty -F /dev/serial0 115200

    And did a cat on serial0, filtered on RMC and it works.

    pi@raspberrypi:~ $ cat /dev/serial0 | grep RMC

    Is gdps still running in the background? try and kill it first
    sudo killall gpsd

    Mark --


    Hello, I have the same issue!

    Did you fix your problem?  I think I fixed this by having a repeated message send until I received an acceptable response.  Scheduling this to run automatically varied in success vs running the commands manually one off.  This seems to be working correctly for me now.  Let me know if you want me to check my code.

Viewing 5 posts - 1 through 5 (of 5 total)
  • You must be logged in to reply to this topic.

Blip, blop, bloop…