HF wspr and ft8 beacon

[krun0x]

Hi,
i am trying to use this fw as test beacon for wspr and ft8 modes.

First ...is it normal that i must adjust TIME_SYNC_OFFSET_SECONDS.
i am using only CW, FT8 and WSPR and i must set this to 18 to get wspr signal synchronized.

Second..FT8 signal is not ok. it looks like letter E, like empty frames.
https://disk.yandex.com/i/_0Rudej_df52Wg
did anyone tried HF emissions with this sonde and have some experience and idea what could be wrong ?

thank you,

kruno 9A3SWO

[Arm-D]

I got WSPR somehow working, all other modes are switched off. So no experience with FT8 and other.

Same issue here with time synchronisation. I confirm TIME_SYNC_OFFSET_SECONDS must be set to 18 in config.h, then it works.
Not sure if this is intended by the author, because I find no info in the source code about that specific setting.

The WSPR transmissions do not happen in every 120s period. Some periods are skipped, so far I found no clear pattern.
So this may be a bug.

[iz2fly]

I tried the WSPR mode in 144 MHz and almost everything works, the period seems right to me of 120", every now and then, about 5%, the transmission is skipped. I confirm 18" offset.
My computer's time needs to be updated often.

[mikaelnousiainen]

@Arm-D @iz2fly Support for taking into account leap seconds is now in the codebase. Please pull the latest changes (and remove your manual 18-second time offset) to test this!

[mikaelnousiainen]

@Arm-D @iz2fly The time offset is because of leap seconds (which the raw GPS time does not include). That will be fixed soon: #34

Skipping of transmissions might be a bug -- but do you have a solid GPS lock -> clear skies above the sonde? If there is no good GPS lock, the time the GPS chip reports is not always reported correctly (it gets "stuck" and skips seconds)

[mikaelnousiainen]

Support for taking into account leap seconds is now in the codebase.

[Arm-D]

Thank you for the hint with leap seconds. This is now clear to me. However there will probably be more leap seconds in the future, so this workaround may not last very long.
Please be aware that the code you have uploaded has an error. The leap seconds must be subtracted not added to get the timing right.
I have changed this in my local code and now it works fine.
About the skipped transmission periods, I will investgate further. GPS reception seems to be stable, the green LED is always flashing slow. Nevertheless WSJT receiving stations report time differences from 0 up to 2.1s for my signal. I guess there is still a timing issue that causes some transmissions do not start at all.
Thank you so much for the great work you are doing.

[mikaelnousiainen]

@Arm-D Thank you for the feedback! I will fix the leap seconds calculation soon too.

Any additional testing is welcome.

If you are able to enable debug logging and semihosting (see README) with GDB, you can get a lot more text output about GPS time and detection of the transmission schedule.

The log would potentially reveal what is happening.

[mikaelnousiainen]

@Arm-D The leap second calculation is fixed now. I also added more detailed docs about the time sync feature in the README file.

And yes, it is true that a hard-coded leap seconds number needs to be updated at times, but looking at the history of leap seconds here https://timetoolsltd.com/gps/what-is-gps-time/ it seems to happen every couple of years.

As an automatic workaround, we could add leap seconds handling with GPS, as there is a separate piece of information transmitted every 10 minutes by the GPS satellites about the number of leap seconds to apply to GPS time, but that's a more involved task... for now hard-coding the leap seconds should be enough for almost all uses cases (assuming one does not try to fly this firmware for weeks/months, possibly going over a leap second boundary :D)