QUESTION

Question

I have a M20071 Eval board that I would like to send $PAIR commands as listed in the M20071 NMEA Packet Manual.  I have had success sending commands like $PAIR002,*38 and $PAIR003*39 via the GNSSdemo GUI tool, but I would like to be able to send commands from outside this tool.  When I send commands like those I just mentioned from a serial monitor like TerraTerm, the Tx LED lights up on the eval kit momentarily as a confirmation that the board is receiving the message, but nothing else happens.  Is there some sort of procedure to send these commands that I'm missing?

Data sheet: Datasheet

M20071 NMEA Packet Manual: packet manual

Answer 1

Hi,
The GNSSdemo tool does not do anything extra, I think there might be a problem with the \r\n terminator.  I'll send you an email.

Michael

Answer 2

Also having this same issue. any resolution here?

Comments

Hi, this issue was resolved, it was related to the terminator characters. I'll send you an email, and see how we can help you.  Michael

Answer 3

Use the following python code to send a command.  I haven't worked out the best procedure to communicate with the device, but this should get you started.

Source: https://stackoverflow.com/questions/19143360/python-writing-to-and-reading-from-serial-port

import serial, time

ser = serial.Serial('/dev/ttyUSB1', 115200, timeout=0.5)

ser.write(b'$PAIR003*39\r\n')

time.sleep(0.1)

ser.close()

Comments

Thanks Cameron! I confirmed this works on the devkit.
The real issue I'm trying to tackle involves sending these commands from a custom board to the receiver. I suspect there is some weird byte padding issue (using char arrays in C) that is hanging me up. I've confirmed data is flowing to the right pin with a scope, just not seeing any change in the behavior of the receiver when I'd expect to.

---

One other thing to try is 'sniffing' the serial line, and reading into Terraterm (or other). Note that the M20071 operates at 1.8V, so the input shouldn't go higher than this, (it might tolerate it). Michael

---

That's my exact issue as well.  I haven't spent much time debugging this, so I'm not sure I can be of much use. I'll update this thread if/ when I come across a fix.

---

Couple recent findings:

1- I can successfully issue change-of-state commands. For example, when I issue both of the following commands

• 003 PAIR_GNSS_SUBSYS_POWER_OFF 

• 062 PAIR_COMMON_SET_NMEA_OUTPUT_RATE

I see the expected change in behavior from the receiver. However, I don't see any PAIR acknowledge messages coming through to my console uart stream (I'm running a python script in the background to sniff that serial port).

2- It takes a long time for these change-of-state commands to execute. The subsys_power_off command takes 20 seconds from time of issue to actual shutdown. The set_nmea_output_rate command takes over a minute from time of issue to observed change of message frequency.

Michael, are the 2 observations described above consistent with your team's internal testing? The long time for command execution makes me think something is wrong.

Ian

---

That timing is at least not my finding.  I have seen the power off execute within 2 seconds.  I can't speak to the nmea output rate.

---

Thank you for checking, I agree a long time to sleep seems odd.  Could it be related to one of the handshake lines floating, which then stops the receiver from clearing its buffer, so it can't sleep.  I think I remember reading that the baud rate changes don't get acknowledged, as it changes baud rate immediately, and the PC could get corrupted chars at the wrong baud rate.

---

Got it. Are there any commands I should manually run after sending a set_nmea_output_rate command for the changes to take effect? For instance, do I need to cycle the GNSS_DATA_EINT pin or do something else to manually enforce the clearing of the receive buffer?

The time for command execution is ballooning (each command takes ~5 minutes to effect change in behavior now) as I send more and more commands to the receiver throughout the day. Possible that some buffer is not getting flushed out properly. Any ideas here

---

I've asked my colleague to look into this.  I agree it seems a buffer is not being emptied. Michael

---

I think the problem is related to the GNSS_DATA_EINT pin, it should be brought low before any command is sent. If it's floating that could be a reason why data is held in the buffer.  Michael

---

I slightly changed the reply above, I think it is worth trying some experiements with this line: GNSS_DATA_EINT.  Michael

---

Initializing to HIGH and then setting to LOW, issuing command, then setting back to HIGH does not work.

Are there other commands that are being sent automatically by the gnss_demo application that maybe aren't described in the documentation?

---

I've learnt that the timing on the GNSS_DATA_IN_EINT pin is important.  The PAIR command must be sent no later than 100ms after GNSS_DATA_IN_EINT goes low.  Also it best to wait 20ms after the pin goes low, therefore there's an 80ms window.  I hope that helps. Michael

---

Still no luck on this. Can you send me whatever documentation you are working off of? Also, can you send me the firmware that the dev kits are flashed with? I have a python script where I'm successfully issuing PAIR commands. I'm assuming my GPIO assignments are messed up somewhere

---

I'm sending you an email.  We want to understand why this isn't working, and will send an Eval board to you, to help fix this.
Michael