Ublox-based GPSDO peculiar baudrate problem - SOLVED!

[Aiy]

Hi All,
I'm trying to figure out what's wrong with my BG7TBL GPSDO. It's not a particularly fancy unit or anything, but still fun to do work on.
I have the version of the GPSDO shown in the picture over here (Photo by JBooth): https://www.eevblog.com/forum/testgear/new-gpsdo-bg7tbl/msg2147224/#msg2147224

My unit only lights up the RUN/ALARM LED and never achieves lock anymore. It did work when I got it and I used it for quite a while, then it suddenly stopped and I put it away.

My unit has an unlabeled ublox equivalent addon board in conjunction with an ATMEGA328 and a few other chips on the PCB.
I've probed the RX/TX lines going between the MCU and the GPS and found that the MCU sends the following byte strings twice to the GPS (9600 baud, 8bit, no parity)

Code: [Select]

b5 62 06 31 20 00 00 01 00 00 32 00 00 00 e8 03 00 00 01 00 00 00 00 00 00 80 00 00 00 00 00 00 00 00 eb 00 00 00 e1 a7
b5 62 06 31 20 00 01 01 00 00 32 00 00 00 01 00 00 00 01 00 00 00 00 00 00 80 00 00 00 00 00 00 00 00 eb 00 00 00 f8 da
The GPS should respond to this I believe with some ACK/NAK, but I never see any wiggles on the GPS -> MCU line when the bytes are sent.

As I was power-toggling the GPS I saw the line wiggle a bit, but the bytes did not make any sense at 9600 baud, so I started troubleshooting further. After a bit of experimentation with an oscilloscope I figured out that the GPS sends out a boot message with the strange configuration of 7200 baud, 7 bit, no parity. The boot message is

Code: [Select]

$GPTXT,01,01,02,u-blox ag - [url=http://www.u-blox.com]www.u-blox.com[/url]*50
$GPTXT,01,01,02,HW  UBX-G70xx   00070000s *04
$GPTXT,01,01,02,ROM CORE 1.00 (59842) Jun 27 2012 17:43:52*59
$GPTXT,01,01,02,PROTVER 14.00*1E
$GPTXT,01,01,02,ANTSUPERV=AC SD PDoS SR*20
$GPTXT,01,01,02,ANTSTATUS=DONTKNOW*33
$GPTXT,01,01,02,LLC FFFFFFFF-FFFFFFFD-FFFFFFFF-FFFFFFFF-FFFFFFF9*53
Which I feel makes sense for a chip to send out at startup.
The fact that the GPS sends out anything at all tells me that the chip is not dead, but the weird discrepancy in baud rate and bits per byte is confusing. Has anybody got any ideas?
I've removed the on-board battery and shorted the pads to try to make the GPS return to factory / COLD boot, but no luck.

Has anybody got any ideas?

Best regards,
AIY

[Aiy]

Wow, that was alot of work, but I solved my problem.

TL;DR:
The version of BG7TBL GPSDO I have uses two TIMEPULSE outputs (One at the regular PPS position, the second on U-Blox footprint position 1).
The problem on my board was that SAFEBOOT_N signal is shared with TIMEPULSE on pin 1, and the pin was pulled low at GPS boot, forcing it into this strange mode.
I finally solved it by strapping a 100Ohm resistor pull-up to 3.3V and now my GPS boots again.


The longer story:
I got myself a second u-blox GPS, a gen 6 (easily available from many sources). I thought I could swap the GPS blocks and replace my bad one  .
I desisted from throwing the NEO7 block in the recycling bin and decided to solder it to the breakout board I got with the Neo6.
To my amazement, the Neo7 which I believed to be broken booted up when I plugged that in and started looking for satellites and it got a fix after a while. 
I thought perhaps this was due to some reflow of the soldering on the GPS daughterboard, so I sat down and swapped the GPS's again.
However, when I plugged in the GPSDO it was back at the strange baud rate and no joy. 
I then took a better look at what could be different between the two boards, and the Neo6 has an external I2C flash, so I thought that might mean that my Neo7 accept a I2C flash on the same pins. I spent some hours studying the boot data on the Neo6 and tried replicating it with an arduino in I2C slave mode I had lying around, strapped that in to the same pins, but the traffic generated by the I2C/DDC pins was not correct I2C transactions. 

Finally I arrived at the solution, and jumpered the TIMEPULSE2 / SAFEBOOT_N pin to 3.3V and turned it on, lo and behold - 9600baud data on the UART. It was this pin that was preventing the GPS from booting up.
Its been an interesting investigation, thats what hobby is all about 

Just wanted to share if anybody runs into a similar issue.

Best regards

[Solder_Junkie]

There are easy to use boards from eBay containing fake Ublox modules. I have a Neo 6 and a Neo 7 board, I replaced the fake module on the latter with a genuine Neo M8T.

These particular boards have micro USB sockets making the modules easy to configure with the Ublox software, although beware the modules are not identical internally to the genuine ones. My Neo 7 fake module has a sticker showing Neo-M8N!

The boards are cheap enough, similar ones often don’t include USB. See eBay item 195486735732

SJ

[james38]

I know this is a very old thread, but
I had exactly the same problem.

@Aiy
First of all, thank you for your feedback.
I would never have thought of how to solve this.

The red ALM LED stayed on and the green one only flashed briefly and was then always off.

The first thing I noticed was that the capacitor had fat cheeks like a squirrel.
The measurement showed 24uF and an ESR of 68 Ohm.
Replaced it, but the error remained.

I have now measured the LED, the series resistors and also the ones that go to the 74HC84. So far everything is OK.
I wonder what else could be pulling the signal down besides the 74HC84D. Something must have caused it.

I will try replacing the 84D and see what happens.

[james38]

It is not yet time for me to replace the 74HC86D.
The workaround with the 3.3V pull-up on pin 1 works.

I have now measured the resistance of pin 1 against ground and measured fluctuating values ​​here.

They range from 2.5 MOhm to 7 MOhm.
If you measure shortly after switching off, the value drops from 12 MOhm to around 6 MOhm.
Sometimes I measure 2.5 MOhm after a short time, but that is very sporadic.

I have now desoldered the 300 Ohm resistor as a test and since then the GPSDO has started again without any problems.
You could also use that as workaround 2.
You don't need the LED inside anyway.

Just for information.

[james38]

I have now found the actual cause.
It was the LED itself.

The forward voltage here is 1.36V, which is too low compared to the usual 1.8V.
This means more current flows and that lowers the voltage  on the other site too much.
I measured the other one for comparison and it was around 1.65V

I used a different LED (3mm green 1.8v) as a test and it worked straight away without any problems.