-
So same behaviour here.
Pin 1 sending 1pps.
GPS Module says: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 00070000 FF7FFFFFo*69
$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-FFFFFFFF-FFFFFFFF-FFFFFFFF-FFFFFFFD*2C
$GPRMC,110520.40,V,,,,,,,151220,,,N*7B
$GPVTG,,,,,,,,,N*30
$GPGGA,110520.40,,,,,0,00,99.99,,,,,,*65
$GPGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*30
$GPGSV,3,1,12,02,28,241,,04,01,087,,05,50,297,,06,08,200,*7D
$GPGSV,3,2,12,07,69,088,,09,36,086,,13,19,266,,14,06,158,*76
$GPGSV,3,3,12,16,09,025,,28,00,162,,29,00,309,,30,64,183,*76
$GPGLL,,,,,110520.40,V,N*49
$GPRMC,110521.00,V,,,,,,,151220,,,N*7E
$GPVTG,,,,,,,,,N*30
$GPGGA,110521.00,,,,,0,00,99.99,,,,,,*60
$GPGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*30
$GPGSV,3,1,12,02,28,241,,04,01,087,,05,50,297,33,06,08,200,*7D
$GPGSV,3,2,12,07,69,088,20,09,36,086,27,13,19,266,26,14,06,158,24*73
$GPGSV,3,3,12,16,09,025,25,28,00,162,,29,00,309,,30,64,183,31*73
$GPGLL,,,,,110521.00,V,N*4C
$GPTXT,01,01,02,ANTSTATUS=INIT*25
Regarding this:
https://portal.u-blox.com/s/question/0D52p00008HKCf6CAH/not-a-real-m8n-i-think
I think its a fake M7.
Would be interesting if a genuine one can output also 1pps at pin 1? :-D -
ARGHHHH...
Started to readout the Atmel but my usbasp was jumpered wrong.. I think 5V on nRST..
Now the ALM is permanent on and the ACT is off..
But i think the GPS Module and the Atmel is still working on the UART?
I read the think out now. Attached the HEX files.. Will order a new Atmel and hopefully the hex is correct and its working again than..
Edit: I think the readout is garbage...? But on the UART is still the same communication..
I think PortC is gone.. All LED and unfortunally also the ADC Pin? I'm unsure.
Now where can i get a proper hex file? I will order a new Atmel but then?
And my UART communication.
-
Ok, it looks like the Atmel is not doing anything important?
I poked a bit around and found pin 2 is outputting 1.0000kHz and 13 is outputting 1.0003khz but it looks like these pins aren't going anywhere?
Maybe i will lift the Atmel up and look under him..
I think the Atmel is only configurating the GPS Module and then measuring the voltage at / under a specific voltage he is switching off the red LED?
And he is switching the green led but i don't know for what he is looking at, maybe some GPS Module message?
If so, i think there are 100k in series on the GPS TX pin or?
I mailed to BG7TBL and asked for a new Atmel / the binary file.. maybe they can help me. Could there be some other issues?
Regarding my counter it looks like its still functioning beside the LED signaling..
Edit:
One thing wha makes me curious.. The 5V i accidantly supplied to the Reset Pin has a 10k in series (USBASP self programming jumper mounted , other signals jumpered to 3.3V) so why could this destroy the Atmel?
If the Atmel is really only "houskeeping" and if don't get the binary / new Atmel i think i can rewrite the code. Config message is already collected..
I only need to know the specific "good" voltage border or?
Edit2:
One thin what makes me curious is the 5V i accidantly supplied to the RESET has 10k in series (USBASP self programming jumper, other signals were set to 3.3V with the other jumper). How could this destroy a Atmel?
Edit 3:
Working again, the series resistor from GPS TX-> Atmel was faulty probably from my solder connection to my LA..
Now ACT is flashing again (Atmel is looking for GPS Module messages..)
Now i have to check if the ALM Led is going off at any time. Currently Green is flashing, red is permanent on..
Edit 4:
Its working. everything is fine again. Found another broken / cracked cap and cleaned the whole pcb / resoldered some pins..
Now the ALM is not flashing any longer, its permanent on and if the 10MHz is locked and accurate it is permanent off..
So maybe my "fix" issues are also gone now. I think cleaning / resoldering was the clue.. Now i have a "good" GPS antenna on its way from china but no need anymore :-( :-D
Would be still interesting if an genuine NEO-M8N / M9N will output 1pps on safeboot_n but i don't think so. maybe a genuine M7N with the "reserved" pin.. which was the chip which was copied..?
-
Yes, they somehow configured pin1 of the GPS module to output a 1PPS signal, see the attached photo. The LED D7 is flashing @ 1 Hz while D2 is flickering @ 1 kHz (just barely visible when quickly turning the head). Both these signals are routed via 18R resistors to the HC86 to the phase comparator (1 kHz) and pin 12 as where one of the XOR gates is used as an output buffer for the 1 Hz signal.
I also checked ublox datasheets and was surprised to find pin 1 more or less described as "reserved for future use"... Maybe the Chinese "copycats" have already entered the future while we're lacking behind...
Btw -- my GPSDO is a rather early model, the date on the silkscreen says 2017-9-23.
P.S. Please disregard the flux mess at the SMA connector. It had been soldered in skew and I just couldn't leave it that way -- been too lazy to clean up afterwards
Edit: Attached the GPS module config sequence with the data in hex format.
The footprint matches a Ublox NEO-M8 module (this one has a timepulse2 output on pin 1). The init sequence starts with 0xb5 0x62, looks like a UBX packet to me.
PS: ROM CORE 1.00 hints a NEO-7, also UBX-G70xx hints a 7-type core. But you're right, the footprint definitely is not a NEO-7 but rather a NEO-8.
PPS: the init sequence is a UBX-CFG-TP5 command that configures the timepulse:Code: [Select]-3.3773239E-07,B5,, header
1.1436623E-03,62,,
2.2876623E-03,06,, class 6 (CFG)
3.4316623E-03,31,, id 0x31 (TP5)
4.5756624E-03,20,, len=32 byte
5.7196624E-03,00,,
6.8636624E-03,00,, tpIdx=0, TIMEPULSE output
8.0076624E-03,01,, version=1, Message version 1
9.1516624E-03,00,, reserved
1.0295662E-02,00,, reserved
1.1439662E-02,32,, antCableDelay=50ns
1.2583662E-02,00,,
1.3727663E-02,00,, rfGroupDelay=0ns
1.4871663E-02,00,,
1.6015663E-02,E8,, freq=1000Hz
1.7159663E-02,03,,
1.8303663E-02,00,,
1.9447663E-02,00,,
2.0591663E-02,01,, freqIfLocked=1Hz (not used)
2.1735663E-02,00,,
2.2879663E-02,00,,
2.4023663E-02,00,,
2.5167663E-02,00,, pulseLenRatio=0x80000000 (2^-1, 50% duty cycle)
2.6311663E-02,00,,
2.7455663E-02,00,,
2.8599663E-02,80,,
2.9743663E-02,00,, pulseLenRatioLocked=0 (not used)
3.0887663E-02,00,,
3.2031663E-02,00,,
3.3175663E-02,00,,
3.4319663E-02,00,, userConfigDelay=0ns
3.5463663E-02,00,,
3.6607663E-02,00,,
3.7751663E-02,00,,
3.8895663E-02,EB,, flags=0xEB: active:1,lockGnssFreq:1,lockedOtherSet:0,
4.0039663E-02,00,, isFreq:1, isLength:0, alignToTow:1,
4.1183663E-02,00,, polarity:1, timeGrid:GPS
4.2327663E-02,00,,
4.3471663E-02,E1,,
4.4615663E-02,A7,,
It configures the TIMEPULSE output to 1kHz, 50% duty cycle. -
ARGHHHH...
Started to readout the Atmel but my usbasp was jumpered wrong.. I think 5V on nRST..
Now the ALM is permanent on and the ACT is off..
But i think the GPS Module and the Atmel is still working on the UART?
I read the think out now. Attached the HEX files.. Will order a new Atmel and hopefully the hex is correct and its working again than..
Edit: I think the readout is garbage...? But on the UART is still the same communication..
I think PortC is gone.. All LED and unfortunally also the ADC Pin? I'm unsure.
Now where can i get a proper hex file? I will order a new Atmel but then?
And my UART communication.
The init sequence is similar, only it configures two timepulse outputs, one to output 1Hz, the other one to output 1000Hz. I guess that matches what you see on the pins of the module?
The module itself is quite a Frankenstein. It poses as a Ublox type "7", but the footprint is neither NEO-7 or NEO-8. Could be a clone (but why doesn't it have a Ublox label on it, then?), or a customer-specific module that was actually designed by Ublox. Could be excess stock that is being sold without label. -
My impression of both the GPS module and the OVCXO that get used on this particular GPSDO is that all of them are salvaged from decomissioned telecom equipment. Some of the oscillator cans in the photos show traces of corrosion and appear to be "well aged"... This doesn't necessarily need to be a bad thing, but it could mean that these are special versions that had been specified by customer contract, so there may not even be proper spec sheets publicly available. As a result to having the equipment scrapped, possibly all the labels had to be removed to make it impossible to (easily) trace back the components to the OEM.
So my best bet would be that the stuff used is probably retired high-quality professional components that's been given another "life" in the hobbyist's world
-
My OCXO has a label, but yes it looks like customer specific for all information i found.
GPS module has no label to be not a fake . Often these modules were sold as M8N but they are copycats..
-
Here are the 2 commands in "readable / copyable":
Command 1:
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
Command 2:
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
Would be nice i someone with a genuine Neo-M8 / M9 can check if Pin1 is working as 1pps after these two. -
Today I decided that I want to understand the performance and the "inner workings" of the GPSDO a little better so I tought to compare it against another, very decent reference that I've got, a source based on an LPRO-101 rubidium oscillator. For a long(er)-term comparison, an oscilloscope with a Ch1 - Ch2 phase difference measurement function is a convenient instrument I used a Rigol DS2000A which has the additional advantage of being able to display a graphical representation of the measurement history.
The GPSDO had been running before for several hours with the antenna placed outside for best satellite reception. In this configuration, I powered up the Rubidium oscillator and recorded this "phase walk graph" of the lock procedure. The horizontal scale of the history graph of all the scope sreenshots is 50s/div, so a little less than seven minutes are regorded over the whole width. It's amazing how little drift the Rb reference has, directly after lock. Total drift is no more than 90° over four minutes time, this equals a frequency tolerance of no more than 1mHz or an accuracy of 10^-10 between the two sources.
Fully warmed up, the phase walk looks like this - that's pretty amazing for two, non-synced 10MHz oscillators compared over almost seven minutes and staying within a band of 30° phase margin vs. each other.
I assume the slow-speed drift effect of the phase is to be blamed on the GPSDO due to ever changing satellite coverage. Already before, I found out that the orientation of the GPSDO has some effect on the frequency, so I turned it by 90° around the logitudinal axis (to rest it on the slim face), later I further tuned it by 180° on the opposit slim side. The phase drifted by almost three vs. almost six full periods of the signal until the PLL stabilized again. But even in the worst case, this equals just a momentary frequency drift of 50mHz or 5*10^-9.
To visualize the phase drift differently and in order to better understand the following measurement, I observed the two oscillators on the screen with infinite persistance enabled over a period of five minutes. I triggered on the square wave output of my Rb reference ot keep the oscilloscope's trigger jitter low. In order to avoid too much "trace smearing", I disabled vector mode -- which proved to be unnecessary. Once again, the total phase walk stayed within a very narrow band of less than 14ns which equals approx. 50° at 10MHz.
Since it had been reported that the 1Hz output of the "simple" GPSDOs suffers from a deterministic jitter, I also wanted to try to visualize that. The scope was now triggered on the 1Hz GPS output while every time, a trace of the Rb reference square signal has been recorded as well, once again with infinite persistance. This time, only 20 traces were logged so I could be sure that during these 20 seconds, the statistical phase drift between the two oscillators would stay below 5ns. It became directly obvious that the 1Hz output jitters within approx. 20ns (triggered on the rising edge, should have checked the falling edge as well...). What the screenshot doesn't show is that the jitter followed actually a very discrete pattern of apparently four traces from left to right within the margin to repeat again from the left. This was superimposed by some small drift which resulted in the pattern shown.
The second instrument in my basement that's almost ideal to examine accurate frequencies and their fluctuations is the hp 53310A modulation domain analyzer ("frequency microscope" as a fellow eevblog forum member very creatively and appropriately called it). This instrument displays the signal frequency vs. time on a very accurate scale. First, I took a look at the outputs of the GPSDO and then the Rb reference. The settings of the instrument were identical, yet the output of the GPSDO was found more "spikey" and the stanard deviation of the frequency was found to be slightly higher. Altogether I've got to add that these measurements are right on the edge of what's possible with the MDA. The internal time base (in this case the MDA's well-aged and warmed up internal hp 10811 OCXO) is in the same ballpark as the GPSDO jitter-wise while the Rb reference is slightly better.
Finally, I wanted to understand how much effect the PLL loop filter in the GPSDO has on frequency stability, so I tested with the MDA both the 1kHz signals at the inputs of the phase comparator (which is quite an "important word" for XOR gate...). And here it really becomes obvious how much remaining frequency modulation is present on the GPS module output while the divided OVCXO signal inside the GPSDO is virtually "clean as a whistle". So it gets obvious that it isn't such a good idea to directly use the frequency output of a standard GPS module for applications that require a clean signal. The slight error of the absolute frequencies mesured on the MDA is the result of thetimebase not being 100% accurately adjusted (but I'ld say a tolerance of 8*10^-9 isn't too bad either for an oven ).
Hope you enjoyed the description of my tests and findings. I guess that except for the sensitivity towards its orientation vs. earth's gravitational field, this gpsdo is pretty decent, especially considering its price.
-
I got one of these smaller box GPSDOs recently from an eBay seller for $91 US including active antenna and wall wart. Took a month to get from Hong Kong. It actually went from Hong Kong to New York in a few days... then Delaware, California, Florida. Why?
https://www.ebay.com/itm/NEW-PLL-GPSDO-10MHz-Sinwave-GPS-DISCIPLINED-OSCILLATOR-2020/402268690713?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649
Mine is different inside that the other pictures I see in this tread. Maybe mine is more like the bigger boxes?
Vectron C4550A1-0213 OCXO
missing GPS battery
ublox NEO-7M
Altera EPM3064A PLD
ATMega6A
No BG7TBL markings inside or out.
Front Marking: 20127A-Y170-201102
Back Marking: GPSDO 2017-12-09 20127A-Y169-200421
PCB Marking: 20200421 20127A-Y172-200421
Had to invert GPS serial output.
Seems to work fine. I've had it running for several days. Just now stopped it to take these pictures. I don't remember how long it took to lock, but it wasn't too long. Put the supplied active antenna on a window sill (inside), and I think it was seeing 13 satellites within a short time. After it and my two LPRO 101 Rubidiums had run for a few days, I adjusted by LPROs to match. My LPROs have always been about 3mHz offset from each other (about 5 minutes to slip one cycle). Now they're closer. After I tweeked the LPRO pots, it took over 58 minutes for one of them to slip a cycle compared to the GPSDO. The second one took 10 min 38 sec. (I didn't do any second adjustments. This is good enough for me.)
I was actually opening it up to probe the 10kHz signal I was reading about in this thread, and now I'm thinking that I have something different.
-
Looked at 10 MHz output from cold start. It was within 1 Hz in 80 seconds. ALM LED turned off at 5 minutes. Six satellites at that time. Compared with LPRO-101 which does its servo thing for about 200 seconds, then boom, it's there. As TurboTom shows, it settles more, but slowly. As I'm typing this the GPS now sees 12 satellites. I'm measuring this with a BG7TBL FA-2 which is also a recent purchase of mine. I've tweeked the FA-2 reference to the GPSDO also, and I'm very happy with its stability.
-
I want to drive my 2 devices with a 10MHz reference input from my GPSDO.
1. DG922 Rigol: It says 10MHz ref in 1kOhm AC
2. Siglent SVA1032X: It says 10 MHz ref in 50 Ohm. Probably AC? But not sure..
Can i drive both inputs directly from the GPSDO with 1 BNC T Connector + 2x BNC RG316 1m cables? Or do in need a distribution amplifier board?
1k||50Ohm are ~47 Ohm should be ok?
How should i connect the units? Special chain?:
GPSDO -> DG922 + T Connector -> SVA <-Best one?
GPSDO -> SVA + T Connector -> DG922
SVA<-GPSDO + T Connector -> DG922
-
Surgery done..
My device has now a genuine M9 module.
Sweat a bit while dismounting the fake one but they are using good PCB material -> pads survived!
I checked the timepulse settings the M9 can output both needed timepulses.
Unfortunally its working with 34800 instead of 9600.. (buffer overflow with this baud rate )
Have to find out how to send less data (not nmea 4 and high precision..) on the UART to get the atmel back to work (its checking the output from the GPS module but im unsure what the "trigger words" are to get the LEDs back working.
And there is so much configuration stuff you can do.. Need to find out whats best for the gpsdo of the fancy new stuff..
Glad that everything can be stored in flash..
Maybe the atmel TX line has to be left dismounted but im unsure if the atmel checks the answer to his configuration.
If it is not working.. got already an empty one.. then i will programm one myself.
Glad that everything important is done by HW only housekeeping stuff or?
Would there be some benefit (precision / control speed) if im using a lower / higher frequency ? I know i have to mount the other divider resistors..
-
I want to drive my 2 devices with a 10MHz reference input from my GPSDO.
1. DG922 Rigol: It says 10MHz ref in 1kOhm AC
2. Siglent SVA1032X: It says 10 MHz ref in 50 Ohm. Probably AC? But not sure..
Can i drive both inputs directly from the GPSDO with 1 BNC T Connector + 2x BNC RG316 1m cables? Or do in need a distribution amplifier board?
1k||50Ohm are ~47 Ohm should be ok?
How should i connect the units? Special chain?:
GPSDO -> DG922 + T Connector -> SVA <-Best one?
GPSDO -> SVA + T Connector -> DG922
SVA<-GPSDO + T Connector -> DG922
A simple passive power splitter could work, that's just three 16.7 Ohm resistors connected to a single node with one leg and to three coaxial cables with the other leg.
You connect the GPSDO to one cable and the other two cables go to you test instruments. But you loose 6dB.
If you want something more sophisticated: I've put together a 4 channel distribution amplifier that you could DIY with a little effort (minimal SMD soldering required).
Forum link: https://www.eevblog.com/forum/projects/my-10mhz-distribution-amplifier
-
@Noy:
Your SVA1032X has got a dedicated REF IN and REF OUT, so you may connect GPSDO -> SVA1032X (REF In) and with another BNC cable SVA1032X (REF Out) -> DG992. The only disadvantage of this interconnection is that the SVA needs to be powered up to supply the DG with the ref signal (unless the REF buffer runs from the standby PSU of the SVA). -
Yes i know. But i don't want to power up the sva to use the DG.
But maybe you are right and the ref in/out is working without powering up the sva ( sva has not a real power switch...so maybe it works will try.)
But for now first part will be to configure the neo9 to work with the remaining atmel / programm the new one. One advantage to use a new one will be i can use nmea 4.0 default output from neo9 and i can control the "stable" voltage border by myself. Does somebody know the original voltage at which the atmel says "OK"? Forgot to measure it before surgery.. -
Lift the Atmel today and mounted a new one. Now i have to program it.
One thing i noticed, the pin 2 is connected over R33 to the 1khz output (R30).
Now i am quite unsure whats they will do with this pin? Measuring the frequency?
Thought they are measuring the control voltage every x seconds and if there is no change anymore its stable?
Or maybe both?
The neo9 is configrued in his flash, so i only need to rebuild the "supervisor" stuff :
1. led green off, red on
1. power GPS on
2. GPS fix reported on uart
3. Led green on
4. is the frequency stable (voltage + frequency?) or how can i measure stable + correct frequency?
3. Led red off
I connected the output today with old atmel + working neo9 to my counter and it works. But i get sometimes a short frequency "hop" 10.000.000,00 to 9.999.995,2 and intant back to 10....
What can this be? Hopefully its something "old atmel" or no case related...
Would it be good to add a cap to the controlling voltage pin at the ocxo to smooth small / fast voltage changes?
Or at the opamp input?
The atmel is not controlling anything else or?
Like you can See i ripped accidantly the UART traces off.. (Pulled on the connected jumper wires :-( but its fixed instant glue ;-))
The other atmel pin which outputs 1.001khz
Is not connected anywhere.. Don't know whats going on with this pin..
-
In the former version (without the dedicated decimal counters), the Atmel's clock was supplied by the 10MHz OVCXO and the programming arranged an OSC In -> PWM Out 10'000:1 divider. I guess this hasn't been removed from the code when the HC390 decade counter have been added, so it's still available at the corresponding pin, though unused.
The Atmel isn't doing anything than configuring the GPS module and monitoring the "stability" of the PLL phase comparator output to identify a lock (ad signal it via the LED). Pretty lazy life i'ld say...
-
Not sure about that.
Check the pictures from post #60
In the 2019 PCB version pin 2 connection + resistor r33 isn't there..
In my 2020 Version its added again. And they advertised it as e-GPSDO which should be more accurate than the PLL gpsdo (never proved this marketing. But seller said slightly other bom and Software to be Mord accurate.)
How is the stability monitored? Its measuring the voltage and looks for what? Voltage drifts/hops?
Maybe they are measuring frequency with pin2 and then they are switching analog input into gpio / pwm and manipulating the compator output voltage to regulate it or something else? -
You're probably right with your assumption regarding pin2. It seems, the output of the frequency divider is fed there. But I don't think it's meant for frequency measurement (which would require the MCU's oscillator to be more stable than the OVCXO). If the GPS 1kHz signal is also supplied to the the Atmel somewhere, the phase walk between the two signals could be measured, and this will probably be a more accurate means to identify the "Locked" condition than looking at the A/D-converted phase comparator filter output. If the GPS-supplied 1kHz signal isn't found at the Atmel, I'm running out of ideas...
-
There comes no signal except the uart from the GPS Module.
Could it be that the pin they use:
"XCK/T0 – Port D, Bit 4
XCK, USART external clock.
T0, Timer/Counter0 counter source."
Counter/Timer or are they using the NMEA Stream on the UART to measure the phase drift? I'm not sure how often / time synchronized the NMEA message is sent from the module. But the Pin which they are using with the 1kHz input can be used as USART Clk? Any dirty hacks possible with this relation?
UART NMEA Stream <-> OCXO 1kHz?
NMEA Updaterate / 1kHz Clk in? or something?
Maybe the Atmel isn't checking NMEA messages and only the time / sync from package arrival and 1kHz Clk? -
I got a second one of these from the same eBay seller (haynswor12). It is the same as the first, with an Altera inside. One of the fails on this design is the serial output connector. It is a stereo jack but puts the RX signal on both the tip and center connector. If you plug in a mono plug, the RX shorts to ground. You have to put the mono plug in only part way for it to work. Also the output is inverted. I decided to fix these two deficiencies.
First try at fixing the jack was cuting the PCB trace between the tip and center on the top side of the jack, and lifting the bottom side center tab off the pad (d_1.jpg). Turns out that didn't work. There must also be a trace between the two center pads underneath the jack. So I also lifted the top center pad (d_2.jpg).
Then I put a second inverter on the RX output line. Q1 is the first interter that was on the board. The GPS RX signal comes to the base through R3. The collector is pulled high to 5V, and the output goes to a via to the top side of the board. I cut the trace between the collector and the via. I scraped a ground pad, and put a NPN (3904) with emitter on the ground pad, collector on the via. I put a 5.1k from collector to 5V. Connected the base to the output of the first inverter (collector of Q1) though a 27k.
Antenna that came with this one looks identical to the first, but it isn't magnetic (first one was). This one had double sided tape pads on it. Says 3-5V. The unit puts 5V on the antenna.
Does anyone know what battery goes on these? Both mine have that missing on the board. Labeled BAT1 on top side.
-
Its inverted to be "RS232" instead of UART
-
Its inverted to be "RS232" instead of UART
+1
Works straight with an off-the-shelf (DB9F) RS232->USB converter (at least with the "original" units).
I'm surprised the manufacturer meanwhile already uses badly dinged/dented oscillators. The early ones had been sold with oscillator modules in decent shape, though the labels had been removed. But installing a module with a can like this, even though you may obseve some "jerks" from the output, tells stories about the standards of this particular manufacturer / reseller.
Take care where you buy this GPSDO -- I think original BG7TBL units are the better choice. -
Especially the latest 2020 Version where "no Software" is requiered to get the gpsdo working. Huge benefit if something is broken / you want to modify..