danak6jq / ESP32-WSPR

Complete stand-alone WSPR2 transmitter using ESP32 + Si5351 modules. Uses SNTP for transmit time-sync
GNU General Public License v3.0
26 stars 10 forks source link

Support ESP-IDF v5 (was Project uses Makefile instead of CMake, which is no longer supported in ESP-IDF) #1

Closed tymarbut closed 2 years ago

tymarbut commented 2 years ago

I've been trying and trying to create a CMakeLists.txt file that will allow a current version of ESP-IDF (v5.0) to compile this project, but have had no luck. However, I really have very little idea what I'm doing, having never converted a Makefile to a CMakeLists.txt before.

The issue is that ESP-IDF now uses CMake exclusively, so there's no way to compile this project without modification (which I haven't been able to do successfully). I'd like to work on some of the wishlist items, like bandhopping and GPIO selection of lowpass filters, but obviously can't do that if I can't compile.

Does Dana, or anyone else, know how to update this project so that it can be built by ESP-IDF v5.0?

danak6jq commented 2 years ago

I'll take a look at evolving to ESP-IDF v5.

danak6jq commented 2 years ago

@tymarbut it doesn't seem there's a release/v5.0 yet - are you asking for support on master?

origin/HEAD -> origin/master origin/audio/stack_on_psram_v3.3 origin/ble_mesh_release/esp-ble-mesh-v0.6.1 origin/customer/11kv_v4.0_xiaomi origin/customer/maintain_v4.0_xiaomi_tsf_issue origin/customer/maintain_xiaomi_11kv_v4.0.2 origin/feature/ftm_support origin/feature/mbedtls_3_0_integration_preview origin/ftm origin/master origin/release/v2.0 origin/release/v2.1 origin/release/v3.0 origin/release/v3.1 origin/release/v3.2 origin/release/v3.3 origin/release/v4.0 origin/release/v4.1 origin/release/v4.2 origin/release/v4.3 origin/release/v4.4

danak6jq commented 2 years ago

I added the necessary CMakeLists.txt files, did a build with master branch of ESP-IDF. Of course I got some warnings about deprecated library interfaces, as well as some warnings about a switch() fall-through that aren't new.

@tymarbut I suggest you do a pull and see if this builds for you now, and let me know if I works - I don't have the hardware available to test it :-)

danak6jq commented 2 years ago

BTW this explains pretty well how to create CMakeLists.txt files as needed. The ESP-IDF examples are also instructive.

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/build-system.html#example-project

tymarbut commented 2 years ago

BTW this explains pretty well how to create CMakeLists.txt files as needed. The ESP-IDF examples are also instructive.

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/build-system.html#example-project

Excellent - thank you very much for taking a look at this. I will try building and flashing and report the results. Very excited to get a little beacon going and then start working on the bandhopping, etc.

tymarbut commented 2 years ago

@danak6jq thanks again - this CMakeLists.txt fix did make it possible to compile! I was able to get it most of the way working. However, I did need to make some changes, so I thought I'd report on my current status:

First, I kept getting errors about the I2C connection, having something to do with the clock speeds and/or flags. After a bit of research about this issue, I was finally able to resolve that and get the I2C to operate correctly by adding the following:

conf.clk_flags = 0;

That went on line 232 of user_main.c, directly after conf.master.clk_speed = 400000;

It would then connect to wifi, do the SNTP, and claim to be transmitting; however, I could never hear it transmit (monitoring with another radio).

So finally today I had a long shot idea: what if some underlying library had changed, so that you now give the Si5351 and/or its library the frequency in hertz, not in hundredths of hertz? So I replaced this:

static uint64_t txFreq = (7038600 + 1500 - 14) * 100;

with this:

static uint64_t txFreq = 7040086;

...which I just simplified to one number for testing, rather than writing it all out. But importantly, it evaluates to 1/100 the value of the number that used to be used.

And bingo! I heard it transmit in the next cycle, on the correct frequency, for the first time! However, now I need to go dive into wspr.c and/or si5351.c and figure out where it modulates up and down in hundreds of frequency units, and change it to 1/100 what it was, because the signal is obviously like a WSPR signal, but spread out way too wide - more like somebody playing an electric organ with one finger than like WSPR that shifts almost indiscernibly up and down.

I'll report back on what I change to make it work, I'm honestly not proficient with GitHub (pulling, forking, and all of that), but if it does work, I'll share the change to be integrated with your existing program. Whatever it is, I'm pretty sure it's just going to be 2 or 3 lines. Thanks again for taking a look and getting me moving again!

danak6jq commented 2 years ago

@tymarbut well that's odd, I don't recall changing the library code - but the proof is in the pudding. Now I might have to lash-up the hardware and revisit this. Thank you so much for taking the time do this!