Please see all COVID-19 updates here as some shipments may be delayed due to CDC safety and staffing guidelines. If you have an order or shipping question please refer to our Customer Support page. For technical questions please check out our Forums. Thank you for your continued support.



Member Since: November 1, 2012

Country: United States

  • I purchased 2 of these GPS units for a class QuadCopter project. We've learned the following along the way:

    • The GPS is a 3.3V device. You will want / need this FTDI breakout board to safely configure your GPS.
    • Click here to download MiniGPS, a great utility for configuring the GPS...including turning off and on GPS sentences, changing frequency, changing baud rate, etc. This will save you the hassle of trying to figure out all the $ commands, calculating checksums, etc.
    • You will want this TinyGPS++ library to integrate data from the GPS into your project. See the sample code in the library's examples folder.
    • We had trouble getting the GPS to get a fix and start producing data. There is a "hot start" command that tells the GPS to use the previously downloaded nav data (almanac, etc.), which will produce a fix within a couple seconds.
    • If you're using a 5V arduino (Uno, etc.), you can only receive data from the GPS, but you cannot send commands as you risk frying the GPS. If you're using a 3.3V arduino (Fio, Due, etc.) you can send commands to the GPS from within your programs, including the hot start command. The code below will send the hot start command to the GPS (Note: use println so the required <CR><LF> is automatically appended at the end of the command.)

      gpsSerPort.println("$PMTK101*32"); //hot start GPS

    • Software serial on our Uno board could not keep up with the default 57600 baud rate. We used MiniGPS to turn off all sentences except GGA and RMC, to reduce the update frequency to 1Hz and to reduce the GPS baud rate to 9600. With those settings we were able to get software serial to work.

    • We're looking at using a Due board going forward because 1) it is a 3.3V board so we can send commands to the GPS and 2) it has multiple hardware serial ports so we can attach the GPS to a hardware serial port and increase the data rate from the GPS.
  • Thank you for the shout out. My partner, Mike Milham, also deserves a shout out; he's been doing some amazing work with our students using Arduino boards.

    I agree with sgrace's comment about students first, and teachers second. I've learned a tremendous amount about electronics from SparkFun's website and SparkFun's great people like Jeff, Casey, Allison, and the many others in tech support. I've then tried to share that knowledge with my students, and coach them as they've done some very creative projects.

    I also appreciate SparkFun's fast order processing! Finally, we're excited about our partnership with SparkFun to introduce Redbots into our classroom next year as the platform for our robotics program.

  • The guide shows only connecting 2 wires to the whisker (bumper) sensors (signal and ground). I hooked my robot up that way, but instead of using the RedBot library to read the sensors, I was using a digitalRead. I got very spurious results. I hooked the two wires to an analog input and found that when the bumper was pressed I got a clean 0V (GND), but when the bumper was not pressed the values were jumping all over the place, which explains why I was having problems.

    When I added a 3rd wire to the center post on the sensor (5V) and connected that the 5V on the robot it cleaned things right up. Obviously the sensor doesn't have a positive voltage reference when the 5V wire is not connected. Perhaps the Redbot library functions for those sensors handle those spurious signals (perhaps because they use an interrupt that looks for a falling signal).

    As a teacher, I don't want my students depending on libraries right out of the chute; I want them to understand what the sensors are doing, and various approaches to using them (digitalRead, interrupts, etc.) Therefore, my recommendation is to change the instructions and have users connect up all 3 wires to get clean results no matter what code they're using or writing. Can't hurt (but costs you 2 more wires).

  • Here is my calibration for the sensor in inches.

    Calibration of Infrared Proximity Sensor Long Range - Sharp GP2Y0A02YK0F
    SparkFun Part#: SEN-08958 https://www.sparkfun.com/products/8958
    By Robert Hazlehurst, Castle View High School robert.hazlehurst@dcsdk12.org
    for use on RedBot Robot SparkFun Part#: ROB-12032 https://www.sparkfun.com/products/12032
    with RN42-XV Bluetooth Module - PCB Antenna installed in the Xbee port SparkFun Part#: WRL-11601 https://www.sparkfun.com/products/11601
    Distance (in inches) = 6202.3*SensorReading^-1.056 fit with an R² = 0.9914
    Raw Data: 
    Sensor          Distance (In)
    502         8
    434         10
    379         12
    329         14
    283         16
    257         18
    229         20
    213         22
    199         24
    139         36
    91          48
    #include <RedBot.h>
    RedBotSoftwareSerial bluetooth;
    float sensor;
    double distance;
    void setup() 
      Serial.begin(9600);  // Begin the serial monitor at 9600bps
      bluetooth.begin(115200);  // The Bluetooth Mate defaults to 115200bps
      bluetooth.print("$");  // Print three times individually
      bluetooth.print("$");  // Enter command mode
      delay(100);  // Short delay, wait for the Mate to send back CMD
      bluetooth.println("U,9600,N");  // Temporarily Change the baudrate to 9600, no parity
      // 115200 can be too fast at times for NewSoftSerial to relay the data reliably
      bluetooth.begin(9600);  // Start bluetooth serial at 9600
    void loop() 
      sensor = analogRead(A3); //read the sensor
      distance = 6202.3*pow(sensor,-1.056); //apply cal curve to convert to inches
      bluetooth.print("distance = "); //print distance to cell phone screen