Espruino Wifi with Adafruit Ultimate GPS - no data

[espruino-discuss]

Posted at 2017-11-30 by ct5845

I've got an Espruino Wifi, and a Adafruit Ultimate GPS (https://www.adafruit.com/product/746).

I've got the following code from the tutorials;

Serial1.setup(9600, {tx: B6, rx: B7});

function onInit() {
  var gps = require("GPS").connect(Serial1, function (data) {
    console.log(data);
  });
}

onInit();

The GPS module appears to power up ok, it's red LED flashing once every 1 seconds for a satellite fix, however i'm getting absolutely nothing back from the console.log. Not an error, not a success, nothing.

Not really sure where to go for troubleshooting from here. I believe I've got the pins wired up correctly.

Is it simply that the GPS module provided won't work "out of the box" with this module, do i need to do some lower level interfacing? Or perhaps something else is afoot?

Is there generally any way to debug/troubleshoot in circumstances like this?

EDIT: just to note: experienced JS dev, completely inexperienced Espruino/Ardunio etc dev!

[espruino-discuss]

Posted at 2017-11-30 by @gfwilliams

It should work, and the software looks fine...

How have you wired it? Generally TX connects to RX and vice-versa for serial.

To debug, you could do just the following:

Serial1.setup(9600, {tx: B6, rx: B7});
Serial1.on('data', function(d) { console.log(JSON.stringify(d)); });

That'll output any serial data that gets received, regardless of whether it's GPS or not.

The Adafruit page says:

The LED blinks at about 1Hz while it's searching for satellites and blinks once every 15 seconds when a fix is found to conserve power.

So at 1 per second it hasn't actually got a fix yet - it flashes every 15 secs when it's got a fix. That could actually be why you're not getting any data out - maybe you just need to wait a bit longer :)

---

Posted at 2017-11-30 by @allObjects

Time to get a fix depends heavily of how 'free' the view of the sky for the GPS receiver antenna is. In one of my rooms at home placing the GPS two feet / 60cm closer to the window onto the window sill makes or breaks getting a fix.

---

Posted at 2017-12-01 by ct5845

Thanks.

So it was as simple as the two above pieces of advice...

(1) Place GPS closer to the window to actually get a fix!
(2) Swap the wires round for RX/TX, i had GPS Tx -> Espruino Tx.

Thanks!

---

Posted at 2017-12-01 by @gfwilliams

Great! Thanks for letting us know!

---

Posted at 2017-12-03 by ct5845

So i've been experimenting reading the NMEA sentences, which has been going well but now looking at changing some of the GPS options sending commands to it.

So with Espruino Wifi B6 connected to Adafruit RX.

var refreshRate10Hz = "$PMTK220,1000*1F"; // ideal refresh rate (10hz)
var refreshRate1Hz = "$PMTK220,100*2F"; // default (1hz)

function AdafruitGPS(serial, options) {
  this.serial = serial;

  serial.setup(9600, { tx: options.tx, rx: options.rx });

  serial.println(refreshRate10Hz); // attempt to update refresh rate
  
  var line = '';
  serial.on('data', function (data) {
    line += data;
    
    if (line.indexOf("\n") > -1) {
      this.parseCommand(line);
      line = '';
    }
  }.bind(this));
}

AdafruitGPS.prototype.parseCommand = function (data) {
  var command = data.substring(0,6);
  console.log(command, data);
};

var gps = new AdafruitGPS(Serial1, { tx: B6, rx: B7 });

So this connects and reads commands fine, but the write command doesn't seem to do anything (by the specs i believe regardless of the result i should be receiving a PMTK_ACK as a receipt of a command). I'm aware it's probably something very simple again! But having no luck, anything blindingly obvious in there?

https://cdn-shop.adafruit.com/datasheets/PMTK_A11.pdf (gps command sheet)

---

Posted at 2017-12-03 by @allObjects

The command cheat sheet has a comment about baud rate and update rate:

...it [the user] needs to see if the baud rate is enough or not.

I have no experience with the device you use, nor do I know if the baud rate of 9600 bps is fast enough to support update rate of 10 ups. I assume not, because the baud default baud rate was chosen to be able to transmit an update within maximal a second. (Updates have different lengths.)

You may need to start out with 9600 bps baud rate, set the GPBS's baud rate to 57600, then set your Espruino Board Serial's baud rate to 57600 as well (Serial1.setup(9600, {tx: B6, rx: B7});), and then set the GPS's update rate to 10.

Something else you can do in your parse: parse whether you get the expected acknowledge value.

---

Posted at 2017-12-04 by @gfwilliams

It might be the need to send "\r\n" as newline rather than println's "\n"? Maybe just use Serial.print and then append "\r\n" to the command?

---

Posted at 2017-12-04 by @allObjects

Was my first thought too, but...

If using just Serial.print and adding "\r\n" as data, then the Espruino Ref Doc for [Serial.println](http://www.espruino.com/Reference#l_Serial_println] has to be updated, or at least made unambiguous. It states:

Print a line to the serial port with a newline (\r\n) at the end of it.

Looks like the doc is not sure about what .println(..) really appends... ;-)

---

Posted at 2017-12-04 by @gfwilliams

@allObjects you're right, and so are the docs.

It should be sending \r\n already with println so ignore what I said above.

---

Posted at 2017-12-04 by @allObjects

Print a line to the serial port with (carriage) return and newline (\r\n), also called (CR LF) at the end of it.

...kind of what the doc should read.

Now CR info with a hilarious and other (interesting) notes...

PS: I guess that todays old type writers are now such a thing of the past barely remembered where this notation came from... and the linux behavior for (\n) or (LF) as line end and begin of a new line is not helping much either... nor the chain / band printers from a while ago...

In attached clip, a lever is used to return the spring loaded carriage to its type begin position. It is a lever and not just a handle, because it is hinged onto the carriage, and on pushing, it first turns the rubber print drum by the set amount of 1..1-1/2..2 lines (nicely seen in 3rd clip). The demonstrator in this video uses the Tab key - most type writers had one to the left and one to the right - to move the carriage from one tab to the next. This were of course all left tabs, settable at any position. So are the left and right margins.

The ringing bell alarms the typer that there are 8..6 characters space left to the set right border and LF CR or hyphenation and LF CR is to think about...

First clip means: Type writer LF CR.

second clip means: CR because C not paid (or parking not paid or illegally parked... ;)>

Third clip: LF CR (start 30 seconds into the clip). - PS: sorry ladies for this gender stereotype clip... (although fits/suites/serves the current alternative-facts gov / culture very much... ouch :(((

---

Attachments:

• CRLF_actually_LFthenCR.png
  
• carriageReturn.png

---

Posted at 2018-01-03 by ct5845

Apologies, real work took over! but a few weeks away and it was solved in a few seconds grrrrr...

I tried a few other of the commands that shouldn't require any update to baud rate, and stumbled across what i think was the problem.

This didn't seem to ever work, no matter what the testNMEACommand;

serial.setup(9600, { tx: options.tx, rx: options.rx });
serial.println(testNMEACommand); // attempt to send something to the GPS unit

But this does;

serial.setup(9600, { tx: options.tx, rx: options.rx });
setTimeout(function () {
   serial.println(testNMEACommand); //  attempt to send something to the GPS unit
}, 10);

I guess the connection just hadn't been made, by giving it just a few ms, the commands are being acknowledged (i'm getting PMTKACT sentences back, that at least tells me i'm sending something).

Is it better in this case to perhaps wait for the GPS unit's first communication to me i.e.

var connected = false;
serial.on('data', function () {
    if (!connected){ 
        serial.println(testNMEACommand);
        connected = true;
    }
    ......
});

As i suppose the timeout of 10ms may sometimes fail? I couldn't see a serial.on('connected') or similar command (as i suppose it's up to the device itself to send a heartbeat back, which can't be relied upon?).

---

Posted at 2018-01-04 by @gfwilliams

Ahh, I think what's happened is that the serial port's transmit line didn't have any pull-up resistors so may have been at some undefined state at power-on. When you initialise Serial it's then set up and the voltage is raised to 3v (the default for serial) - but that can confuse the GPS into thinking a character has started, and if you then transmit then probably the first character gets lost.

I don't think there's anything wrong with the timeout you've suggested, however it's a neat idea to wait for the first serial data as you could then maybe even show some kind of error if you found that the GPS wasn't connected/working properly?