Home/Amateur Surveying/GPS/Trimble Resources/Trimble UCCM Resources

Trimble UCCM Resources

The UCCM is…

ASICs

• RF: Colossus

Part Numbers

Trimble uses the same format of part numbers for sub-assemblies as they do for products, so there is often confusion about the UCCM part number

    57964-05    OBSO PRD ASSY DOCXO UCCM
    57964-10    +PDT ASSY UCCM SOCXO
    57964-15    PRD ASSY HI TEMP. DOCXO UCCM
    57964-20    OBSO PRD ASSY DOCXO T8000 UCCM-LA STD TEMP
    57964-25    +PRD ASSY SOCXO UCCM
    57964-40    OBSO PRD ASSY DOCXO UCCM WCDMA
    57964-60    OBSO PRD ASSY DOCXO UCCM EXTNDED TEMP
    57964-70    OBSO PRD ASSY DOCXO UCCM EXTNDED TEMP CDMA
    57964-71    OBSO PRD ASSY DOCXO UCCM EXTNDED TEMP KDDI
    57964-80    OBSO PRD ASSY DOCXO UCCM EXTNDED TEMP UQ_WIBRO
    57964-84    OBSO PRD ASSY DOCXO UCCM-LPK EXTNDED TEMP
    57964-85    OBSO PRD ASSY DOCXO WiMAX UCCM-LP EXTNDED TEMP
    57964-86    OBSO PRD ASSY DOCXO UCCM-LPS EXTNDED TEMP LTE
    57964-88    OBSO PRD ASSY DOCXO UCCM-L8 EXTNDED TEMP

Hidden Commands

Playing around in the serial console on the UCCM, I noticed some interesting things…

The command parser appears to do two passes. I imagine the first pass parses a command and breaks it up into tokens. If a command contains a token contains that it doesn’t recognize, it fails with an “Undefined header” message. In this pass, all of these pass the test

UCCM-P >SYST:COMM:SER2:BAUD?
+57600
Command complete

If I scramble the tokens, I get a Command error:

UCCM-P >COMM:SER2:BAUD:SYST?
Command error

If I mix up tokens from multiple commands into a non-sensical soup salad, I still get a Command error:

UCCM-P >TRAC:SER2:BAUD:DIAG?
Command error

But if I put in something that isn’t a recognized token in any of the implemented commands, I get an Undefined header message:

UCCM-P >TRAC:OINK:BAUD:DIAG?
Undefined header

The takeaway is that as long as a token exists somewhere in the global dictionary of tokens, it will give a different error than if you’ve provided a token that isn’t implemented at all. This means that it’s quite easy to search the command namespace for interesting things, so I just started guessing at things:

UCCM-P >debug                                                                   
Undefined header                                                                
UCCM-P >dump
Undefined header                                                              
UCCM-P >tsip                                                                    
Command error                                                                   
UCCM-P >monitor                                                                 
Command error
UCCM-P >version
Command error

After a bit more trial and error, I found that both tsip, monitor and version all live under the DIAG heading.

diag:version

diag:version presumably prints out the version of Trimble’s underlying receiver code, which is a different version from the SCPI implementation layer.

UCCM-P ›diag:ver?
V7.11 REL 05/25/2010

diag:tsip

diag:tsip switches the UCCM into TSIP mode, and can be used from within Trimble’s Visual Timing Studio. The receiver reports as a generic “GPS Receiver”, but everything otherwise appears normal. Power cycling the unit puts the unit back into SCPI mode. It has to be a power cycled, the reset button doesn’t work in TSIP mode.

Here’s the UCCM being controlled from Trimble’s Visual Timing Studio:

And here it is in Lady Heather:

diag:monitor

diag:monitor appears to cause the receiver to stop responding to serial commands, but I strongly suspect it dumps the receiver into its ROM monitor.

In almost all of the Trimble gear I’ve investigated, the PC based firmware upgrade tool uses a ROM monitor running on the device to do the installation. At a minimum, their monitors have commands to read and write memory, change the serial port baud rate, and sometimes they contain commands to do a jump to an address. In some receivers, their firmware upgrade tool uses the minimal built in ROM monitor to load a fancy ROM monitor into some unused RAM, then it jumps to that fancy monitor to do the firmware upgrade. The catch is that all of the ROM monitors I’ve investigated use the same packet structure (Trimble’s Data Collector Format, which uses commands wrapped in STX/ETX bytes), but they use different command bytes. So what might be an innocuous READ command on one model might be a WRITE command on another.

To be investigated.