Help sending PAIR/PQTM commands via transmitAT() on the mobile station (SKU: KIT0198-EU)
eboustou 2026-08-10 22:36:41 167 Views3 Replies Hi,
I'm trying to send configuration commands (like $PAIR063 or other PQTM commands) to my mobile station's GNSS module using transmitAT() from the DFRobot_RTK_LoRa library, over I2C on a Raspberry Pi.
I can get it working with the exact example from configParam.ino ($PQTMVERNO), and I get a correct response back. But when I try other commands, I never get anything back — it either times out or just repeats the previous response instead of a new one.
Could you help with:
Is there a recommended way to use transmitAT() for commands other than the version query in the example? Maybe I'm missing a step (waiting longer, resetting something between commands, a specific mode to be in, etc.)? Is there a newer firmware available for the mobile station's relay board? Also, I noticed the schematics download on the wiki only includes the base station board. Would it be possible to get the schematic (or just the GNSS module pinout) for the mobile station board too? I'd like to be able to wire directly to the GNSS module as a backup option if needed.
Thanks a lot!
eboustou
Thanks for the pointer! I dug into it more and wanted to share what I found, in case it's useful for others.
Checksums turned out not to be the issue.
What I found instead: $PQTM... commands work reliably through transmitAT() — I tested about 30 different PQTM read commands (message rates, RTK config, antenna, geofence, etc.) and got real responses (OK or a proper ERROR) for almost all of them. As of now, that covers everything I actually need.
$PAIR... commands, on the other hand, never got a response — tried several (PAIR051, PAIR063, PAIR865), all with checksums straight from the datasheet, no luck. Not a blocker for me, but flagging it in case it's a known quirk of the relay firmware, or in case someone else runs into the same thing.
Really appreciate the help on this!
eboustou Good catch，PQTM covers everything you need, you're set.
The example works because $PQTMVERNO*58\r\n is a query command with no parameters — the checksum is static and the format is simple. Most other PQTM and PAIR commands need a write/read flag and parameters, and the checksum changes with the payload. If the checksum is wrong, the module silently drops the command.
The format is $PQTMCMD,W,param1,param2*CS\r\n for writes and $PQTMCMD,R*CS\r\n for reads. The checksum is XOR of every byte between $ and *. The DFRobot library's transmitAT() just forwards the string as-is — it doesn't calculate the checksum for you, so you're responsible for getting it right.
A quick test: send $PQTMVERNO,R*3F\r\n (read mode, checksum 0x3F) and see if you get the same response. If that works but $PQTMCFGRCVRMODE,W,1*2A\r\n doesn't, your checksum calculator is off.
Jason.Miao 