Which 'Pico' to host Rev2.0 board?

[mungewell]

I'd like to redesign the rev2.0 Pico-Timecode board to be as cost efficient as possible, so am reviewing Picos.... I could lay out a complete design with RP2040/RP2350, but that would make the build more difficult for others (and I don't think I want to be a manufacturer with all that entails).

There are the following, which are almost identical:
https://shop.pimoroni.com/products/tiny-2350?variant=42092638699603
https://shop.pimoroni.com/products/tiny-2040?variant=39560012300371
https://www.waveshare.com/product/rp2040-tiny.htm
https://www.waveshare.com/product/rp2040-zero.htm

The WaveShare have an extra pin per side, and the PiMoroni have the extra ground which would pull GPIO15 low on the WaveShare. Both differences seem workable.

18mm x 25mm is tiny!

That said the 'one connector' layout of the Rev1 board is about this size, though the PCB could be longer than the Pico's. We'd probably want to add battery charging, buttons and OLED connector to the mix.

Note: I've put out some suggestions for manufacturers to do custom/limited builds with XTCO (rather than XTAL). Anyone want to work with me on this?

[xiaopeng12138]

Personally, I prefer the one from WaveShare because it's more likely to be found here in Germany and you can also get it at aliexpress for a pretty cheap price. It costs about 1.49 Euro each without shipping if you buy 3.

I'm wondering if it's possible to use an external RTC? I think an external clock would be more accessible to more people. Something like the DS3231 seems pretty good, and there's also some time code project based on it.

https://github.com/mitkunz/diy_timecode_generator
https://github.com/lydasia/openltc

[mungewell]

I did some experimental layouts, and it appears that the Tiny footprint can fit 'inside' the regular Pico, with one side sharing pins...

This means that a single board could support either (one or the other).

[mungewell]

@xiaopeng12138 I don't see the use/purpose of the RTC, wall-clock time has no connection with the TC that would be used in production. Actually value of TC is irrelevant, only that all devices have the same and that it counts forward at the same time.

By 'calibrating' the Pico's XTAL (or preferable TCXO) the frequency can be match to a few parts-per-billion.

[xiaopeng12138]

@mungewell The RTC I mentioned uses TCXO, it's pretty accurate at +-3.5 ppm. I'm wondering if it's possible to use the clock from the DS3231 to calibrate the pico. (DS3231 costs only about 1€ - 3€ depending on where you get it.)

[xiaopeng12138]

@mungewell The RTC I mentioned uses TCXO, it's pretty accurate at +-3.5 ppm. I'm wondering if it's possible to use the clock from the DS3231 to calibrate the pico. (DS3231 costs only about 1€ - 3€ depending on where you get it.)

And one of the advantages of the DS3231 is that even if you turn off the pico itself, for example to change the batteries, etc., the timecode will not be lost. It will still be synchronized thanks to the onboard memory and battery.

[mungewell]

@xiaopeng12138 I wrote up how this project functions here:
https://github.com/mungewell/pico-timecode/tree/main/docs

I suppose someone could use a DS3231 to initialize the time, the IC has a square output which can be configured for 1HZ. This could be use as the 'trigger' for the PIO engine 'sync_from_pin'. That would get time domains sync'ed, but not calibrated.

My code doesn't actually know what the current time is (in the moment), The 'current time' is held in the state of the PIO FIFOs. The python code just preloads the bits representing the LTC frame (and header) into the FIFO and the PIOs clock it at the correct rate/time.

For calibration my code use the rate at which LTC frames arrive, and compares this to the rate that it's outputting it's own frames. During calibration it runs a PID controller to make these match, coming up with a 'calibration value' which represent how much adjustment is needed to it's own XTAL/TCXO, This code would have to be completely re-written to figure out calibration from a 1HZ signal, and I'm not even sure that it's possible to do for fractional frame rates (ie 29.97 and 23.98)

For reference; a (random) stock PICO has XTAL which was off in my testing by 1.2ppm, with calibration I could pull this accuracy down to 96ppb.

Code is MIT license, if you want to experiment it would interesting to see how you get on...

[mungewell]

Here's a draft schematic, if anyone cares...
Rev2_draft.pdf

The GPIO will have to be reallocated to suit the smaller Pico's.

[mungewell]

BTW on the topic of syncing to 1Hz output from RTC: for fractional framerates, if DropFrame is enabled then I think that the 1Hz and 1PPS (frame 0) will perfectly align on the hour, and every 10minutes.