Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Which 'Pico' to host Rev2.0 board? #16

Open
mungewell opened this issue Nov 13, 2024 · 8 comments
Open

Which 'Pico' to host Rev2.0 board? #16

mungewell opened this issue Nov 13, 2024 · 8 comments

Comments

@mungewell
Copy link
Owner

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
Copy link

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
Copy link
Owner Author

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

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

@mungewell
Copy link
Owner Author

@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
Copy link

@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
Copy link

xiaopeng12138 commented Nov 18, 2024

@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
Copy link
Owner Author

mungewell commented Nov 18, 2024

@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
Copy link
Owner Author

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
Copy link
Owner Author

mungewell commented Dec 3, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants