I am now sold on NeoGPS, will spend the rest of the day on understanding it and getting it to work. Two queries I'd just like confirmed to have full confidence in what I believe I have learnt so far:
SoftwareSerial is limiting the scope of using interrupts here. What if I plugged up to pins 1 and 0 and used the GPS with hardware serial? Is this even possible?
I tried increasing the frequency of interrupts before posting last night but could not see any impact so didn't mention it. Obviously I'm not going to bother pursuing this option any further because the SS limitations make it fruitless, but it would be good to know I was on the right path. Does the hex value dictate the number of clock cycles that will be counted up to before a reset/interrupt takes place? So as standard; it was 0xAF = 175 cycles? I was halving this hex value (then halving again and again) to try and increase interrupt frequency. Ignoring the SS limitations of this particular case, was this the right thing to do?
Appreciate the script jboyton. I've certainly got more than enough from both you guys to get started on, I will churn through what you guys have generously posted so far and see how I get on.
SoftwareSerial is limiting the scope of using interrupts here. What if I plugged up to pins 1 and 0 and used the GPS with hardware serial? Is this even possible?
Yes! No GPS library can fix the fundamental problem with SoftwareSerial. NeoGPS will give you a more wiggle room in the timing because it's faster, but it may not be able to compensate for the interrupt burden. I occasionally suggest dedicating Serial to the GPS, but I've never seen anyone actually do it.
I do this on a Mini, which doesn't have a USB port. I connect a TTL Serial-to-USB converter to the SoftwareSerial pins, and use the HardwareSerial on pins D0 (RX) and D1 (TX) to talk to the GPS device.
This allows the efficient HardwareSerial object, Serial, to reliably receive the GPS data. The inefficient SoftwareSerial is used for the occasional debug output through the converter to the PC. SoftwareSerial disables interrupts while each character is being sent, but it does not cause any any interrupts. Interrupts are re-enabled between characters, allowing the HardwareSerial to buffer 1 or 2 characters. You can still try to print too much, which causes the Serial input buffer to overflow.
The disadvantage of using Serial for the GPS is that you either have to disconnect the GPS to upload a new sketch, or you have to use an ISP to program the Arduino through the ICSP header pins. I use an AVR ISP MKII, but you can also use a 2nd Arduino as a programmer.
That's great, cheers for the info Dev. I will have a play about with the arrangement and see how I can deal with not having the direct link to PC as normal. Will try what you've mentioned.
Anyway, I've become stumped at the first hurdle w.r.t NeoGPS it seems. Being quite new to Arduino, and having no previous coding experience, I've been following the instructions to the letter Dev, and don't have enough experience to provide much initiative when coming across unexpected issues.
Error from IDE when compiling NMEA.ino as per Step 5 of Installing.md:
This report would have more information with
"Show verbose output during compilation"
enabled in File > Preferences.
Arduino: 1.0.6 (Windows XP), Board: "Arduino Uno"
In file included from NMEA.ino:37:
/GPSport.h:25:30: error: SoftwareSerial.h: No such file or directory
In file included from NMEA.ino:37:
GPSport.h:33: error: 'SoftwareSerial' does not name a type
NMEA.ino: In function 'void GPSloop()':
NMEA:127: error: 'gps_port' was not declared in this scope
NMEA.ino: In function 'void setup()':
NMEA:195: error: 'gps_port' was not declared in this scope
Something wrong with the syntax of line 33 in GPSport.h? I haven't modified anything yet, all .ino, .h and .cpp files are as out of the box, not sure what I need to add here :S
I tried increasing the frequency of interrupts... Ignoring the SS limitations of this particular case, was this the right thing to do?
Sure, increasing the polling frequency is the thing to do if you can ignore (or don't use) interrupts. OTOH, using an interrupt to poll seems a little silly, but that's not your fault. TinyGPS tries a different work-around, smartDelay, which isn't. >:(
Hmm, why is that file not found? I'm using 1.0.5, which is fairly close to your version. Does putting it in the INO work? There are two forms of the include:
#include <SoftwareSerial.h>
and
#include "SoftwareSerial.h"
The double-quoted one is in gps_port.h, and the angle-bracket version does not work for me.
SoftwareSerial is limiting the scope of using interrupts here. What if I plugged up to pins 1 and 0 and used the GPS with hardware serial? Is this even possible?
Like /dev said, you can do this. But it makes development more cumbersome because you can't upload without disconnecting the GPS. So you'd be constantly connecting and disconnecting the GPS. Or using an ICSP programmer. And you can't use the serial monitor for debugging while the GPS is connected either. Well, actually you could do that if after initializing the GPS you disconnected the TX only.
But both gSoftSerial or AltSoftSerial are both huge improvements over SoftwareSerial. Here's a simple benchmark to give you an idea. At 9600 baud (on an Uno) SoftwareSerial spends on average 95% of the available processor time in its interrupt service route. So out of each second only 50ms is left for the rest of your code to do anything. At 38400 baud even less time is left over.
AltSoftSerial averages only 5% and gSoftSerial about 7%.
And you can't use the serial monitor for debugging while the GPS is connected either.
...unless he connects the SoftwareSerial pins to a TTL-to_USB converter module. Then you print debug stuff to the SoftwareSerial variable instead of the Serial variable. In the final system, debug prints may even not be needed.
Barring that, I second jboyton's suggestion to use the other software serial libraries, which may require you to use different pins.
BTW, I've found some posts about the "SoftwareSerial.h file not found." It can be caused by:
Building for the Due instead of Uno. Check which board is selected in the Tools->Board menu.
Library files that need to be copied from hardware\arduino\avr to the "My Documents\Arduino\libraries" (IDE 1.6.? only)
Messing with the built-in SoftwareSerial code or providing another set of files that have a "class SoftwareSerial". (IDE 1.6.? only)
Only the first one seems possible for your IDE 1.0.6, but I had to wonder about the third. @jboyton have you ever seen this when substituting gSoftSerial?
/dev:
...unless he connects the SoftwareSerial pins to a TTL-to_USB converter module.
Of course. Or send debug to an LCD or something.
/dev:
Barring that, I second jboyton's suggestion to use the other software serial libraries, which may require you to use different pins.
gSoftSerial can use any pins.
/dev:
BTW, I've found some posts about the "SoftwareSerial.h file not found." It can be caused by:
Building for the Due instead of Uno. Check which board is selected in the Tools->Board menu.
Library files that need to be copied from hardware\arduino\avr to the "My Documents\Arduino\libraries" (IDE 1.6.? only)
Messing with the built-in SoftwareSerial code or providing another set of files that have a "class SoftwareSerial". (IDE 1.6.? only)
Only the first one seems possible for your IDE 1.0.6, but I had to wonder about the third. @jboyton have you ever seen this when substituting gSoftSerial?
I don't understand the question. The gSoftSerial library doesn't have a "class SoftwareSerial".
Next issue; on startup of the NMEA.ino sketch, I see the initial 4 lines in the Serial Monitor, but no data scrolls no matter how long I wait:
NMEA.INO: started
fix object size = 34
NMEAGPS object size = 53
Looking for GPS device on SoftwareSerial( RX pin 6, TX pin 5 )
GPS antenna is located at my window which always gets good satellite fixes (it's how I've been running the GPS with all my other sketches).
As you can see my fix object size and NMEAGPS object size values are less than those stated in the Installing.md doc Dev. What could this mean? What should I do to rectify this?
For info, I've changed pins to 6 and 5 because I've had issues using Pin 4 for SoftwareSerial on my Uno before. I simply changed the defined pin values in the GPSport.h file. Have checked and double-checked the pins are referenced / plugged in correctly.
CWAnthony:
What could this mean? What should I do to rectify this?
No big deal... different configs will have different sizes. I should make it match the out-of-the-box config, though.
Well, how about trying NMEAdiagnostic.ino? You do the same install steps and copy a bunch of files into the NMEAdiagnostic subdirectory. And just like you had to do in NMEA.ino, add this include to NMEAdiagnostic.ino
#include "SoftwareSerial.h"
Make sure GPSport.h is using the correct pins:
// Arduino RX pin number that is connected to the GPS TX pin
#define RX_PIN 6
// Arduino TX pin number that is connected to the GPS RX pin
#define TX_PIN 5
...since you know what pins to use. You posted a previous sketch on pins 8 & 7, so you've rewired to 6 and 5, right? I'm still looking into the mysterious "SoftwareSerial.h - file not found" error...
The NMEAdiagnostic.ino sketch will try different baud rates to see if it's getting the right data. It also displays any data it does receive, just in case it's garbled.
If it finds a GPS device and receives valid data, it will tell you the baud rate that worked. I hope this is the same baud rate that has already worked for you with other sketches, but this will verify it.
jboyton:
The gSoftSerial library doesn't have a "class SoftwareSerial".
Right, I just was wondering if you ever saw an unexpected "include file not found" while you were developing it. There are some new features in 1.6.x that track what files contains a particular class, and that making your own version of SoftwareSerial could confuse it. I don't think this is CW's problem though.
Have you used NeoGPS on an UNO? I've used it successfully on a Mini and a Mega, with HardwareSerial and SoftwareSerial ports selected by GPSport.h.
Come to think of it I have seen an include file issue when I compiled a certain sketch in 1.6.x for the first time. It wasn't with gSoftSerial though. I can't think of any reason why gSoftSerial would be any different than any other library I happened to add to the libraries folder.
The only time I used NeoGPS was when I first learned about it from the thread where you introduced it. I ran a few tests with the original version of it using an Uno and the Ultimate GPS logger shield. I was using IDE 1.0.5.
I wouldn't be adverse to trying an experiment with my Uno. What is the problem exactly?
So I'm working on a lot of the options mentioned by you guys above in parallel. Haven't completely cracked what I want but have some nice progress, if a bit slow. Brain is fried for tonight so will try and progress further tomorrow. Appreciate the continued support from you both.
Just wanted to comment on something you mentioned earlier jb (first page):
AltSoftSerial uses timer 1 hardware features to enable it to be more robust. For RX it uses the input capture mechanism and that's tied to digital pin 8 on an Uno. Fortunately the Ultimate GPS Logger shield uses pin 8 for RX. But AltSoftSerial also uses one of the output compare pins for TX, pin 9 on the Uno (pin 10 would also be possible). But on the shield TX is pin 7. So that means you'd have to do one of two things: (1) Jumper pin 7 to pin 9 and leave pin 7 unusable for other purposes; or (2) cut the trace on the shield between TX and pin 7 and solder a wire from TX to pin 9.
I couldn't work out what you meant by describing cutting new traces, and how shield pins were set, etc. I've only just realised why I was confused by this.
I've soldered jump wires to the RX / TX pin holes of the breakout board, which have to now allowed me to choose whatever digital pins on the Uno that I like (as long as they support SS).
Assuming you were not aware of this, I wonder if this changes any of the advice you have given to date? I think the module is exactly the same in either application, and it is just physical architecture that is different between the two, but I'm not 100% sure
CW is getting a "include file SoftwareSerial.h not found" error in GPSport.h. NMEA.ino includes GPSport.h, which conditionally includes SoftwareSerial.h.
If he puts the exact same include statement directly in the INO, it finds the file and builds without errors.
I have reproduced the problem in 1.0.5, so I must have tested this when all the INOs had the GPSport.h contents "inline". They worked. Noticing the common code, I pulled 50 lines out into a new file, GPSport.h. But now it doesn't find the SoftwareSerial.h at compile time.
This is the actual compile command that works (#include in NMEA.ino):
This is actually an IDE issue, but I should have caught it in testing. I have even tried Importing the SoftwareSerial library. I guess the GPSport.h includes will have to be in each INO. So I guess you don't need to try it, I just need to work around it.
CWAnthony:
Assuming you were not aware of this, I wonder if this changes any of the advice you have given to date? I think the module is exactly the same in either application, and it is just physical architecture that is different between the two, but I'm not 100% sure
That makes more sense. I couldn't figure out why you weren't using pins 7 and 8 for TX and RX since on the shield that's where they're located.
You used the word "shield" in your description instead of "breakout". That's why I misunderstood. A shield plugs right on top of an Arduino so that you don't need any jumper wires. A breakout board requires jumpers. The shield concept has some advantages but also disadvantages.
What that means is there's no reason to cut any traces since you can jumper or solder wires from your GPS to any pins you want.
I think it can only use the same pins that SoftwareSerial can use. gSoftSerial::listen uses digitalPinToPCICR and digitalPinToPCMSK just like SoftwareSerial. These macros are defined in
hardware/arduino/variants/*/pins_arduino.h
Depending on which board is selected, it chooses a variant. I was giving it a try on my Mega...
@CWAnthony, I think you should change this line in NMEA.ino:
I think NMEA.ino is waiting for the wrong "last sentence". In your case, the GPS device may only be emitting an RMC; the GGA never arrives. As mentioned in the Troubleshooting section, you can use NMEAorder.ino to find out which sentence is really last (or the only sentence ). This is crucial for knowing when the GPS quiet time begins.
If you tried it, NMEAdiagnostic probably worked, as you already knew the correct pins and baud rate. And if you try NMEAorder, it would probably NOT print GGA as one of the received sentences.
/dev:
I think it can only use the same pins that SoftwareSerial can use.
That's true. But with an Uno -- which is what I thought we were assuming in this thread -- that means any digital pin that isn't being used for something else. The gSoftSerial library only claims support for a 16MHz Uno (or an 8MHz Atmega328 in a more limited way).
