richardjkendall / rp2040-freq-counter

Various frequency counter implementations
MIT License
9 stars 1 forks source link

counter update and serial corruption #2

Closed ballistRC closed 1 year ago

ballistRC commented 1 year ago

Hi, I get a strange value for pulseCount of 1256470418, pulseCountSnapshot has the same value. The other thing I noticed is I can't make sence of the serial output. It seems to be sending at 38400 from the DUT to the Debugger but the recovered serial stream looks to be at the wrong baud rate or something along those lines. For the debugger I'm using a PicoDebugger. I would like to try and get this working correctly as like you I have also built up a GPSDO with the same bits as you used in the pics. I actually have the ocxo controlled from the gps using a pll and changing the 1 pps to 1mhz as a reference. I have tried to use the interrupt method but found the same issues as you and it was too unstable to be able to tune with a PID controller, which is why I used the PLL way for now.

richardjkendall commented 1 year ago

Hi @ballistRC

It is a bit hard to work out exactly the issue you are facing.

Are you using the PIO-PPS version?

Could you share a circuit diagram?

The default baud rate used is 115200.

ballistRC commented 1 year ago

Yes, pio-pps. I have the PPS pulse connected to pin 15nd Fo to measure on pin 2. I built up your circuit using pin info in main.c. I mesured the serial output to the debugger with a CRO and it looks more like 38400, around 25us per bit. I tried to monitor it directly with a serial/usb adaptor but it was still rubbish, regardless of the baud rate. I'm not worried by the LCD, its a standard 1602 display but I'm not sure on the controller chip, I;ve not used these displays in the past but had it sitting around, I have a tft for my project. I'm building a GPS locked signal generator based on an ad9910. The gps code is complete, DDS code was running but I need to merge. I ran into the same issues with large spikes due to irq actions so I went looking for a pio solution to see if that would be good enough for the PID controller as I couldn't stablize the loop using the information from the irq based system. For now, I'm using a PLL to lock the ocxo, looks like the same you are using. I'm trying basically to get your version working before I integrate into my other code. I'm using 2 Picos, 1 with my IRQ code as a reference with clk on pin 15 and pps on pin 14 to use the timer, the pico has your code with your pins with a lcd display.

BR tony

ballistRC commented 1 year ago

Update, I got the LCD working by adding the a couple of additional wires :-) I have the signal going in on pin 15 and the 1pps on pin2. With this config the display is looks to be updating every approx 10ms with the serial comms led lite most of the time. I tried swapping pin2 and 15 which resulted in a very slow screen update(you could see digits updating 1 at a time) and Fo measurement was o or way off. I think maybe the 2 SMs are starting out of order.

br tony

ballistRC commented 1 year ago

Ok got it fixed. Seems the pulse width of the of my 1pps was too wide at 200ms. Things started to work correctly when I changed it to 100ms. I tired running it at both 125mhz and 250mhz that you have set up. Seems to work on either clock. The only thing now is that is seems to be measuring 10hz high.

BR tony

ballistRC commented 1 year ago

ok breadboard issue, reconnected pll reference and all ok now. The average varies but averages about 0.4hz high. most spot frequencies are spot on but there is an over or under count every few seconds. I run a different averager which is both a lost longer and is smoothed. That usually is good to 0.00n but peaks at +/-5. There seems to be some time slippage every now and then as seen by -935961562 10000001 10000000.300000 953 241406 -945961562 10000000 10000000.200000 954 241656 -955961563 10000001 10000000.300000 955 241906 -965961564 10000001 10000000.400000 956 242156 -975961567 10000003 10000000.700000 957 242406 -985961567 10000000 10000000.700000 958 242656 -995961567 10000000 10000000.600000 959 242906 -1005961568 10000001 10000000.700000 The ocxo is locked to the other gps reference which I have set to 1MHz. I divide that down to 1pps using a bunch of 74ac390 dividers then divide the ocxo by 10 and feed those into a 74lv4046.

I'm thinking a bit out loud but I noticed with the irq method I have, if the 1pps is not phase coherent with the 10Mhz( ie not derived from it) I get a lot of spurious readings. I guess the same is happening with the pio-pps version but to a lesser extent. I need to fix my counter chain to give out a 100ms pulse, not 200ms as it does now. I modified counter.pio and moved the wait 0 to after push like this: .program counter mov x !null ; setup initial value main: ; wait 0 pin 0 ; wait for low if high wait 1 pin 0 ; wait for high jmp x-- next ; decrement counter next: mov isr x push noblock wait 0 pin 0 ; wait here for low. jmp main Results are better a little: 546 384779 477299132 10000000 10000000.000000 4547 385779 467299132 10000000 10000000.000000 4548 386779 457299128 10000004 10000000.400000 4549 387779 447299132 9999996 10000000.000000 4550 388779 437299128 10000004 10000000.400000 4551 389779 427299132 9999996 9999999.600000 4552 390779 417299132 10000000 10000000.000000 4553 391779 407299132 10000000 10000000.000000

Sorry for the noise.

BR tony