A look at my Symmetricom GPSDO / 10MHz reference (OCXO + Furuno receiver)

[PA0PBZ]

Has anyone LH running on a *Pi and a UCCM module?

Yes, I have (or had) it running on a RPi3. It took a bit of a fight to run LH full screen without borders but in the end I won. And as always that is where I lost interest in the project 

[wkb]

Hm, yes happens. Same with my narrowband QO-100 station 😁

Too much projects/toys.  But I will give LH/*PI a try "soon". Is the V6.14beta already running
on Linux?

Wilko

[PA0PBZ]

I got a beta version 6 from texaspyro in May 2018 to compile and test, and it worked fine when using -vp. I'm not sure if this is now available in the release.

[lamaral]

Is the V6.14beta already running on Linux?

Yes. I downloaded the heatherx11.zip file and it compiled straight away. Not running on a RPi tho.

[wkb]

Is the V6.14beta already running on Linux?

Yes. I downloaded the heatherx11.zip file and it compiled straight away. Not running on a RPi tho.

OK, at least it sounds promising! Where did you download it from?

Wilko
(being distracted by a newly arrived SDR)

[lamaral]

Is the V6.14beta already running on Linux?

Yes. I downloaded the heatherx11.zip file and it compiled straight away. Not running on a RPi tho.

OK, at least it sounds promising! Where did you download it from?

By the end of the first post here: https://www.eevblog.com/forum/metrology/lady-heather-v6-beta-for-windows-exe/

There is a link to tinyupload.com. I downloaded this file, extracted, went into the folder and issued "make". That did it.

An update on my GPSDO: It has been running for about an hour. I live in an apartment, so it's kinda hard to get a good view of the sky. My GPS antenna is one of those black squares with a magnet on the bottom, sitting on the balcony railing.

GPSDO acquired lock,  TFOM 2, FFOM 0, mode fixed. Looking good so far.

Only problem is a "#OPERATION ALARM ----------------------------[Antenna]" that doesn't go away. Ideas?

Code: [Select]

UCCM> stat

       - UCCM Slot STATE -

1-1 #Now UCCM STATUS ----------------------------[Alarm]
1-2 #Before UCCM STATUS -------------------------[OCXO Warmup]
2-1 #Reference Clock Operation ------------------[Not Used]
2-2 #Current Reference Type ---------------------[Ext Clock]
2-3 #Current Select Reference -------------------[GPS 1PPS]
2-4 #Current Reference Status -------------------[Available]
    #GPS STATUS ---------------------------------[Available]
    #Priority Level -----------------------------[EXT->GPS]
    #ALARM STATUS
    #H/W FAIL -----------------------------------[NONE]
    #OPERATION ALARM ----------------------------[Antenna]
    PLL STATUS ----------------------------------[Enable]
    Current PLL MODE ----------------------------[LOCK 2 MODE]
"Command Complete"
 UCCM> syst:stat?
-------------------------------------------------------------------------------
UCCM-L8  serial number SE2F302882  firmware ver 1.0.0.3-02 GPS(or Ext) mode   
-------------------------------------------------------------------------------
Reference Status __________________________   Reference Outputs _______________
XXExt Ref : Unknown[LOS]                                                       
                                              TFOM     2            FFOM      0
                                              UCCM A Status[Master]           
                                                                               
>>GPS :     [phase : +2.433E-8]                                               
ACQUISITION ................................................ [ GPS 1PPS Valid ]
Tracking:  5 ___   Not Tracking:  5 _______   Time ____________________________
PRN  El  AZ  CNO   PRN  El  Az                GPS      21:04:11     23 DEC 2020
  4  11 314  39      2   8  40                GPS      Synchronized to UTC     
 16  18 296  38      5  21  68                ANT DLY  +0.0E+0                 
 18  41 176  39      9   5 348                Position ________________________
 26  50 291  49     25  34 126                MODE     fixed                   
 31  46 226  42     29  69  68                                                 
                                              FIX LAT  N  xx:xx:37.804         
                                              FIX LON  E  xx:xx:44.506         
                                              FIX HGT           +54.95 m       
                                                                               
                                                                               
                                                                               
                                                                               
ELEV MASK  5 deg                              ANT V=5.112V, I=28.840mA         
-------------------------------------------------------------------------------
Temp = 37.500 / Antenna
"Command Complete"

[wkb]

Sure, can you please do a SYST:STATUS? command?

I bet you are using a passive antenna -> no antenna supply current -> ALARM!

Wilko

[lamaral]

The syst:stat? was a little further down on my code snippet, but here it is again.

As far as I know, my antenna is active. You can even see the antenna using about 28mA.

Code: [Select]

UCCM> syst:stat?
-------------------------------------------------------------------------------
UCCM-L8  serial number SE2F302882  firmware ver 1.0.0.3-02 GPS(or Ext) mode   
-------------------------------------------------------------------------------
Reference Status __________________________   Reference Outputs _______________
XXExt Ref : Unknown[LOS]                                                       
                                              TFOM     1            FFOM      0
                                              UCCM A Status[Master]           
                                                                               
>>GPS :     [phase : -2.117E-9]                                               
ACQUISITION ................................................ [ GPS 1PPS Valid ]
Tracking:  5 ___   Not Tracking:  5 _______   Time ____________________________
PRN  El  AZ  CNO   PRN  El  Az                GPS      21:20:34     23 DEC 2020
  4   9 307  39      2   2  39                GPS      Synchronized to UTC     
 16  25 298  39      5  22  60                ANT DLY  +0.0E+0                 
 18  48 174  38      9   6 343                Position ________________________
 26  57 288  49     25  27 129                MODE     fixed                   
 31  40 220  48     29  61  70                                                 
                                              FIX LAT  N  xx:xx:37.804         
                                              FIX LON  E  xx:xx:44.506         
                                              FIX HGT           +54.95 m       
                                                                               
                                                                               
                                                                               
                                                                               
ELEV MASK  5 deg                              ANT V=5.112V, I=28.800mA         
-------------------------------------------------------------------------------
Temp = 38.000 / Antenna
"Command Complete"


[wkb]

The syst:stat? was a little further down on my code snippet, but here it is again.

As far as I know, my antenna is active. You can even see the antenna using about 28mA.

Ooops... sorry, I did not scroll down, sorry about that! All looks identical, scrollable or not 😑
Short of assuming that the antenna current is higher than what the UCCM prefers  I have no ideas to offer, sorry.

I had the same error that was triggered by me feeding a shared antenna usng a biasT. So no current for the UCCM to measure. I kludged a resistor on the antenna connector to fool the UCCM   

[cdev]

Unless your apartment's balcony railing is an abnormally wide and flat one (its quite possible it is, but also quite possible its not) you likely would benefit from using a flat piece of metal or something like an old CD/DVD as a ground plane, place it so it is level in both directions and its placement approximates the horizon, and tape it with some weatherproof tape. The larger it is the better, and the improvements will be noticeable up to maybe 200 mm. Depending how much sky is visible, this could easily be your main problem.

Those kinds of antennas are designed to be placed on a flat car roof. They may resonate way off the desired frequencies when operated without at least a minimally sized GP. (it depends on the manufacturer's specifications, a good rule of thumb is use as much as you can)

Also, make sure its stable in the wind and rain and that your antenna is waterproof.

Curious about your RX-888- how well that works. Also, will it run under Linux?

[wkb]

Well.. progress has been made: LH compiled without issues on Armbian Linux and is now running on my OrangePi Zero. If that test proves succesful I will try ti shoehorn it into the little space left in my GPSDO enclosure.

[wkb]

Has anyone ever seen this behaviour:

- Operation mode is alternating between "Recovery" (in yellow font) and "Locked" (in green font).
- FFOM forever stays in INIT (red font)

Previously this Trimble UCCM was stuck in "Settling" (yellow) Operation mode. I feel it is suspect that the white Loop graph is always 0 (zero)?

Thoughts?
Wilko

[wkb]

The Samsung UCCM in the meantime has been 'canned' in a surplus aluminium enclosure. It has grown an 8 port distribution amplifier for the 10MHz which started life as a video distribution amplifier. And it has had an OrangePi Zero running Armbian fitted. The OPi runs LadyHeather which allows me to monitor things via the network using VNCviewer.

Wilko

[lamaral]

Very nicely built, Wilko!

Since we are here, one of my plans for the GPSDO is to use it as a reference for my HackRF, but it requires requires a square wave in the clock input. Should I just use the one from pin 23 or should I start looking into some circuitry for getting a square wave out of the sine output?

[wkb]

I myself put a small standalone OCXO in my hackRF.  But *be careful*, hackRF requires a 3V clock, do not let the UCCM kill it, measure the output first, as it might be too high.

https://www.reddit.com/r/hackrf/comments/32s93g/hackrf_external_clock_with_lvcmos/

Wilko

[lamaral]

So, long holiday, too much free time on my hands....

After having a look around the board, I came across the flash memory and thought to myself: what if I dump its contents? After some trial and hacking together a EEPROM reader, success.

I managed to get a full flash dump. This will be the very first time I "reverse engineer" a firmware, but so far, looks promising.

Below is the binwalk output of the dump file:

Code: [Select]

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
361           0x169           Xilinx Virtex/Spartan FPGA bitstream dummy + sync word
8397          0x20CD          LZMA compressed data, properties: 0x8A, dictionary size: 0 bytes, uncompressed size: 40 bytes
680533        0xA6255         Ubiquiti firmware header, third party, ~CRC32: 0x0, version: ":CURR:THR"
680697        0xA62F9         Ubiquiti firmware header, third party, ~CRC32: 0x0, version: ":CURR:THR?"
852329        0xD0169         Xilinx Virtex/Spartan FPGA bitstream dummy + sync word
994286        0xF2BEE         LZMA compressed data, properties: 0xC0, dictionary size: 0 bytes, uncompressed size: 33792 bytes
1090379       0x10A34B        LZMA compressed data, properties: 0x90, dictionary size: 0 bytes, uncompressed size: 33 bytes
1550521       0x17A8B9        Ubiquiti firmware header, third party, ~CRC32: 0x0, version: ":CURR:THR"
1550685       0x17A95D        Ubiquiti firmware header, third party, ~CRC32: 0x0, version: ":CURR:THR?"

If anyone else out there is interested, I'm attaching to the post the full dump.

EDIT: After running a strings command against the dump file, I got about 632 lines that look like possible commands. Some of them are repeated, with just some weird prefix, but they might yield something useful. Full list is contained in the commands.txt file.

[ve7xen]

Thanks for the firmware image!! This is very interesting.

I've made a little bit of progress reversing the image. binwalk was not very useful, what it finds is totally useless aside from the bitstream identifiers. However with some poking around I was able to figure out a little bit of what is going on here. The flash is split into two main regions 'bank 0 [0x00000-0x1ffff]' and 'bank 1 [0xd0000-0xeffff]'. Each contains a header from offsets 0x0-0xff indicating the sizes and versions of the two parts, and the fpga bitstream file (with some header information that might be proprietary or might be Xilinx) follows at 0x100, in both banks it is 340697b long. The AVR32 firmware immediately follows and is variable size, but seems to just be filled with 0xff until the end of the bank. There is some extra stuff starting at 0x1ffff that I am not sure about, it looks like a similar header but doesn't have any actual data after.

The AVR32 image is loaded by the bootloader at address 0x80010000.

Couple commands that may be known but aren't shown in the help on my unit:

Code: [Select]

UCCM> IMAGE:INFO?

-------------- IMAGE BANK INFO --------------
 * BANK 0
   MAKE TIME  : 2012/10/24 23:14:54
   F/W Info.  : 1.0.0.2 (size = 416396bytes)
   FPGA Info. : 1.0.0.1 (size = 340697bytes)
 * BANK 1
   MAKE TIME  : 2014/02/10 16:58:38
   F/W Info.  : 1.0.0.3 (size = 436120bytes)
   FPGA Info. : 1.0.0.2 (size = 340697bytes)
---------------------------------------------
 * CPU FLASH  : Copy from Bank1
   MAKE TIME  : 2014/02/10 16:58:38
   F/W Info.  : 1.0.0.3 (size = 436120bytes)
   FPGA Info. : 1.0.0.2 (size = 340697bytes)
---------------------------------------------
   Next Boot from Bank1
"Command Complete"
 UCCM> DEBUG

 uccm_rev_02 1.0.0.3> pll state

--------------------------------------------------------------------- [ON] ---
  OCXO PULL-IN RANGE : lowPpm := -0.315, upPpm := 0.298
   set PULL-IN RANGE : 30 ppb
           EFC RANGE : 000CCCCC ~ 00000000
------------------------------------------------------------------------------
  Current Reference  : GPS_REF (ok)
* Locking_2 (531120 - 30) : uni_polar(0), bi_polar(0) 
  phsErr = -8.430, tiE = -2 ns
  phsAcc = -1094.138, acqDac = -101.635, holdDac = -34.191
  dacOffset = 000576F7 (0006A9E7(h) - 0006662F(f)), dacValue = 00057692
------------------------------------------------------------------------------
  pllIntSetCount = 4996107, pllTaskClrCount = 4996107
------------------------------------------------------------------------------
  Monitoring Ref. ppm = 0.000
------------------------------------------------------------------------------
 InhibitAlignFlag(off), DuringAlign(off)
 alignCheckFlag(off), alignExecution(off)
 alignCheckDelay(0)
 uccm_rev_02 1.0.0.3> system

------------------------------------------------------------------------------
 TIME        : 2021/01/05 01:20:26 (GPS)
 Temperature = 30.500
------------------------------------------------------------------------------
 SYSTEM MODE : WCDMA
   ACT STATE : MASTER (non-Protect)
        REF  : GPS_REF (ok)
------------------------------------------------------------------------------
    x-ACT in : L(other)
      A/S in : H(slave)
     Ref_sel : L(GPS)
     mode_id : H(WCDMA)
------------------------------------------------------------------------------
 Task Counts : DebugTask(49960545), EngineTask(58588941)
               TodTask(49901745), CtrlTask(191634117)
               PllTask(99920939), BackUpTask(99503426)
               TodEvenTaskCount(99563963)
------------------------------------------------------------------------------
  Int Counts : pllIntCount(4996109 - 4996109), todIntCount(2498054)
               dacIntCount(499610883 - 499610794), twIntCount(4996108 - 4996108)
------------------------------------------------------------------------------
-----------------------------------
 TIME := 2021/01/05 01:20:26
 LAT   := N xx:xx:03.737
 LON   := W xx:xx:21.920
 HIGT := +13.013 m
 uccm_rev_02 1.0.0.3> scpi



[lamaral]

Thanks for chipping in, VE7XEN! Your info is extremely useful and shows me that I was going in a totally different direction.

With your info, I'll try to start looking into the firmware, although I don't expect to have much success since this is far from being my field of expertise.

One thing that I noticed is that the "event log" also seems to be stored on the flash memory (found it with the strings command). You can even see it bloated with events on the dump because apparently, when I powered on the flash to dump it, it also powered on the uC on the board.

[wkb]

Hmm...would be interesting to see if I could do the same for the Trimble UCCM I have here. Obviously Sam & Trim are not identical hardware, but the idea is interesting.

Did you document the flash "extraction" procedure?

Wilko

So, long holiday, too much free time on my hands....

After having a look around the board, I came across the flash memory and thought to myself: what if I dump its contents? After some trial and hacking together a EEPROM reader, success.

I managed to get a full flash dump. This will be the very first time I "reverse engineer" a firmware, but so far, looks promising.

Below is the binwalk output of the dump file:

Code: [Select]

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
361           0x169           Xilinx Virtex/Spartan FPGA bitstream dummy + sync word
8397          0x20CD          LZMA compressed data, properties: 0x8A, dictionary size: 0 bytes, uncompressed size: 40 bytes
680533        0xA6255         Ubiquiti firmware header, third party, ~CRC32: 0x0, version: ":CURR:THR"
680697        0xA62F9         Ubiquiti firmware header, third party, ~CRC32: 0x0, version: ":CURR:THR?"
852329        0xD0169         Xilinx Virtex/Spartan FPGA bitstream dummy + sync word
994286        0xF2BEE         LZMA compressed data, properties: 0xC0, dictionary size: 0 bytes, uncompressed size: 33792 bytes
1090379       0x10A34B        LZMA compressed data, properties: 0x90, dictionary size: 0 bytes, uncompressed size: 33 bytes
1550521       0x17A8B9        Ubiquiti firmware header, third party, ~CRC32: 0x0, version: ":CURR:THR"
1550685       0x17A95D        Ubiquiti firmware header, third party, ~CRC32: 0x0, version: ":CURR:THR?"

If anyone else out there is interested, I'm attaching to the post the full dump.

EDIT: After running a strings command against the dump file, I got about 632 lines that look like possible commands. Some of them are repeated, with just some weird prefix, but they might yield something useful. Full list is contained in the commands.txt file.

[lamaral]

I'm still preparing a proper write up, but I can brief you:

I used roughly the steps from here: https://www.flashrom.org/Arduino_flasher_3.3v

The only difference is that I powered my Arduino via normal USB and used a little chinese level converter board between the Arduino and the flash IC. Wires were soldered directly to the Flash IC pin.

You can run "flashrom -p serprog:dev=/dev/ttyUSB0:115200" to check if it identifies your chip model. In my case, it yielded three different models, so I chose the right one with "flashrom -p serprog:dev=/dev/ttyUSB0:115200 -c MX25L1605A/MX25L1606E/MX25L1608E --read fwdump.hex".


To add a little more to the reasoning behind the flash dump: while it's impossible to turn the FPGA bitstream into something useful, reverse engineering the uC firmware should at least yield some information in regards to what is being done by the FPGA in a very high level.

I also hope to be able to figure out how to change the selected reference and other extra settings, if they are not tied to specific firmware versions.

Finally, I have another Samsung on the way. Hopefully it's "the other side of the pair" and we can have a look at some differences between them.

[ZigmundRat]

FWIW, my Symmetricom UCCM units have a 8Mbit Spansion flash (S29AL008) in TSOP48 package, so not so easy to read out. I don't know if I expect the 'hidden' commands to be identical though. I don't have the bandwidth right now to explore that, but I'll update the thread with any new contributions. Thanks for posting - it'll be fun to follow the updates.

[wkb]

FWIW I can confirm that at least the Trimble UCCM does not have the bulk of the hidden commands 😢 And worse: would have loved to have the DEBUG command. Alas.. not there 😵

FWIW, my Symmetricom UCCM units have a 8Mbit Spansion flash (S29AL008) in TSOP48 package, so not so easy to read out. I don't know if I expect the 'hidden' commands to be identical though. I don't have the bandwidth right now to explore that, but I'll update the thread with any new contributions. Thanks for posting - it'll be fun to follow the updates.

[ve7xen]

I've pretty much broken this completely open now. There are quite a few undocumented commands in both the main CLI and the debug one. I'll work on documenting all of them soon.

Also, something I did poking around is now causing my previously-working module to get pegged in EFC Exceed, and it is now clearly off frequency, so be careful... still haven't quite worked out how to get it back, if that's possible.

I also have a non-working Trimble module kicking around, might give ripping the image a try, but I don't think it will be very fruitful due to the TMS320. Ghidra at least doesn't support it. Maybe some basic analysis would find something.

[lamaral]

Hey ve7xen, would you mind sharing some more info on what have you tried with the firmware?

In the Samsung case, it's an AVR32 (UC3), which Ghidra seems to support.

Yesterday I spent some time on Ghidra (don't get me wrong, I have almost no clue of what I'm doing) and noticed that while the analysis yielded some stuff, it was still getting lost a lot with the strings. I fixed a lot of them manually to see if running the analysis again would make things better, but so far, not much achieved.

If you would like, I can put the Ghidra project on GitHub.

Luiz

[ve7xen]

Hey ve7xen, would you mind sharing some more info on what have you tried with the firmware?

In the Samsung case, it's an AVR32 (UC3), which Ghidra seems to support.

Yeah, I've decompiled and tagged some sections of the code, figured out the command parser and handler table (their implementation is pretty funny, to support SCPI abbreviations they just duplicate the command variants and do simple string matching, so there are like 16 copies of the same command in the table). Also mapped out most of the AVR32 peripherals. The biggest problem Ghidra seems to have with it is sometimes the disassembler gets a bit tripped up and it gets out of sync due to there being 2-byte and 4-byte instructions. It also sometimes thinks pointers are instructions, which can really mess up the interpretation. It's not magic, and requires human effort unfortunately.

It's quite a bit of work doing the archaeology to find meaning in the stream of instructions. You need to kind of start to work from known starting points - certain strings that are part of code you are interested in, the entry point, peripheral register accesses etc. and work out from there following references and function calls labelling stuff as you go. If you don't have the memory map correct, it will make no sense at all, most calls are indirect.

I do plan to post my Ghidra work when I feel like I've finished with it.