|
|
$65.00 ea
IN STOCK
|
|
SKU:
DSSC-0104
|
|
DIMENSIONS:
2.05" x 1.70"
|
Now also available for sale at Dipmicro Electronics
|
FEATURES
- I2C communication up to 400 kHz
- 66 Channel GPS receiver
- 10 Hz update rate
- Ultra Sensitive -165 dBm GPS receiver
- Optional serial access to NMEA data
- Stackable shield headers
- Configurable external interrupts
- 3D Fix LED indicator
- Underside battery holder for optional battery backup
- GPS data compressed to 32 bytes total
|
|
DESCRIPTION
The I2C GPS Shield is an Arduino based GPS shield that gives the user access to the most common GPS data via I2C commnication. The onboard microcontroller acts as a NEMA-to-I2C bridge that parses all incoming NMEA data and stores the data in registers.
Finally an easy way to access GPS data, no more worrying about choosing correct baud rates or trying to figure out the correct voltage level for communications or even parsing the data...it's all done for you.
You don't even have to worry about pullup resistors for the I2C lines since the shield uses a special translator that maintains I2C signal integrity no matter how many other I2C you decide to add...even in 400 kHz mode!
|
|
Comments
Have tried to determine from Schematic what is in and out but have not been able to figure it out.
Thanks.
Richard.
The datasheet specifies that the altitude is saved with two digit decimal precision - but in the Arduino sample you divide by 10.0 to get "altitude in meters".
Am I missing something, or shouldn't it be "divide by 100"?
Also, I seem to get quite random altitude readings - from -16 to +30 at the same spot. Is that normal? (I see 6 or 7 sats, and the "3d fix" bit is set.)
Sorry Robin, it is in fact a typo in the datasheet. The correct digit of precision is one digit so you'll want to divide by 10.0 .
As for the accuracy of the altitude, from what I understand most GPS devices are not as accurate with altitude as they are with lat/long.
Tryng to find the Communication-adress of the shield!?
Trying to find the Communication-adress of the gps shield!?
Can anybody help me?
The 7 bit address is 0x29
But i don't understand in which order i have to receive the data?
Can anybody send me a sample?
Hi Mathew,
Have you tried the sample sketch? What output are you getting from the sketch?
I've uploaded a separate 1.0 version.
Thank you,
John
New I2C gps shield.
Using sample 1.0 program.
Program starts reporting values as soon as it comes out of reset.
Status register always reports "FF" value.
All GPS values show as -1 or -0.01 or such except speed and course both show values of 655.35. The status value of FF concerns me the most. I have another brand GPS module here and it has a good lock on satellites.
Arduino Mega2560 r2 is running program. I2C gps stacked on top of it. Powered from USB on computer.
Any suggestions?
Thank you,
John
I see on the schematic there is a 1PPS signal from the GTPA010 module. Is this signal available in a register or interupt to the Arduino program. My present interest is in a timimg application and this would be helpful if it's available.
Thank you,
John
1. With a Mega2560 the shield doesn't use the same pins. I removed the solder bridges from SJ2 and SJ3. I added JP2 and wired from there to pins 20 (SDA) and 21 (SCL) on the MEGA2560. I now see real data.
2. The sample program had the 5th line of the loop rem'ed out. Its the 1 ms delay. Removinng the "//" works much better.
3. I set update rate back to 1Hz. I now get real data every second, but the Status Register still seems strange. Are the bits documented properly on page 4 of the I2C documentation?
Thank you for your patience,
John
Uncomment the //delay(1); worked fine, why it is commented?
Sometimes it works with it commented, sometimes it doesn't. As best I can tell, there is a minimum setup time from when the stop bit and next start bit is sent (I believe it's 4.7us) and sometimes the standard sketch puts that right on the hairy edge so the delay guarantee's that setup time is exceeded.
I think I understand the status register after some more thought. The only thing that concerns me is that the status register is now reporting "7F" or "8F". This would mean 7 or 8 satellites, but the "F" portion should mean the 3d Fix LED should be on, but it is not.
It would be helpful if your documentation mentioned details of using the I2C GPS with Mega Arduinos.
I like the speed of the I2C bus and the way you have parsed the NMEA sentences.
Finally, is the 1 PSS signal available?
Thank you,
John
Hi John,
Let me see if I can answer your questions. The 1PPS signal is not available externally. Originally when designing the board I thought about breaking out the signal but ran into the problem of deciding which pin to route it to. I started doing some research and noticed that I didn't see many people taking advantage of the 1PPS signal, which in hindsight I now know was probably not the best decision (I've received numerous requests about this). The signal is routed to the onboard controller so the firmware could be hacked using pin change interrupts to reroute the signal to one of the other header pins.
Oddly enough I didn't realize I left the section out of the the datasheet on how to modify the shield to make it usable with the Mega, but as you've seen it's only a matter of removing the two solder jumpers and soldering two wires to the Mega's I2C pins.
The 1ms delay you see in the code was due to intermittent strange behavior when requesting data from the shield. It seems to be a function of the AVR itself where there needs to be minimum delay of 4.7us between start and stop bits. Sometimes the setup time on the Arduino is below this value which is why I had the 1ms delay (actually if memory serves a simple 1 microsecond delay works also if you run into the problem).
As for the status register 0x7F and 0x8F you are seeing, yes the 7 and 8 are reporting the number of satellites used and the F is reflecting a 3D fix. In the case of this shield (another thing I failed to mention in the datasheet
If you have any other questions please don't hesitate to ask.
I appreciate the information. The 3D Fix LED being off when it has a lock makes sense to save power. The only problem I seem to have now is that after being powered down overnight, the program wouldn't run until I removed the CR2032 backup battery. The battery checks good, but without a battery it takes a long time to lock.
John,
Can you tell me what you mean by the program wouldn't run? Are you consistently having this problem with the battery installed? I hate to ask this but I have to (sorry) do you have the battery in the correct way? Let me know.
I will do some more testing with and without the battery. According to the printing on the battery holder I'm pretty sure I had the battery in correctly. I understand about sometimes having to ask those kind of questions because you don't know the knowledge of the people you are speaking with. The battery was installed with the bump on the battery toward the PCB.
When the program wouldn't run, I added lost of Serial.print statements to see how far it was getting. Eventually it got as far as the Wire.endTransmission when it was setting the update rate. It never seemed to return from that. Of course during this whole process I'd recompiled and uploaded the sample program multiple times. It was only after I removed the battery that the program started to run properly.
I'll try the same thing tonight and see if it happens again. I also appreciate seeing the firmware for the card. It's good to learn from other peoples programming. It's been a while since I worked with C and I'm never sure how much is supported on the Arduino.
Thank you,
John
i'm considering using this GPS Shield with a ChipKit Max32. Am I correct in assuming that I need to feed the Shield just with 5V and GND and connect A4 and A5 via 5V/3.3V level converters to the I2C pins of the ChipKit Max32? Or can the Shield be driven by 3.3 Volt I2C as well?
Thanx
erwin
Hi Erwin,
The shield does need to be powered by 5 volts. If you're interfacing to a device where the I2C lines are not 5 volt tolerant than yes you would need an additional level converter. Now don't quote me on this but I thought I heard somewhere that the IO lines on the ChipKits were 5 volt tolerant. You may want to ask on their forum.
Thanx, will check again there but think you are right.
What happens when the speed exceeds the integer limit?
First I thought this will give just maximum integer value. But looking at the atoi definition, I think it will just skip the last digit, which would be the second decimal place.
The limit is 640km/h = 178 m/s, this is reachable and the GPS module is said to function until much more. Although it might be that you will lose satellite locking at those speeds.
You know what, you are correct. I went back and look to see what I did and I misread the datasheet as the maximum speed for the GPS IC as being 515 km/hr instead of the actual 515 m/s. So the number will probably rollover at 655 km/h.
I started using the module today and I love it.
I like these the best for two reasons, one, you don't need to use pullup resistors and two, they work for both open collector/drain and push/pull communications.
Those are only used if you want to connect the shield to your computer's USB port. In normal operation you don't need them.
I was also wondering if you are thinking of porting your Sample Sketch (IDE 1.0) over to your I2C library?
I could. I'll have to break up the communication parts because the shield does not support the repeated start because it's based off Wire.
But when you do figure out how to let it be a slave then we could reprogram the shield through J1? Just when I think I have i2C figured out, I learn I need to go back and read some more on the I2C subject.
I have a few questions: 1) Is there a external ant port that I can use? 2) is there a way to display sensitivity of the device? 3) Is this device broken in any way?
What number is the status register reporting on the display?
It's probably best to uncomment the line. Long story short the reason for the delay is because the ATmega328p chip needs a 4.7us delay between sending the stop bit and before sending the next start bit when requesting data. Most times it's not a problem but sometimes it creeps up so the 1ms delay extends the hold time long enough to exceed the 4.7us.
Actually the easiest way to compare sensitivities between receivers would be to look at the PDOP, HDOP and VDOP values (registers 0x19 - 0x1E). You should be able to compare these numbers across different GPS vendors also. There's a little write up about the parameters here ( gpsinformation.net/main/dopnontech.htm ) if u want to check it out but basically the lower the number the better with a 1 being the best possible accuracy.
RSS feed for comments to this post