Recent Posts

[Country]

Country	Italy
Note	I do develop in c small applications for microcontrollers

Hi, I've designed a Isolated USB to dual serial converter for my field usage. This circuit is designed and tested to withstand higher surge level. If anyone interested, please take the circuit diagram.

[Country]

Country	India
Note	Working as Junior Engineer R and D in Xtend Technologies Pvt Ltd. I have 2.5 years experience in Pic microcontroller(8bit and 32bit) and PCB designing.

Yes, I think I was hitting the limits of breadboarding with the 20-bit DAC and TIC method; just too many criss-crossing wires carrying 10MHz clocks and fast rise time pulses. I was getting hit with too many random bugs and glitches to be able to actually develop the thing. I'm sure the method would work well if I had a PCB made for it, or laid it out much more neatly.

Although, as I later found out, those dodgy Chinese level converters were messing things up so it could have just been those causing all my problems. That, and the buggy CCS compiler which wasted another couple of troubleshooting hours.

Wow, I have enough trouble getting a circuit on one breadboard working (and never reliably).

Compliments for a nicely executed job. Your PCB looks very neat
And yes , you learn much more when you do it on your own !

(I accidentally edited this and mucked it up, trying to put it back...)

An update to my GPSDO, delayed due to life, drunkenness and girls. Not so many of the latter unfortunately. (Duck's out of way of wife reading over shoulder)

After extensive testing of the dsPIC's CTMU, I've decided it's rubbish. It looks really useful but is let down by sever instability and erratic behaviour.

I set up a carefully wired signal delay line to it, with a stable 50ns delay. I had already measured the CTMU's minimum switching time as 4ns, and it supposedly has a resolution of <1ns. The dsPIC has a massive offset from zero (not mentioned in the fine documents, possibly charge injection?) which is so unpredictable as to make it almost useless. On successive reboots, the offset varied randomly from 20 to 290, on a 10-bit reading! I gave it up as a bad job.

I've been through a number of options on my breadboard, including a 20-bit DAC and MCU control of the OCXO voltage instead of the basic PLL, and even a two-step software method of FLL followed by PLL using a TI TIC chip and the DAC. I felt it offered little benefit over the basic PLL method other than the novelty factor.

Back to the old-fashioned PLL it is.

Right now it's been running for 24 hours. The frequency is long-term stable at 1ppt. Any short-term variation is below my capability to measure. My DMM shows the voltage to the OCXO is stable within 50uV. That's less than 1/3 of a millihertz. I think I can live with that.

Best of all, I've used the TIC chip to lock my derived PPS (DPPS) to the centre of the GPS's jittery PPS. That gives me a low jitter (the OCXO jitter +a few ps) second pulse aligned to within 250ps of the 'real' second start used by the GPS system. Just in case I want to coordinate lightning strikes or earthquakes, or something. Well, you never know.

The TI TDC7200 TIC (Time Interval Counter) chip is great. It has a resolution of 55ps and a minimum measurement time of 12ns, up to 8ms. I'm using a Maxim DS1023 500ps step delay line to adjust the phase of the DPPS, once I've measured it with the TIC.

I've implemented a Kalman filter on the TIC measurements. The longer it runs, the more accurate it gets but it's pretty good after 30 minutes or so. That compliments the whole thing as I've plotted changes and the whole system takes about that long to fully stabilize from cold. I would say it's usable, within 1ppb and a few ns for the DPPS, within ten minutes though.

Here are some pictures of the breadboard layout tonight. I'm continually amazed that it works at all, like this. Oh, and the "Dodgy Chinese level converters" caused no end of trouble, that I finally realized was them causing signal integrity problems. some resistors cured that.

ETA: I forgot, I found another nasty bug in CCS: When using spi_xfer, it would suddenly (after working for a while) decide to stop sending the three bytes it was given and told to send, and only send two of them from then on. Took me ages to spot that, wondering why my DAC was suddenly not working as expected.

One more small detail I forgot to add: The "DPPS Divider" is another PIC, a 16F18313. Those are quite remarkable little things, 8-pin chips packed full of peripherals and cheaper than a couple of logic gates. Great for 'little' jobs.

It divides down a 10MHz clock generated by the dsPIC's PWM to 1Hz. The dsPIC can control that clock in 10ns steps by tweaking the PWM phase cycle by cycle, thus I can move the DPPS phase in 10ns steps for a coarse adjustment. The little PIC also has a built-in sync to the PPS to bring it within adjustability and measuring range to begin with.

When the DPPS is 100ns leading the PPS, I then take over with the TIC, Kalman filtering and Maxim delay line. That allows user-controlled adjustment of DPPS lead in 500ps steps from 100ns leading up to dead-on, or a bit past if I want. It can accounts for cable delay and logic propagation delay to other kit.

[Country]

Country	Italy
Note	Hi thanks for you invitation a register to site

yes that is right. it is a 47pF

What you can do is to measure the voltage over the current sense resistor as the this voltage will have a linear relationship with the output current. But you have to ground reference this voltage and apply some gain to this volage so it fit your ADC range. If you look at the datasheet for LM324 http://www.ti.com/lit/ds/symlink/lm324-n.pdf  
You can use figure 32 or 38 for this. Any single supply OPAMP can do the job here as long as you stay inide the input Common-Mode Voltage Range given in the datasheet and of course also the supply volage. That will be the same as IC1 and IC4 use. If you want to measure the negative rail with the same micro controller this voltage will need to be inverted