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

Tone spacing and frequency scaling error + only FT8 working on 2m/6m #32

Open
jrhilton opened this issue Jun 23, 2024 · 1 comment
Open

Comments

@jrhilton
Copy link

I have managed to get FT8 on 2m/6m to work but I have to have FT8_TONE_SPACING as 62.5 instead of 625, and FT8_DEFAULT_FREQ set to 14417400UL if I want 144.174mhz as an example.

It seems the scaling in both is off for some reason. No issues using any other Si5351A examples I find on the internet, including GPS frequency corrected versions using 2.5mhz output etc.

Also all the other modes don't seem to work, I can see the signal looks ok on the waterfall on the receiver, but I suspect the timing or frequency spacing is not quite right and I assume it must be related to the scaling issue above.

I'm using an Arduino Uno, and the only modifications are setting the mode and having to change the scaling factor and frequency - has anyone seen this issue too or have any ideas for troubleshooting?

@jrhilton
Copy link
Author

I've finally had some time to test further and have identified a solution for anyone else wanting to use this on 2m.

There are two issues, first using the following does not work as there is an overflow and it mucks up the tone spacing too:
#define FT8_DEFAULT_FREQ 144075000UL

Therefor I modified this as follows:
si5351.set_freq((freq * 100) + (tx_buffer[i] * tone_spacing), SI5351_CLK0);

to this (manually setting the frequency):
uint64_t target_frequency = 14448000000ULL;

and

si5351.set_freq((target_frequency) + (tx_buffer[i] * tone_spacing), SI5351_CLK0);

Secondly, when you use frequency >around 80mhz the time it takes to set the frequency seems to go up a bit. Therefor I had to reduce the delay as follows so the message length overall was still correct and as expected by say WSJT-X:

FT8_DELAY needs to be 156 (instead of 159)
JT65_DELAY needs to be 362 (instead of 371)

As an example using a shorter delay of 156 for FT8 results in a message length of 12.494s vs 12.64s per the mode specs.

And using 362 for JT65 results in a message length of 46.708s vs 46.7s per the mode specs.

Hope this is helpful to anyone else wanting to use it on 2m.

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

1 participant