Novice with GPS venus Sparkfun Venus638FLPx

it works perfectly.

Oh, good. There is a problem with the OVERRUN flag, but I could not find any other problems.

Were you using one of the NeoxxSerial libraries in reply #18? Which one? What pins?

What Arduino are you using?

I'll need answers to those questions before suggesting anything else. Well, sampling the IMU @ 100Hz will require using the FIFO.

I am PhD student at University in France. I work on motorcycle active safety systems...

Neat project! You're doing very well for a beginning programmer.


Hello /dev,

As I said with real SD card it works:


I just used your serial library every time. Seeing warning in comment about the basic serial one I didn’t use it!
I am using NeoHWSerial library in addition with the NeoGPS one.

My board is an Arduino Mega 2560 (I have also a genuino 101). I don’t know if it will be enough from performance point of view maybe buy an Arduino Due? What do you think?

The GPS is wiring to the board as following:
GPS Pins -> Arduino Mega 2560 Pins
3.3V -> 3.3V
Tx -> Rx01(D19)
Rx -> Tx01 (D18)

To complete the features of my project, I would like validate a mathematical model of a scooter. To do it I need to acquire on a SD card:

  • Inertial data at the center of gravity -> IMU (100Hz)
  • **Steering angle **-> Not yet fixed but probably a 10 bits optical absolute encoder or a second IMU on the steering column but I am scared of the noise and of the accuracy of the measure for the IMU solution (100 Hz)
  • Wheel speed (front & rear) -> ABS sensors (100Hz). I have removed the sensors from the scooter and I will test it today or tomorrow at the laboratory. It seems to be active 2 wires Hall effect or magnetoresistive sensors. I will just unplug the connector for the test it will not a definitive solution!
  • Position, Speed -> GPS (20HZ). Done with your help!

Thank you for your positive comment and your help it is good for motivation!

Have a good day,

I would suggest adding the “loggingTime” to the SD file. This will help you determine this part of the time “budget”. Line 248 in the original NMEASDlog.ino

      logfile.print( lastLoggingTime ); // write how long the previous logging took

This assumes lines 217 and 299 are still there, too.

Like I said, the IMU has a FIFO, so it can accumulate samples while the Mega is busy.

You’ll have to know the pulse rate for the wheel sensors at the max speed (Pin Change interrupt rate), and how long it takes to get a reading from the steering encoder (SPI? I2C? Digital pins?). That will determine whether you need multiple processors, a faster processor, or some external counting hardware for those devices.

It’s not hard to achieve 100KB/s or 200KB/s logging, so the the SD writing isn’t going to be a problem.

NeoGPS uses < 1ms per update for parsing, so that’s only 2% of the CPU time… no problem there, either.



I have added « loggingTime » as you suggest. Today, I have performed a little test with car when I went to university. The location results seems very coherent (attached picture). About speed, I have used the default “speed” data but after the test I have realized that if I want acquire the speed in mph I have to change “speed” to “speed_mph”. What is the unit of “speed”?
Just one remark, I have checked “loggingTime” data and max is 10 ms. Is it coherent?

For embedded applications as in my case, it is more convenient to have a hardware switch button to launch data acquisition. I don’t know how to properly do it because I guess that each time the button is on “ON” position I have to setup and calibrate all the sensors: GPS, IMU,….
Can I use the reset?
I was thinking to create a loop reading a digital input (HW button). First time it is true I start the program and then for the second, third, I reset the code each time it is switched.
Maybe another suggestion?

Did you know an interesting tutorial about FIFO programming?
About WSS (wheel speed sensor), I am a little bit afraid of my calculated results #3 (ABS_SENSOR). For the moment I am trying to exploit the native ABS sensors but it is not so easy without the datasheet.

About steering sensor, I don’t have a fixed solution yet. I am thinking to buy a low cost 1024 absolute encore like this one (ENCODER) but I am sceptic about measure accuracy. Did you have any experience with this kind of encoder?

Thank you,

Image embedded for our convenience:


…just like reply #3

What is the unit of “speed”?

From the Data Model page:

a speed, accessed with
* fix.speed_kph(), in floating-point kilometers per hour
* fix.speed_mph(), in floating-point miles per hour
* fix.speed(), in floating-point knots (nautical miles per hour)
* fix.speed_mkn(), in integer knots, scaled by 1000
* fix.spd.whole, in integer knots
* fix.spd.frac, in integer thousandths of a knot, to be added to the whole part

Declarations for these member functions of gps_fix here.

I have checked “loggingTime” data and max is 10 ms.

That’s very good, and a little surprising. Next time you post the sketch I’ll review that part of the code to make sure it is really including the SD write time.

each time the button is on “ON” position I have to setup and calibrate all the sensors: GPS, IMU,….

If I understand the question, you can just let setup initialize all the sensors like it does now. When you add the ACQUIRE switch, don’t open the SD file in setup. Just initialize the SD card.

In loop, when the switch is turned on, pick a filename, open it and set a flag. Guard all the logfile.print code with “if (flag) {”. Everything else always runs; just don’t write the data to the file.

When the switch is turned off, close the file and clear the flag. You could use the Bounce2 library for debouncing your ACQUIRE switch or roll your own with information from here, here or here.

I would not reset the Arduino with the ACQUIRE switch.

Did you know an interesting tutorial about FIFO programming?

Another user was trying to “poll” for the samples, and he eventually switched to letting the IMU generate regular samples into its FIFO. The sketch watches for the IMU INT pin to change, then it reads all the available samples from the IMU FIFO. I found his sketch here, but google is your friend, too.

You may not have to wait for the INT pin if you just empty the FIFO every time a fix arrives.

About WSS (wheel speed sensor)…

If your opamp turns it into 1KHz pulses (max), counting that is reasonable with a 16MHz processor. However, you would have to make sure that interrupts are not disabled by other parts of your sketch for longer than 1ms (a little less to make sure you don’t miss a pulse). Your current sketch is probably ok. This might be a good place for a digital counter/divider. It will be an epic data acquisition at 110km/h.

About steering sensor… Did you have any experience

I do not.


Hello dev/,

Don’t hesitate to say me when I am doing wrong!

fix.speed(), in floating-point knots (nautical miles per hour)

I didn’t have time to do another test but the scale of the speed in kmph (1.852xspeed) is a little bit strange. Also the sample rate seems to be longer than 20 Hz, we can see the variation steps on the graph:

That’s very good, and a little surprising. Next time you post the sketch I’ll review that part of the code to make sure it is really including the SD write time.

You can find the sketch attached(to long to be embedded).

I have read some forums and some examples about FIFO but I didn’t understand if the FIFO hardware “buffer” is include in the MPU or in the Arduino. Considering the first case I am not sure that BNO055 supports FIFO programming.
I will spend more time tomorrow to read more about it.

Thank you,

NMEASDlog_PM.ino (13.5 KB)

the scale of the speed in kmph (1.852xspeed) is a little bit strange.

By "strange", do you mean you're not sure about converting nautical miles per hour (knots) to kilometers per hour? (ref here)

Or are you questioning the speed value reported by the GPS? Speed has "jitter", just like the latitude and longitude. And the speed is not very good below 5kph. When stationary, you will get random speed values up to a few kph. Wheel sensors are much better for that, unless they're slipping. o_O

Also the sample rate seems to be longer than 20 Hz

I'm not sure what the graph is showing.

If the x-axis is 20 seconds per tick, there isn't enough resolution to see 400 updates. The "stair step" jaggies could be the way you are plotting it, or it may be that the GPS does not update the calculated speed more than once per second. Maybe you should show us some of the raw data from the SD file, and tell us which values are not what you expected.

I didn't understand if the FIFO hardware "buffer" is include in the MPU or in the Arduino. Considering the first case I am not sure that BNO055 supports FIFO programming.

The FIFO should be in the chip so you (1) don't have to ask for every sample, and (2) you don't have to ask for a sample at an exact time. I have only looked at the MPU6050 IMU, not the BNO055.

After a quick look at the chip spec, I see that it does not have a FIFO for storing a series of readings, but it is taking the samples automatically for you (i.e., at an exact time). You just have to make sure you read them before the next sample is taken (10ms).

The SD write time could interfere with this, so you may have to implement the function, yield. It is called from inside the SD write. It's a way to let "other things" (IMU read) happen when "one thing" (SD write) is waiting ("blocked"):

void checkIMU()
  // If any IMU reading are available, get them now
  //   (save them for later, to be written to the SD with everything else)

// This is called while the SD write is busy
//     NOTE: Make sure that no SD methods can be called from here!

void yield()

Then checkIMU can also be called from loop.



Sorry my question was not so clear. I mean by "strange" that when I went to the university by car, the speed was varying from 0 to 70 kmph. On the speed graph attached previously the scale factor is 10^-6 kmph...

Thank you for having spent some times to read the BNO055 datasheet. I am going to continue the project by adding a Button and the IMU.

Have a good day,

Ha, I just looked at how you are writing speed and heading:

      printL( logfile, fix.speed_mph() );
      printL( logfile, fix.heading() );

The utility routine, printL, is really for the long integer lat/lon values that are scaled by 107. You can just print the speed and heading as floats:

      logfile.print( fix.speed_mph() ); // defaults to 2 decimals
      logfile.print( fix.heading() );

That explains the quantization “jaggies” and the weird scale.



It works perfectly thank you.
During the weekend I just have time to add the hardware switch following your previous advices and it works. My sketch is attached maybe it could help someone. I use a hardware solution to debounce the switch:

There is just a problem on the first acquisition. When you switch the button for the first time, the acquisition is normally launched but when you see the data file there is an issue with the starting time of the acquisition. Take a look at the fist and the second lines:


Do you have any idea about the source of the problem?

Thank you,

NMEASDlog_PM_v4.ino (14.3 KB)

Another idea is to add an adafruit TFT 2.8 screen to display dynamics data. I need some help about multiple slaves management. To avoid the post of the same topic please find the link below redirecting in display section:

I would like to know what is the best way to proceed in order to display data without interupt data saving process?

Thank you very much,

Do you have any idea about the source of the problem?

That could be a NeoGPS bug, perhaps related to FIX_MAX and OVERRUN. I'll take a look...

Hello dev/,

I have hard difficulties trying to add other sensors at 100 Hz and 1 kHz. I am trying to mix GPS (20 Hz), IMU(100 Hz), encoder (100 Hz) and hall effect sensor counter (1000 Hz). I hesitate between 2 programming schemes:


I guess no matter the considered scheme I will have interruption problems with SD writing process. Is there a best way to do?

Thank you,

I don't know what the chart is showing, or why you think there are "interruption problems". None of the sensors require "immediate" service:

  • I would suggest putting the Hall Effect Sensor on one of the Input Capture pins. This will record when the HES changed/pulsed, according to the TIMER you set up. You only have to read that recorded value before the next HES change (1ms @ 1KHz, usually much less than that). You could use an interrupt to save that recorded time in a queue for later use (just like Serial does with characters).

  • The IMU will generate one new fix every 10ms, and can be read anytime within that window.

  • The encoder can be read whenever you want.

  • The GPS generates one new fix every 50ms, but it will buffer 4 fixes (or whatever you choose) until you can read them. That gives you 200ms window before a GPS update is lost.

With these windows, I think there is plenty of time to gather and record the data. Because the SD write could be longer than some of these windows, you will have to write the yield function as I mentioned in reply 26. Your yield function is almost like loop, except that you can only save data for later use, while the current data is being written.



I am realizing that the PPS pin of the GPS doesn't send any signal. I am not able to make it work....

After having read the data sheet of the GPS, I saw :

Hence I try to send the following message to the GPS:

   // PPS message:
   byte PPSmessage[] = {0xA0, 0xA1, 0x00, 0x03, 0x3E, 0x01, 0x01, 0x3E, 0x0D, 0x0A};  
   gps_port.write( PPSmessage, sizeof(PPSmessage) );                                  

but nothing changes.

Is there someone who has ever had a similar problem?

Thank you in advance,

I made a simple arduino programmer file that will help you set this up without the FTDI board:

Note that you can not upload/change firmware using the arudino, this is only possible with the FTDI board