I`m having a hard time trying to read data from the EM-406A. The unit seems to be working - at least partially, but
I get nothing but 'garbage' from it.
First I´ve connected only EM´s pins 1 and 5 to GND and 2 to +5V. The EM406 red led lit, and after a couple of
hours in an open environment it started to blink, indicating a fixed position.
Problem starts when I try to read the NMEA strings. First I connected EM pin 4 to one of Arduino´s digital
I/O pin and tried a bunch of ways to read the serial data ( SoftwareSerial, reading with digitalRead() from
pin considering the asynchronous serial protocal, etc ) with no success. To isolate the problem I tried the
simple code below suggested by wayneft in another thread:
After connecting the GPS Tx to the Tx pin on my UNO I´ve got the same 'garbage' in the serial monitor,
no matter the baud rate used - the expected baud rate should be 4800.
Now, I use 'garbage' between '' because there seems to be a pattern in the strings I´m getting. For
instance, this is some of the data from the serial monitor:
[[bunch of non printable]]?ª¨Èè?A??$H9???Eº?Ad
J¨-ª¨h(-??ÍN(/(? +?(ª¨È)-ò$rÈJJJÅE[[bunch of non printable]]
???(-ò誨H[[bunch of non printable]]È????Eº?ÇèHÕ?âÿ¨h(mÚ?Í^(/(Ú?HAIª¨È)-ò?rÈJJJÅE
So, there are sequences like "ÈJJJÅE" that repeat along the stream. That indicates
that there is a pattern underneath. I´m aware about the GPS´ 2.85V level and
Arduino expecting 5, but there are so many reports of success in using this unit
without any level circuitry that I expected that to work.
Maybe the logic is inverted, I´ll try that tomorrow. That would explain the
pattern. But what puzzles me is that there are many reports of this GPS model
being used, with source, and none implement an inverted logic.
Hi, I saw forum stuff a year ago that said it was inverted if you took the direct TTL level signal, and the optional RS232 interface inverted it back...
The fact that you see repetitive garbage sounds like inversion also...
Well, I tried to solve the issue by software with no success. The code below is a stripped down
version of code posted elsewhere as an example on how to get data from the EM406-A. I´ve
changed it to read all data in a buffer first, to avoid timing issues, and changed the logic of
detecting IDLE and START bits. Got no valid data for all combinations.
#define bit4800Delay 188
#define halfBit4800Delay 94
byte rx = 7;
// Control logic for IDLE, START BIT, etc.
byte IDLE;
byte START;
// EM406 serial content is stored here
#define MAX_SIZE 1100
byte output[ MAX_SIZE ];
void setup() {
pinMode( rx, INPUT );
Serial.begin( 9600 );
// Init buffer with all 1s
for( int i = 0; i < MAX_SIZE; i++ ) {
output[i] = 255;
}
}
char SWread() {
byte val = 0;
while (digitalRead(rx) == IDLE );
//wait for start bit
if( digitalRead(rx) == START ) {
delayMicroseconds( halfBit4800Delay );
for (int offset = 0; offset < 8; offset++) {
delayMicroseconds( bit4800Delay );
val |= digitalRead( rx ) << offset;
}
//wait for stop bit + extra
delayMicroseconds(bit4800Delay);
delayMicroseconds(bit4800Delay);
return val;
} else {
return 'A';
}
}
void loop()
{
// Inverted logic for IDLE and START bits. Tried
// also with IDLE=HIGH and START=LOW
IDLE = LOW;
START = HIGH;
for( int i = 0; i < MAX_SIZE; i++ ) {
output[i] = SWread();
}
Serial.println( "Direct" );
for( int i = 0; i < MAX_SIZE; i++ ) {
Serial.print( output[i], BYTE );
}
Serial.println( "Inverse" );
for( int i = 0; i < MAX_SIZE; i++ ) {
byte inv = ~output[i];
Serial.print( inv, BYTE );
}
while( 1 ) {
}
}
With or without the inversion guess the way to go is first convert the signal levels to
0~5V just to be sure.
In the meantime it would be great to have any report on the use of this module
with the Uno.
First thing I would do is verify the GPS is working. Download the below code and connect the GPS Tx pin to the Arduino Tx pin. Next open up serial monitor and cycle through the baud rates until you see valid NMEA sentences. I believe the default baud rate is 4800. If/when you see valid sentences then you'll know it's working and the baud rate the unit is configured to.
Hello Wayne,
that was my starting point - at least for the forum post, before that I´ve tried a lot of
things.
problem is I get 'garbage with pattern'. The unit seems to be working, at least it blinks
when in an open environment meaning that it has satellite lock.
by the way, the test you suggest assume a direct logic, right? That is, 0V meaning bit 0
and 2.8V meaning bit 1.
I´m a bit confused on how to interpret this info from the datasheet:
Wow.don't know how I missed that . It maybe in binary mode.download the sirfdemo software and try to reconfigure it. You'll also need to connect the rx line to the rx line with the sketch downloaded.you'll have to put it across a voltage divider first to bring the voltage down.
wayneft:
First thing I would do is verify the GPS is working. Download the below code and connect the GPS Tx pin to the Arduino Tx pin. Next open up serial monitor and cycle through the baud rates until you see valid NMEA sentences. I believe the default baud rate is 4800. If/when you see valid sentences then you'll know it's working and the baud rate the unit is configured to.
I was having the same problem and found this code very usefull.
I´m using broken gps-bluetooth module, and could no make it work at the datasheet baudrate(4800). After some reading i saw that bluetooth uses 115200bps, and for some strange reason my module was outputing NMEA sentences at that speed, of course inverse logic.
I´ve already made it work via arduino with the mentioned code and with the following schema via serial port:
YES, it is alive!
Working with SiRF protocol at 9600 baud. With the code suggested by wayneft running and making sirfdemo listen
to the console COM port the GPS data is displayed.
Now the next step is to switch it back to NMEA protocol, or simply work with SiRF. I´ll post the updates.
I tried to change the EM406 back to NMEA through sirfdemo but with no success.
Anyway, saw in another forum a message mentioning that everything fails you
could switch it back to NMEA by disconnecting the power and waiting for
3 days.
Doing that worked in my case. The first try after that worked as expected,
with the NMEA messages coming at 4800 bps.
At least for my case, monitoring the serial traffic using the Tx and Rx Arduino
pins was possible with no need to any level conversion. It was simply a matter
of connecting the right pins.