Closed emard closed 5 years ago
How about UP time ? It is 20% longer too ? If so I can add a calibration parameter.
It would be great if you could add a parameter to specify a specific date/time to set '73 de IU5HES
Il 04 dic 2016 20:40, "Mauro" notifications@github.com ha scritto:
How about UP time ? It is 20% longer too ? If so I can add a calibration parameter.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/F5OEO/rpitx/issues/52#issuecomment-264725590, or mute the thread https://github.com/notifications/unsubscribe-auth/ABrFIXYSL_1p5x1FRPY42DIlZQtQNEpzks5rExcjgaJpZM4LARHL .
Hope that dev branch commit solve this timing issue.
Hey thanx I can dust off my setup and try again with the fresh update!
On 5/17/17, F5OEO notifications@github.com wrote:
Hope that dev branch commit solve this timing issue.
-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/F5OEO/rpitx/issues/52#issuecomment-302085365
On rpi2 and rpi3 I have problem with setTime.py
I connected GPIO18-GND to series resonant LC antenna, Carrier is great, 77.5 kHz precise to 4 decimals, and can be cleanly received by the clock few meters away.
the DCF time binary message is correct but the bits transmitted have wrong timing.
everything is slowed down by about 20% so the time distance between 2 adjacent 1-second bits (pulses) actually last about 1.2 seconds, short pause 120ms is too long (should be 100ms), long pause 240ms is too long, so receiver clock won't accept it
Should I somehow use dt-blob.bin? (77.5 kHz transmitter uses 19.2 MHz base, I understood the blob matters for high frequencies which need clock base 1 GHz)
Any help